Binary AS2 over HTTP multi-step use case solution - IBM Websphere

This outlines the Binary over HTTP to AS2 architecture.

These steps outline the processing flow:

  1. The binary message is sent by HubBinary back-end application to the MQ queue.
  2. The binary message is fetched from the queue and transformed by a MPGW object to include AS2 headers and transmitted over HTTP to a B2BGW.
  3. The AS2 wrapped binary message is sent to PartnerBinary B2B Gateway over HTTP.
  4. The message is received by B2BGW AS2 Front Side Handler, and the AS2 headers are processed to obtain routing information.
  5. The Partner profile is read and the appropriate destination is selected based on the message type.
  6. The binary message is sent to the PartnerBinary back-end application via placement on MQ queue.

Binary over HTTP to AS2 architecture

Binary over HTTP to AS2 architecture

Use case outline

Here is a summary of the steps to configure the appropriate processing objects toimplement the scenario:

  • Step1: Creating the Partner Binary partner profile
  • Step 2: Creating the Partner Binary B2B Gateway
  • Step 3: Creating the Hub Binary MPGW
  • Step 4: Creating the Multi-step processing policy

Use case implementation

We describe each step in detail.

Step 1: Creating the Partner Binary partner profile
In this section, we define the partner profiles that are necessary to allow the information interchange to occur with a specific partner. We define two separate partner profiles to represent the trading entities: an internal profile that represents the PartnerBinary back end and an external profile that represents the HubBinary back end. These profiles will ultimately be contained in the PartnerBinB2BGW object that will point to the HubBinary MPGW service.

PB_int Internal profile
The PB_int internal partner profile defines the object that will manage the messages sent to the PartnerBinary B2BGW. The internal profile defines,among other things,the business IDs associated with the profile and the destination route for the binary documents that are received by the B2BGW.

On the Main tab,the following items need to be defined:

  • Object name
  • Profile Type
  • Partner Business IDs

PB_int partner profile Main configuration tab

PB_int partner profile Main configuration tab

We do not use any AS Security in this scenario,so we do use that configuration tab.On the Destinations tab, we define the destination that is available for a binary message that is sent to the PB_int profile.This shows the configuration of the PartnerBin_MQ destination for the PB_int internal partner profile. This destination object sends binary documents to the Q12 queue associated with the XB60 queue manager object.

Only binary documents will be routed to this queue. Because this destination is the only destination that is defined for binary documents, all binary documents will route to thisqueue.

PB_int internal profile Destinations configuration tab

PB_int internal profile Destinations configuration tab

The Contacts tab is optional so we do not make any configuration changes using that tab for this scenario.

HB_Ext external profile
The HB_Ext external partner profile defines the object that will manage the messages sent to the HubBinary MPGW. The external profile defines,among other things,the business IDs associated with the profile and the destination route for the binary documents that are received by the MPGW.

On the Main tab,the following items need to be defined:

  • Object name
  • Profile Type
  • Partner Business IDs

HB_Ext partner profile

HB_Ext partner profile

We do not use any AS Security in this scenario,so we do not use that tab.On the Destinations tab,we define the destination that is available for a binary message that is sent to the HB_Ext profile. This tab shows the configuration of the HubBin_FTP destination for the HB_Ext external partner profile. This destination object sends binary documents to the FTP Server Front Side Handler listening on port 5117 on the HubBin MPGW.

Only binary documents will be routed to the HubBin MPGW over FTP, because this destination is the only destination defined for binary documents.

Important: The Destination object defined in an External Partner Profile is responsible for routing messages from the current B2B Gateway to the destination outlined in the Destinations tab.The Destination outlined here will not be used for the Binary HTTP multi-step use case; however, it will be used in the FTP multi-step use case in 13.6,“Presenting the binary FTP multi-step use case”.

HB_Ext external profile Destinations configuration tab

HB_Ext external profile Destinations configuration tab

This shows extra fine-tuning parameters available for AS3/FTP destinations. We have defined our connection to use Passive Mode exclusively (Require Passive Mode). We have set the Data Type as Image (Binary) Data.

HB_Ext external profile Advanced AS3/FTP Settings

HB_Ext external profile Advanced AS3/FTP Settings

