1 Reply Latest reply on Feb 3, 2015 8:40 AM by jorgemoralespou_2

    Manipulating SOAP Elements when using outbound SOAP Service

    nathan.samson
    nathan.samson Feb 3, 2015 7:01 AM

      Hi

       

      Intro:

      I have to call an external Soap Service via switchyard. Problem with this is, that the SOAP Service is a system written by a 3rd party company, and not willing to change the implementation quickly...

      This wouldn't be a problem if hte component would be working correctly, but it isn't.


      The SOAP/XML implementation has a lot of quirks, where the main one is that it only accepts the message if the SOAP local namespace is "soapenv", sadly enough my messages are being sent with the default "soap"

       

      Actual Question:

      I need to change the SOAP Messages so that the used namespace would be "soapenv" instead of the default generated "soap".

       

      I've tried using a custom composer & context mapper extending from the default SOAPComposer  / ContextMappers.

      After calling the default implementation (super.mapTo & super.decomposer); I've tried manipulating the SOAPMessage, Body & Envelope to

      setPrefix("soapenv"), after declaring this prefix on the root node.

       

      This changed the XML generated towards my service point but not in an expected way. As I remember correctly the root node (envelope) suddenly used "SOAP-Env", while the body & header indeed used "soapenv". This didn't please the external service at all...


      It seems that after the message composer / context mappers run, another component takes these bodys and headers and wraps them in a new SOAPMessage.

      Is there a way to manipulate the namespaces used (property flag, changing the SOAPMessage as I did, but in a slightly different way, ...)

       

      I am using Switchard 2.0 Beta 1

       

      Apologies

      I didn't keep all the details of what I tried, so I don't have exact code anymore of what I did, or what the outputs were. I was under time pressure so I've fixed my implementation to use the HTTP endpoint, manually creating the SOAPMessage (with correct prefixes), and sending these over the wire. it is a bit (lot!) hackish, but works for now...

       

      I can try to reproduce the problem in a minimal system if required, but I hope maybe someone can already help with the info I gave...

       

      Regards

      Nathan