Often times in a demonstration or a POC, B2B is asked to transport binary encoded files. This is actually very easy to do, but there are a number of restrictions you should be aware of when considering whether to use B2B for this or not.
First, the file you're sending should be base64 encoded. Binary files that are not base64 encoded will invariably cause problems when sending them through B2B. Second, you have to consider how B2B will identify the document for the purpose associating it with the right agreement. Since the file is in a binary format, you cannot solely use the content of the document for this purpose. Third, is the binary document being sent as an attachment or by itself. This discussion focus' on how to send the document by itself. Finally, which transport protocols can be used for the purpose of sending and receiving binary document.
Configuring B2B to handle the binary document follows the same pattern as that of any other EDI transaction. From a high level those steps are;
To send a binary document, you will need to create a Custom Document definition. The illustration below shows that I've created a new custom document with a revision of 1.0, a document type of Binary, and a document definition name of Binary_def. Of course you can use any names you want. These are just the ones I've chosen.
The next illustration shows that there are no XSD or ecs files defined for the binary document definition. Without the XSD or ecs files, B2B has no information to use to try to translate the document so no attempt is made. Essentially the document is treated as opaque and simply passed on to the trading partner as is.
So the first thing you have to do is determine how you are receiving and sending the binary documents from the back end systems (application message) and to the remote trading partner (wire
message). If the application message is being sent to B2B using a SOA composite, B2B will determine the agreement it needs based on b2b header information you provide in the composite. If the application
message is being sent to B2B as a file on the local file system, then B2B will have to identify the agreement using information contained in the file name or the name of the directory where the file is located.
For this exercise, I'm using an internal listening channel for the Host to receive the binary documents from a back end system. I configured the the listening channel with the location of the file and the file name format mask below.
In the Channel Attributes tab for the listening channel, select the check box for Internal and be sure to enable the channel.
Next, I've configured a delivery channel for the remote trading partner. In this example I'm using a SFTP channel to send the document to the remote trading partner. When you are sending a binary document as I am here, you are limited to File, FTP, and AS2 for transport protocols. AS2 can only be used for outbound message transport (to remote trading partner) since there is no way to identify the document type for an inbound message using this protocol.
The Host trading partner, by default, can see all document types in the B2B repository. The remote trading partner must have each document type added to trading partner profile as needed. In the figure below I have added the the Custom-1.0-Binary document definition to the remote trading partner and made them a receiver only for that doc type.
At this point I have everything I need to create the trading partner agreement to send my binary document to the remote trading partner.
I've created the agreement and named it something appropriate. I then added the binary document definition I created earlier.
Next, I configure the agreement to use the SFTP delivery channel for my remote trading partner. There is no need to add any trading partner identifiers and I've left the validation button turned off. Save, Validate, and Deploy the agreement.
So now I can test my agreement by dropping any binary type message (pdf, bmp, jpg, exe, bin, etc.) into the location I defined in my internal listening channel. The name of the file must comply with the file name format mask I defined when I created the listening channel. In this case the format is,
and the name of the document I'm sending will be
From the information contained in the name of the document, B2B can determine that the trading partner agreement named SFWY_ORCLB2B_1.0_Binary_AGR should used to process this message. BTW, the similarity between the name of the doc and that of the agreement is more than a coincidence. When configuring agreements in B2B, I try to use as much commonality in my naming conventions as possible. That way when it comes time to create, deploy, and test the agreement, it is very easy to determine which pieces belong together.