I was recently working on an integration in Oracle Integration Cloud (OIC) which leveraged REST APIs exposed from Oracle HCM. I needed to retrieve details from the REST endpoint in the image below. The overall solution would take this REST response and write the data to an XML file to be consumed by another system.

As you can see in the REST response headers above, the content-type of the response is application/octet-stream. This response type has been supported by the Oracle Integration REST adapter for a couple of years now and is configurable in the trigger request and response allowing the possibility to both invoke REST integrations using binary content and return binary content in a REST response.

What is application/octet-stream MIME attachments?

Effectively, a MIME attachment with the content type “application/octet-stream” is a binary file. Usually, the MIME attachment is an application file or document that may be opened in specific applications. For example, a spreadsheet .xlsx file would open in Microsoft Excel, a .docx file would open in Microsoft Word or an .exe file would indicate a Windows or DOS executable program. However, the application/octet-stream MIME type is used for unknown binary files and is in fact the default binary file. File contents will be preserved in binary but it requires the processor to understand and determine the specific file type (e.g, from a filename extension).

Using application/octet-stream in OIC

This feature can be used by selecting the “Raw” option within the invoke Request/Response page when configuring the REST adapter. When you select this option, you do not need to provide a schema because the payload does not have a pre-defined structure. This feature can also be used with other types that can be sent as raw bytes. Refer to Oracle documentation for more details on this feature.

Processing application/octet-stream data

As I mentioned earlier, in this particular scenario, I was required to pull text data from the REST response and present that into an XML file. The REST endpoint in question held HTML formatted job descriptions in which I needed to preserve the HTML formatting tags.

The response returned from the REST endpoint, due to the application/octet-stream raw type (as can be seen below) is actually a “streamReference”. i.e, a reference to the binary file stored in OIC object storage.

In order to retrieve the textual representation of this binary file, I wrote to an interim/stage file using the Oracle FTP adapter. However, to do this, given the streamReference variable is an “unknown” format/type, I had to use a method which effectively tells the FTP adapter.. “I don’t know the format, so try to write it into an XML element”.

I did this by using an XSD file as below:

<?xml version = "1.0" encoding = "UTF-8"?>
<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/opaque/" xmlns="http://www.w3.org/2001/XMLSchema">
      <element name="opaqueElement" type="base64Binary"/>
</schema>

From a mapping perspective (to the FTP adapter), I used the encodeReferenceToBase64() function to convert the file location reference to textual base-64 value.

This text can then be read from the interim/stage file and mapped to the final XML file destination.

Encoding and Decoding File Attachment Content

Given I’ve mentioned above, the use of “encodeReferenceToBase64()” function in Oracle Integration Cloud, I thought it would also be useful to share brief details of 2 key XPath functions available to use with OIC adapters.

• encodeReferenceToBase64(String reference) – This function accepts the object storage or Virtual File System reference as an input and returns the base64-encoded content of the file returned as a value. The function has a file size limit of 10MB, where exceeding this limit will result in an exception message of "Maximum file size supported is 10MB".
• decodeBase64ToReference(String base64String) – This function accepts the base64-encoded content as an input, decodes it and stores the value in a file within the Virtual File System. The reference location of the file is returned. The function does not have a file size limit.