Jobs (JOBS)

An Automic Automation Job is a unit of work that is Agent-specific. A Job executes commands on computers or in enterprise business solutions (SAP, PeopleSoft, Oracle Applications, etc.). These solutions differ from each other, therefore specific Job templates are available for each of them. This means that there are SAP Jobs, PeopleSoft Jobs, Windows Jobs, and so forth, depending on the target system that they address. Jobs are always assigned to Agents. They always need a Login object that submits the necessary credentials to the target system (Agent)

As a developer and object designer, you create Job objects (JOBS) to execute processing steps in a target system. You can specify their attributes using the Automic Web Interface on the Job definition pages. Alternatively, you can use the Automation Engine scripting language to add functional logic on their Process pages, where their JCL is stored.

The Job objects of Rapid Automation solutions differ from the standard ones provided with the Automation Engine. For Rapid Automation Agent documentation, see https://docs.automic.com/documentation.

Object class: Executable object

Object type/Short form: JOBS

Default Object Templates/Subtypes: Templates for specific platforms. You can customize them or create your own ones.

This page includes the following:

Stages of Job Processing

Jobs go through four execution stages. Click the links below to read more about what happens during each one:

  1. Activation
  2. Generation
  3. Processing
  4. Completion

In Case of Agent Downtime

When an Agent ends and is restarted, it gets the whole restart information from the Server. This includes information about all Jobs that were being executed at the time the Agent ended.

If Jobs have ended during the Agent downtime, the Agent starts searching for Jobs in the process lists of the operating system. If it does not find a Job anymore, it searches for its report file in the temporary directory and retrieves the job end time and return code.

If the Agent is not able to find any information, the Job status changes to V - status vanished.

Character Conversion During Job Execution

Some Operating Systems and applications use special character sets. When the Automation Engine exchanges data with them, the Agent converts this data as required by the character set of the target system. For this purpose, when configuring an Agent, your Automic Automation administrator specifies the Agent's character encoding set in the UC_HOST_CODE parameter in the [VARIABLES] section of the Agent's INI file. If you do not specify a different character encoding set for the Job, this configuration in the Agent's .INI file is used.

This Is How it Works

The Automation Engine sends the Job data (JCL) to the Agent using the Code Table specified in the UC_HOST_CODE parameter in the [VARIABLES] section of the Agent's INI file.

The Agent converts the data as required by the character set of the target system. For this purpose, it uses the default Code Table sent to it by the Automation Engine during the login.

After the Job is executed, the generated report is converted again using the character set defined in the .INI file and it is sent to the Automation Engine.

Optionally, you can specify a target Code Table when defining a Job on the Job's Attributes Page. If you do so, this definition overwrites the one in the Agent's INI file. The Automation Engine searches for the Code Table in the Client where the Job is defined. If it does not find it, it searches for the Code Table in Client 0. However, this is valid only temporarily and exclusively for the JCL and report of this particular Job.

Important! The Code Table setting does not affect the OS runtime. That means Windows Jobs still run with the code page 850, which is not UTF-8. Therefore, if the Job generates any UTF-8 output on STDOUT, this output is not recognized even if the Code Table value is set to UTF-8. You can change this on the OS level for Windows with a chcp command. See https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp or/and https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers. For example, if you try to run a job with the >> echo command, doing so does not work until you have applied the chcp command with the particular code page set. (1250 or 65001).

For more information, see Code Tables (CODE).

Working with Job Objects

The list below tries to depict a possible road-map to define and work with Job objects and provides short descriptions of the actions you can take, additional information that can help you understand how they work and links to topics that further describe them:

  1. Define the Job general settings, which include the following:

    • The basics, on the General Page.
    • If required, apply a Sync object to the Job. For more information, see Sync Page.

    • On the Runtime Page specify the settings to be used for runtime calculations.

      This information is relevant for planning tasks and monitoring them. It is also used in forecasts and autoforecasts.

    • The administrator can fine-tune access rights at object level on the Authorizations Page.

    • Specify important object Attributes on the Attributes Page. Among other important settings, here you assign the Agent and the Login object that allows the access to it

      Important! Your definition in the Generate Task at: Activation time / Runtime attribute can have an important impact in the execution times of your jobs. Have a look at Generating at Activation or at Runtime, where the implications of either option are described.

    • Register the output files that will be produced when processing them on the External Output Files page. To be able to carry out searches in those output files and, if required, perform follow-up actions, you specify these settings on the Output-Scan page. For more information, see Output Pages.

    • You may want to use variables or prompts. You do so on the Variables Page and Prompt Sets Page.

      Have a look at Variables and VARA Objects to get acquainted with the various types of variables and VARA objects that are available in an Automation Engine system.

    • You may want to define the settings to backup and restore a Job task when included in a Workflow. This is useful to recover the last successful status in case of failed processes. You do this on the Rollback Page.
    • The Version Management Page lists all the versions of an object and allows you to restore it to an older version in case of a misconfiguration.
    • Enter information on the Job you are defining on the Documentation Page.

  2. Job objects (JOBS) have three Process Pages on which you enter the scripts to be processed. You build the Job logic on these pages. They provide a number of convenience functions to help you with your work. If you enter scripts on all of them, they are processed in the following order:

    1. Pre-Process
    2. Process
    3. Child Post-Process Page (SAP and PeopleSoft only)
    4. Post-Process

    For more information, see Working with the Script Editor. For more information about the Automation Engine scripting language, see Writing Scripts.

  3. You can easily reuse code using Includes (JOBI), which saves time and helps you keep your scripts consistent.

  4. Execute the Job.

    There are multiple ways to do this that can be grouped as follows:

    • By a parent task.

      This is the case of Jobs that are included in a parent object (for example a Workflow or a Group). When defining them, take into account that their activation time can be different from their start time; the latter usually depends on the parent object.

      See Superordinate Tasks (Parents).

    • Stand alone

      This is the case when the Job is not part of a parent object or, even if it is, you execute it independently of its parent. You have three possibilities:

    Important! The generated JCL can be modified. However, changes to the JCL affect only the execution for which they have been done and not for the Job definition. The report contains the original JCL and the modified one with an extra line indicating who changed the content.

  5. When processing Jobs, the Automation Engine generates output files and reports that guarantee traceability and auditability. Have a look at the following topics to learn more about this:

    To see the generation result, do the following:

    1. Open the Reports window, see Accessing the Reports.
    2. Select JCL from the Reports dropdown list.

  6. Monitor the generated task.

    As soon as the Job is activated, it is available as task in the Process Monitoring perspective. In the Task list you can see its status.

    Right-click it to open its monitor (see Monitoring Jobs); it contains three pages that provide the most important information on the Job parameters.

    You can also access the Job Monitor from the Process Assembly perspective.

  7. In the Process Monitoring perspective a number of functions are available, depending on the status of the job. For more information, see Working with Tasks.

See also: