How do IWSz and Autosys Custom Dependencies work?
Release : 6.0.2
Component : AUTOMIC AUTOMATION INTELLIGENCE ENGINE
AAI uses naming conventions within IWS and AutoSys to indicate which jobs are connected to one another across scheduling platforms.
AAI will analyze these relationships and create “Custom Dependencies” between jobs as specified below.
Jobs that are defined in AutoSys that are associated with IWS jobs (causing them to run when the AutoSys job completes) will be identified in the following way.
A user-specified field in the AutoSys job will contain a string that contains a “token” which identifies the string as being significant for the automatic detection. By default, the AutoSys job field “Application” will be initialized with a literal that starts with “TSL”.
The token will be followed by an underscore(_) and a specially formatted string that indicates which IWS job will be the subject of the custom condition. The format of the string will be:
Target Scheduler Name as defined in JAWS_Application / Parent_Operation Number_Target Job Name
One specific example of an expected value in the specified field of an AutoSys Job would therefore be:
TSL_IWSZ-SCHEDULER_[APPLICATION-PARENT]_[OPERATION-NUMBER]_[MAINFRAME.JOB001]
All fields in the above string are required. If for some reason, any field is not needed to uniquely describe the relationship, it should be left empty (zero length string), however the underscore must be inserted into the string.
Additional data may exist in the field, only items beginning with token and it’s matching square brackets are to be processed by AAI's custom condition generator. This field may contain 0, 1, or many such entities to be processed.
AAI's Custom Condition Generator will look up MAINFRAME.JOB001 in scheduler IWSZ_SCHEDULER and create a custom condition between the AutoSys job and the mainframe job.
IWS jobs set values of Global Variables in AutoSys on completion by way of a Third Party agent such as Stonebranch.
The Global Variable names all begin with a user-defined prefix. The default value will be “OPC”. The remainder of the global variable will be the name of the IWS job that sets the variable.
An example global variable name would be: OPCMAINFRAME.JOB001
The AAI Custom Condition Generator will examine all AutoSys schedulers defined to AAI and determine which jobs have conditions related to global variables that begin with the prefix. The mainframe (source) job will be looked up based on the name of the global variable. Custom dependencies will be created between any and all AutoSys jobs that are dependent on the global variable and the source job.
When more than one mainframe job is found, conditions should be created between each matching mainframe job and the AutoSys job. These conditions should be logically “OR-ed” together.
The existing condition between the AutoSys job and the AutoSys global variable is superseded by the custom condition that is created between the Mainframe Job and the AutoSys job for that specific global variable.
At the conclusion of a converter run, AAI core server will publish a message to the ActiveMQ message broker on a topic. Generally, this is intended to implement a “POST CONVERTER” webhook.
Messages are published by JAWS to ActiveMQ when the converter completes, assuming that the DB transaction commit was successful. The content of the message is the existing SchedulerLite JSON object. SchedulerLite is a trimmed down version of JobScheduler. The messages are persistent so that they can survive an ActiveMQ restart. The messages have a default TTL of 1 hour. The TTL’s can range from 1 minute to 1 week.
The Subscription Service will consume these messages and dispatch as normal to any subscribed endpoints.
A new deployable component has been created to perform the functions outlined above with respect to custom dependencies. This component is packaged as a WAR file and runs inside of JBOSS.
All access to AAI data from the Custom Condition Generator will be through the REST API. In the case that REST APIs are not adequate to provide the necessary data or functions, new APIs will be created or existing APIs will be enhanced.
This component creates its own log file: CustomConditionGenerator.log that is generated each day after the converter runs.
subscribe.publishPostConverter
Type: Boolean
Default: FALSE
Description: If true, a notification indicating the converter is complete will be published.
POST_CONVERTER_TTL
Type: IntegerDefault: 60
Minimum: 1
Maximum: 60*24*7
Description: Time to live in minutes of post converter notifications
CustDep.AutoSys.FieldName
Type: String
Default: “Application”
Description: Allows user to override which field in the AutoSys job definition will contain the relationship between jobs for automatic custom dependency creation.
CustDep.AutoSys.Token
Type: String
Default: “TSL”
Description: Allows user to override the token used in the AutoSys job definition field to specify the relationship to another job.
CustDep.IWS.AutoSysGVToken
Type: String
Default: “OPC”
Description: Allows user to override AutoSys global variable prefix to examine for automatic custom dependency creation.
Example JIL showing the IWS job depending on the Autosys job
/* ----------------- crossplatform-job-ae_to_iws_01 ----------------- */
insert_job: crossplatform-job-ae_to_iws_01 job_type: CMD
command: sleep 70
machine: localhost
owner: autosys
permission:
date_conditions: 1
days_of_week: all
start_times: "10:10"
description: "Dummy job for AAI Custom Condition"
alarm_if_fail: 0
alarm_if_terminated: 1
application: TSL_IWSZ-SCHEDULER_[APPLICATION-PARENT]_[OPERATION-NUMBER]_[MAINFRAME.JOB001]
Below is an example JIL for an Autosys job depending on an IWS job, "condition: value(OPC***)" is where the OPC variable is set.
/* ----------------- crossplatform-job_iws_to_ae ----------------- */
insert_job: crossplatform-job_iws_to_ae job_type: CMD
command: sleep 70
machine: localhost
owner: autosys
permission:
date_conditions: 0
condition: value(OPC Variable) = "DONE"
description: "Dummy job for AAI Custom Conidtion"
alarm_if_fail: 0
alarm_if_terminated: 1