I have created ECO and the ECO fails in the Process ECO stage (PIP) but it was still getting interfaced to Oracle. Can anybody tell me what causing th
com.oracle.bpel.client.BPELFault: faultName: {{http://schemas.oracle.com/bpel/extension}remoteFault} messageType: {{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage} parts: {{ summary=<summary>oracle.fabric.common.FabricInvocationException: Unable to invoke endpoint URI “http://set.at.runtime” successfully due to: javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Message send failed: set.at.runtime: Name or service not known</summary> ,detail=<detail>Unable to invoke endpoint URI “http://set.at.runtime” successfully due to: javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Message send failed: set.at.runtime: Name or service not known</detail> ,code=<code>null</code>} *—-Previous error has caused the below error—-* AGILE XREF ERROR – An error has occurred in the Agile requester that may have prevented the Agile cross reference records from being written in the ITEM_ITEMID and CHANGE_CHANGEID tables. If there are no Agile XREF records for the ECO and item(s) that were sent, manual intervention MUST be done to fix this issue. First, the original issue that caused the requester to fail must be corrected. Second, the ECO that was sent to the provider application needs to be removed from the provider application. Third, the provider (e.g. EBIZ or JDEE1) and common XREF records should be removed from the ITEM_ITEMID and CHANGE_CHANGEID tables for the ECO and item(s). If these steps are not done, the ECO cannot be resubmitted from the queue, as that ECO and item(s) will already exist in the provider edge application.
During any interface there are always chains of activities that must transpire to complete the whole process. These including creating records, updating ERP data, BoM updates, etc… some of these ‘chains’ must be completed to start and complete others. In order to understand all of the processes that must happen you will need to dive into what the interface (PIP) process is doing. i.e. checking if part exists, creating record, making any attribute updates, bom updates…. this should be in the tech docs either created by IT or your integration partner. Or if you are lucky and still maintain a support contract with the implementation partner…. you can ask them.
BTW, this appears that some temp tables were populated and do not ‘reset’ in the event of a failure. If it were me I would check all the destination apps to see if the ECO was indeed implemented… most times this is TRUE and then look to cancel the transaction. Sometimes thos just happens.
Any chance this occurred in a test environment after a clone from production? In that instance, it is possible for XREF tables to get out of sync. By the way, our company tolerated the classic PIP solution for several but recently replaced it with DocState by ZeroWaitState. Highly recommend it.