Scenario -The Multi-Protocol Gateway (MPG) - IBM Websphere

After we describe the major aspects of the scenario from a high-level perspective, we willprovide a technical explanation of all the steps to fully implement the solution.

One of the key aspects of the scenario implementation is that we simulate the trading partner within the DataPower device, which means that you need to create a specific B2B Gateway (B2BGW) Service for the trading partner.

The Multi-Protocol Gateway (MPG) service has a key role in this scenario, because it holds a policy rule for the transformation map. The synergic interaction between the B2B Gateway Service nd the MPG is what makes this solution an extremely powerful use case for many trading scenarios.We present a full picture of all the services and objects to implement in the scenario outline, where we also summarize what we will create.

Scenario outline

The scenario’s architecture is presented.The left side of corresponds to the simulated trading partner, which is referred to as the Banking partner, and the right side corresponds to the hub system, which is referred to as the Banking Hub. This architecture demonstrates that the DataPower device can fully accomplish both the partner and provider perspective.

Using AS3 and transformation outline

Using AS3 and transformation outline

As you can see in Figure above we use WebSphere MQ (WMQ) queues to put the messages in the Multi- Protocol Gateway service that will be responsible for running the WebSphere Transformation Extender (WTX) map, inside a processing rule that has a “binary transform” action in it.

The communication between both B2B Gateway Services will be made using AS3. In thiscase,we have only considered a one-way flow to keep the scenario as simple as possible.

These steps summarize what we need to do in order to implement the scenario:

  • Step 1: Creating all the necessary crypto objects
  • Step 2: Creating the Banking Partner profiles
  • Step 3: Creating the Banking Hub profiles
  • Step 4: Creating the Banking Partner B2B Gateway Service
  • Step 5: Creating the Banking Hub B2B Gateway Service
  • Step 6: Creating the Bank2Xml WTX map
  • Step 7: Creating the ERP back-end system

Scenario implementation

Follow these steps to implement his scenario.

Step 1: Creating all the necessary crypto objects This scenario is intended for people who are experienced with the DataPower device, so we do not explain in detail how to create the crypto objects (we assume that you have this knowledge), but it is important to point out that several objects are required for signing and validating signatures and encrypting and decrypting payloads.

The following objects have been created specifically for this scenario:

  • Public/Private keys:
  • Bankingpartner key pairs
  • Bankinghub key pairs
  • Validation credentials:
  • Banking_Partner_valcred: Used to validate signatures coming from the Banking Partner
  • Banking_Hub_valcred: Used to validate signatures coming from the Banking Hub
  • Identification credentials:
  • Banking_Partner_IDcred: Used to sign messages from the Banking Partner system and to decrypt payloads coming from the Banking Hub
  • Banking_Hub_IDcred: Used to sign messages from the Banking Hub system and to decrypt payloads coming from the Banking Partner.

Both ID Credentials and validation credential objects are configured with the corresponding key pair.

Step 2: Creating the Banking Partner profiles
A Partner profile is an object that defines the routing for messages by defining Destinations. It also establishes the AS Security rules when interchanging information with that specific partner.

Because we are simulating our trading within the DataPower device, we need two Banking Partner profiles: an internal profile for the B2B Gateway Service that will represent the partner back end and an external profile to be included in the Banking Hub B2B Gateway Service where we set the destination pointing to the other B2B Gateway Service.

Banking Partner internal profile
The Banking Partner internal profile contains information, such as the type of AS Security that the partner expects, including how to sign the outgoing messages, decipher the incoming messages (AS Security tab),and where the messages are going to be routed (Destinations tab).

Here are the aspects of the configuration that you need to take into account in order to successfully configure this profile. We have named this object Banking_Partner_int, and we will use this methodology for the next objects as well.

First of all, we need to add Business IDs so that the B2BGW service can associate the incoming business ID in the AS3 headers to this partner profile and route it to its destination.

