Variable mapping for migration

In migration, some variables map directly from previous product versions to Automation 360 while others behave differently or contain configuration changes.

Note: In Enterprise 11, if a bot used a variable that was followed by a space and a string that began with a dollar sign character ($) and enclosed in parentheses, brackets, or braces, after migration, the variable field encounters an error. The error occurs because, in Automation 360, two dollar sign characters ($) are required in a string to display the dollar sign. To fix this error, add another dollar sign to the string. For example, if you are using the prompt-assignment variable to display a string followed by $5 [$Prompt-Assignment$ ($5)], after migration, the variable field displays an error. To fix the error, edit the variable field to add another dollar sign, as follows: [$Prompt-Assignment$ ($5)].

User-defined variables

In Automation 360, all variables defined in bots are created as Use as input and Use as output types during migration to exchange values between parent bots and child bots.

If variables are mapped between a parent bot and a child bot in Enterprise 11 and some of the mapped variables are not available in either the parent bot or the child bot, the migration process removes these variables. The migration process removes such variables for child bots that are migrated along with the parent bots and for child bots that are already migrated.

For information about the list of variables supported, see Variables support.

Review how the following user-defined variables are migrated.

Array

This section explains how Array variable is migrated to Automation 360. In some cases, you might have to perform some actions or ensure a few things before or after migration.

Subtype "Value"
Variables with this subtype are migrated to Table with all column values as String.
Subtype "Read from text file"
Variables with this subtype are migrated to Table with all column values as String.

The following actions are added as part of migration to configure data in the variable:

Automation 360 actions Function
CSV/TXT > Open Opens the file for reading.
CSV/TXT > Read Returns the value in the Table variable.
CSV/TXT > Close Closes the file.
Subtype "Read from database"
Variables with this subtype are migrated to the Table package with all column values as String.

The following actions are added as part of migration to configure data in the variable:

Automation 360 actions Function
Database > Connect Adds the Connect action with the respective connection string.
Database > Export to datatable Adds the Export to datatable action to return the results to the datatable variable.
Database > Disconnect Adds the Disconnect action to disconnect the database.

See also: Database package.

Subtype "Read from Excel/CSV file"
Variables with this subtype are migrated to Table with all column values as String.

The following actions are added as part of migration to configure data in the variable:

Automation 360 actions Function
Advance Excel > Open Opens the file for reading.
Advance Excel > Get multiple cells Returns the Table variable value if the All Cells or Range option is chosen in the variable declaration.
Advance Excel > Read now Returns the Table variable value if the Entire Row option is chosen in the variable declaration.
Advance Excel > Read column Returns the Table variable if the Entire Column option is chosen in the variable declaration.

Additionally, the Assign list to datatable of list package is used to store the returned valued to the variable.
Advance Excel > Close Closes the file.
Important: In Automation 360, an empty table variable returns a runtime error. If your migrated bot contains an empty table variable, you must resolve the issue in Automation 360.
Array variable: Input types accepted by DLL function
When the system passes an Array variable from an Enterprise 11 bot to a DLL function of a different type, the DLL function accepts the following as input types:
  • UInt16[], Int16[], Int32[], Int64[], Int[], Char[], Single[], Decimal[], Float[], Double[], Boolean[], bool[], Byte[], String[], and Datetime[]
  • UInt16, Int16, Int32, Int64, Int, Char, Single, Decimal, Float, Double, Boolean, bool, Byte, String, and Datetime
  • List<UInt16>, List<Int16>, List<Int32>, List<Int64>, List<Int>, List<Char>, List<Single>, List<Decimal>, List<Float>, List<Double>List<Boolean>, List<bool>, List<Byte>, List<String>, List<Date-Time>
  • UInt16[,], Int16[,], Int32[,], Int64[,], Int[,], Char[,], Single[,], Decimal[,], Float[,], Double[,], Boolean[,], bool[,], Byte[,], String[,], and Datetime[,]
More information
You can migrate your Enterprise 10 or Enterprise 11 bots that include Array variables.

