Orchestrator Guidelines

If orders are to be viewed in OMS, then the OMS services must be used to submit orders.

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

Orchestrator provides data interfaces for retrieving orders and plans. Invoking these on a live system will have a performance impact, so they should only be used when absolutely necessary. In most cases the same information is already available in OMS. 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 may 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 may 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, as well as retries for feasibility, plan development, and process component failures. This should not be set to less than 60000 milliseconds.

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

  1. Shutdown the Orchestrator Cache and Agent engines and purge the backing store database using SQL scripts. This should be done with TDS at the same time. Restart Orchestrator Cache and Agent. This will result in an outage of the system while the cleanup occurs.
  2. Make use of the CleanupAtEndOfOrder option in Orchestrator which automatically purges the order from the system when it reaches a COMPLETE, CANCELLED, or WITHDRAWN state. The order and plan details will still be retained within OMS, but no history will be available in Orchestrator.
  3. Make use of the DeleteOrder/DeletePlan operations in Orchestrator. This will require the use of an external project to determine which orders to purge and then invoke these services with the list of orderIDs. This should be done during a slow period in order processing due to the performance impact.