SOAP Messages with Attachments - IBM Websphere

The key aspect of this scenario implementation is configuring a service to handle SOAP Messages with Attachments.

The XB60 will receive these messages using SOAP standard over a protocol,such as HTTP, from a trading partner (as in our case).SOAP over HTTP (or Java Message Service (JMS)) does not have the same routing headers as AS2 or AS3, where specific information about the sender and the receiver is set.Those headers will need to be set in order for our B2B Gateway Service to consider them a valid trading scenario.

Information about how to route messages to the specific B2B Gateway is required. By using the B2BGW service, we take advantage of all the profiling and viewing features that the XB60 provides.

Therefore, there is a set of information that we need to retrieve from several sources:

  • The sender ID, which is retrieved from an incoming request, which, in our example, is the SOAP payload
  • Routing information that is stored on the device in an XML properties file

After the AS2 headers have been added, we extract the binary attachment and route it to the appropriate B2B Gateway Service that we use to trade with that specific partner. We will configure a processing policy on the Multi-Protocol Gateway Service to perform these tasks.

Scenario outline

This shows the architecture of the scenario.

SOAP Messages with Attachments use case outline

SOAP Messages with Attachments use case outline

The box in light blue represents the Multi-Protocol Gateway (SWA MPG); this service is the front end for the incoming SOAP Messages with Attachments requests. After wrapping the attachment in AS2 and setting the appropriate routing information, the message will be sent to the appropriate Binary Partner B2BGW service (purple box), where it is treated as a “regular AS2” transaction. It is important to notice that in this particular integration situation, MDNs will not be needed, because the original request from the partner was not generated with AS2, but with SOAP.

In order to implement this scenario,we perform these tasks:

  • Step 1: Creating the SWA_MPG Multi-Protocol Gateway
  • Step 2: Creating the SWA_Policy processing policy

Scenario implementation

Next,we describe the implementation.

Step 1: Creating the SWA_MPG Multi-Protocol Gateway
The MPGW service will be responsible for receiving the SOAP Messages with Attachments payload, extracting the binary attachment, and sending it to the B2B Gateway Servicewrapped in AS2.

The AS2 headers will be created based on the information coming in the SOAP payload (not in the attachment),and on certain internal data,as our “host name” or our own partner ID.

the General configuration tab window of the B2BGW Service: we have selected dynamic backend for the back-end type, SWA_http_FSH as the Front Side Protocol handler, and SWA_Policy as the Multi-Protocol Gateway processing policy (which will be explained in Step 2).

SWA_MPG General configuration tab details

SWA_MPG General configuration tab details

This shows the HTTP Front Side Handler configuration.

SWA_http_FSH configuration details

SWA_http_FSH configuration details

Notice that we have set the Response type as Pass Thru; there will be no response fromthe B2B Gateway Service.

SWA MPG General configuration tab details (continuation)

SWA MPG General configuration tab details (continuation)

Also, it is important to configure the MPGW to allow the attachments coming from therequest; therefore, access the Multi-Protocol Gateway service through the Objects tab, and go to the Proxy Settings tab.On that page, select Attach for the Request Attachment Processing Mode and configure the other fields as in .

SWA_MPG Proxy Settings configuration tab details

SWA_MPG Proxy Settings configuration tab detailsSWA_MPG Proxy Settings configuration tab details

Step 2: Creating the SWA_Policy processing policy
The processing policy included in the SWA MPG will handle the actions to fetch the attachment and route it with the appropriate AS2 headers to the back end.

Before configuring the policy, it is important to examine our sample SOAP with Attachmentpayload in Example below.

it is important to notice the various Multipurpose Internet Mail Extensions (MIME) headers that are defined in the MIME standard as Content-type, Content-Transfer-Encoding, and Content-ID.Specifically, the Content-ID MIME header will be used to fetch the attachment (identified as bin) in the Fetch action.

Example - Incoming SOAP with Attachment sample

This shows the processing policy. We only configure a request Rule Direction (select Client to Server), and no response is expected from the B2B Gateway Service (remember that this scenario is a one-way flow).

SWA_Policy processing policy configuration details

SWA_Policy processing policy configuration details

In the next steps, we describe the various processing actions.

Match action
We do not go into any detail about this action. It is a matching rule that handles all theincoming URLs with the “.*” regular expression.

Route action
The Route action will call a stylesheet (mpg-test-routing.xsl). This stylesheet will route the attachment to the B2B Gateway Service and add the mandatory AS2 headers.

Route action configuration details

Route action configuration details

is the stylesheet that we used in the Route action.

Example - The mpg-test-routing.xsl stylesheet used in the Route action

The mpg-test-routing.xsl stylesheet used in the Route action

A local XML properties file (Example below b2b-routing.xml) is used to retrieve the routing information for our B2B Gateway Service.The sender ID in the incoming SOAP message is retrieved by XPath and then compared with the sender IDs stored in the XML properties file (b2b-routing.xml). If it finds a match, it retrieves the routing path and sets all the AS2 headers: AS2 From, AS2 to, message ID (which is internally generated by DataPower),and Host.

With this information,the AS2 FSH from any B2B Gateway Service can successfully accept our binary payload.Here is the sample of the XML file b2b-routing.xml we use to route based on the incoming sender ID. More partners can be added by updating this file.

Example - The b2b-routing.xml that is used to provide the routing information

The b2b-routing.xml that is used to provide the routing information

Fetch action
The Fetch action is configured to extract the attachment coming in the SOAP Messages with Attachments payload. DataPower uses the MIME Content-ID header, which appears before the attachment.this Content-ID bin is highlighted.

Example - SOAP with Attachment Content-ID used to Fetch Attachment in bold

In the Configure Fetch Action indow ,set the Output context to attachment. This context will only contain the stripped attachment without the SOAP payload.

Fetch action configuration details

Fetch action configuration details

Important: Notice that bin in the Content-ID is only a value that we have used here as an example, but any value can be configured as long as it matches the value coming in the Multipurpose Internet Mail Extensions (MIME) Content-ID header.

Results action
In the Configure Results Action window,the Input context is the attachment context that we generated in the Fetch action.

Results action configuration details

Results action configuration details

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Websphere Topics