Creating Publishing History Objects
The Windchill ESI response generator (that is invoked upon releasing a business object from Windchill) creates an ESIRelease object that represents the given release. Besides, it creates an ESITransaction object for every ERP instance (or destination) in the release.
The initial status of the ESIRelease object and that of each of the newly created ESITransaction objects is set to “pending”.
 |
See the ESIResponseGenerator section for more information on the ESI response generator.
|
Windchill ESI RPCs GetPart, GetBOM, GetECN, GetDocument, GetPromotionRequest, GetProcessPlan and GetResource create ReleaseActivity objects for every object that is expected to be published. The status of the ReleaseActivity objects is set to “pending”.
|
|
An RPC named GetXXX here simply refers to a Java API named getXXX() of class StandardESIService. The ReleaseActivity objects are created by the markPending() API of class ESITransactionUtility, which is invoked from the createReleaseActivities() API of VdbBuilder, via the getXXX API.
|
Windchill ESI adds ReleaseActivity objects to a transaction whenever a PostResult RPC request for a subtransaction executes.
When a PostResult RPC request for an overall transaction executes, Windchill ESI sets the transaction status to "succeeded" or "failed". The RPC also causes all "pending" ReleaseActivity objects to be deleted. Also, if it is found that all the transactions in the given release have completed, the status of the ESIRelease object is set to an appropriate value – it is set to “succeeded” if all the transactions in the release have succeeded, and to “failed” if any of the transactions have failed.
The Windchill ESI Windchill Service processes the PostResult request. The service determines whether or not a subtransaction is being processed. The service then passes the request parameters to the appropriate method of ESITransactionUtility, which in turn creates a ReleaseActivity or updates the ESITransaction.
The Windchill ESI Windchill Service’s RPC support methods are not available for execution on remote clients.
The level of logging detail is controlled by these two Windchill ESI configuration preferences:
• Log Failed Subtransactions: If this preference is set to No, it causes the PostResult to ignore failed subtransaction messages. The default value for this preference is Yes.
• Log Successful Subtransactions: If this preference is set to No, all successful subtransaction messages are immediately flagged as deleted. This suppresses their display on the user interface, but records the object as having been released. The default value for this preference is Yes.
The figure Successful Transaction Status Values Over Time below, shows the status values of a successful transaction.
The following figure shows the status values of a failed transaction.
