Almost every executable object includes a Variables & Prompts page. On the Variables sub page you enter the variables to be used in the Process pages and the attributes. On the Prompt Sets sub page you assign PromptSet objects whose variables are also available for the object. Variables do not have to be read but can be used directly as script variables.
Object and PromptSet variables are available in all Process pages and the object attributes.
The following illustration shows the object variable &HOST#.
This variable can immediately be used in the script. The following example uses the object variable to terminate the agent.
: IF SYS_HOST_ALIVE ( &HOST# ) = "N"
: SEND_MSG "ADMIN","AE","Agent &HOST# is not active!"
:ENDIF
The values of object variables can be specified with or without quotation marks. If you use single quotation marks, an individual quote within the string must appear twice, as otherwise one or more characters may be removed. You can also use double quotation marks. They are always handled as normal characters and are not removed.
Examples
|
Variables & Prompts Tab Entry |
Actual Value |
|---|---|
|
string 1234 |
string1234 |
|
'string1234' |
string1234 |
|
"string1234" |
"string1234" |
|
string'1234 |
string'1234 |
| 'string'1234' | string |
| 'string''1234' | string'1234 |
There is another special feature that applies to object and PromptSet variables. They can be inherited from superordinate objects. The tasks in a Schedule object can use the PromptSet variables of the schedule. This simplifies the maintenance process because it is not necessary to store the values in the individual objects.
Use the Variables & Prompts page to specify whether object variables should be inherited, and if so, which ones.
|
Field/Control |
Description |
|---|---|
|
Inherit from parent |
|
|
All values (default) |
The object obtains all the object and PromptSet variables of the superordinate task. |
|
Only defined values |
The object only obtains the object and PromptSet variables that are defined in the Variables & Prompts page of the superordinate task. |
|
No values |
The object does not obtain object and PromptSet variables of the superordinate task. |
The values of objects that are activated using ACTIVATE_UC_OBJECT and the parameter PASS_VALUES are inherited regardless of the setting "Inherit from parent".
PromptSet and object variables are not inherited if the subordinate task includes a PromptSet variable of the same name regardless of the setting "Inherit from parent".
Note that inherited object and PromptSet variables overwrite existing object variables if they have the same name. PromptSet variables are never overridden.
Overwriting PromptSet Variables with the Value of a Parent Variable
Open the task's workflow or schedule properties and switch to the Variables & Promts page tab. Select the PromptSet area and use the parent's variable name as the value of the relevant PromptSet element. If the particular PromptSet element is not a text field, click its labeling.
The setting "Inherit from parent" significantly affects all the object's subordinate tasks. Values are directly passed on from a task to its subordinate task. If it has been specified in an object that no values or only defined ones should be inherited, a task's subordinate tasks cannot access all object variables of "grand parent objects". The effects are shown in the examples below.
Object and PromptSet variables are passed on to:
- Workflow tasks
- Schedule tasks
- Tasks that are started with ACTIVATE_UC_OBJECT using the PASS_VALUES parameter
- Child post processes of Remote Task Manager objects
- !Process in Event objects
- Tasks that start from within the object
The last bullet point could be an object that has been defined in the Result tab in the properties of a workflow task.
Variables are not passed to:
- Tasks of a group
- Tasks that were started manually
- Objects that were started by the AE system
The last bullet point could be a notification that starts automatically (warning) before a calendar's validity date expires.
Object and PromptSet variables can also be used in order to set particular object attribute (see Attributes Page) without using :PUT_ATT.
The script statement :PSET creates a new entry in the Variables & Prompts tab which is valid for the particular execution if the object variable does not yet exist. If an object variable of the same name already exists, its value is replaced by the new value.
If the object variable is modified by using the script elements :SET, :RSET or :READ, the value that has last been assigned is available in the object (Process, PostProcess, Child PostProcess tabs). It is not necessary to explicitly assign this value using the script element :RSET (for example, to the PostProcess tab).
If you create an object variable by using the script statement :PSET , it is automatically passed on to the superordinate object. If the superordinate object already includes an object or PromptSet variable of the same name, this variable's value will be overwritten. Subsequent parent tasks can then access this variable.
When you restart an object, the values of the "Variables & Prompts" tab will be used for object variables provided object variables have been defined through this tab. The values of certain object executions are therefore irrelevant in restarts. The reason for this behavior is that when an error occurs because of the object variable, the system can correct the value in the object and this value will then also be used for the restart.
As opposed to script variables, object and PromptSet variables do not have a particular data type (see Script Variable). You can use the script function CONVERT in order to assign a particular data type to the variables.
Examples
Example 1
A file transfer is activated by a schedule. The following object variables are involved:
Schedule:
- &FILE# = Close_of_week.txt
- &HOST# = win01
File transfer:
- &FILE# = Close_of_day.txt
- &PATH# = C:\Temp
The file transfer's script accesses the variables &FILE#, &HOST# and &PATH#. Depending on the setting that has been made in the FileTransfer object's Variables & Prompts tab, the value assigned to the above variables changes:
|
Inherit from parent |
Variable content |
Explanation |
|---|---|---|
|
All values (default) |
&FILE# = Close_of_week.txt |
The schedule's value overwrites the file transfer's value. |
|
&HOST# = win01 |
All the schedule's values are inherited. Therefore, the file transfer can also access &HOST#. |
|
|
&PATH# = C:\Temp |
This object variable is already part of the file transfer. |
|
|
|
||
|
Only defined values |
&FILE# = Close_of_week.txt |
The schedule's value overwrites the file transfer's value because it also contains the object variable &FILE#. |
|
&HOST# = "" |
The value of &HOST# is not inherited because the file transfer does not contain an object variable of the same name. Task activation is canceled if an attempt is made to access a non-existing or non-inherited object variable via script. |
|
|
&PATH# = C:\Temp |
This object variable is already part of the file transfer. |
|
|
|
||
|
No values |
&FILE# = Close_of_day.txt |
No values are inherited. Therefore, the file transfer's object variable is used. |
|
&HOST# = "" |
The value of &HOST# is not inherited. Therefore, it cannot be used. Task activation is canceled if an attempt is made to access a non-existing or non-inherited object variable via script. |
|
|
&PATH# = C:\Temp |
This object variable is already part of the file transfer. |
|
Example 2
This example shows how values are inherited in a chain of task.
A workflow includes the objects FILETRANSFER01 and PROCESSFLOW01. PROCESSFLOW01 includes two jobs. Value inheritance between the main workflow and the file transfer is as explained in example 1.
|
Workflow Object variable: |
||
|---|---|---|
|
FILETRANSFER01 Object variable: |
PROCESSFLOW01 Object variable: |
|
|
JOB02 Object variable: |
JOB03 Object variable: |
|
Different situations are shown below and describe how PROCESSFLOW01 and its settings affect the two jobs:
- In all objects, the setting "All values (default)" has been defined.
Object variables are always inherited to the corresponding subordinate task. JOB03 can access the object variables of PROCESSFLOW01, as well as those of the main workflow. Therefore, &FOLDER# can be used in the job. FILETRANSFER01 obtains the object variables of the main workflow but not the ones of the other objects because they are not its parents. - PROCESSFLOW01 has the setting "Only defined values". PROCESSFLOW01 does not inherit the object variable &FOLDER#. Therefore, the other two jobs cannot access its values because values are only passed on from a task to its direct subordinate task.
- JOB03 has the setting "No values".
The job's script does not inherit object variables. Its script remains unaffected and &HOST# obtains value "unix03".
Example 3
The following example includes the various combinations and special features of the inheritance of object and PromptSet variables.
Five tasks run in a workflow (tasks 1, 2, 3, 4 and 6) and are executed one after the other. Task 5 is activated by using the script of task 4.
The workflow includes the object variables &VAR1#, &VAR2# and the PromptSet variables &TEXT1#, &COMBO1#.
- Task 1:
No variables are inherited because of the setting "Inherit from parent - No variables". - Task 2:
Only includes variables that have been defined in the object itself. Only &VAR2# is inherited and set to the value JOBP2. - Task 3:
Inherits all the workflow's variables. - Task 4:
All parent variables except for &COMBO1# are inherited. The reason is the PromptSet variables of the same name are not overwritten.
The script element :PSET is used to pass the object variable &VAR3# on to the workflow. It is then available for subsequent workflow tasks.
Task 5 is activated by using the script (ACTIVATE_UC_OBJECT) and the variables are passed on PASS_VALUES). - Task 5:
Includes only variables that have been defined in the object.
&VAR1# is set to the value "JOBP1" and &TEXT1# is set to "text" (workflow value). - Task 6:
The next workflow task inherits all the workflow's variables including &VAR3#. This variable has been passed on to the workflow by task 4.
See also:
Script Variable