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
• No change occurred since last published
• 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
To configure BusinessWorks use the following procedure:
1. Backup the following file:
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
2. In a text editor, open the following file:
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
3. Search for the following string:
tibco.env.CUSTOM_CP_EXT
4. Replace that string with the following:
tibco.env.CUSTOM_CP_EXT %RV_HOME%/lib/tibrvj.jar:%RV_HOME%/lib:%RV_HOME%/lib/64:
 |
There may be additional folders on the path. Keep these entries when replacing the string.
|
5. Search for the following string:
tibco.env.CUSTOM_LIB_PATH
6. Replace that string with the following:
tibco.env.CUSTOM_LIB_PATH %RV_HOME%/lib:%RV_HOME%/lib/64:
|
|
There may be additional folders on the path. Keep these entries when replacing the string.
|
7. Save and close designer.tra
8. Open TIBCO Designer and start the process archive.
One of the following SAP messages appears in the Windchill Enterprise Systems Transaction Log:
“No unit of measure found in ISO code __ in field BASE_UOM_ISO”
or
“The field MARA-MEINS/BAPI_MARA-BASE_UOM(_ISO) is defined as a required field; it does not contain an entry”
The following can cause this problem:
• 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
Windchill ESI returns an adapter timeout message
• 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.
|
|
Resolving this problem may require assistance from your Windchill ESI administrator.
|
Windchill PDMLink cannot subscribe to an EMS queue
The following can cause this problem:
• 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
|
|
Resolving this problem may require assistance from your Windchill ESI administrator.
|
Errors appear on PostResult
The following can cause this problem:
• 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 #ESISAPTroubleOther/WCPDMLinkCannotSubscribeEMSQueue).
• A database error occurred in Windchill PDMLink
• The PostResult RPC request was improperly formatted due to a programming error in the Windchill ESI middleware
|
|
Resolving this problem may require assistance from your Windchill ESI administrator.
|
There is no distribution target assignment for a published object
The following can cause this problem:
• 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.
No change occurred since last published
The following can cause this problem:
• 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.
Cannot connect to TIBCO BusinessWorks EMS, Windchill or both are failing to connect
The following can cause this issue:
• 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.
To resolve this issue:
• Set the url property associated with QueueConnectionFactory in factories.conf file to tcp://<machinename>:7222
where <machine name> is the machine that the EMS server is running on.
• 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:
>show connections
This gives you a list of which users are connected and from what machine. See TIBCO Enterprise for EMS documentation for more details.
TIBCO Adapters are timing out for ESI transactions
• 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 ESI response meta information file related error message appears
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.
Adapter fails to start with JMS transport
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:
Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms.
To resolve this issue:
• 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
Adapter fails to start status remains at “Starting up” in the Administrator
If the process ID "-1" is allocated to an adapter process, an error launching the adapter has occurred. This error is generally library dependent.
The following are known errors:
• 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
Similar issues have been observed on the following libraries:
• libresolv.so.2 sunw_2.2.2
• libstdc++-libc6.2-2.so.3
• libstdc++.so.5
Verify the following:
• 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.
Coyote connector has not been started
Verify the ESIOthers/WSHost and ESIOthers/WSPort variables.
Publication remains in a “Pending” state in the Enterprise Transaction Log
This issue can be caused by any of the following:
• 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.
1. Open a command window from the Windchill server.
2. Ping <JMSServer> using the exact string as it appears in the Windchill method server logs.
3. If the ping request fails, run ping <JMSServer_IP> .
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>
5. If the pin request continues to fail contact your network administrator.
• 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:
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
6. Commit
• 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.
JAX-M Parser or XML Parser failed to parse message using ResultResponse XML schema
The following error message is displayed:
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 issue is with the Java libraries shipped with JRE 6. This has not been observed with JRE 1.5 and JRE 1.6.0.18.
An "Input data invalid" message appears in the Enterprise Transaction Log
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
Transaction remains in a “Pending” state in the Enterprise Transaction Log
This issue can be caused by any of the following:
• 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:
1. Open a command window from the Windchill server.
2. Ping <JMSServer> using the exact string as it appears in the Windchill method server logs.
3. If the ping request fails, run ping <JMSServer_IP> .
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>
5. If the pin request continues to fail contact your network administrator.
• 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:
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
6. Commit
• 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
All EMS server configurations disappear after the EMS server is manually started
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:.
"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"
The TIBCO Adapter for an SAP instance stops working and an Error status is shown
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.
This issue currently only appears on HPUX v3 machines.
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.