For this particular case, we have one Business ID, bankpartner, which is used in the XML that sent from our back end, and it is also used to enable us to route it to the partner destination.

Banking Partner internal profile Main configuration tab

Banking Partner internal profile Main configuration tab

On the next tab,we configure AS Security aspects. Because this object is an internal profile,all the Identification Credentials are configured here. It is a requirement in this scenario to exchange AS3 messages signed and encrypted, so we check all the boxes and include theBanking Partner ID Credentials that we created in Step 1.

Banking Partner internal profile AS Security configuration tab

Banking Partner internal profile AS Security configuration tab

The next step is to configure the Destination to where the documents from the Partner must be routed.The banking partner back end is simulated with WebSphere MQ. Therefore, an MQ destination is needed.

It is also important to notice that we only enable XML as the document type, because XML isthe only type we will handle.

Banking Partner internal profile Destinations tab details

Banking Partner internal profile Destinations tab details

The Contact tab is an optional tab, which we do not use in this scenario. You can use it toenter the partner information if required.

Banking Partner xternal profile
The Banking Partner external profilewill handle the information that is needed by the provider in order to successfully trade with the Banking Partner (AS Security tab) along with the Partner destination point (Destinations tab).

Here are the aspects of configuration that you need to take into account in order to successfully configure this profile.We have named it Banking_Partner.In our naming convention, external partners do not have any indicator on the name.From a Business ID perspective, we use the same configuration that we had on the internal profile.This shows the configuration.

Banking Partner external profile Main configuration tab

Banking Partner external profile Main configuration tab

Because this profile is an external profile, from an AS3 Security perspective, validation credentials are required in order to verify the signed payload. Again, we use the object Banking_partner_valcred that was created in Step 1.We do not add anything to the MDN Secure Sockets Layer (SSL) profile, because we do not use SSL for our transport layer.

Banking Partner external profile AS Security configuration tab

Banking Partner external profile AS Security configuration tab

In the Destinations tab,we add an AS3 destination, which is the information that describes how to route messages to the Partner system from the Hub system.We will communicate by using AS3.

Again, only XML is enabled as a valid document type.Next, we add the URL of the BankingPartner’s AS3 front side handler.

Banking Partner external profile Destination details

Banking Partner external profile Destination details

If we scroll down the window, we see AS Outbound security and Advanced AS Behaviordetails.

In the Outbound security details, make sure that you select Encrypt messages and select the certificate that you generated in Step 1. Do not select “Send messages unsigned,” becausewe will sign our messages.

In the advanced AS3/FTP settings, leave everything as it is. We do not require any authentication in this case, because the Partner’s Front Side Handler will be configured without security.However, it is worthwhile showing that more security can be added if it is a requirement.

Banking Partner external profile Destination details (continuation)

Banking Partner external profile Destination details (continuation)

The Contact tab is an optional tab, and we do not use it in this case. However, you can use it to enter partner information if needed.

Step 3: Creating the Banking Hub profiles
As we explained in Step 2, we also need two Banking Hub profiles: an internal profile to associate with the Banking Hub B2B Gateway Service (refer to Step 5 for further details) and an external profile to associate with the Banking Partner B2B Gateway Service, which will enable our partner to be able to successfully send all the messages to the Banking hub, as well as validating the incoming signature, among other tasks.

Banking Hub internal profile
The Banking Hub internal profile manages the detail with regard to the type of AS Security that the provider expects (the AS Security tab),which includes how to sign the outgoing messages, how to decipher the incoming messages, and where the messages are routed (the Destinations tab). In this case,the messages are routed to the partner system.

Here are the aspects of the configuration that you need to take into account in order to successfully configure this profile. We have named it Banking_Hub_int to keep with our previous naming convention.First, you configure the Business IDs,so that the B2BGW service can associate the incoming business ID in the AS3 headers to this partner profile and route it to its destination.

We enter our one Business ID, which is erpcustomer, which will come in the XML that is sent from our back end.

