...
- A "splitter" job has to be included for each "set" of job nodes that are to be processed in parallel. The splitter job starts the parallel jobs as soon as it itself is started.
- In order to do this the splitter job has to "know" the names of the parallel nodes, which are specified in the splitter job's state_names parameter (see Setting_How to set and read job, order and node parameters).
- The parallel processing normally ends at a specific node in the the chain: thereafter processing continues serially. This node is the synchronisation node and implemented using the Sync-Job.
...
- The splitter job state_names parameter is used to specify the node names of the jobs that are to be started in parallel (see Setting_How to set and read job, order and node parameters).
- The node names are to be separated by semi-colons.
- In job chains with this diamond pattern structure, the parameters are specified for the job chain and referred to as node parameters. Node parameters can be used to specify parameters for more than one splitter in a job chain, independently of one another, as in our example, without creating conflicts.
...
A unique sync job is required at the end of every set of processes running in parallel (see Setting_up_a_sync_ Example showing how to set up a sync job), when further nodes in the job chain after the sync node are only to be processed after all the jobs (tasks) that are to be carried out in parallel have been completed without errors.
Each sync job has to be unique within a JobScheduler instance - and within a job chain as long as a cross-over pattern has not been implemented (see Example showing the synchronization of multiple job chains).
...