Process Pages

As a developer and object designer you add functional logic to your objects on their Process pages using the Automation Engine scripting language. All executable objects have at least a Process page. Some object types also have pre-process, post-process, and child-post process pages.

An object definition consists of several pages. The Process page is available for all executable objects. Jobs objects have two additional process pages, the Pre Process and the Post Process page. Each Process page can contain up to 32767 lines. However, if the script generates more than 1000 JCL lines, its generation is canceled. If your script generates more JCL lines, you can change this limit using the MAX_JCL_LINES in the :PUT_ATT.

The scripts on the process pages are processed either when the object is activated or when it is generated. The order in which the pages process in Jobs is processes is important. For more information, see:

To access the Process page, click or expand the Process tab on the left pane of the object definition.

Tip: Read Working with the Script Editor before starting to write your scripts to learn about the script editor functions.

This page includes the following:

Process Page

The Process page is available in all executable objects. The script on this page is processed during the Generation stage. More specifically, the scripts on this and on the Pre Process pages are processed together during the generation stage, first the script on the Pre Process and then the script on the Process page. For detailed information about what happens during the script generation, see Script Generation in Detail.

For JMX, PeopleSoft, SAP, and SQL Jobs, the Process page provides two options to create scripts:

Writing code in the script editor

This option is the standard one, available for all executable objects.
Adding predefined, ready-to-use commands available in the Forms view

For more information, see Forms View on the Process Page.

Platform-Specific Information

Special Functions for Guardian/NSK

For information about the special functions that are available for the automatic handling of input requests, see Automated Handling of Input Prompts.
JCL for z/OS

The actual JCL is indicated here. Do NOT specify a job statement (to be specified through the attributes) or an end statement.
SAP JCL Interpreted by the SAP Agent

SAP has no JCL. For this reason, the Automation Engine supplies one that is interpreted by SAP and converted to processing statements for the target system. For more information, see About SAP JCL.
Enabling an Interpreter for Windows and UNIX

You can also enter a script for use with an external interpreter. To enable the interpretation of that script, use :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS.

The binary files of the Storage can be attached and transferred to the Windows Agent using the :ATTACH_RES script function.

To be able to use these functions, configure the UC_EXT_INTERPRETERS_* - Register External Interpreters and :REGISTER_VARIABLE variables.
Windows BAT and PowerShell Examples
- This Windows BAT script puts the output of the C:\Temp directory into a file and checks whether the command ran successfully. If the command does not complete successfully, the Job ends with the return code from the dir command:
  
  dir C:\temp /S >> C:\temp\test.txt@
  
  set retcode=%errorlevel%
  
  @if NOT %ERRORLEVEL% == 0 goto :retcode
- This Windows PowerShell script gets content of the C:\Temp directory and puts the output into a file. The error code from Powershell is then checked. If it is not 0, the job aborts with $LastExitCode. This exit code is the equivalent to %ERRORLEVEL% in the CMD.EXE/.BAT script.
  
  Get-ChildItem C:\Temp > C:\Temp\test.txt
  
  if( $LastExitCode -ne 0 )
  
  { __uc_return $LastExitCode }
The __uc_return function can be used for ending of PowerShell jobs. This function works only if the Windows job type is set to Interpreter. The function does not work with the new functions :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS.

For more information, see Configuring Include Objects for External Interpreter Calls.

Pre-Process Page

Available for Job objects (JOBS) only. On the Pre-Process page you enter statements that prepare the Job for execution. A typical example is the :PUT_ATT statement, which sets attributes such as the Agent. The script on this page is processed at the same time as the script on the Process page.

Since pre-process statements are executed in the Job header, you can add statements that are executed before the Job Messenger gets involved in the execution. For more information, see Agent Job Messenger.

Tip: Use the :INC_SCRIPT script statement to insert the content of this page on any other process page.

z/OS

On the Pre-Process page, you can define all JCL commands (e.g. JCLLIB, JOBCAT, JOBLIB, OUTPUT etc.). These commands must be defined after the Job statement but before the first step in the script.

The Event Monitor considers steps on the Pre-Process page only if the first step has the same name as the Automation Engine system. Otherwise, canceled pre-processing Job steps do not affect the end status of an Automation Engine Job.

Example:

In this example, the name of the Automation Engine system is UC4PROD.

Pre-Process page:

//JOBLIB DD DISP=SHR,DSN=.....

// DD DISP=SHR,DSN=....

//UC4PROD EXEC PGM=modname

Process page:

//STEP01 EXEC PGM=IEFBR14

//STEP01 EXEC PGM=IEBGENER

Post Process Page

Available for Jobs (JOBS) and File Transfers (JOBF) only. Scripts on the Post Process page are processed after the Job has ended normally or after a partial completion. A Job has partially completed if, for example, it is canceled. With post-processing commands you influence how a Job ends.

The following rules apply:

Post process scripts cannot include JCL lines
Post process commands are NOT executed in cases of ENDED_LOST task statuses
You cannot use the following script statements on the Post Process page:
- :PUT_ATT
  Setting attributes for Job generation is irrelevant
- :EXIT
  Canceling script processing with return code > 0 is not allowed
- :STOP
  Interrupting script processing is not allowed

Tips:

Use the :RSET script statement to transfer script variables between the Process and Post Process pages. This script statement returns the value that has been assigned to the script variable in the Process page.
Use the :MODIFY_STATE script statement to change the final ending of a Job. This script statement lets you modify the Job return code and status supplied by the Job Messenger in the trailer.
Use the PREP_PROCESS_REPORT script statement on the Post Process page to analyze reports. You can then define an ENDED_NOT_OK status for a Job even if the Job has technically ended normally.

Child Post-Process Page

SAP and PeopleSoft Jobs usually contain statements that start multiple processes (sub jobs) in the target systems. To replicate this job structure in the Automic Web Interface, SAP and PeopleSoft Jobs have an extra Child Post Process page. The SAP or PeopleSoft Job you create in the Automation Engine is the parent of those sub Jobs (child processes) and serves as their container.

The script you enter on the Child Post-Process page is processed for each individual child process immediately after it has finished.