OSB - Processing a SOAP inbound attachment

Problem:
A SOAP service returns a XOP/MOTM attachment as a zip file in its response. This must be unzipped to obtain the XML document inside and then write that file to a folder.

Solution:
There are a bunch of blogs already which describe how to retrieve a XOP/MOTM attachment from a web service response, but why not document my process as well.

The Business Service must first be edited so that XOP/MOTM is enabled, which is disabled by default:

There are two options here as to how to handle the attachment. The difference is explained in this blogpost:

Include Binary Data by Reference: (Default) In an outbound response message, replace xop:Include elements with ctx:binary-content elements when setting up the $body message context variable. 

Include Binary Data by Value: In an outbound response message, replace xop:Include elements with Base64-encoded text versions of corresponding binary data when setting up the $body message context variable.

In my case I used Reference since I didn't really have to validate the XML or do anything else with it. This is how the web service would return its response:

So to get the binary-content element and pass it directly to the Java callout as a byte array, you have to select the whole binary-content element like so:

$body/typ:getDocumentsForFilePrefixResponse/*:result/*:Content/*:binary-content

The Java class which takes care of unzipping the file and returning the contents as String can be found in this blog post: An example of how to process a zipped file in OSB by Mike Muller. Putting it here as well for future reference:

To be able to write it to a file, all that's left is to call the encode method in the Java class, passing the result of the first Java callout to this method. This will transform the XML (as string) into base64 which will allow you to invoke the File adapter to write the file.

BPEL - FTP Adapter writes XML file without prefix in the root element

Problem:

When writing a file using the FTP adapter with the message schema defined, for some reason the output would come out without a prefix in the root element, like so:

This would happen even with the XSL transformation declaring the prefix in the root element:



I'm not sure if it's a bug or the fact that we have our schema/transformation wrong, but a coworker and I just couldn't get it to work, so we opted for a workaround using Java embedding.

Solution:

We used the following code to add the prefix to the root element by transforming the XML into a string:

 try{   
   oracle.xml.parser.v2.XMLElement responseFile = (oracle.xml.parser.v2.XMLElement)getVariableData("varResponseFile");   
   //setting prefix to root   
   oracle.xml.parser.v2.XMLNode firstChild = (oracle.xml.parser.v2.XMLNode)responseFile.getFirstChild();   
   responseFile.setPrefix(firstChild.getPrefix());   
   //getting xml document   
   oracle.xml.parser.v2.XMLDocument responseFileXML = (oracle.xml.parser.v2.XMLDocument)responseFile.getDocument();   
   //setting prologue   
   responseFileXML.setVersion("1.0");   
   responseFileXML.setEncoding("UTF-8");   
   //writing xml document   
   java.io.ByteArrayOutputStream outputStream = new java.io.ByteArrayOutputStream();   
   responseFileXML.print(outputStream );   
   String responseFileString = outputStream.toString();   
   //encode xml document   
   oracle.soa.common.util.Base64Encoder encoder = new oracle.soa.common.util.Base64Encoder();   
   String stringEnconded = null;   
   stringEnconded = encoder.encode(responseFileString);   
   //setting xml encoded   
   setVariableData("encodedBody",stringEnconded);   
 } catch (Exception e) {   
   addAuditTrailEntry("Error encoding Response File: " + e.getMessage());   
   throw new RuntimeException(e);   
 }  

We would of course change the FTP message schema to opaque instead. Applying this code would then write the XML file correctly:



If anyone knows how to do this without Java (or perhaps what we are doing wrong in the first place), please let us know in the comments!