Windows Jobs

This subtype of the JOBS object defines Windows operating system processing steps to be carried out in a target system. Like all other job objects (JOBS), Windows jobs can run independently or they can be added to a group (JOBG) or to a workflow.

The page contains the Windows-specific execution parameters:

Job object (WINDOWS)

Start Parameters Section

The following table describes the available options:

Field Description
Interpreter Type

Define here how the script is executed:

  • Batch: The script statements and DATA lines are executed as a MS-DOS batch file.

    See Script Elements - Alphabetical Listing and About Automation Engine Scripts.

    Select this option if you want to transfer resources from the Storage object to the Windows agent.

  • Command (cmd.exe): If you select this option the Command field is displayed and you can enter a command or command sequence that is passed to the Windows command line. This is called and executes the commands.

    The JCL contained in the Process page is executed; OS commands are skipped.

  • Custom interpreter: The script is transferred to an interpreter as a file.

    For this purpose, the following must be specified in INI file of the agent:

    • ECPEXE=Interpreter
    • ECPEXT=File Extension
Working Directory

Specify here the directory in which the job will run.

In addition, you can use the working directory to write files in the external interpreter script for transferring resources to the agent.
Batch Mode: Log on as batch user

Activate this checkbox to executes the job in batch mode.

This setting is required in order to execute jobs with elevated rights on hosts where UAC is activated. For more information, see User Account Control in Windows.
View Job on Desktop

Define how the job is displayed:

  • Do not show: The user cannot see the job when it is executed.
  • Normal: The job is displayed in the default view
  • Minimized: The view is minimized
  • Maximized: The view is displayed in full screen mode
Use Windows OS Job Object

Automic recommends taking advantage of the Windows OS job object (that is, the job object function that is available in Windows) in combination with the Automation Engine Windows Job Object (JOBS).

This is important for AE Windows Jobs containing processes and sub-processes that run asynchronously.

Let's suppose that you have such a job with a script with three command lines, where the first one starts three sub-processes. When the three command lines are successfully executed, the Windows agent returns this information to the Automation Engine, which considers the job as finished. As the sub-processes are running asynchronously, it can happen that they are not finished yet. The Automation Engine has no control over them and does not know about their status.

These has several negative consequences:

  • The information written to the reports is incorrect.
  • If the job is started again while the sub-processes are still running, it will abend.
  • If a process is canceled, its sub-process is not automatically canceled, which will cause an abend as well.

Use the Windows OS job object to group an Automation Engine Windows Job Object with its sub-processes within one Windows OS job object. The latter is then in charge of signaling the end of the Automation Engine object when all its sub-processes have also ended and to also cancel all its sub-processes when the job is canceled.

The options are:

  • Default setting from agent: Whether the Windows OS job object is used or not depends on the default setting specified in the INI file of the agent.
  • Yes: The Windows OS Job Object is used.
  • No: The Windows OS Job Object is not used.

Job Report Section

The following table describes the available options:

Field Description
Store to
  • Database: As soon as the job has been processed, the process log available on the target system is stored in the database.
  • File: The process log is stored as a file on the target system.

You can select one option or both of them simultaneously.
Generate

Define when the operating system process log is written.

  • Always: The process log is always written.
  • On error only: The process log is written only when an error occurs, for example, when the job is canceled or aborted.
Scripted Report Select this option to write an own job report instead of the default one.

The following table describes the available options for the Job Report pane of the UNIX page:

Field Description
Store to
  • Database: The job's UNIX process log is stored in the database.
  • File: The process log is stored as a file on the target system.

You can select both options together.
Generate

Defines, when a UNIX process log is written.

  • Always: the process log is always written.
  • On error only: The process log is only written when an error occurs, e.g. when the job is canceled or aborted.

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; You do so on the Sync Page.
    • On the Runtime Page specify the job runtime settings.
    • Fine-tune access rights at object level on the Authorization Page.
    • Specify the object Attributes on the Attributes Pages of Executable Objects.
    • Register the output files that will be produced when processing them on the Output Page.
    • To be able to carry out searches in those output files and, if required, perform follow-up actions, specify these settings on the Output-Scan Page.
    • You may want to use variables or prompts. You do so on the Variables & Prompts Pages.
    • 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 pages on which you enter the scripts to be processed. 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 Page
    2. Process Pages
    3. Post-Process Page
    4. Child Post-Process (SAP and PeopleSoft only), see Child Post-Process Page.
  3. You can easily reuse code using Include Object (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:

    When executable objects are processed, they go through the following four stages: 1. Activation, 2. Generation, 3. Processing and 4. Completion. Take a look at these topics to understand what happens with every processing stage.

  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:

  6. In the Process Monitoring perspective a number of functions are available, depending on the status of the job. See Working with Tasks.