Jobs Library
The Job Library offers a method of using pre-written code that provides various functions and features. This avoids the Job Designer from having to write scripts or code (much less having to actually test what was written). Another major advantage to creating a “Jobs Library” job is that you can create a series of job steps rather than a series of jobs to perform the different types of processing that a business flow might need.
Create a Jobs Library Job
To create a Jobs Library job change the Job Type, in the Job Properties category, to “Jobs Library”.
The left third of the window consists of job library categories (i.e. Database, Networking, etc) while the remaining two thirds are reserved for the job library steps. If you click on the plus side of the category you can see the various job features for that category.
To use a job step feature simply drag the feature into the “Steps” area and drop it. For example, this is what the FTP/SFTP/FTPS job step would look like:
Common Step Properties
There are several properties that are common for all job steps. Let’s take a closer look at the above step:
From left to right:
-
Expand/Collapse Indicator. Click on arrow pointing right to expand. Click on arrow pointing down to collapse.
-
Enable Job Step checkbox. If checked, step is enabled for execution. If clear, step is disabled and will be ignored.
-
Job Step Icon.
-
Job Step Name. Assigned when step is created. May be changed by clicking on the name.
-
Job Step Category.
-
Job Step Deletion Indicator. Clicking on the x causes the job step to be deleted.
Many of the dropdowns enumerate machines or step related data on those machines. Some dropdowns provide a selection and some provide a lookup of ActiveBatch objects.
Certain job step properties are displayed in bold which indicates required (non-blank) properties for the step.
Iteration Job Steps
Several Job Steps offer the opportunity of iteration. Iteration is the ability to loop depending on the job type. For example:
In this example, the ForEachRow job step connects to a database and based on the results of a SELECT statement allows a series of nested job steps to iterate through each row of the recordset. The single nested job “Log” writes the data to the job’s log file. One property that is common to all iteration job steps is the ContextName property. This property represents an execution variable into which a row (using the above job step) is returned. In an iteration job step an execution variable’s scope is limited to the iteration itself (in other words, the nested job steps within the iteration). Similar to an ActiveBatch variable, an execution variable uses a similar substitution sequence with the notable difference of percent-sign (%) instead of dollar-sign ($) to start the sequence. If you examine the Log job step, you’ll see a sequence of %{value.hostname}. “Value” is the execution variable defined in the ForEachRow step. “Hostname” is a member of the database table “jobschedulers” that is indicated in the SELECT command.
Expressions
While execution variables are typically created in iteration steps you can create execution variables and perform operations on them using the ActiveBatch Expression step. For example:
“ListOfHosts” is a new execution variable that’s created in the first job step. Instead of logging the results of each iteration we’re now appending the values to the newly created variable. Finally the last LOG step will display the complete results. Note the use of Function call within the LOG step.
String literals that contain a backslash (\) must be doubled (\\) if you want the actual backslash. This only applies to string literals (i.e. quoted strings) and not to variable values.
Functions
In the preceding section, a function named TrimEnd was used to remove the last trailing comma. You can specify functions anywhere you specify a variable (either as part of variable substitution or within an ActiveBatch Expression). For example:
This example shows the Replace function and how it might be used during a Move (or Rename) operation.
Error Handling
While each Job Step offers the ability, when an error is encountered, to either stop or continue the execution flow, a special flow control job step named “Try-Catch” allows for more precise error handling. For example:
A “MoveFile” of “test.dat” to “test.mst” is executed. If the MoveFile job step fails, the “Catch” portion will be executed. In this case, an IfFile job step verifies that the file exists and if not moves the file into the proper place. The “Finally” portion is executed regardless of any error encountered. In this case, it’s our intention to FTP that file to another server. TryCatch job steps can be nested anywhere within a job stream flow.