Message Flow
The following figure describes the message communication process flow for Windchill ESI:
The numbered circles in the figure correspond to the following activities:
1. Windchill PDMLink notifiesWindchill ESI services that an object has changed state.
2. Windchill ESI services traverse the distribution targets associated with the released object and for each set of targets that belong to a given ERP instance, generate the Windchill ESI response message by invoking getXXX API. Apart from generating the response message, the API marks the released object or objects as publish pending.
3. The response message is then placed on the relevant JMS queue, which by default is named com.ptc.windchill.esi.DataResponse.<System ID>.<Client>. The placeholders in the name carry the usual meanings for an SAP system.
4. EAI software components process theWindchill PDMLink data contained in the JMS message.
 | Substantial processing may occur with the EAI software components or with the distribution targets between step 4 and step 5. These steps are not provided in the figure above. |
5. EAI software components receive acknowledgement from the distribution target and create a SOAP-formatted Result RPC request.
6. The RPC request is written to the result JMS queue. The default queue name is com.ptc.windchill.esi.Result.
7. Info*Engine receives the RPC request, the SOAP RPC parameters and JMS message properties which are then converted to parameters of aWindchill ESI services task
8. TheWindchill ESI services task invokes methods on theWindchill ESI services to record the distribution target acknowledgement.
9. Windchill ESI services create an appropriate RPC result response message while Info*Engine formats the resulting response message as a SOAP RPC response.
10. Info*Engine stores the RPC response in the JMS queue named on the RPC request. This is a temporary queue, the name for this queue is auto-generated by TIBCO EMS.
11. EAI software components process the result response message.
| | Steps 2–11 may occur multiple times in response to a singleWindchill ESI release. These steps are executed once for every ERP instance associated with the released object, and each execution of these steps represents a Windchill ESI transaction. A release may result in as many Windchill ESI response messages and PostResult RPC requests for Windchill ESI transactions as there are ERP instances in the release. There may also be an invocation of the postEvent API. For more information, see Transaction Management. The default queue names referred to in this section can be modified through certainWindchill ESI preferences. For more information, see the Windchill Enterprise Systems Integration Customizer's Guide - SAP R/3 |