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