1

I am trying to test an outbound messaging request end to end from sandbox A to B. Have imported the WSDL from sandbox A to B. Have given the endpoint in server A as server B's URL (but as both these sandboxes are on same server cs*,have give the url of the wsdl2apex ).

But it keeps failing with the below message :

org.xml.sax.SAXException: Processing instructions are not allowed within SOAP messages

Am just starting to explore API using Apex and would like to know: post executing the wsdl2apex in server B : with 4 classes --and referring the endpoint as i understand-still it doesn't work. I am not aware if I need to edit this wsdl2apex code to make this work or is a way that i can parse the XML received in the wsdl2apex to check if the message from server A has been received and then fails due to some xyz reason ?

Please suggest.

  • For Sandbox B to implement the WSDL and successfully receive the SOAP message it will require a value session id in the request. This won't be present in the outbound message. You will need to rethink your approach. It may be possible to use a public site to process the SOAP message. – Daniel Ballinger Feb 10 '15 at 8:26
  • There is an option in outbound message: which when ticked generates a session ID. I have already done that. and am wondering if is it due to the structure of my message which is incorrect or not as expected format in the target system? How to check: – user10727 Feb 10 '15 at 10:34
  • That session id is for your current session. If sandbox org A is different to sandbox org B then it won't be valid. Also, the session ID isn't sent in the way that is required to authenticate the request. – Daniel Ballinger Feb 10 '15 at 18:19
2

You can't have one Salesforce Org directly send an outbound message to another Org that implements the notification WSDL in Apex.

The webService that gets implemented in Apex will require a SessionID parameter in the request header. The outbound message can optionally include a session id, but there are two issues with this:

  1. It is a session id for the source org, not the target org. It is intended for the target to call back into the source org.
  2. It is not in the header as required by the webservice. Rather it is in the SOAP message body.

One option is to host the web service in a public Sites instance. Then you no longer require the target orgs session id.

See also:

  • I dint get then the issue mentioned with session ID's,as even if thats source specific : target is calling back with the same session ID. So If its possible to record them in some custom error handling table to see which session ID errored out for a request-then its an advantage only -not an issue...When you mentioned as issue am not clear how do you perceive it? – user10727 Feb 11 '15 at 14:40
  • @user10727 You could potentially call back using the valid session ID in the request for the source org. However, the target orgs web services will reject the request unless it includes a valid session ID for that org or is hosted in a site. – Daniel Ballinger Feb 11 '15 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.