Identifying Other Problems

This section describes common problems and possible causes that relate to areas that do not fit under the previous categories. A bulleted list of common problems follows. You can use the links to go directly to the information for the problem you are experiencing. If you do not see the problem you are experiencing in the list, or the suggested course of action does not solve the problem, contact your system administrator.

• Tibco BusinessWorks Designer throws "Cannot create Transport" and "Process Definition Load" errors when starting process archive

• One of the following SAP messages appears in the Windchill Enterprise Systems Transaction Log:

• Windchill ESI returns an adapter timeout message

• Windchill PDMLink cannot subscribe to an EMS queue

• Errors appear on PostResult

• There is no distribution target assignment for a published object error message appears

• No change occurred since last published error message appears

• Cannot connect to TIBCO BusinessWorks EMS, Windchill or both are failing to connect

• TIBCO Adapters are timing out for ESI transactions

• An ESI response meta information file related error message appears

• Adapter fails to start with JMS transport

• Adapter fails to start status remains at “Starting up” in the Administrator

• Coyote connector has not been started

• Publication remains in a “Pending” state in the Enterprise Transaction Log

• JAX-M Parser or XML Parser failed to parse message using ResultResponse XML schema

• An "Input data invalid" message appears in the Enterprise Transaction Log

• Transaction remains in a “Pending” state in the Enterprise Transaction Log

• All EMS server configurations disappear after the EMS server is manually started

• The TIBCO Adapter for an SAP instance stops working and an Error status is shown

• Promoting a set of business objects via a promotion request causes an RTM workflow to be created for each of those objects

• The ESI response file that is generated upon promoting one or more business objects does not contain any information on the promotion request apart from its ID

Tibco BusinessWorks Designer throws "Cannot create Transport" and "Process Definition Load" errors when starting process archive

• Cross reference lookup files do not have the correct values

• Default Unit of Measure in Windchill is missing or invalid

• Using SAP’s native unit of measure codes instead of the required ISO codes

• Adapter configuration is incorrect

• ESITarget is invalid

• Adapter instance(s) not running

• The SAP application server is unavailable

• Insufficient available connections between the adapter and SAP

• The in-flow of messages is more than the adapters capacity to process them.

• Windchill ESI services is not installed correctly

• EMS server not functioning

• Network error between Windchill Method Server and EMS server

• Windchill Adapter EMS configuration is not correct

• Windchill ESI preferences incorrectly specify one or more EMS queue names, EMS queue users, or EMS queue passwords

• A data issue exists in the data that is being published

• One or more required TIBCO components are offline

• Windchill ESI Services is unable to read from, or write to, a JMS queue (this has the same causes as Windchill PDMLink cannot subscribe to an EMS queue).

• A database error occurred in Windchill PDMLink

• The PostResult RPC request was improperly formatted due to a programming error in the Windchill ESI middleware

• You have attempted to publish an object prior to assigning any distribution targets.

• You have attempted to publish an object after removing all distribution target assignments.

• The Windchill ESI preference Check Iteration is set to No and only the iteration of the object being published has changed.

• There has been no change to the data since it was published last.

• You have already successfully published the object to all of the distribution targets that are associated with the object.

• An attempt was made to publish an already published object after adding new distribution target assignments to it.

• The EMS server is not configured properly. When you specify the name of the EMS server as "localhost", that server is only recognized on the machine on which it is running. No other machine can connect to it. An application that is set to connect to the EMS server "localhost" attempts to find the EMS server running on the same machine. If the server is not found, an error appears. When you specify a machine name as your server name, other machines can connect to your EMS server.

• Set the url property associated with QueueConnectionFactory in factories.conf file to tcp://<machinename>:7222

• Set the global variable ESIJMS/JNDIContextURL (in BW Engine, TIBCO Designer or in TIBCO Administrator, depending on where you are running ESI from) to = tibjmsnaming://<machinename where the EMS server is running>:7222.

It does not matter where this EMS server resides. It can reside on the same machine as Windchill, the same machine as the middleware engine, or a different machine altogether. If the values described above are set appropriately (and the machines are on the same network), Windchill PDMLink and the middleware will be able to connect to the correct EMS server.

To determine which machine and username is connected to an EMS server, in the EMS Administration Tool, type the command:

This gives you a list of which users are connected and from what machine. See TIBCO Enterprise for EMS documentation for more details.

• If the TIBCO Adapters start timing out after their connection to the ERP is broken, check the connection status and restart the adapters. This can be confirmed by looking at the adapter log.

• Check Max job and flow limit settings of bwengine at TIBCO Administrator GUI, Application Management, <Application_Name>, Configuration, Process Archive.par, TIBCO BusinessWorks Process Configurations, ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_End_PD. It should be a finite non zero number based on load testing done at user environment