The following are some key behavior differences:

  • The index position starts with 1 in Enterprise 10 and Enterprise 11, while the index position starts with 0 in Automation 360. For example, $arrayVariable(1,1)$ becomes $arrayVariable[0][0]$
  • If an array has 10 rows/columns and a loop is running more than 10 times, then Enterprise 10/Enterprise 11 returns the name of the array variable with the index position.
  • In Enterprise 11, if you pass a constant string value to an array index in any command (for example $array(field1), where field1 is not a variable), the value is used as is (for example, $array(field1)). However, after the bot is migrated to Automation 360, a compile time error occurs if the command has a non-variable value.
  • In Enterprise 11, if you pass an array variable without any index (for example "$array
    quot;    , "$array()
    quot;    , where index is missing), the value is used as is (for example, "$array
    quot;, "$array()
    quot;    ). However, after the bot is migrated to Automation 360, a compile time error occurs.
Important: If an invalid index is used to access any arrays in Enterprise 11, ensure that you resolve the bot error before or after migration.
Dictionary

This section explains how Dictionary variable is migrated to Automation 360. In some cases, you might have to perform some actions or ensure a few things before or after migration.

Run Logic
In Enterprise 11, when you perform a Run Logic operation, you can select a specific key from the Dictionary variable and map it to the required value variable.

In Automation 360, you can only map variables directly and cannot map a Dictionary(key) variable to a string.

Subtype "Value"
The system migrates these variables to the Dictionary type with the String subtype in Automation 360.
Subtype "Read from CSV file"
The migration process adds actions to read the CSV file using the CSV/Text package and stores the data in a table variable. The process also adds actions to perform a loop on the Table variable and uses the Put action of the Dictionary package to add the key and values in the Dictionary variable.
Dictionary variable: Input types accepted by DLL function
When the system passes a dictionary variable from an Enterprise 11 bot to a DLL function of a different type, the DLL function accepts the following as input types: UInt16, Int16, Int32, Int64, Int, Char, Single, Decimal, Float, Double, Boolean, bool, Byte, String, and Datetime.
More information
You can migrate your Enterprise 10 or Enterprise 11 bots that include Dictionary variables.

The following table describes some key behavior differences and how they work in Automation 360:

Enterprise 10 or Enterprise 11 behavior Automation 360 behavior
Dictionary keys are not case-sensitive in Enterprise 10 or Enterprise 11. Dictionary keys are case-sensitive in Automation 360.

To maintain the bot execution resilience, the migration process converts all dictionary keys to lowercase values. String express Lower case is used if a variable is used as a dictionary key to obtain the lowercase key name.
List

This section explains how List is migrated to Automation 360. In some cases, you might have to perform some actions or ensure a few things before or after migration.

Subtype "Value"
These variables are migrated to List with subtype String.
Sub-type Array
These variables are migrated to List with subtype String.
Subtype "Reading from text file"
Where a variable that is declared by reading a file is called, the Import list from text file action of the Legacy automation package is added above the action that is being migrated.
Declared as "Make Random"
The List variable can be declared as Make Random in Enterprise 10 or Enterprise 11 to return a random item from the list. The migration process adds the new Size action to the List package to get the list size and adds the Assign a random number action to the Number package to find the random position and use it to get a random list item.
Important: In Automation 360, an empty list variable used outside a loop returns a runtime error. If your migrated bot meets this criteria, you must resolve the issue in the Automation 360 environment.
More information
  • In Enterprise 10 and Enterprise 11, List is accessible without specifying any index. In Automation 360, you must specify the respective index to retrieve the specific value from the list.

    Example: List variables can be accessed by index in the following way:

    $listVariable[0]$

    Here, 0 represents the first value in the list.

  • Index position starts with 1 in Enterprise 10 or Enterprise 11, whereas it starts with 0 in Automation 360.
  • Enterprise 11 behavior: In Enterprise 11, when a list with a fixed index is used, the system returns the value available in the first index of the list.

    Example: For example, consider that you have a list with values 1, 2, 3, and 4, and you use $IntList(3)$ to retrieve the value in the third index position of the list. The system returns the value available in the first index position of the list (1) instead of the specified index position (3).

    Automation 360 behavior: In Automation 360, the system returns the value available in the specified index position (for the above example, it returns 3).

    Behavior of migrated bots: Enterprise 11 bots that use such expressions with fixed indexes in the list and are migrated to Automation 360 return the value available in the specified index position.

  • If a list has 10 items and a loop is running for more than 10 times, then Enterprise 10 or Enterprise 11 returns the first value of the list after the 10th iteration.
