Using Chain Definitions
A chain executes one or more chain processes in parallel or sequentially. The chain processes are grouped into steps. All chain processes in a step are executed simultaneously (parallel processing) and the process server waits until all chain processes in a step get a final status before proceeding with the next step (sequential processing). Chain Processes executed by chains are still subject to routing using queues and resources and the limitations applied by queue limits and locks.
A Chain Definition is a JobDefinition
of type JOBCHAIN, where the scheduling and runtime behavior of the chain are defined.
A step gets an error status when one of its chain processes runs into a erroneous status. A chain aborts by default when one of its steps gets an error. This can be overridden by defining a status handler.
Tab-Specific Topics
Tab | Relevant topic |
---|---|
Chain | Creating chain definitions |
Parameters | Process definition parameters Parameter validation Using Table Parameters |
Retention | Setting the Retention Period for Processes |
Process Control | Setting the Scheduling Behavior |
Options | Setting Process Definition Options |
Wait Events | Process definition wait events |
Raise Events | Process definition raise events |
Locks | Process definition locks |
Runtime Limits | Process definition runtime limits |
Status | Process definition restart behavior |
Actions | Process definition actions |
Published Web Services | Connecting Web Services with Redwood Server |
Process Monitor Updates | Creating Process Monitors |
File Searches | Searching Files |
Security | Process definition object privileges |
Status Handlers
Status handlers can be defined at two levels:
- chain level, called default status handlers.
- Step level, called step status handlers.
A status handler defined at chain level acts as default for a step. Chain status handlers are overruled by any triggered step status handler. A status handler is triggered when one or more chain processes in a step, a step in the chain, or the chain itself reach a specific status:
Status handlers are evaluated as follows:
- A Completed handler triggers only if all chain processes in the step have the status Completed or Ignored.
- Otherwise, a Canceled handler triggers when there is at least one chain process with the status Canceled.
- Otherwise, an Error handler triggers when there is at least one chain process with the status Error.
- Otherwise, a Killed handler triggers when there is at least one chain process with the status Killed.
- Otherwise, an Unknown handler triggers when there is at least one chain process with the status Unknown.
- Finally, if no other handler is triggered, an 'Otherwise' handler will trigger.
Restart Behavior is used to control when the submit frame should be interrupted and the recurrence stopped. By default, final states resume the recurrence.
Context-Menu
Chain processes have the following context-menu actions:
Action | Description |
---|---|
Show Chain diagram | Display a diagram of the chain with related objects. |
Submit | Submit the chain definition; this action is only available for top-level chain definitions. |
Cancel non-final state chains | Cancel chains that have not reached a final state, see the States section for more information on states. |
Delete final state chains | Delete chain definitions that have reached a final state, see the States section for more information on states. |
Monitor related chains | Jump to the chain monitor with a temporary filter displaying chains and chain processes for the chain definition. |
Reset Statistics | Reset the runtime statistics for the chain. |
Export > Export | Export the chain definition into a CAR file. |
Export > Export with related objects | Export the chain definition into a CAR file including referenced objects. |
Promote > Promote to system | Promote the object to a remote system. |
Promote > Edit further then promote | Edit the export rule set prior to promoting. |
Promote | Promote the chain definition to another Redwood Server instance. |
Edit | Edit the chain definition. |
Edit Submit form | Edit the submit for of the chain. |
Edit Security | Edit the security of the chain definition. |
Delete | Delete the chain definition. |
Duplicate | Duplicate the chain definition. |
Expand all | Allows you to expand the entire tree of the chain definition. |
New | Create a new chain definition. |
Filter > New Filter | Create a new chain definition filter. |
Filter > Edit Filter | Edit current chain definition filter. |
Filter > Delete | Delete current chain definition filter. |
Filter > Duplicate Filter | Create a copy of the filter. |
Filter > Export Filter | Export the filter into a CAR file. |
Filter > Add to navigation bar | Add the filter to a navigation bar. |
Filter > Create filter from search | Create a filter from the current IntelliSearch query. |
Finding Chain Definitions
You can search for chain definitions using filters and the Search Chain Definitions box on the Chain Definitions tab. This box is known as the IntelliSearch box and located under your username on the top right-hand side of the user interface. Filters allow you to specify a list of objects with static criteria. IntelliSearch allows you to specify complex queries in a simple way using prefixes. Prefixes are used to specify which property you are searching in and have short as well as long syntaxes. For example, if you want to display all chain definitions with the term import in the comment, you would use the search criteria as follows:
c:import
You can search more than one property, as follows:
c:import n:BI
note
No spaces should be entered before or after the colon (: ).
See the Advanced Object Search for more information.
The following table illustrates the available prefixes for chain definitions:
Prefixes | Description |
---|---|
n, name | searches the name property |
c, comm, comment | searches the documentation property |
d, desc, description | searches the description property |
a, application | searches the application property |
cb, changedbefore | (internal) search for chains that changed before a certain ISO-8601 period |
Queue Selection
In general, when you set a queue on the chain, the queue is used for all calls that do not have the Queue scheduling parameter set.
When you have calls to one or more of the following definition types in your chain, no Queue scheduling parameter is set on the call and the queue set in the Queue scheduling parameter of the chain is not valid for the call, the queue is determined as follows:
SAPR3
,OraApps
,OraOHI
, andPublish
- the default queue of the specified remote system.JDBC
andAS400
- the queue is looked up in the following order:- First queue that only provides the process server in question (and no others).
- First queue that provides the process server in question.
The above queue selection mechanism requires the system constraints to be set on the definitions. The constraints are automatically created when you create the process definitions, however, it is possible to manually delete constraints - in this case you will be able to submit the chain and any process definition with an invalid queue will reach status Error.
When you have a call to a process definition that has an invalid Queue parameter specified on the call you will not be able to submit the chain.
Deleting Chain Definitions
You can only delete chain definitions when no other objects relate to them. For example, if the chain definition is still referred to in another chain definition, for example, the chain definition cannot be deleted until all relations have been deleted. You can see relations that relate to the chain definition in Related Objects in the lower detail pane and on the show page. Furthermore, chain processes of a chain will prevent you from deleting the chain, these will not be displayed in the Related Objects table.
The table in related objects contains three columns:
- Type - the type of object, like for chains, Source for the source of the chain process with a link to it
- Related Object - the name of the object with a link to it
- Used As - objects can sometimes be used in different roles
For example, chain definitions that are called in other chain definitions, will have the call-reference in Related Objects. The type will be Chain Process, and the Related Object will be the name of the chain definition, for example, if it is the first chain process in a step, it will be Process 1.
Chain Definition Messages
By default, several of the internal chain components create JobNotes under different circumstances to store processing and/or error messages. You can overrule this to create OperatorMessages instead by specifying the following registry entry and setting it to OperatorMessage.
/configuration/jcs/JobChainMessageLocation
JobChain