Hmm...
It still appears that this is a connection-related issue, because of 2 things:
- The error you presented earlier states that the connection is being refused (you can ignore the "DomainManagerBean" portion of the error, which is generic and look further down the stacktrace for the true error.
- If you point the external system at any IP address, you get the same error. So when it's pointed at the BPEL server, it's not even making the initial connection.
Since it doesn't appear to be working at a base level, let's take a step back and verify a couple of things:
- Have you gotten the EBS to OTM integration working correctly? Are you able to sync carriers and send deliveries over from EBS to OTM? This would verify the BPEL configuration and since EBS is the data master, we should start there anyways.
- By BPEL Suitcases, I meant the BPEL deployment jars (WshReceivePShipmentFromOtm, WshSendDlvyToOtmService, WshSendItemRefDataToOtm, etc). I just want to ensure that all of these (8 total, including the PO/AP integration flow) are deployed onto your BPEL server.
- You may want to consider WebServices instead. For all of our CU1 installs, we utilized straight BPEL communication, however in CU2, they changed the BPEL layout form in the External System, making it impossible to duplicate the old settings. Those who had integration working in CU1 and upgraded to CU2 were fine, but all of our clients who started fresh with CU2 had to utilize WebServices.
- If you do use WebServices, you'll need to manually add a couple of elements back into the default outbound XML. This is a known issue that was introduced in OTM v5.5 CU2. Unfortunately, I can't find the Doc ID immediately, but if you're not able to find it - let me know and I'll look it up.
I don't believe it's related to the error in Note 359390.1 (that's appears to be an RMI Context lookup exception, rather than a Connection Refused exception), though I'm glad that you searching Metalink.
Hope this helps!
--Chris