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 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 Release Activity objects for every object that is expected to be published. The status of the Release Activity 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 createdby the markPending() API of class ESITransactionUtility, which is invoked from the createReleaseActivities() API of VdbBuilder, via the getXXX API.
|
ERP Connector adds Release Activity objects to a transaction whenever a PostResult RPC request for a subtransaction executes. The first Release Activity that is added to the transaction causes its state to be set to processing.
When a PostResult RPC request for an overall transaction executes, ERP Connector sets the transaction status to succeeded or failed. The RPC also causes all pending Release Activity 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 ESITransaction Utility, 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.
