Orchestrator Guidelines

If orders are to be viewed in Order Management Server, then the Order Management Server services must be used to submit orders.

Notifications have an impact on overall Orchestrator performance. If notifications are not required, they must be disabled through the use of global variable flags. Turning off notifications in Orchestrator impacts the Activity Log in Order Management Server as well. In all cases, the data element of notifications must be turned off unless necessary.

Orchestrator provides data interfaces for retrieving orders and plans. Invoking these on a live system has a performance impact, so they must only be used when necessary. In most cases, the same information is already available in Order Management Server. Orchestrator provides a retry framework for process components in the event of a failure. This makes use of the cache server and a timer to retry. The system has been designed for this, but it might be more efficient to implement retry handling internally within the process component instead of relying on Orchestrator to do it. This is particularly true in the case of IPE process components.

When implementing error handling for process components, you can configure different error handler names in the plan fragment model. By default, Orchestrator specifies the error handler name as configured in global variables. If one is specified in the plan fragment model for a given process component, then that is specified in the call to the Plan Item Failed Handler. These names have no meaning within Orchestrator, but if necessary might be used within the Plan Item Failed Handler or subsequent error handling framework to route errors.

Scheduler polling interval in global variables is used to configure the cache server scheduler for timed events. This is used for time dependencies, for feasibility, plan development, and process component failures. This must not be set to less than 60000 milliseconds.

There are three methods currently available for cleaning up orders within Orchestrator:

  1. Shut down the Orchestrator Cache and Agent engines and purge the backing store database by using SQL scripts. This must be done with the Transient Data Store at the same time. Restart Orchestrator Cache and Agent. This results in an outage of the system when the cleanup occurs.
  2. Make use of the CleanupAtEndOfOrder option in Orchestrator that automatically purges the order from the system when it reaches a COMPLETE, CANCELLED, or WITHDRAWN state. The order and plan details are retained within Order Management Server, but no history is available in Orchestrator.
  3. Make use of the DeleteOrder/DeletePlan operations in Orchestrator. This requires the use of an external project to determine that orders to purge and then invoke these services with the list of orderIDs. This must be done during a slow period in order processing due to the performance impact.