Attributes Page

Queue in which the object is going to be executed.

If you do not select a queue here, the object starts in the CLIENT_QUEUE. See CLIENT Queue.

In the Agent and Queue fields, it is not possible to use { } expressions combined with script-variables like {VARIABLE.STATIC,&SCRIPTVAR#,1}. It is possible to use either { } expressions or script-variables, but only the combination is not valid. A possible workaround is to use GET_ATT and :PUT_ATT in statements in pre-process scripts.

Queue in which the object is going to be executed.

For all three job types, the queue of the subordinate tasks is replaced by the value specified here when the group is processed.

If no value is specified, the queue defined for the parent task is used.

If you specify *OWN here, also the queue defined for the parent task is used.

If you want to include this object in a Job Group (JOBG), select the group from this drop-down list. If nothing is specified here, the object is activated immediately.

This option is ignored if the object is started by a workflow (JOBP), a schedule (JSCH) or a recurring task.

Objects are processed in queues based on their priority. A Client variable that can be set by administrator users defines the default priority for tasks within in a Client (TASK_PRIORITY key of the UC_CLIENT_SETTINGS variable).

Here you specify the priority you assign to this object, which overrides the default set by your administrator in the Client variable.

• Allowed values: 0 to 255

• 1 = highest priority
• 255 = lowest priotiy
• 0 = the value specified in the TASK_PRIORITY key of the UC_CLIENT_SETTINGS variable applies

If no default priority is specified, or if the variable is not available in the Client, the priority is 200.

See also Automation Engine Priority and UC_CLIENT_SETTINGS - Various Client Settings.

If you activate this checkbox, the priority assigned to the tasks included in a workflow is ignored. They inherit the priority defined for the workflow instead. The same applies to child workflows; they inherit the priority defined in the parent workflow.

This function gives you the chance to control when tasks and child workflows are processed and, if so desired, avoid that they run in parallel.

Example:

You have designed a workflow that contains two children workflows, each with two tasks:

If you leave this checkbox deactivated, although the workflows have different priorities, the tasks will be processed with the same priority, probably in parallel, considering the available resources only.

If you activate this checkbox for the children workflows (Child Workflow 1 and 2) but NOT for the parent workflow, their tasks will inherit the respective priorities. Therefore, Task 1 and 2 will be processed before Task 3 and 4.

If you activate this checkbox for the parent workflow, all of them will inherit priority 50 and will be processed with the same priority again.

You can select a time zone ( Time Zone Object (TZ)) here. This will be applied to runtime calculations, see Runtime Page.

AgentGroup Setting

Assign same Agent

Activate this option if workflow tasks that use the same agent group should also use the same agents. For details on how the agent is determined see Setting the Agent Group for Workflows.

If this option is not activated, the system determines an arbitrary agent in the group and enters it in the task.

The activation and the start time of an object can be different, for example when an object is executed by a workflow in which an earliest start time has been defined.

With this setting you define when the script is processed.

This setting also affects the way the system decides which agent in an agent group will process the task.

• Activation time: The script is processed when the object is activated (before processing).

  The start time of the task is used for agent selection. The status of the task switches to Waiting for resource in case no sufficient resources are available on the agent at that moment. It waits until processing is possible again. It does NOT change the agent even if a different one had enough resources.

• Runtime: The script is processed directly after activation, when the executable object is executed.

  The start time of the task is used for agent selection and resource allocation at the same time. The status of the task switches to Waiting for host in case no sufficient resources are available on any agent at that moment. It waits until one of the agents in the group has the necessary amount of free resources.

See 2. Generation for details of what happens when selecting the one or the other option.

You can define how many tasks can be processed simultaneously. You will have to consider this when you assign single objects to a group and decide whether they should be executed simultaneously or not.

If you are defining this attribute for a Job Group, this field refers to the number of jobs that can be executed simultaneously within the group.

The default is Unlimited, the allowed values are 0 to 999 (for Jobs within a Job Group) or 99999 for all other object types.

Note: Changes to these settings are active only after the first generation and do not apply to Jobs that are already running.

Remaining Task: If you enter a value in Maximum ExecutionsAllow <x> simultaneous executions, two additional options are displayed where you can define what happens with the tasks exceeding this limit:

• Wait: The object waits until processing is possible.
• Abort: The object ends.

The task is always deactivated after its execution. It is available on the Tasks window as long as it is active; once finished, it is removed from it.

You can still access it from the Process Monitoring perspective if you filter the list of tasks to be displayed activating the Include deactivate tasks checkbox.

The task is only deactivated if it has been executed without errors and its successful status is confirmed.

If no status is selected, the system return codes 1900 to 1999 (ANY_OK) indicate a successful file transfer.

Workflows: An interrupted workflow including its tasks remain the Tasks window. To deactivate and remove them from the list.

You can define a time span in minutes after which the task is automatically deactivated. You can still deactivate the object manually within the given time span.

The default value is 0. This means that the value that the system administrator has defined in the UC_CLIENT_SETTINGS variable will be applied.

Selection field for the end status that is expected for the subordinated tasks.

Optionally browse to an executable object to run if the status in the OK Status field is not returned.