Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Multiple Processes

Unlike Parallel Jobs, input and or output (passive) stages can be deployed in designs which enable a single stage to act as both an input and output in the one a Server job. When a job contains such a design, the Server engine will synchronize execution of the stage, so that any load processes are completed before performing the read processes.

For example, consider the following job design:

...

The processes used by the server job will be synchronized such to ensure that the stages grouped by the yellow annotation on the left in Group 1 (above) are fully executed before starting the stages grouped by the annotation on the right.in Group 2. To convert this job design to run on the PX engine we’ll need to create a Parallel job representing each of the job’s synchronised sub-groups (1 and 2) and a coordinating sequence to mimic the synchronization provided by the Server Engine:

Gliffy
imageAttachmentIdatt2148630531
macroIdaa590c06-7521-45a1-b873-f4e3efa2ef39
baseUrlhttps://datamigrators.atlassian.net/wiki
nameSynchronisation Stages Decomposed
diagramAttachmentIdatt2148204553
containerId1432027151
timestamp1645491577312

...

A similar challenge exists for shared containers that include stages that act as both a source and target. The same principles apply here but need to split the shared containers:

...

Note

Jobs that use DSJobName and DSJobController macros will no longer produce the same output after applying this transformation. Any easy solution would be to have the sequence capture these values and pass them to the child jobs as parameters. Any existing use of DSJobName and DSJobController would then be updated to use the parameters.