Using Oracle B2B to send binary documents

Introduction

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;

  • Create a document definition for the binary file

  • Configure the host to receive the binary document

  • Configure the remote trading partner profile

  • Create and deploy the agreement


Creating the document definition

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.


The Trading Partner Profile

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.

The listening channel

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.

%TO_PARTY%_%FROM_PARTY%_%DOCTYPE_REVISION%_%DOCTYPE_NAME%

In the Channel Attributes tab for the listening channel, select the check box for Internal and be sure to enable the channel.

The delivery 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.

Add document type

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 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.


The Trading Partner Agreement

At this point I have everything I need to create the trading partner agreement to send my binary document to the remote trading partner.

Create the agreement

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.



Test 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 created the listening channel. In this case the format is,

%TO_PARTY%_%FROM_PARTY%_%DOCTYPE_REVISION%_%DOCTYPE_NAME%

and the name of the document I'm sending will be

ORCLB2B_SFWY_1.0_Binary.dat

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 a lot of 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 figure which pieces belong together.

Comments:

Hi!

I followed your example(step by step), but when i put a file in the folder, nothing happens. am i missing something? i don't see any errors or anything. Plz help.

Thanks for this nice tutorial, it helped me a lot!

Posted by guest on September 05, 2012 at 07:37 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About


This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today