Transient Data Store Guidelines
Transient Data Store data is replicated to the Order Management Server through the use of bridges. If the data in Order Management Server is out of date, verify that the correct bridges are in place for order and plan data.
Transient Data Store stores both order and plan data:
To make changes to order data in Transient Data Store, the updated order must be submitted as an amendment to Order Management Server and processed accordingly.
The process components must not make use of order data. Instead, they must use plan data.
Order data is stored in large XML CLOBs within the Transient Data Store backing store. Operations are provided to retrieve orders, but extensive use of these causes a performance impact.
Plan data is stored in concepts. Operations are provided to retrieve plans and plan items. This is the preferred way of retrieving data within Process Components.
The Transient Data Store is designed to be a pass-by-reference data cache. This means that duplicate data must not be replicated across plan items. One plan item must be a designated master for any given User Defined Field. If a particular User Defined Field is required by a plan item that doesn’t master this data, then the master plan item must be retrieved as well.
Where possible, process components must retrieve only data for its own plan item by using the GetPlanItems interface. If the process component requires data from other plan items, it must retrieve those by using the same interface at the same time if the planItemIDs of those other plan items are known.
It might be necessary for the process component to invoke GetPlanItems multiple times to determine the planItemIDs of dependent plan items. Where it is possible, bundle these into the same GetPlanItems call to reduce the number of invocations.
Retrieving the entire plan from the Transient Data Store by using GetPlan can be less efficient than retrieving plan items by using GetPlanItems. This is particularly the case for larger plans where a process component needs only a limited set of data. However, if it is necessary to do multiple GetPlanItems calls to determine dependent plan items, it might be more efficient to do a single GetPlan instead to get all the information. Make use of the IDs-only option to retrieve a list of IDs in the plan rather than the entire plan data.
The SetPlan operation is provided so that User Defined Fields might be set on the plan header. It is very important not to set data on the plan items by using this interface because it might potentially overwrite other plan item data that might be set by other process components. Setting the plan header User Defined Field data must only be done as a last resort. Use the plan item User Defined Field data instead.
The SetPlanItem operation is provided to set User Defined Field data on an individual plan item. By convention a process component must set plan item User Defined Field data only on its plan item. There is no technical restriction on setting data on other plan items, but this introduces a situation where there might be contention for the data. This is particularly a problem with plans with parallel tracks of execution. The convention of setting User Defined Field data only on its plan item eliminates the possibility of this happening.
Where possible make use of the merge data option in SetPlanItem. Using merge means sending through only the User Defined Fields that have changed rather than the entire set of User Defined Fields. It is only possible to merge data if unique User Defined Field names are implemented and configured in the Transient Data Store global variable flags. If the merge data is not used, then the entire set of User Defined Fields is be replaced by the set values. In this case, it is necessary to send through all User Defined Fields, whether or not they have been changed.
- Shut down the Transient Data Store Cache and Agent engines and purge the backing store database by using SQL scripts. This must be done with Orchestrator at the same time. Restart Transient Data Store Cache and Agent. This results in an outage of the system while the cleanup occurs.
- Make use of the CleanupAtEndOfOrder option in the Transient Data Store that automatically purges the order from the system when it reaches a COMPLETE or CANCELLED state. The order and plan details are still be retained within Order Management Server, but no history is available in Transient Data Store.
- Make use of the DeleteOrder/DeletePlan operations in the Transient Data Store. 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.