Attributes Page

Agent

Remote Task Manager(JOBQ), Job (JOBS)

Target system (agent or agent group), that is, the system where the job is going to run.

Every agent field that can be searched provides a filter functionality. To open the filter click the folder icon in the respective agent field:

The resulting Select Agent dialog displays a list of Agents as well as the filter pane which allows you to immediately perform a search. To do so, define the relevant search parameters and click Filter. The resulting list displays the agents that meet your search criteria. The number of agents currently displayed is shown at the top left corner of the dialog according to the value defined in the AGENT_LIST_LIMIT variable. The icon next to the Agent's name shows if the agent is active or not.

Generic jobs are a special case. When defining them, it is not necessary to assign them an agent. If you do so and if you want to use the &$PLATFORM# predefined variable in a script statement, you must also define the &AGENT# variable. The &AGENT# variable can be set to an Agent, but not to an Agent Group.

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.

Login

Login object that contains the necessary information for the job to be able to log on to the target system.

For OS/400 platforms the user profile specified in the selected Login object must also be activated in the OS/400 platform. Otherwise, starting jobs is not possible.

Code Table

Code table that is applied to transform character sets. See Code Table Object (CODE)

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.

Group object (JOBG), Schedule (JSCH), Workflow (JOBP)

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.

Event (EVNT), Job (JOBS), Script (SCRI), Notification (CALL), Schedule (JSCH), Workflow (JOBP)

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.

Schedule objects start tasks periodically. Here you define the time at which a new period starts, that is, the time at which completed tasks are removed from the Schedule and reloaded again for the next execution.

The tasks in the Schedule start at this time by default, unless you specify something different in the Start Time field on the Schedule page, see Defining Schedule Objects.

Tasks are executed only once within a period. With every turnaround they get a new RunID.

If you change this setting while the tasks are being processed, they continue running. They will start again when the new turnaround time is reached.

See Defining a Schedule with Tasks with Time and Calendar Conditions.

The time frame that determines the regularity with which the tasks in the Schedule will be executed. The default is 1 day, which is also the minimum valid value; it means that the tasks in the Schedule are executed once a day. Specifying 2 here means that the tasks in the Schedule are executed every second day, and so on.

You use this setting in combination with:

• The time entered in the Period Turnaround Time field also on this page.

  For example, if the duration is one day and the turnaround time midnight, each task in the Schedule will be executed once a day (provided the Calendar conditions, if defined, allow it) and loaded again at midnight.

• The Start Time and Start Offset you can define per task in the Schedule.

Consumption

Consume <x> resources

The number of resources that are consumed during the execution.

The default value applies the value set by your administrator in the WORDKLOAD_DEFAULT_FT key of the UC_SYSTEM_SETTINGS variable.

• Default value: 0
• Allowed values: 0 to 100000

See also Resources.

Remote Task Manager (JOBQ), Script (SCRI), Notification (CALL), Event, File Transfer (JOBF), Job (JOBS), Notification (CALL), Schedule (JSCH), Script (SCRI), Workflow (JOBP)

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.

All objects

Select this option to display a dialog box allowing you to change the attributes for the current execution of the object.

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.

Maximum Executions

Allow <x> simultaneous executions

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.

This option is available for ALLJOBS and INTERCEPTEDJOBS Remote Task Manager objects for SAP only. It allows you to start scheduled SAP jobs.

External Job Reports are stored in the Automation Engine database.

In Remote Task Manager objects for processing chains (R3>PROCESSCHAINS), either all reports (report of the chain and its steps) or no reports are transferred.

End Job if there are no more external operations which correspond to the specified filter criteria.

If no matching tasks are found when the Remote Task Manager is activated, it will not end. At least one task which corresponds to the specified filter criteria needs to be handled for the automatically end to occur.

Here you define the configuration for monitored and controlled operations. The options are:

• Flat: Operations are displayed in vertical order.

• Hierarchical: Existing parent-child relationships are displayed.

A Remote Task Manager object cannot start intercepted child jobs without parents if hierarchical filtering has been specified. To start them, specify flat filtering.

This option is not available in Remote Task Manager objects for process chains (PROCESSCHAINS).

Defines how this Schedule object should be handled if its execution exceeds the specified maximum number of tasks that can run at the same time.

• Wait: The Schedule object waits until execution is possible.
• Abort: The Schedule object is interrupted.

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.

The return code of the external operation controlled by the Remote Task Manager object.

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

Optionally browse to an executable object to run if the return code is less than the one set in the Return Code <= field.

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