Banking Hub internal profile Main configuration tab

Banking Hub internal profile Main configuration tab

Next,we complete the AS Security tab information.Because this profile is an internal profile, all the identification credentials are configured here.It is a requirement in this scenario to exchange signed and encrypted AS3 messages, so we must select Require Signature and Require Encryption.Include the Banking Partner ID Credentials that we created in Step 1. Notice that the ID Credentials contain the private key of the Banking Partner that,in this case, is used for both signing and decrypting.

Banking hub internal profile AS Security configuration tab

Banking hub internal profile AS Security configuration tab

Next,we configure the Destination from where the documents come.which shows the main architecture,the Banking Hub system has an Multi-Protocol Gateway (MPG) service,which transforms the data. The connection is done with HTTP. Therefore,an HTTP destination is needed.Note that we have only enabled XML as the document type, which is the only type we will handle.

Banking hub internal profile Destinations tab details

Banking hub internal profile Destinations tab details

The Contact tab is an optional tab that we do not use in this case; however, enter the
partner information if needed.

Banking Hub external profile
The Banking Hub external profile manages the information details, such as what is needed by the partner in order to successfully trade with the Banking Hub (AS Security tab) and where the Provider destination point is located (Destinations tab).

Here are the parts of the configuration that you need to consider in order to successfully configure this profile. We have named it Banking_Hub. In our naming convention,external partners do not have any indicator on the name,and everyone chooses their own naming convention.From a Business ID perspective, we create the same configuration that we had on the internal profile.This shows the configuration.

Banking Hub external profile Main configuration tab

Banking Hub external profile Main configuration tab

Because this profile is an external profile, from an AS3 Security perspective,only goodvalidation credentials are required in order to verify the signed payload. Again, we use the object Banking_hub_valcred that we created in Step 1.We do not add anything to the MDN SSL profile, because we do not use SSL for our transport layer.

Banking Hub external profile AS Security configuration tab

Banking Hub external profile AS Security configuration tab

In the Destinations tab, we add an AS3 destination that is the information that describes how to route messages to the Partner system from the Hub system,which we communicate using AS3.Only XML is enabled as a valid document type.This shows how to add the URL of the Banking partner’s AS3 Front side handler.

Banking Hub external profile Destinations tab details

Banking Hub external profile Destinations tab details

If we scroll down the window ,we see AS Outbound security and Advanced AS Behavior sections. In the Outbound security section, make sure that you select Encrypt messages and select the certificate that you generated in Step 1. Do not select “Send messages unsigned,” because our messages are signed.

In the advanced AS3/FTP settings, leave everything as it is. We do not require any authentication in this case, because the Banking Hub’s Front Side Handler will be configured without security. However,it is worth showing that more security can be added if more security is a requirement.

Banking Hub external profile Destinations tab details (continuation)

Banking Hub external profile Destinations tab details (continuation)

The Contact tab is an optional tab, which we do not configure in this case; however, feel free to enter the partner information if needed.

Step 4: Creating the Banking Partner B2B Gateway Service
Having created all the profiles for the scenario, it is time to create the B2B Gateway Services that will handle all the traffic and attach the profiles,depending on the case. For the Banking Partner,this service acts as the entry point to their system,identifying the incoming messages and mapping the incoming messages with the specific profiles that need to handle them.we see the Banking Partner B2BGW service has two partners attached, the Banking Partner internal profile and the Banking Hub external profile, but you can add as many profiles as your business needs require.

We have two Front Side Handler objects, which are used in all the DataPower services,toreceive incoming traffic. For this particular case,an AS3 FSH is needed to receive messages coming from the Banking Hub and an HTTP FSH is needed to receive messages from the Partner back end.

Banking Partner B2B Gateway architecture

Banking Partner B2B Gateway architecture

This shows the Main tab window for the Banking Partner B2B Gateway service.

Banking Partner B2BGW Main configuration tab