List variable: Input types accepted by DLL function
When the system passes a List variable from an Enterprise 11 bot to a DLL function of a different type, the DLL function accepts the following as input types:
  • UInt16[], Int16[], Int32[], Int64[], Int[], Char[], Single[], Decimal[], Float[], Double[], Boolean[], bool[], Byte[], String[], and Datetime[]
  • UInt16, Int16, Int32, Int64, Int, Char, Single, Decimal, Float, Double, Boolean, bool, Byte, String, and Datetime
  • List<UInt16>, List<Int16>, List<Int32>, List<Int64>, List<Int>, List<Char>, List<Single>, List<Decimal>, List<Float>, List<Double>List<Boolean>, List<bool>, List<Byte>, List<String>, List<Date-Time>
  • UInt16[,], Int16[,], Int32[,], Int64[,], Int[,], Char[,], Single[,], Decimal[,], Float[,], Double[,], Boolean[,], bool[,], Byte[,], String[,], and Datetime[,]

    See also: List package.

Random

This section explains how Random variable is migrated to Automation 360. In some cases, you might have to perform some actions or ensure a few things before or after migration.

Subtype "Random String"
When there is a Random variable of the subtype String, the migration process adds the Generate random string action of the String package to generate a random string above the If condition and assigns the value to the respective migrated variable in Automation 360
Subtype "Random Number"
When there is a Random variable of the subtype Number, the migration process adds the Assign a random number action of the Number package to generate a random string above the If condition and assigns the value to the respective migrated variable in Automation 360.
Value

This section explains how Value is migrated to Automation 360. In some cases, you might have to perform some actions or ensure a few things before or after migration.

Subtype "Value"
These variables are always migrated as String in Automation 360, even if they have number, boolean, or datetime values in them. Expressions are used in Automation 360 to convert a string to other types if required.
Subtype "Read from text file"
To maintain the integrity of bot execution during migration, where a variable that is declared by reading a file is called, the Import string from text file action of the String package is added just above the action being migrated.
If Enterprise 11 bots contain variables that read values from a text file, then these bots are migrated using the Read variable action.

If a specific variable does not exist in the text file, or if the specific variable is reading a value from a file that does not exist, then Automation 360 generates an exception error.

After migration, when you run the bot that contains the Read from file variable, the reading occurs only once in the Read variables action at the start of the bot running process. If the file that the variable is trying to read gets updated while the bot is running, then the Read file variable is not refreshed.

.
More information
Bots that use value type variables within a variable can be migrated to Automation 360. For Enterprise 11 bots that use a variable within a variable in the Insert Keystrokes command, the Evaluate value action of the String package is added in the migrated bot

See also: String package | Number package | Boolean package | Datetime package

System variables

In some cases, system variables such as Error Line Number, Error Description, and OS Name return a different value in Automation 360. Bots using these variables in a decision-making or string operation require a review after migration.

Some system variables used inside a loop are user-defined variables in the loop after migration. In some instances, the user-defined variable might require some configuration in the migrated bot.

Some system variables are migrated as actions in Automation 360. These actions are added just above the action that uses these variables.

If a variable is defined at the index position for the following system variables, you might have to resolve the migrated bots because the migration process could not determine if the variable contains an index or column name. If you do not resolve it, the bot might return a Key not found in record runtime error. The migration process treats the value of a variable as name; but if it is an index, you must change it accordingly.
  • $Filedata Column$
  • $Dataset Column$
  • $XML Data Node$
  • $Excel Column$
The following table provides information about the various system variables and how they are migrated to Automation 360. Some variables are part of actions, some become actions, and some are known as system variables but have syntax changes.
Note: Migrated bots do not preserve data outside of the loop for the following system variables:
  • $FolderName$
  • $FileName$
  • $Extenstion$
System variable How they are migrated to Automation 360
$Day$ Becomes $System:Day.Number:toString$ in Automation 360
$FileName After migration, the system automatically creates this variable according to the Automation 360 naming convention, to run the migrated bots successfully.
$Error Description After migration, the system automatically creates this variable according to the Automation 360 naming convention, to run the migrated bots successfully.
$Error Line Number$ After migration, the system automatically creates this variable according to the Automation 360 naming convention, to run the migrated bots successfully.
$Extension$ After migration, the system automatically creates this variable according to the Automation 360 naming convention, to run the migrated bots successfully.
$Folder Name$ After migration, the system automatically creates this variable according to the Automation 360 naming convention, to run the migrated bots successfully.
$Month$ Becomes $System:Month.Number:toString$ in Automation 360
$Year$ Becomes $System:Year.Number:toString$ in Automation 360
$Date$ Becomes $System:Date$ in Automation 360

