This appendix is useful for the customizer who would like to implement custom checkpoint business logic for new object processing.

Today checkpoint activity is to be considered a costly but unavoidable task that is necessary in order to maintain retention of a job. But the ultimate goal checkpointing is to avoid data corruption. This means that whatever business objects have been published to SAP should not be published again on restarting a TIBCO job. Publishing the same business object again may cause data corruption and/or a misleading Windchill status. In TIBCO, standard checkpoint activities are used strategically at every place where activity for publishing the business objects to ERP is executed. But this consumes a heavy amount of memory. To overcome this high memory consumption, custom-checkpoint mechanisms have been developed. The custom-checkpoint approach helps reduce the memory footprint and also reduces check-pointing time. In some scenarios a 40% to 60% improvements has been observed

If we consider the “GOAL TO AVOID DATA CORRUPTION”, then there is no need to really persist the entire job data (for e.g. all input/output of all processes, process stacks, subroutines, process data etc..). Instead, only the data that is required to help the restarted job to know what is remaining and what has been published so far needs to be persisted.

Out of the box, standard checkpoint activity has been removed from various places. Instead, thecustom-checkpoint mechanism has been applied, storing information on what objects and how many objects have been processed.

The following points detail a high level design that can aid in understanding and implementing custom-checkpoint mechanisms in any customized TIBCO project for Windchill ESI -SAP.

1) Custom –Checkpoint Schema:

Schema name: CheckPointSchema

Location: SharedConfigurations\ESISchemas\EAIMiddlewareSchemas

Details of the elements: This schema contains the metadata for all objects. Each object child elements contain the following:

Position- Position of the node to be processed next.

Count- Total number of elements in the node.

Action- Create/Change action for Part, BOM etc.

Result- Element contains the child elements to store part/material Revision processing results. The Child elements are same as the SharedConfigurations\ESISchemas\EAIMiddlewareSchemas\ESIObjectResult schema that used to store the Result message.

Method- Checkpoint method (GetParts, GetBOM, SetPosition etc). According to method name, Java code activity would return appropriate data.

TransactionNumber- Windchill ESI Transaction number

2) Write the CBO structure to a file instead of keeping CBO in memory

This is an added advantage in addition to having a custom checkpoint. The CBO might be consuming more memory. The business logic does not need the whole CBO when publishing a specific business object to SAP. CBO is an XML structure and the business logic would fetch the exact business object as and when required.

Process : Start_ESIResponse_Map_CBO_PD

Location: ProcessDefinitions\DataProcessing

3) Custom checkpoint process

The custom checkpoint process is the core process which takes input parameters per control data schema and custom checkpoint schema.

Process name: CustomCheckpoint.process

Location: ProcessDefinitions\Services

4) Java Code for GetCBO activity:

5) No need to pass CBO in the process ProcessDefinitions\DataProcessing\Start_CBO_ObjectPr ocess_PD

BOM Processing as an example:

The process definition that needs to be modified in order to incorporate custom checkpointing business logic for BOM processing: ProcessDefinitions\ERPCommunication\SAP\BOM\Start_CBOBOM_SAPCreateChange_PD process incorporating custom checkpoint:

Here is the BOM overall process definition that demonstrates the steps that involve to fetch the BOM data from CBO and set the next position to CheckPoint_<TransactionNumber>.xml in each iteration. Subsequent iterations fetch the next BOM to be published to SAP.

The process Start_CBOBOM_SAPCreateChange_PD has been modified such that it fetches the BOM data that needs to be published and sets the position (xml element position) after BOM data publication happens for that object.

CallProcess_CustomCheckpoint_GetBOM - fetches a BOM to be created next CallProcess_CustomCheckpoint_SetPosition - Increments the position of BOM in CheckPoint_<TransactionNumber>.xml

Iterate_BOM_AllCreateBOMs and Iterate_BOM_AllChangeBOMs would iterate over the destinations of BOM fetched by GetBOM activities.

CallProcess_StartCBOBOMSAPCreate and CallProcess_StartCBOBOMSAPChange input data would change accordingly. The filter for Children and Substitutes according to destination would be applied here.

Persisting Result message if required:

In the following process it is required to store result message as the business logic demanded for the result of an earlier execution.

Process name: Start_CBOPart_CreateRevisionLevel_PD

Location: ProcessDefinitions\ERPCommunication\SAP\Part

Other objects that have implemented the custom checkpoint business logic:

Apart from the BOM processing and create revision processing demonstated above, all other objects processing like Part, Routing, Document, ECN Resources etc. have been implemented using custom checkpoint mechanisms. Customizers can take an out of the box project as a guideline and implement the custom checkpoint business logic for new objects as well.