• If the TIBCO Adapters start timing out even if their connection to the ERP is not broken, check TIBCO Administrator GUI, Application Management, <Application_Name>, Configuration, ESISAPAdapterConfiguration.aar, Advanced, adr3.maxconnections value. This value should be equal to the max job settings of bwengine

An error message pertaining to the ESI response meta information file appears when clicking Finish from the New Distribution Target or the Edit Distribution Target window

This can be caused by any of the following issues with the value specified for the distribution target attribute ESI Response Meta Information File Path:

• The path to the file is a non-existent one.

• The contents of the file do not conform to the underlying schema (out-of-the-box, the schema is provided by the file ESIResponseMetaInformation.xsd).

• The contents of the file are invalid – for example, a MapInformation element in the file references a non-existent Map element. There could be a variety of other reasons for why the contents of the file may be considered invalid.

• The id attribute associated with at least one Map element in the file is already in use with a different Map element that is not identical to the former. For example, this can occur if the user makes the distribution target (being created or edited) point to a certain ESI response meta information file, whose Map element for parts is modified to accommodate an additional global attribute, but whose id attribute continues to have the value ESIPart, while a different distribution target is already pointing to the ESI response meta information file that is provided by default.

After installing TIBCO Runtime Agent 5.6 and TIBCO Runtime Agent 5.6.1, TIBCO Adapter projects using Enterprise Message Service as their transport do not start up from TIBCO Designer. The following error message appears:

• On Windows: Back up, and then remove libeay32.dll and ssleay32.dll from <TIBCO_HOME>/adapters/sdk/version/<lib>

• On UNIX: Back up, and then remove the libssl and libcrypto openssl libraries from the TIBCO_HOME/adapters/sdk/version/lib directory

If the process ID "-1" is allocated to an adapter process, an error launching the adapter has occurred. This error is generally library dependent.

• Error while loading shared libraries: librfccm.so: wrong ELF class: ELFCLASS64

This error may occur if you have used 64 bit SAPJCo libraries. On certain platforms, like Windows X64 and Linux ia64, the SAP Adapter is a 32 bit application. Using 32 bit libraries will resolve the issue

• Error while loading shared libraries: librfccm.so: wrong ELF class: ELFCLASS32

This error may occur if you have used 32 bit SAPJCo libraries. On certain platforms, like HPUX IA64 and Solaris SPARC, the SAP Adapter is a 64 bit application. Using 64 bit libraries will resolve the issue

• libresolv.so.2 sunw_2.2.2

• libstdc++-libc6.2-2.so.3

• The correct compatibility packages have been installed. This will resolve any dependencies.

• If Java environmental variables have been set, ensure that the versions are compatible. TIBCO applications also installs JRE 1.5 and 1.6. You can remove any Java settings that you have already configured and allow the TIBCO application to set the appropriate Java variables.

• ON HPUX and Solaris machines if the Java variables have already been set ensure that the class path contains 64 bit Java libraries as the SAP Adapter is a 64 bit application on these platforms.

• There was a failure to connect to the JMS Server tcp://<JMSServer>:7222

This could happen if the JMSServer is either not reachable or the hostname is not resolved to the correct IP address. An incorrect version of the tibjms.jar file could also cause this issue. To resolve this issue ensure that the tibjms.jar file from the Windchill server is using the correct version of JMS on the TIBCO server.

4. If the ping request succeeds, use the displayed IP address or add the following entry to the %Windir%\System32\drivers\etc\hosts file: <JMSServer_IP> <JMSServer>

• There was a failure in connecting to the DataResponse queue.

To verify that this was the cause of this issue connect to the JMS server and check that the DataResponse queue has been created and the WCESI user has been granted send rights on the DataResponse queue. If an asterix (*) appears in front of the DataResponse queue name, the queue is temporary and needs to be created. This issue can occur when the EAR has been deployed manually. To resolve this issue run following commands in the JMS Administration window:

• The Process Archive is not connected to the same DataResponse queue.

Open the JMS Administration window to confirm that the DataResponse queue has been subscribed to by the Process Archive. When manually deploying this step is often omitted, resulting in the error. If the DataResponse queue has not been subscribed to verify the value in the DataResponseQueue by navigating to TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue

• Only one WCESI user is connected to EMS server. Verify by navigating to EMS Administration Tool> Show connections.

• The number of ESISYS connections with ClientID (BW-ESIMaster_JMSConnection-queue-<Application Name>-Process_Archive) should be equal to number of ERP instances configured. If not, there is a possibility that the additional instances of running process archives are consuming the ESI Response message. Verify the number of ESISYS connections by navigating to EMS Administration Tool> Show connections.