The date format set for the variable in the Enterprise 11 or Enterprise 10 bot is stored in the AADefaultDateFormat global value.
$Hour$ Becomes $System:Hour.Number:toString$ in Automation 360
$Minute$ Becomes $System:Minute.Number:toString$ in Automation 360
$Clipboard$ Becomes $System:Clipboard$ in Automation 360
$Machine$ Becomes $System:Machine$ in Automation 360
$MiliSecond$ Becomes $System:MiliSecond.Number:toString$ in Automation 360
$ArrayColumns($arrayVariable$)$ Becomes an expression in Automation 360: $arrayVariable.DataTable:columnCount$
$ArrayRows($arrayVariable$)$ Becomes an expression in Automation 360: $arrayVariable.DataTable:rowCount$
$AAControlRoom$ Becomes $System:AAControlRoom$ in Automation 360
$RAMUsage$ Becomes $System:RAMUsage$ in Automation 360
$TotalRAM$ Becomes $System:TotalRAM$ in Automation 360
$OSName$ Enterprise 10 or Enterprise 11 returns the Microsoft Windows 10 Pro 64-bit value. In Automation 360, this variable becomes $System:OSName$ and returns the Windows 10 64-bit.
$CPUUsage$ Becomes $System:CPUUSage$ in Automation 360
$Counter$ This system variable is deprecated in Automation 360. The migration process creates a user-defined variable type Number and modifies the bot to ensure it provides the same output as the 11.x bot.

If you have used the $Counter$ variable in a loop, the migration process replaces the variable with the $Condition-Counter$ variable in the migrated bot and sets its value to 1.
$Dataset Column$ This system variable is now part of the For each row in a SQL query dataset iterator in Loop. The system creates a new variable in the loop and uses it inside the loop wherever $Dataset Column$ is present.

If the variable is used outside a loop, it is converted to a record type user-defined variable and assigned to a Record action, which enables you to assign the value of the source record variable to the destination record variable. Therefore, when you run migrated bots that contain this variable, data from the last row is displayed.
$Excel Column$ This system variable is now part of the For each row in worksheet iterator in Loop. The system creates a new variable in the loop and uses it inside the loop wherever $Excel Column$ is present.

If the variable is used outside a loop, it is converted to a record type user defined variable and assigned to a Record action, which enables you to assign the value of the source record variable to the destination record variable. Therefore, when you run migrated bots that contain this variable, data from the last row is displayed.
$Extension$ and $FileName$ These system variables were used in the For each file in a folder iterator of Loop. However, in Automation 360, a dictionary type variable is used to capture the extension and file name, which can be retrieved with "extension" and "name" key name respectively.

Loop package.

$Email$

$Email From$

$Email Message$

$Email Received Date$

$Email Received Time$

$Email Subject$

$Email To$

$Email Sent date$

$Email Sent time$

 These system variables were used inside the For each mail in mail box iterator of Loop. In Automation 360, a dictionary type variable is used to capture all email values that can be retrieve with the respective keys.

See Using dictionary variable for email properties.
$Filedata Column$ This system variable is now part of the For each row in CSV/TXT iterator in Loop. The system creates a new variable in the loop and uses it inside the loop wherever $Filedata Column$ is present.

If the variable is used outside a loop, it is converted to a record type user defined variable and assigned to a Record action, which enables you to assign the value of the source record variable to the destination record variable. Therefore, when you run migrated bots that contain this variable, data from the last row is displayed.
$FolderName$ This system variable is used inside the For each folder in a folder iterator of Loop. In Automation 360, the value is returned to the string variable specified in the loop.
$Excel Cell Row$ This system variable is migrated to the Get row number action of the Excel package in Automation 360 and added just above the action in which it is used.

In Enterprise 11, the last executed Excel session is used as a Session Name value in the Excel Cell Row variable. However, in Automation 360, the Excel Cell Row variable is not present. So, the last executed Excel session used before Excel Cell Row is taken as a value for Get row number during migration.

Workaround: Create a string variable, assign a name to it, and add it after the Excel command in the migrated bot. Use the newly created string variable in Get row number.
$Excel Cell Collumn$ This system variable is migrated to the Get column name action of the Excel package in Automation 360 and added just above the action in which it is used.
Enterprise 10/Enterprise 11 returns the first column (for example column A) for the $Excel Cell Column$ even if the active cell is not column A (for example column F10) inside a loop. In Automation 360, the same configuration returns the active cell (for example column F10). Below are the use cases that result in the above behavior change:
  • Excel is opened with or without contains header checked containing 10 rows.
  • Set active cell as F10
  • A loop is performed to row read
  • Put a Message Box with $Excel Cell Column$ in it
  • Run the bot
