I recently had a unique integration requirement where an external service provider was expecting XML within the SOAP request. One automatically thinks CDATA but in this case the endpoint required the XML to be escaped within a SOAP request.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://exacttarget.com/wsdl/partnerAPI"> <SOAP-ENV:Body> <ns1:CreateRequest> <ns1:Name>XML_Data</ns1:Name> <ns1:Value><order> <ns1:Attributes> <ns1:Name>Transaction_ID</ns1:Name><ns1:Value>Transaction_ID goes here</ns1:Value> </ns1:Attributes> </order> </ns1:Value> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
After multiple attempts trying to solve this with XSLT’s a colleague suggested why not move back to ESQL and use the ASBITSTREAM function. A few minutes later the below ESQL snippet proves once again why Message Broker is a true Enterprise ESB.
SET soapReq.ns:Objects.ns:Subscribers.ns:Attributes[1].ns:Name='XML_Data'; SET myMsgBlob = ASBITSTREAM(InputRoot.XMLNSC.Order, InputRoot.Properties.Encoding, InputRoot.Properties.CodedCharSetId, '','','', FolderBitStream ); SET myMsgChar = CAST( myMsgBlob AS CHAR CCSID InputRoot.Properties.CodedCharSetId ENCODING InputRoot.MQMD.Encoding); SET soapReq.ns:Objects.ns:Subscribers.ns:Attributes[1].ns:Value = myMsgChar;
What’s next?
If you’re still using WebSphere Message Broker, it might be time to think about upgrading your ESB. Whether you’re using an unsupported version of WMB or want the features of the newest IIB release, use our best practices compiled over the course of countless migrations to ease the process and maximize your IBM investment.