Banking Partner B2BGW Main configuration tab

As you can see, we have only one AS3 Front Side Handler attached in the Front Side Handlers tab. There will be no communication from the partner back end to the Banking Partner B2BGW, because this scenario is a one-way flow.

We do however have two active Partner Profiles (Banking_Partner_int and Banking_hub)attached in the Attach Partner Profiles section. If you want to add a new Partner profile,select the partner profile that you want from the drop-down list and click Add; then,select the Profile Destination.

This shows the detailed configuration of the AS3 FSH.

Banking Partner AS3 FSH

Banking Partner AS3 FSH

Note that we have left everything as default, because our scenario has no specialrequirements for security.We use localhost as a Host Alias for 127.0.0.1 in order to not tie our Front Side Handler with any specific IP address and to limit the incoming traffic only to the IP address coming from the device internally. In a real scenario, the host alias is an external IP address.

On the Archive configuration tab we select Purge Only and enter 3 days for the Archive Document Age, even though,depending on the use case,this property will need to be resized later.

Banking Partner B2BGW Archive configuration tab

Banking Partner B2BGW Archive configuration tab

We must now configure the XML format,which allows us to identify all the core routing information from inside the XML message, which includes Sender, Receiver, Document ID,and Timestamp. Click + (the plus sign) to create a new routing policy.We have already created a routing policy called Banking_XMLFormat.

Banking Partner B2BGW XML Formats tab

Banking Partner B2BGW XML Formats tab

With the help of the XPath tool, we upload our sample incoming XML and identify the required fields explained earlier.

For our specific case, these fields are located in tags whose names are Sender_ID,Receiver_ID, FileReference,and Date.

Example - Header detail of the incoming XML data

After uploading the XML file and selecting each field in the XPath tool, you will have a result
similar.

Banking Partner B2BGW XML Formats configuration details

Banking Partner B2BGW XML Formats configuration details

In the Advanced configuration tab,we need to set the default AS3 MDN Return Path.This information will be in the AS3 headers when the partner sends any AS3 messages to the Hub,so that the Hub knows where, by default,to send the As3 MDNs back. For this reason, we indicate the port number, which matches the Partner’s AS3 Front Side Handler.

Banking Partner B2BGW Advanced tab

Banking Partner B2BGW Advanced tab

We have now finished configuring the Banking Partner B2B Gateway.

Step 5: Creating the Banking Hub B2B Gateway Service
For the Banking Hub case, our B2B Gateway Service acts as the entry point to the hub system, identifying the incoming messages and mapping them with the specific profiles that need to handle them.the Banking Hub B2BGW service has two partners attached: the Banking Hub internal profile and the Banking Partner external profile, but you can add as many profiles as you need.

We have two Front Side Handlers, which are used in all DataPower services, to receive incoming traffic.In contrast with the previous Partner B2B Gateway,in this particular case,we still need two FSHs: an AS3 FSH is needed for receiving MDNs (and only MDNs because we only have a one-way flow) coming from the Banking Partner and an HTTP to receive messages from the Multi-Protocol Gateway ERP_backend_MPG.

Banking Hub B2B Gateway architecture

Banking Hub B2B Gateway architecture

The B2B Gateway Service Main configuration tab window.

Banking Hub B2BGW Main configuration tab

Banking Hub B2BGW Main configuration tab

We have two active partner profiles (Banking_Partner and Banking_Hub_int) attached in the Attach Partner Profiles section.If you want to add a new partner profile, select a partner from the drop-down list and click Add; then, select the Profile Destination.

This shows the detailed configuration of the AS3 FSH.

Banking Hub AS3 FSH

Banking Hub AS3 FSH

Note that we have left everything as default, because there are no special configurationsneeded for security for our use case.

It is important to mention that we are using localhost as a Host Alias for 127.0.0.1 in order to not tie our Front Side Handler with any specific IP address and to limit the incoming traffic only to the IP address coming from the device internally. In a real scenario, the host alias is an external IP address.The Archive configuration tab is set up as Purge only and we entered 3 days of Archive Document Age. Depending on the use case, you will need to resize thisproperty later.