Important: Considering the behavior differences, you might have to change some bots.
$Excel Cell$ This system variable is migrated to the Get cell address action of the Excel package in Automation 360 and added just above the action in which it is used.
$AATaskExecutor$ This system variable becomes $AATaskExecutor$ and $AATaskInvoker$ in Automation 360.
In Enterprise 11, this variables return various values about the task invoker and executor (for example, the invoker's and executor's first name, last name, email address, and username). In Automation 360, the $AATaskInvoker$ variable returns the following values:
  • Invoker_Username
  • Invoker_Firstname
  • Invoker_Lastname
  • Invoker_Email
The $AATaskExecutor$ variable returns the following values:
  • Executor_Username
  • Executor_Firstname
  • Executor_Lastname
  • Executor_Email
  • Executor_Type
$AATaskName$ This system variable becomes $System.AATaskName$ in Automation 360.

In Enterprise 10/Enterprise 11, this variable returns the value to your computer path directory (for example Automation Anywhere\My Tasks\My Folder\My Folder2\AATaskName.atmx). In Automation 360, in returns the value to the bot path relative to the Control Room (for example Bots/AATaskName).

Action required: Considering the values returned are different between the versions, you might have to change some bots.
$AAApplicationPath$ Enterprise 11 specific: This Enterprise 11 system variable returns the path set by users in the Tool > Option setting of what is known as the “client application”. In Automation 360, the variable becomes a global value. The migration process maps this change automatically and the value set of each user in Enterprise 11 is copied to the global value variable @AAApplicationPath.
Note: No action is required by a user for Enterprise 11 because the system variable is automatically mapped as a global value during migration if you have used the restored Enterprise 11 database when installing Automation 360.

Enterprise 10 specific: This Enterprise 10 system variable does not automatically migrate to Automation 360 as a global value, so some action is required after migration.

Important:
  • Enterprise 10 users must create the AAApplicationPath global value in Automation 360 and update it with the Enterprise 10 path. This update ensures that when you run the bot in Automation 360, the AAApplicationPath folder value is uniquely resolved for each user.

    Example: If the Enterprise 10 path value for AAApplicationPath is D:\John.Doe\My Documents\Automation Anywhere Files, then you must create the AAApplicationPath global value in Automation 360 and update with this path.

  • Ensure that the CAN be changed option is selected when creating the AAApplicationPath global value. Bot Creators and Bot Runners must set the value for the AAAplicationPath global value before they run the migrated bots.

See Global values.
$AAInstallationPath$ This system variable becomes $System:AAInstallationPath$ in Automation 360.

Enterprise 10/Enterprise 11 behavior: Returns the Enterprise Client installation path (for example C:\Program Files (x86)\Automation Anywhere\Enterprise\Client).

Automation 360 behavior: Returns the Bot Agent installation path (for example C:\Program Files\Automation Anywhere\Bot Agent).

Action required: Considering the values returned are different between the versions, you might have to change some bots.
$Current Directory$ This system variable is deprecated in Automation 360 and automatically converted to a user-defined variable during migration. The value of the variable is set per the value defined in Loop > For each file in a folderr and For each folder in a folder.
$Date$ This system variable becomes $System:Date$ in Automation 360.

Enterprise 10 and Enterprise 11 behavior: The $Date$ variable returns the current date and time in a format specified in the AA.Settings.XML file.

Automation 360 behavior: The $System:Date$ variable returns values of type Datetime and users must use an action to change it in to String. To minimize disruption to users, the migration process does the following to each $Date$ instance:

  • Creates a temp variable $SystemDateInString$ of type String.
  • Adds a ToString action of Datetime package to convert $System:Date$ to string with customer format as "MM/dd/yyyy HH:mm:ss" and store the output into above string variable.
  • Uses this string variable where ever $Date$ is used.
  • The above steps are repeated for each occurrence of $Date$.

Depending on how your bot is configured, you might have to update the date/time configuration.

Action required: Change the bot if the date format is not MM/dd/yyyy HH:mm:ss.

$Error Line Number$

$Error Description$

In Enterprise 10 or Enterprise 11, these system variables are used after the Error Handling command. In Automation 360, the value is returned to the user defined variables specified in the Catch action.

$PDFFileName$

$PDFTitle$

$PDFAuthor$