Step 2: Creating the Partner Binary B2B Gateway
The B2B Gateway object is responsible for defining the characteristics of the transaction and the trading partners in the transaction. Characteristics,such as Front Side Handler objects, partner profiles, and transaction archive parameters, will be covered in thissection.

The details the Main tab for the PartnerBinaryB2BGW object. Here,we associate partner profiles PB_Int (internal profile) and HB_Ext (external profile) to the B2BGW object.

Configuration of PartnerBinaryB2BGW gateway object

Configuration of PartnerBinaryB2BGW gateway object

Archive settings define how long transaction documents will be held on the XB60 hard drive and the action that will taken on those messages for archive purposes.For this scenario, we set the transactions to be purged after 5 days.

Configure the B2BGW Archive tab

Configure the B2BGW Archive tab

Creating PartnerBin_as2_fsh AS2 Front Side Handler
The Front Side Handler objects are responsible for listening on a particular port and retrieving messages in the defined protocol. The AS2 Front Side Handler object is called PartnerBin_as2_fsh.

This AS2 Front Side Handler represents the listener object that receives the binarymessages that are sent from the HubBinary MPGW over HTTP.

Configuring the AS2 Front Side Handler object

Configuring the AS2 Front Side Handler object

Step 3: Creating the HubBinary Multi-Protocol Gateway
The displays the configuration window for the HubBinary MPGW object. The following objects will need to be configured: Front Side Protocol, Processing Policy, and Type.The configuration of these objects will be shown in subsequent sections.

The Front Side Handler (FSH) object is responsible for receiving the binary messages sent from the back end via MQ and passes the message to the Processing Policy. The Processing Policy receives the message and applies, in a step-wise fashion, the configured actions in the selected processing rule. The Processing Rule routes the message to the HTTP URL destination.

HubBinary Multi-Protocol Gateway Main tab

HubBinary Multi-Protocol Gateway Main tab

The Proxy Settings tab in displays extra settings provided by the HubBinary MPGW. The Client Traffic Type is set to Non-XML to allow binary messages,and the Server Traffic Type is set to Passthru.

HubBinary MPGW Proxy Settings tab

HubBinary MPGW Proxy Settings tab

Defining HubBinary MQ Front Side Handler
The configuration of the MQ Front Side Handler object that is responsible for receiving the incoming message from the Hub Binary application sent over MQ.The message received from the HubBinary_mq_fsh will be passed to the multi-step processing rule fortransformation and routing.

Hub Binary MQ Front Side Handler

Hub Binary MQ Front Side Handler

Step 4: Creating the inbound AS2 Header values
In order to send an inbound binary message to the B2BGW over HTTP,we need to wrap the message in an AS2 Header.We will take advantage of the multi-step processing capability in the MPGW to create the AS2 header values.

Injecting AS2 header values
The HTTP Header Injection tab of the MPGW service allows us to create header values dynamically for each binary message transaction. We will use these values to define severalof the required AS2 header values,specifically, the Host and AS2-From values. The Host value identifies the current server sending the message,and the AS2-From value identifies the Business ID associated with the Sender.

HTTP Header Injection values for the AS2 Header

HTTP Header Injection values for the AS2 Header

MPGW HTTP to AS2 Processing Policy
The MPGW service allows us to define a multi-step processing policy that is made up of one or more processing rules. Each rule is made up of one or more processing actions.It is these actions that we will leverage to create the AS2 headers that are needed by theB2BGW Service.

Hub Binary processing policy

Hub Binary processing policy

Transform action
The b2b-test-routing-mq.xsl defines the message route as well as defining several of thenecessary AS2 header values. The code sets:

  • 'AS2-To' value
  • 'var://service/routing-url' - the route to the B2BGW
  • ‘Message-ID’

The code snippet in checks the protocol of the message received and retrieves the partner URL.

Example- Protocol checking and partner URL retrieval code snippet

Defining the Header Rewrite Action
The Header Rewrite action allows us to use the URL Rewrite Policy to configure the content-type header value. This value will be used by the B2BGW to determine the type of theincoming message.

Configuring the content-type in the URL Rewrite Policy

Configuring the content-type in the URL Rewrite Policy

Route action
The Route action uses the value of the var://service/routing-url,which was defined in theTransform action, to send the message to its destination in the B2BGW.

Setting destination with Route action

Setting destination with Route action


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

IBM Websphere Topics