Job Factory

Some job groups require multiple instances with variations in scheduling rules and the data they operate on. For example, a payroll service provider that uses the same job group to generate the payroll for each of its customers would want to define the job group once and then reuse it for each customer, based on that customer's unique scheduling and data requirements.

While one option is to create copied job group instances (one for each required variant), global changes are made complicated, since each instance must be updated or replaced separately. A more efficient method is the job factory, which can automatically generate unique instances of a job group template.

The Tidal Automation job factory is a dynamic scheduling feature where one job group serves as a static template, while another ad-hoc job group acts as a “factory”, inserting multiple customized instances of the template group into the Job Schedule. These customized variables are updated at the time of insertion.

Process Overview

  • Job group templates are pre-defined for use by the job factory.

  • The job factory executes on an event.

  • Based on the event, the job factory selects a template and creates a new instance of it.

    Note: If applicable, the instance is customized based on variables and directives.

  • The job factory ad-hoc inserts the instance into the queue of jobs to be run.

  • The ad-hoc jobs may be monitored via the Job Activity

Job Factory Patterns

A job factory follows a basic structure: plan, context, execution.

  • Plan – A job definition parameterized with conditional constructs. This is the template.

  • Context – A job action triggered by an event. The compiler inserts a job based on the event and the resulting directives from the conditional constructs.

  • Execution – A job run. The resulting output.

Basic Job Factory Pattern

If processing payroll for other companies:

  1. Define a payroll job definition template, parameterized to result in different job runs based on which company's data is being processed.

  2. Receive payroll data from two companies: ABC, Inc. and 123 LLC.

    Note: The job compiler recognizes the events and creates two new instances of the payroll template: ABC Payroll and 123 Payroll.

    Both ad hoc jobs are inserted into the queue and run.

Job factory pattern showing a job definition template being used to create two different job runs.

Each of the factory jobs can inherit a common calendar and agent from a factory job group or be scheduled individually based on the required calendar and other scheduling criteria.

Also, each instance can have its own scheduling criteria. For example, if processing takes place on Thursdays for one set of customers and Fridays for another. Nested groups can be used to organize customers based on processing requirements and enforce scheduling rules on a group-by-group basis without touching the job group template.

Variables and Directives

These variables and directives allow for further refinement of whether and how the jobs in a job group instance are run.

$PREFIX and $SUFFIX

These variables work for the ad hoc jobs and the jobs added to the schedule. To identify jobs more easily, these variables allow values to be inserted at the beginning ($PREFIX) or end ($SUFFIX) of the job name displayed in the Job Activity pane. The TA Master resolves values pertaining to the variable references (Example: BuildNumber) at runtime. This job group definition has a $PREFIX variable and a $SUFFIX variable.

When the job group is inserted into the schedule, the group name including the values of the $PREFIX and the $SUFFIX variables is displayed in the Job Activity pane.

$PREFIX and $SUFFIX variables are used at the time of inserting a job into the schedule. If $PREFIX or $SUFFIX variables are assigned with local group variables, the names of the local group variables themselves are used as values; the local group variables do not get substituted by their defined values. Local group variables are substituted by their defined values only when a job goes to ACTIVE state. To have local group variables substituted by their defined values at the time of inserting a job into schedule, set sysval 174 to N.

$C Job Compiler Directive Variables

These directive variables only work with the adhoc jobs, not scheduled jobs. They are referenced by the Compiler during job compilation.

$C Event

By default, an adhoc job has no parent and appears at the root of the Job Activity. These directives allow an adhoc job to be made a child or sibling of its triggering job.

  • $C(EVENTPARENT) - If “”, then the adhoc job is made the child of a triggering job.

  • $C(EVENTSIBLING) - If “”, then the adhoc job is made the sibling of a triggering job.

Job group definition showing $C(EVENTPARENT) enabled. This is the job which is made the child.

When the parent job is run, it triggers the child job to run, too. The Job Activity shows the result, with the above job displayed as a child to the triggering parent job.

$C(OVERRIDECAL)

