Transaction Management

The transaction management feature ofWindchill ESI services manages and keeps track of eachWindchill PDMLink business object published to a distribution target. Each publishing transaction inWindchill ESI is initiated by a standardWindchill PDMLink workflow and error handling for failed transactions is integrated with the workflow.

Transaction management serves the following three purposes:

• Provides a history of published objects enabling theWindchill PDMLink components inWindchill ESI to determine which objects to publish during subsequent publishing operations.

Windchill ESI services provides the following transaction management capabilities:

The overall publishing of a business object and its related objects to distribution targets that belong in a given ERP instance is represented as a transaction. Within this transaction, each of the related objects in the transaction, including the main object itself, is represented as a subtransaction. The object types covered by a subtransaction are part, part assembly (BOM), document, document link, Change Notice (CN), process plan, operation, sequence, resource, control characteristic and the associated quality link. Each subtransactions is stored as an object of type ReleaseActivity. Each ReleaseActivity is linked to the transaction in which it occurred and there is a separate Release Activity for each Windchill object published to a distribution target.

Each transaction stores the status of the overall transaction as: pending, processing, succeeded, or failed. The Release Activity objects store the status of the subtransactions as: pending, succeeded, or failed.

When an object is released from Windchill PDMLink,Windchill ESI services creates one or more transaction objects, each of which represents the release of the object to a given ERP instance. Initially, each transaction object in the release has a status of pending, this indicates that the object data is being published to theWindchill ESI business logic.

Windchill ESI services then queryWindchill PDMLink for the object data and generate a formatted output that constitutes the Windchill ESI response for the given ERP instance. The output is then sent to the Windchill ESI business logic, and is formatted according to the Windchill ESI Response Schema. For more information, see Implementing Windchill ESI.

Just before sending the formatted output to theWindchill ESI business logic, theWindchill ESI services create a ReleaseActivity object for eachWindchill PDMLink object and distribution target combination. The initial status of the Release Activity object is pending, indicating that the object/target has been published toWindchill ESI business logic, but its outcome on the EAI-side is not known. The existence of the pending ReleaseActivity object prevents theWindchill ESI services from publishing the object to the same distribution target again.

After theWindchill ESI business logic processes each subtransaction (object/target), it generates a completion notification. This notification includes the status (success or failure) and an optional textual message describing the status. WhenWindchill ESI services receive this notification, the services update the ReleaseActivity object for that specific object/target.

OnceWindchill ESI services receive the first completion notification for a subtransaction, they update the status of the relevant transaction the subtransaction is a part of to processing. At the end of processing the transaction, theWindchill ESI business logic generates a completion notification for the transaction. WhenWindchill ESI services receive this notification, they update the transaction's status as succeeded or failed depending on the status in the notification. At this time, the pending ReleaseActivity objects are deleted.

When a transaction fails, the overall Windchill ESI release is considered to have failed and the user who published the object can correct the problems that led to the failure and republish the object. For more information, see Enterprise Systems Transaction Administration Graphical User Interface. Resubmitted data originates from theWindchill ESI services; the EAI components of Windchill ESI do not store or handle any previous transactions or validate new transaction data against previous publications. All resubmitted data is processed as newly published objects. When objects are republished, by default only those objects that have changed since the last successful attempt to publish the objects was made are published. This maintains consistency between theWindchill ESI services and the distribution targets.

By resubmitting the data, you republish the object. A new transaction object is created for every ERP instance for which a failure occurred. However, the resubmitted data gets sent only to those distribution targets for which the original publish failed.

The Enterprise Systems Transaction Administration graphical user interface (GUI) allows users to view and edit the transaction history of published objects. Users responsible for initiating the publishing of an object to a distribution target have the authority to view and edit the transaction history of all the objects they have published. AWindchill ESI administrator has the authority to view and edit the transaction history for all released objects. Additionally, an administrator can correct and resubmit failed transactions. .

Over time, the amount of transaction history maintained by the system can get very large and cumbersome. SinceWindchill ESI needs this transaction history to determine which objects need to be published in future publishing activities, the actual data cannot be deleted from the system. Instead, the history can be marked as deleted so that it can be hidden from the end-user and not shown in the reports.