Permanent orders for distributed job chains

Current Situation

• Orders for distributed job chains are available as
  • ad hoc orders (non permanent), i.e. orders that are added by use of the API and that will not be repeated.
  • file orders that are created for incoming files and are removed with the files being processed.

Desired Behavior

• Permantent orders can be added to JobScheduler cluster members with distributed job chains.
• The user is responsible for the deployment of orders as files to hot folders in a JobScheduler cluster.
• JobScheduler supports CRUD operations for orders from files.

Order File Operations

• The handling of order files is the same as for single instances of JobScheduler and supports CRUD operations:
  • Adding an order file (*.order.xml) to a cluster member adds the order to the distributed job chain.
    • Though this works by adding the order to only one cluster member it is strictly recommended to deploy the order file to all cluster members.
  • Modifying an order file on one cluster member would apply the changes to the order to all cluster members.
    • It is required that the order file is modified on all cluster members.
    • If an order file were not modified on all cluster members then In case of JobScheduler restart two versions of the order would exist and would result in an arbitrary version to become effective for the cluster members.
  • Renaming an order file on one cluster member would rename the order for all cluster members.
    • It is required that the order file is renamed on all cluster members.
    • Though this feature works if the order file is exclusively renamed on the first cluster member, however, in case of JobScheduler restart the order files that have previously not been renamed would re-create the order which would result in the fact that the renamed order and the unchanged order would both be available.
  • Removing an order file from a cluster member removes the order from the distributed job chain in all cluster members.
    • It is required that the order file is removed from all cluster members.
    • Though this feature works if the order file is removed exclusively from the first cluster member, however, in case of JobScheduler restart the order files that have previously not been removed would re-create the order for the respective job chains.
• It is strictly recommended to use a JobScheduler Supervisor instance for the deployment of orders. A Supervisor will synchronize CRUD operations across JobScheduler cluster members.