Attributes Pages of Executable Objects

Agent

Remote Task Manager(JOBQ), Job (JOBS)

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

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 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 start. The tasks that you include in the schedule object will start at this time by default, unless you specify something different in the Start Time field on the Schedule page.

Tasks are started once within a period. With every turnaround a period gets a new RunID.

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

The length of the period you assign to the schedule. The default is 1 day, which is also the minimum valid value.

This is the time frame that determines when the tasks will be started. You use this setting in combination with the time entered in the Period Turnaround Time field on this page and with the tasks' start time and offset you specify on the Schedule page.

These settings apply for all tasks you then assign it, unless you specify them otherwise on task level.

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

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. Here you specify the priority you assign to this object. For details see Automation Engine Priority.

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

• Default value: 0, which corresponds to a priority of 200
• Allowed values: 1 (lowest) to 255 (highest)

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 here. This will be applied to runtime calculations.

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.

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.

  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 are processed in parallel. You will have to consider this when you assign single objects to a group and decide whether they should be executed simultaneously or not.

• Default value: 0 (no limit)
• Allowed values: 0 to 99999

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

Remaining Task: When you define a limit for parallel file transfers, you can also 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.