Banking Hub B2BGW Archive configuration tab

Banking Hub B2BGW Archive configuration tab

Now,it is time to configure the XML format (Figure below) that allows us to identify where we perform all the core routing. These fields include Sender, Receiver, Document ID,and Timestamp. We have the same type of messages in both gateways, so we can use the same XML format that one we created before in Banking Partner B2B Gateway. Choose that XML format in the drop-down list and click Add.

Banking Partner B2BGW XML Formats configuration tab

Banking Partner B2BGW XML Formats configuration tab

In the Advanced configuration tab,we need to set the default AS3 MDN Return Path. This information is used for the AS3 return MDN path in the outbound message headers when a return path value is not set in the Partner’s AS3 destination.

Banking Hub B2BGW Advanced configuration tab

Banking Hub B2BGW Advanced configuration tab

We have successfully created the Banking Hub B2B Gateway.

Step 6: Creating the Bank2Xml WTX map

The transformation map ERP2XML uses one input type tree that represents the Flat File coming from the ERP system.We built this input type tree specifically for this scenario. From a structure standpoint,it has one Header record (initiated by 01) that contains all the information to describe the whole payment lot and then a set of separate Detail records, each of which matches a single payment.

Example - Input flat file coming from the back end

The output type tree is an XML chema that the Banking Partner has provided so that we can transform our data into the XML that the Banking Partner expects.It is structured in a root tag called PaymentFile that contains a set of tags that contain the main information about the document (sender, receiver, and so forth) and then several Payment file tags, each of which contains the payment specification for each of the payments coming in the input file.

This shows a sample of the Output file.

Example - Output XML that is sent to the trading partner

The key concept, from a mapping perspective,is that all the information that comes in theDetail records (initiator 02) must be mapped into Single Payment tags.

This shows the logic of both Functional Maps,including the Input and Output cards.

Functional map for mapping each Single payment

Functional map for mapping each Single payment

When you build your map in WebSphere Transformation Extender Design Studio, make sure that you use WebSphere DataPower as the map Runtime mode.You can configure this in Map Settings.

Map Settings configuration

Map Settings configuration

After building the map, you have a .dpa extension on your workspace, which is the compiled map that must be uploaded into the DataPower device for the transformation action.

Make sure that you also test the map locally,using Run locally,so that you are sure that everything works as you expect. At this point,we are ready to create the MPG that will host the transformation.

Step 7: Creating the ERP back-end system
In order to configure the MPG,we will need an MQ FSH, which is called ERP_MQ_FSH that will listen on Q5 from our queue manager QM, and a back-end URI that will be the Banking hub B2BGW (port 10080).

ERP_Backend General configuration tab

ERP_Backend General configuration tab

make sure that you select Non-XML as the Request and Response type, because we will send non-XML payload to it.

ERP_Backend General configuration tab(continuation)

ERP_Backend General configuration tab(continuation)

If we examine the policy that we have created in Figure below (click + to create a new policy in DataPower), we can see that it only has a simple Match all, based on the incoming URL,and a transform binary action.

When you configure this action, drag and drop the Transform action,and then select Use XSLT specified in this action on a non-xml Message,and all of the WTX map options appear.

Important:Our ERP_Transformation Policy has only one request rule,because we will only send messages, and no response is expected. If you were to test this scenario with data going both ways, make sure that you add whichever response rule suits you best and add a Reply Q to the MQ FSH.

ERP_Transformation Policy overview

ERP_Transformation Policy overview

we can see all the options for adding the transformation map. Make sure that you haveuploaded your map previously or just use Upload at this point.

Transform Binary action configuration details

Transform Binary action configuration details

Click Done and apply your policy and then your MPG settings. We are now ready to test our scenario.


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

IBM Websphere Topics