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.
• Can't create a document (can't see it in Oracle Applications)
• Windchill ESI returns an adapter timeout message
• Windchill ESI successfully created one or more business objects in Oracle Applications, but indicates a failure
• 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
• When looking at the ESI Transaction Log and the EAI log, a failure occurs when publishing an object with Windchill ESI and an error message appears next to the object(s) I have published
• Responding to Master - Child Attribute Conflicts
• TIBCO Adapters are timing out for ESI transactions
• An ESI response meta information file error message appears
• On Windows servers the ADB Agent fails to start
• Publication remains in a “Pending” state in the Enterprise Transaction Log
• 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.
Can't create a document (can't see it in Oracle Applications)
Due to Oracle Applications API limitations, Windchill ESI does not support the publication of documents (attachments) to Oracle Applications.
Windchill ESI returns an adapter timeout message
• Adapter configuration is incorrect
• ESITarget is invalid
• Adapter instance(s) is not running
• The Oracle Applications server is unavailable
• Network congestion between the adapter and Oracle Applications
|
|
Resolving this problem may require assistance from your Windchill ESI administrator.
|
Windchill ESI successfully created one or more business objects in Oracle Applications, but indicates a failure
• Adapter configuration is incorrect
• Windchill ESI published the object(s) successfully, but timed out when waiting for Oracle Applications to return the subsequent log table message
|
|
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 preferencies 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
• Oracle Applications is offline
• TIBCO Adapter for Oracle Applications is not configured correctly
• 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
|
|
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:
• The Windchill ESI preference
Distribution Target Finder is set to
"com.ptc.winchill.esi.tgt.ESIRootInheritTargetFinder" so that objects inherit
distribution target assignment from the root object.
• The object is a component on a BOM and inherits distribution target assignments from the parent assembly or BOM.
• 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 ESIpreference 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 box 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
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 box as Windchill, same box as the middleware engine, or a different box altogether. As long as the values described above are set appropriately (and the machines are on the same network), Windchill PDMLinkand 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.
When looking at the ESI Transaction Log and the EAI log, a failure occurs when publishing an object with Windchill ESI and an error message appears next to the object(s) I have published
The following error message appears next to published objects:
Input Data Invalid
This error indicates that the data has not reached the Adapter. The Adapter schema validation failed while invoking the adapter activity.
In Oracle Applications before sending data to an adapter, some values are cross-referenced (from ESIORALookup.properties file) and some values are defaulted (from ESIORADefault.properties file). If these properties files are not properly configured (for example, the. BOM usage value is empty or the template ID is not matched) then the empty data is passed to the adapter and adapter activity throws the exception above. To know exactly which element is not populating properly, an ESI Administrator needs to view the Process engine log; the exception message details the element name and validation error.
Responding to Master - Child Attribute Conflicts
Oracle Inventory can be configured such that certain item attributes are controlled at the master organization level or the child organization level. If an item is published by ESI, and the operation attempts to set item attributes in a way that conflict with the attribute control settings, the Oracle Item Open Interface will return an error. The error message will contain the text given below, followed by a list of attributes that are causing the error.
Master - Child Conflict in one of these Attributes:
This message indicates that the ESI publish operation is attempting to set an item attribute in a child organization, that is controlled by the master organization, and the attribute value of the child item does not agree with the attribute value of the master item.
To resolve the issue, the attribute control settings should be reviewed to identify the conflict. Be aware that the item template being used to create the child item could also be setting an item attribute to an incorrect default value. Refer to the Item Setup and Control chapter of the Oracle Inventory User’s Guide for information on configuring attribute controls, and item templates.
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.
• When using Windchill Enterprise Systems Integration for Oracle Applications, the TIBCO adapter "MasterConfiguration" stops if any CN is published with a CN number exceeding the 10 character limit.
To resolve this issue, clear the ledger files with a .ldr extension from the following two folders under the ESI TIBCO installation directory:
1. <Install_Home>\tibco\bw\5.13\
2. <Install_Home>\tibco\tra\domain\<DOMAIN_NAME>\application\Oracle_Apps\ledger
|
|
All adapters must be stopped before you will be able to clear the ledger files.
|
An ESI response meta information file 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.
On Windows servers the ADB Agent fails to start
The following error message is displayed:
The ordinal 3823 could not be located in dynamic link library LIBEAY32.dll
To resolve this issue run the following commands:
1. MOVE /Y <Tibco_Home>/adapter/sdk/6.0/bin/libeay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/libeay32_bk.dll
2. MOVE /Y <Tibco_Home>/adapter/sdk/6.0/bin/ssleay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/ssleay32_bk.dll
3. COPY /Y <Tibco_Home>/tibrv/8.4/bin/libeay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/libeay32.dll
4. COPY /Y <Tibco_Home>/tibrv/8.4/bin/ssleay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/ssleay32.dll
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 JMS Server 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 ping 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 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 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 the 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.
• 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 value specified for the attribute DSN while creating the distribution target does not match the corresponding value specified while running the MICU for the given Oracle Applications 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.
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.
