Transaction Management
The transaction management feature of Windchill ESI services manages and keeps track of eachWindchill PDMLink business object published to a distribution target. Each publishing transaction in Windchill ESI is initiated by a standardWindchill PDMLink workflow and error handling for failed transactions is integrated with the workflow.
Purpose and Capabilities
Transaction management serves the following three purposes:
• Provides an audit trail ofWindchill PDMLink objects published to a distribution target.
• Provides a history of published objects enabling theWindchill PDMLink components in Windchill ESI to determine which objects to publish during subsequent publishing operations.
• Enables an end user to view and manage this history, through the Enterprise Systems Transaction Administration user interface.
Windchill ESI services provides the following transaction management capabilities:
• A persistent set of Java classes that record transaction activity and track the status of Windchill ESI publishing activities.
• A set of APIs that prevent concurrent attempts to publish the same Windchill object.
• RPCs that allow external processes to request Windchill ESI services to record the status of a publishing activity.
• A graphical user interface that displays (and allows the user to edit) the publishing status that Windchill ESI services have recorded.
Transactions and Subtransactions
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 subtransaction is stored as an object of the type ReleaseActivity. Each ReleaseActivity object is linked to the transaction in which it occurred. However, there is a separate ReleaseActivity for each Windchill object published to a distribution target.
Each transaction stores the status of the overall transaction as: pending, processing, succeeded, failed, warning or partially_succeeded. The ReleaseActivity objects store the status of the subtransactions as: pending, succeeded, or failed.
Transaction Tracking
When an object is released from Windchill PDMLink, Windchill ESI services create 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, indicating that the object data is being published to the Windchill ESI business logic.
Windchill ESI services then query
Windchill 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.
Windchill ESI services then query
Windchill 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 the Windchill ESI business logic, the Windchill ESI services create a ReleaseActivity status object for eachWindchill PDMLink object and distribution target combination. The initial status of the ReleaseActivity object is pending, indicating that the object/target has been published to Windchill 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 the Windchill 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. When Windchill ESI services receive this notification, the services update the ReleaseActivity object for that specific object/target.
Once Windchill ESI services receive the first completion notification for a subtransaction, they update the status of the relevant transaction to processing. At the end of processing the transaction, the Windchill ESI business logic generates a completion notification for the transaction. When Windchill 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.
|
|
The activities described in the above paragraph are carried out for every transaction in the release.
|
Transaction Resubmission
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. Resubmitted data originates from the Windchill 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 the Windchill ESI services and the distribution targets.
|
|
Upon republishing an object by resubmitting the data, a new transaction object is created for every ERP instance where a failure occurred. However, the resubmitted data gets sent only to those distribution targets for which the original publish failed.
|
Enterprise Systems Transaction Administration Graphical User Interface
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. A Windchill 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.
Deletion of Transaction History
Over time, the amount of transaction history maintained by the system can get very large and cumbersome. Since Windchill 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.
