Enterprise Administration > Windchill ESI > Administering Windchill ESI in an SAP Environment > Guidelines for Monitoring, Diagnosing, and Resolving Problems > Resolving Problems > Resolving Specific Problems > Transaction remains in pending state
  
Transaction remains in pending state
This could happen if the JMS server queues are not subscribed to as described in Configuring and Administering JMS Queues.
Common root causes are: the JMS server is not running when the Windchill method server starts, misconfigurations in the JMS properties of the Windchill adapter, or misconfigurations in the JMS server.
When Windchill ESI services are successful in subscribing to the JMS queue meant for receiving result messages, the following information is included in the Windchill PDMLink method server log:
Thread-10: subscription to queue "com.ptc.windchill.esi.Result" successful
If this information does not appear in the log, it means Windchill was unable to subscribe to the said queue successfully. In this case, all Windchill ESI transactions are left in a pending state. The transactions are processed once Windchill is able to subscribe to the queue successfully.
Normally, when Windchill ESI services are unable to subscribe to the queue because the JMS server is unavailable, Info*Engine receives an exception. Windchill ESI services log this exception in the Windchill Adapter transaction log. If TIBCO EMS is the JMS provider, the message contains the following text:
javax.ems.JMSException: Failed to connect to the server at tcp
As a detection measure, you may consider configuring your monitoring software to look for this or similar text. To resolve the issue, make sure the EMS server is up before the method server, and resolve any issues with the Windchill adapter JMS configuration and the JMS server configuration.
To avoid this issue, ensure the following:
• Only one WCESI user is connected to EMS server (can be viewed from EMS Administration Tool> Show connections)
• The number of ESISYS connections with ClientID (BW-ESIMaster_JMSConnection-queue-<Application Name>-Process_Archive) should be equal to the number of ERP instances configured (can be viewed from EMS Administration Tool> Show connections)
• All the connections are from either TIBCO or Windchill server in the current testing suite. There are no connections from a previous suite or from an alien machine (can be viewed from EMS Administration Tool> Show connections)
• Windchill and Process Archive connect to the same JMS Queue (can be viewed from EMS Administration Tool> Show queues)
• The queue com.ptc.windchill.esi.Result has only one receiver (can be viewed from EMS Administration Tool> Show queues)
• There should be no messages in any of the queues (can be viewed from EMS Administration Tool> Show queues)
• Windchill has subscribed to the DataResponse queue successfully. Connect to the JMS server and check if the DataResponse queue is created and the WCESI user is granted send rights on the DataResponse queue. If 'show queues' displays a * in front of the DataResponse queue name, it indicates that the queue is temporary and needs to be created. This issue is observed if the EAR is deployed manually. Run the following commands in the JMS Administration window to resolve the issue:
◦ create queue <DataResponse>
◦ setprop queue <DataResponse> secure
◦ grant queue <DataResponse> <EAI User> receive
◦ grant queue <DataResponse> <WC ESI User> send
◦ setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
◦ commit
• The Process Archive is connected to the same DataResponse queue that Windchill has subscribed to. Check the JMS Administration window, to confirm that the DataResponse queue is subscribed to by the Process Archive. In case of manual deployment this step is missed sometimes. If the DataResponse queue is subscribed to, check TIBCO Administrator--> Application Management --> Application Name --> Configuration-->Deployment Name--> Advanced -->ESIJMS/DataResponseQueue