...
- A "splitter" job has to be included for each "set" of job nodes that are to be carried out 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. - !! to be done !! - : link to Node Parameter Definition wiki-artikel.
- 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.
...
We refer to the pattern that results with this type of job chain as a "diamond" pattern. These diamonds can occur more than once in a job chain: both sequentially, as shown in the diagram above, in parallel and nested. They can also be combined with other job chain patterns such as - !! to be done !! - add definitions/links emerald or cross-over patterns).
...
- "splitter job node name" ":" "job name" - in the example diagram above, one of the first nodes would then be split_partitions:partition_1.
This allows the diagram algorithmus to in JOEto know and correctly display the nodes that directly follow on from the splitter. This is because the JobScheduler syntax does not recognise predecessor relationships (only successors).
...
For more information see the documentation for the JobSchedulerSynchronizeJobChains job.
Best practices
Start- und End-Knoten verwenden
Use "Start" and "End" nodes:
We recommend that you use our Wir empfehlen, in jeder Jobkette im ersten Knoten den Startjob /sos/jitl/JobChainStart und im letzten Knoten den Endjob start job as the first node in every job chain and our /sos/jitl/JobChainEnd zu verwenden.
Eindeutiger Name für Sync-Job
Um den Sync-Job eindeutig zu definieren empfehlen wir, den Namen der Jobkette, in welcher der Sync-Job verwendet wird, als Präfix in dem Job-Namen des Sync-Jobs zu verwenden.
...
end job as the last full node.
Give each sync job a unique name:
Give each sync job a unique name by using the name of the job chain in which the sync job is included as a prefix in the name of the sync job.
- For example: ideal_insert_to_export_table_parallel.export_table_build_sync
...
Follow our convention for node naming:
Splitter
...
nodes
We recommend that you start the node name of a splitter job with the prefix split (e.g. split_partitions). This means that the algorithmus in JOE that produces the diagrams "knows" that this is a splitter node and can render it correctly. This is nnecessary because "Splitter" is not included in the job node syntax.
Parallel nodes
We recommend that you use the following syntax for the names of job nodes that are processed in parallel:
- "splitter job node name" ":" "job name": in the example described above, one of the first nodes would then be split_partitions:partition_1.
This allows the diagram algorithmus in JOE to know and correctly display the nodes that directly follow on from the splitter. This is because the JobScheduler syntax does not recognise predecessor relationships (only successors).
Job nodes
As far as possible, the names of job nodes should identical to the job names (poss. without the ohne folder name). If a job is used more than once in a job chain, then the node name can be uniquely specified using a letter or number as a suffix.
Error nodes
The name of the error node should either contain the job name or be identical with it. This means that in the event of an processing error in the job chain, it is possible to see immediately in JOC the point in the job chain where the abnormal termination occured.
In addition, the name should start with an "!" (an exclamation point, or with another unique special character. This makes it easier to see in the order history in JOC that the job chain has terminated abnormally.
See also:
*
Downloads
You can download the example described in this FAQ :
Wir empfehlen, den Knoten-Namen eines Splitter-Jobs mit der Zeichenfolge split zu beginnen, zum Beispiel split_partitions. Damit "weiß" der Algorithmus, der das Diagramm erstellt, dass es sich um einen Splitter-Knoten handelt und kann ihn korrekt darstellen. Den Knote-Typ "Splitter" gibt es in der Syntax der Job-Knoten nicht.
Parallele Knoten
Für die Knoten-Namen der parallel zu verarbeitenden Jobs empfehlen wir die Syntax "Knoten-Name des Splitter-Jobs" ":" "Name des Jobs", zum Beispiel split_partitions:partition_1. Damit "weiß" der Diagramm-Algorithmus, welche Knoten die direkten Nachfolger, aka Vorgänger, des Splitters sind und kann dies korrekt darstellen. Die Syntax des JobScheduler kennt eine Vorgänger Beziehung nicht, deshalb die hilfsweise Darstellung über den Knoten-Namen.
Job-Knoten
Soweit möglich sollte der Name des Job-Knotens identisch sein mit dem Job-Namen (evtl. ohne Folder Namen). Wird ein Job mehrfach in einer Job-Kette verwendet, so können die Knoten-Namen durch eine angehängte Ziffer (oder Nummer) eindeutig spezifiziert werden.
Fehler-Knoten
Der Name des Fehler-Knotens sollte den Job-Namen enthalten oder identisch sein mit diesem. Damit kann bei einem Fehler im Ablauf der Jobkette sofort in JOC erkannt werden, an welcher Stelle die Jobkette abnormal beendet wurde.
Außerdem sollte der Name mit einem "!" (Ausrufezeichen, oder mit einem anderen eindeutigen Sonderzeichen) begonnen werden. Damit kann in JOC auf dem ersten Blick in der Order-Historie erkannt werden, daß die Job-Kette abnormal beendet wurde.
siehe auch
Downloads
Das verwendete Beispiel können Sie hier herunterladen insert_to_export_table_parallel.zip.