This directive specifies how calendars are handled for ad hoc jobs:

  • Y = All jobs run. The calendars and other directives are ignored. This is the default behavior when no compiler directives are defined.

  • N = Jobs run if their calendar matches the current date AND they are allowed by other directives.

  • A = Jobs run if their calendar matches the current date OR they are allowed by other directives.

  • X = Calendars are ignored. Jobs run if they are allowed by other directives. This is the default behavior if any compiler directives are defined.

Example: Job Group Definition showing $C(OVERRIDECAL) = N. If Job Group "Calendar Override N", has multiple subgroups, each with different calendar values, e.g., "Monday" runs on Monday, "Friday" runs on Friday, etc.

Example: If $C(OVERRIDECAL) = N and the current date is Wednesday, only the Wednesday job is run.

$C Var and Follow

These directives provide options for including and excluding child groups when a parent group is inserted manually or by an event. Includes are applied before excludes. These do not bypass calendar checks, if those are enabled.

  • $C(VARINCLUDE[varname]) = val1,val2,…

    Only include jobs which have the [varname] directive AND a directive value matching any of the [varname] comma-separated values (val1,val2,…). Clear out the values to disable the directive.

  • $C(VAREXCLUDE[varname]) = val1,val2,…

    Only exclude jobs which have the [varname] directive AND a directive value matching any of the [varname] comma-separated values (val1,val2,…). Clear out the values to disable the directive.

  • $C(FOLLOW) = Skips any VAR checks and lets the job follow its parent.

    Example: Job Group Definition showing $C(VARINCLUDE[decision]) = maybe,yes. Job Group "Var Only Include" has multiple subgroups, each with different $C(VARINCLUDE[decision]) values.

    Example: If $C(VARINCLUDE[decision]) = maybe,yes, only the jobs with those values are run.

$C(PROCESS)

This directive tells the job compiler how to apply the VARINCLUDE/VAREXCLUDE and the FOLLOW directives to groups and non-group jobs.

Value

Description

G

When an inserted group has the process directive set to G, variable compile directives are applied to all descendant groups only to determine if they should be included under their included parent. Non-group descendant jobs always follow their parent by default unless they have the process directive set to Y (see below)

Note: On a non-group job, the value G is treated as N. This is the default behavior when the inserted group does not have the process directive.

A

When an inserted group has the process directive set to A, variable compile directives are applied to all descendants, including groups and non-group jobs, to determine if they should be included under their included parent

Note: On a non-group job, the value A is treated as Y.

N

When a non-group job has the process directive set to N, it overrides the A directive from its inserted ancestor group. Variable compile directives are not applied to the job, and the job always follows its included parent

Y

When a non-group job has the process directive set to Y, and the job is the descendant of an inserted group, variable compile directives are applied to the job to determine if it should be included under its included parent

$C(EVAL[])

EVAL is a compiler directive that can be used to evaluate any variable when the jobrun is created after compilation begins.

Note: This directive applies to adhoc and scheduled jobs.

When this job is compiled, the EVAL directives are processed immediately after the jobrun is created.

Note: This directive applies to adhoc and scheduled jobs.

$C(PREVAL[])

PREVAL is a compiler directive that can be used to evaluate variables in the job definition at pre-compilation time, that is before the jobruns are created. This makes it possible to use variables in combination with pre-compilation operations such as $C(VARINCLUDE[]) to determine whether to include a job in a compile operation. Any local variables that are $C() directives will be evaluated automatically at pre-compilation time as if they are enclosed in a PREVAL directive.

Here is an example of using PREVAL in which a variable, “CurrentDept”, is defined for the current department.

Example: If there is a group with a VARINCLUDE directive that includes only child groups with “DEPT=Finance” and a child group with the “DEPT” department defined to the PREVAL evaluated value of the “CurrentDept” variable, the value of DEPT is evaluated before VARINCLUDE is applied to this job, so this job will be compiled. Without PREVAL, “CurrentDept” would not be evaluated at precompile time, and the job would not be included in the compilation.

Note: This directive applies to the manually inserted jobs and scheduled jobs.