• Verify that all connections are from either the TIBCO or Windchill server in the current testing suite and that no connections are from the previous suite or are from an alien machine. If not, there is a possibility that the additional instances of running process archives are consuming the ESI Response message. Verify the number of ESISYS connections by navigating to EMS Administration Tool> Show connections. Verify by navigating to EMS Administration Tool> Show connections.

• The Windchill and Process Archives are connected to the same JMS Queue. Verify by navigating to EMS Administration Tool> Show queues.

• The com.ptc.windchill.esi.Result Queue has only one receiver. Verify by navigating to EMS Administration Tool> Show queues.

• There are messages remaining in a queue. Verify by navigating to EMS Administration Tool> Show queues.

• The values specified for the attributes Client and System ID while creating the distribution target do not match the corresponding values specified while running the MICU for the given SAP instance. This results in Windchill ESI services placing the ESI response message on a non-existent EMS queue, which in turn causes the ESI transaction to remain in a pending state.

2,,2,2,1,20021,Windchill sent an invalid ResultResponse message. JAX-M Parser or XML Parser failed to parse message using ResultResponse XML schema. See Windchill logs for details,,,,,Job-1 Error in [ProcessDefinitions/Services/WCResult_Service.process/RepeatUntilTrue_SendAllResults/RepeatOnError_Result_ResultResponse/Java_ParseESIResultResponse]While executing [invoke] encountered [com.ptc.windchill.esi.ext.ESISoapException] : [Unable to create envelope from given source: at com.ptc.windchill.esi.ext.SoapResponseFinder.getResult(SoapResponseFinder.java:216)]

This error indicates a schema validation failure in the “Invoke an adapter request response service” activity. A detailed description and stacktrace are logged into processArchive logs. The logs will indicate the exact reason of schema mismatch. For example:

validation error: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs ({com.tibco.xml.validation}SIMPLE_E_LENGTH_TOO_LONG) at /aeRequestInputType[1]/{http://www.tibco.com/xmlns/ae2xsd/2002/05/ae/700/basic/functionModules}__caret_request_caret_BAPI__MATERIAL__SAVEREPLICA_caret_BAPI__MATERIAL__SAVEREPLICA[1]/MATERIALDESCRIPTION[1]/item[2]/MATL__DESC[1]com.tibco.xml.validation.exception.k: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs

• The ESI services could not write the ESIResponse to DataResponse queue of EMS server. To verify this, navigate to Info*Engine Administration > Property editor > Core JMS Properties and confirm that JMS BASE URI is correct. Then refer to the method server logs to confirm DataResponse queue is subscribed successfully.

• Failed to connect to JMS server tcp://<JMSServer>:7222. To resolve this ensure that the tibjms.jar file from the Windchill server has been taken from the correct version of JMS on the TIBCO server.

• The JMSServer is either not reachable or the hostname is not resolved to the IP address. This could be caused by an incorrect version of the file tibjms.jar . To verify this:

4. If the ping request succeeds, use the displayed IP address or add the following entry to the %Windir%\System32\drivers\etc\hosts file: <JMSServer_IP> <JMSServer>

• There was a failure in connecting to the DataResponse queue.

• The Process Archive is not connected to the same DataResponse queue.

Open the JMS Administration window to confirm that the DataResponse queue has been subscribed to by the Process Archive. When manually deploying this step is often omitted, resulting in the error. If the DataResponse queue has been subscribed to verify the DataResponseQueue by navigating to the TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue

The command to start the EMS server has been changed in version 5.1.4. In EMS versions 4.x the start command was "./tibemsd". In EMS version 5.1.4 it is ./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf. The command uses a relative path and it should be executed from "<TIBCO_HOME>\ems\5.1\bin".

To resolve this issue stop the process started by the command "./tibemsd" and start the EMS server with the correct command:.

This issue occurs because of an adapter stack overflow error. TIBCO support has accepted it as a known issue and suggested increasing a parameter adr3.stacksize to an appropriate value to resolve this issue. It has been tested it with 524288 (512 KB) successfully.

To increase adr3.stacksize navigate to TIBCO Administrator GUI > Application Management > <ApplicationName> Configuration > ESISAPAdapterConfiguration.aar > Advanced.

Promoting a set of business objects via a promotion request causes an RTM workflow to be created for each of those objects

This can occur if the preference Publish Promotion Requests has a value of No. Set the preference to Yes in order for the objects in the promotion request to be published via a single RTM workflow.

The ESI response file that is generated upon promoting one or more business objects does not contain any information on the promotion request apart from its ID

This is an expected behavior. If you wish to send other attributes on the promotion request with the ESI response in a separate XML element, you need to configure the ESI response meta information file as appropriate.