$PDFSubject$

 In Enterprise 10 or Enterprise 11, these system variables were used after any PDF command. In Automation 360, a Dictionary type variable is used to capture all PDF values that can be retrieve with the respective keys. Every PDF action returns this Dictionary variable with corresponding PDF values.

See Using a dictionary variable for PDF properties.
$System$ In Enterprise 11 or Enterprise 10, this system variable is used to retrieve information about a device's settings and its performance. In Automation 360, the Get environment variable action of the System package is used.

See Get environment variable action.
$WorkItem$
  • $WorkItem$ is String: Migrated as is.
  • $WorkItem$ is Number
    • If it is displaying or logging a Number, the number is changed to a String
    • If it is displaying as a Number, migrate as a Number type
  • $WorkItem$ is DateTime: Migrated as is, but the migrated package results in an error, so you cannot migrate the package.
Note: For the DateTime type, you cannot migrate the package yet, so the associated bot must be migrated at another time.
$Trigger Value$ Becomes $TriggerValue$ in Automation 360. For Enterprise 11 bots that use this variable, perform the following tasks to run the migrated bots successfully:
  • Create the equivalent triggers in Automation 360 for all the triggers that were used in Enterprise 11 bots.

    The output of triggers in Automation 360 is stored in a record type variable.

  • Update the migrated bots to use the appropriate actions to assign the values from the record variable that contains output from triggers to the $TriggerValue$ variable.

    For example, if you want to assign a host and port key from the record variable of an email trigger to the $TriggerValue$ variable, use the $EmailTriggerData(host)$EmailTriggerData(port)$ expression. Similarly, to retrieve location of a file use $FileTriggerData(file)$ expression and to retrieve location of a folder use $FolderTriggerData(fromFolder)$ expressions.
$Table Column$ This system variable is now part of the For each row in table iterator in Loop. The system creates a new variable in the loop and uses it inside the loop wherever $Table Column$ is present.

If the variable is used outside a loop, it is converted to a record type user defined variable and assigned to a Record action, which enables you to assign the value of the source record variable to the destination record variable. Therefore, when you run migrated bots that contain this variable, data from the last row is displayed.
$XML Data Node$ This system variable is used inside the For each node in XML dataset iterator of Loop. In Automation 360, the value is returned to the string variable specified in the loop.

If the variable is used outside a loop, it is converted to a string type user defined variable and assigned to a Record action, which enables you to assign the value of the source record variable to the destination record variable. Therefore, when you run migrated bots that contain this variable, data from the last row is displayed.

Credential variables

The credential variables used for the Username and Password fields in Enterprise 10 and Enterprise 11 are migrated as Credential variables in Automation 360.

The method of migration differs for Enterprise 10 and Enterprise 11.

To learn how Enterprise 10 credentials are migrated, see the section on credentials in How Enterprise 10 data is copied to Automation 360.

The credential variables used in fields other than the Username and Password fields are migrated as Global Values. These fields include hostname, port number, and so on. The migrated global values have the following syntax: <credentialname>_<attributename>. For example in Enterprise 11, a credential FTPConnection with an attribute hostname is migrated as FTPConnection_hostname.

The following table provides information about the packages and actions that support the migration of credential variables from Enterprise 11 to Automation 360:

Package Actions
Active Directory
  • Create and Modify User
  • Create and Modify Group
  • Create and Modify Object
  • Search
  • Get Property
Database
  • Connect with connection string
  • Username
  • Password
Email Automation
  • Hostname
  • Username
  • Password
Excel Open Spreadsheet
FTP / SFTP Connect
Insert Keystrokes All keystrokes that require use of credentials
Legacy Automation Set Text in Manage Web Controls action
Manage Window Controls
  • Set Text
  • Append Text
PDF
  • PDF to Image
  • Extract Form Fields
  • Extract Text
  • Split, Encrypt, and Decrypt Document
PGP
  • Encrypt and Decrypt Files
  • Create Keys
Recorder
  • Set Text
  • Append Text
Note: Migrated from Object Cloning command as Capture action.
REST Web Service
  • URI
  • Username
  • Password
  • Headers
  • Operation parameters
Note: Domain name is migrated as a global value.
SOAP Web Service
  • Username
  • Password
  • Headers
  • Operation parameters
  • Raw data parameters
Terminal Emulator
  • Connect command for SSH2 with User and Key file authentication options
  • Send Text
  • Set Field
Web Recorder Manage Web Controls with Set Text and Append Text functions