We describe the implementation of the scenario from a high-level perspective, and then, we explain the technical steps necessary to fully implement the solution.
The key aspect of the scenario implementation is that we are dealing with binary payloads. The XB60 often receives these messages via a protocol,such as WebSphere MQ (as our case), that does not have the same routing headers as AS2 or AS3, where specificinformation about the sender and the receiver is set.
In a regular X12 scenario (same as with EDIFACT) messages,the XB60 can parse the message contents and find the partner IDs from the ISA and UNA headers.In XML, the XPath Routing Policies tab on the B2B Gateway configuration tells the XB60 how to retrieve the partner IDs from the payload.
Important:In the case of binary messages, an appliance administrator must configure an XSLT stylesheet as the Document Routing Preprocessor for the gateway to route the message properly.
Another important point of this scenario is the fact that all the communications will be over SSL (including MDNs),which makes communication with our trading partners more secure at the transport layer.A full picture of all the services and objects to implement is presented in the scenario outline, where we also present a summary of what we will create.
The outlines the message flow for the binary with AS2 payload scenario. The left side of the corresponds to the simulated trading partner, which is referred as the binary partner, and the right side corresponds to the hub system, which is referred as the Binary Hub.This architecture demonstrates that the DataPower device is fully implemented from both a partner and provider perspective.
Binary files trading outline
Here is a summary of the steps needed to implement the scenario:
Next, we explain the steps to implement our scenario.
Step 1: Creating all the necessary crypto objects This scenario is intended for those individuals who have experience with the DataPower device, so we do not go into detail about how to create the crypto objects, but it is important to point out that several objects are required for signing and validating signatures, as well as encrypting and decrypting payloads.
The following objects have been created specifically for this scenario:
Both ID credentials and validation credential objects are configured with the corresponding key pair.
Important:We will explain SSL-specific objects, as SSL Proxy Profile and Crypto Profile, in an upcoming section.
Step 2: Creating the Binary Partner profiles
A Partner profile is an object that defines routing destinations for messages, as well as establishes the AS Security rules, when interchanging information with that specific partner.
Because we simulate trading between partners within the single DataPower device, we need two separate binary partner profiles to be included in the B2B Gateway: one internal profile for the B2B Gateway Service that represents the partner back end and one external profile whose destination will be pointing to the other B2B Gateway Service.
Binary partner internal profile
The binary partner internal profile contains information for the type of AS Security that is defined for this partner, including signing outgoing messages and decrypting incoming messages. This information is located in the AS Security tab. The destination definition for this partner profile is listed in the Destinations tab.
The Main tab of the Binary_Partner_int internal partner profileallows you to add a Business ID,which allows the the B2B Gateway (B2BGW) service to identify which profiles must be handling the request. In this case, we have one Business ID called binarypartner. This name is the identifier of the business partner that is waiting for the binary file.
Binary partner internal profile Main configuration tab
This shows the configuration of the AS Security parameters.
Because this profile is an internal profile, all the Identification credentials must be configured in here. A requirement of this scenario is to sign and encrypt AS2 messages that we exchange,so we check all those boxes,and we include the Binary Partner ID Credentials that we created in “Step 1: Creating all the necessary crypto objects”.
Binary partner internal profile AS Security configuration tab
we configure the Destinations tab, where documents from the Partner must be routed.This shows that the binary partner back end is simulated by MQ queue,therefore, we define an MQ destination. It is also important to notice that we have only enabled Binary as the document type, because this type is the only type that we will handle. The Contacts tab is an optional tab and we will not populate this tab.
Binary Partner internal profile Destinations configuration tab details
Binary partner external profile
The binary partner external profile manages the information needed by the hub in order to successfully trade with the Binary Partner. We will define parameters in the AS Security tab and Destinations tab.
The Main tab of the Binary_Partner external partner profile allows you to add a Business ID, which allows the B2BGW service to identify which profiles need to be handling the request. In this case,we have one Business ID called binarypartner.
Binary Partner external profile Main configuration tab
This shows the AS2 Security tab, and we focus on two aspects:
Binary Partner internal profile AS Security configuration tab
Inspecting the MDN SSL Proxy Profile’s configuration (refer to Figure below), we see that it has been defined as Forward, meaning that when we establish the SSL handshake, we act as clients of the Partner, because it is the Hub that connects to the Partner system to make the SSL connection for the MDN.
To finish this configuration, we need to provide an SSL Forward Crypto Profile, which we name AS2_2_BinaryPartner_CP.
Binary Partner internal profile SSL Proxy Profile configuration
Inspecting the Crypto Profile’s configuration, we see that the object Binary Hub validationcredentials have been added to it.This way, when the Hub tries to establish the SSL connection to the Partner, and the Partner presents its certificate to it, the connection will be made only if it presents a trusted certificate, which is stored in theBinary_Partner_valcred object.
Binary Partner internal profile Crypto Profile configuration
In the Destinations tab,we must add an AS2 destination: this is the information thatdescribes how to route messages to the Partner system from the Hub system, and AS2 is the selected protocol.
Only Binary is enabled as a valid document type, because for this specific partner, we will only handle this kind of documents.Next, we add the URL of the Binary Partner’s AS2 Front Side Handler of the Binary_Partner B2B Gateway Service, which is where it listens for incoming AS2 messages.
Moreover, we include the AS2_2_BinaryPartner SSL proxy profile that was used in the MDN SSL Proxy profile. In this case, we are acting as clients to our trading partner.
Binary Partner external profile Destinations details
If we scroll down on the window, we see the AS Outbound security and the Advanced AS Behavior details. This security is message-oriented (the way the AS2 messages are signed and decrypted), not at the transport layer as in SSL.
Binary Partner external profile Destinations details (continuation)
In the Outbound security details section , make sure that you select Encrypt messages and select the binary_partner certificate that was previously generated. Leave “Send Messages Unsigned” unchecked, because we want to sign our messages.
In the advanced AS behavior section, select Request MDN and Request Asynchronous MDN and make sure that the AS2 MDN Redirection URL is selected using https protocol.The As2 MDN Redirection URL is the profile that we use to send the AS headers to the trading partner,so it knows where to route the MDNs, which is why we set up the partner’s own Front Side Handler (FSH) port.
Important:Remember that the scenario that we implement is a one-way flow from the Hub to the Partner, so in this case, there will be no MDN coming from the Hub.
Step 3: Creating the Binary Hub profiles
Similar to “Step 2: Creating the Binary Partner profiles”, we also need two separate Binary Hub profiles. The internal profile is associated with the Binary Hub B2B Gateway service, and an external profile will be associated with the Binary Partner B2B Gateway service.This profile will allow our partner to successfully send all the messages to the Binary Hub, as well as, among other things, validating the incoming signature.
Binary Hub internal profile
The Binary Hub internal profile contains information that will manage the kind of AS Security that the provider expects.This security includes how outbound messages will be signed, how the incoming messages will be decrypted,and where the messages will be routed to the partner system.
The Main tab of the Binary_Hub_int internal partner profile allows us to add a Business ID so that the B2BGW service can identify which profiles need to handle the request. Remember that for binary use cases that do not include AS2 or AS3 wrapping,we will use an XSLT that will help us set up the sender and receiver information,so the message processing can be associated with the right profiles that come in the XML sent from our back end.
Binary Hub internal profile Main configuration tab
The defines the AS Security tab parameters. Because this profile is an internal profile, all the identification credentials must be configured here. It is a requirement in this scenario to exchange signed and encrypted AS2 messages, so we must check all those boxes, and include the Binary Partner ID Credentials that we created in “Step 1: Creating all the necessary crypto objects”.Notice that the ID Credentials contain the private key of the Banking Partner that, in this case, is usedboth for signing and decrypting.
Binary Partner internal profile AS Security configuration tab
This shows the definitions of the Destinations tab,where documents from the Partner need to be routed. Figure above shows that in the main architecture, the binary Hub back end is simulated by an MQ queue so an MQ destination is needed.It is also important to notice that we have only enabled Binary as the document type, because this type is the only type that will be handled.
Important:When testing this scenario, we do not use this destination, because we only have one flow.
Binary Hub internal profile Destination configuration tab details
Binary Hub external profile
The Binary Hub external profile manages the information needed by the Partner in order to successfully trade with Binary Hub and where the messages will be routed to the partner system.The Main tab of the Binary_Hub external partner profile, from a Business ID perspective, is the same configuration that we had on the internal profile.
Binary Hub external profile Main configuration tab
From an AS2 Security perspective, we focus on two aspects:
Binary Hub external profile AS Security configuration tab
If we explore MDN SSL Proxy Profile’s configuration ,we can see that it has been defined as Forward, meaning that when we establish the SSL handshake, we act as clients of the Hub, because the Partner is the one that connects to the Hub system to make the SSL connection for the MDN.To finish this configuration, we need to provide an SSL Forward Crypto Profile, that in this case we have named AS2_2_BinaryHub_CP.
Binary Hub external profile SSL Proxy Profile configuration
The Crypto Profile’s configuration contains the Binary Hub validation credentials .When the Partner tries to establish the SSL connection to the Hub, and the Hub presents its certificate, the connection will be made only if it presents a trusted certificate.
Binary Hub external profile Crypto Profile configuration
In the Destinations tab, we add an AS2 destination containing the information that describes how to route messages to the Hub system from the Partner system via AS2. Again, only Binary is enabled as a valid document type. Next, weadd the URL of Banking Hub’s AS2 Front Side Handler of the Binary_Hub B2B Gateway service, which is where it will listen for incoming AS2 messages.
Moreover, it will be necessary to include the AS2_2_BinaryHub SSL proxy profile that we have already used in the MDN SSL Proxy profile, because, in this case, we also act as clients to our trading partner, to whom we will be serving the SSL connection.
Binary Hub external profile Destinations details
The defines the AS Outbound security and Advanced AS Behavior details. Remember that this security is related to how AS2 messages are signed and decrypted.
In the Advanced AS Behavior section, select Request MDN and Request Asynchronous MDN and make sure the AS2 MDN Redirector URL is selected using Https protocol. The As2 MDN Redirection URL is the profile that we use to send in the AS headers to the hub, so it knows where to route the MDNs. That it is the reason why we set up the partner’s own FSH port.
Binary Hub external profile destination details (continuation)
Step 4: Creating the Binary Partner B2B Gateway Service
After having created all the profiles for the scenario, it is time to create the B2B Gateway Services that will handle the message traffic and attach the profiles, depending on the case.
For the Binary Partner, this service acts as the entry point to that system, identifying the incoming messages and mapping these messages to the specific profiles that need them.This shows the Binary Partner B2BGW service has two partners attached: the Binary Partner internal profile and the Binary Hub external profile, but you can add as manyprofiles as your business needs require.
Binary Partner B2B Gateway architecture
This shows the Main tab for the Binary Partner B2B Gateway Service.
Binary Partner B2BGW Main configuration tab
This shows that we have only one AS2 Front Side Handler attached in the Front Side Handlers section. There will be no communication from the partner back end to the Banking Partner B2BGW, because this scenario is a one-way flow.
On the other side, we have the two Partner Profiles (Binary_Partner_int and Binary_hub) attached in the Attach Partner Profiles section in Figure below.If you want to add a Partner profile, select the profile that you want from the drop-down list and click Add. You can add as many profiles as necessary. The topmost profile will be the default profile.
it is important to notice that we are using localhost as a Host Alias for 127.0.0.1 in order not to tightly couple our Front Side Handler with any specific IP address.
Binary Partner AS2 FSH
if we scroll further down,we can see that there is an SSL Proxy profile associated to Binary Partner AS2 FSH, because we will be using SSL on our communications.
Binary Partner AS2 FSH (continuation)
The defines the Binary_Partner_PP, which is configured as a Reverse Proxy Profile, because the Front Side Handler will be the actual SSL server on the connections that will bereceived. Therefore, you need to configure a Reverse Crypto profile, Binary_Partner_CP.
Binary Partner AS2 FSH SSL Proxy Profile
On the Binary_Partner_CP window, we need to include the ID credentials that this B2BGateway Service presents to the incoming clients so that the SSL connection can be established. We will use the Binary_Partner_IDCred object that we created in “Step 1: Creating all the necessary crypto objects”.
Binary Partner AS2 FSH Crypto Profile
On the Archive configuration tab,we have set the archiving as Purge only and entered 3 days of Archive Document Age, even though, depending on the use case, this property might need to be resized.
Binary Partner B2BGW Archive configuration tab
There are no XML Formats,because we are trading with binary files.
Binary Partner B2BGW XML Formats tab
In the Advanced configuration tab,we need to set the Default AS2 MDN Return Path: this information will come in the AS2 headers when the partner sends any AS2 messages to the Hub,so that the Hub knows where, by default,it must send the AS2 MDNs back.That it is why we are indicating the port number that matches Partner’s AS3 Front Side Handler.
Binary Partner B2BGW Advanced tab
We have finished configuring the Banking Partner B2B Gateway Service.
Step 5: Creating the Binary Hub B2B Gateway Service
For the Binary Hub case,our B2B Gateway Service will act as the entry point to the hub system, identifying the incoming messages and mapping them with the specific profiles that need to handle them.
In this B2B Gateway configuration, we will handle plain binary files coming from our back end. In this case,we do not have access to Sender and Receiver information,so we will have to use an XSLT stylesheet to run against our transaction. This stylesheet will examine information from transport headers and other non-content sources to select relevant trading partners.The default sample on the XB60 is in store:///b2b-routing.xsl,so we make our own copy to local and edit it to our needs.
As we can see in this,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 your business needs require. It also has two Front side handlers, which are used in all other DataPower services,to receive incoming traffic.
Binary Hub B2B Gateway architecture
Contrasting with the previous B2B Gateway,in this particular case,we still need two FSHs:an AS2 FSH is needed for receiving MDNs (and only MDNs, because we only have a one-way flow) coming from the Binary Partner,and also an HTTP to receive messages from our MQ back end.
This shows the Main tab of the B2B Gateway Service.
There are two Partner Profiles (Binary_Partner and Binary_Hub_int) attached that show in the Attach Partner Profiles section. If you want to add a new Partner Binary Hub B2B GW profile,all you have to do is select the profile that you want from the drop-down list and click Add; then, select the Profile Destination, if the profile has more than one destination,or leave it as the default if it only has one.
Binary Hub B2BGW Main configuration tab
This shows the detailed configuration on the AS2 FSH. It is important to notice that we are using localhost as a Host Alias for 127.0.0.1 in order to not tightly couple our Front Side Handler with any specific IP address.
Binary Hub AS2 FSH
This shows that there is an SSL Proxy profile associated to it,because we will use SSL on our communications.
Binary Hub AS2 FSH (continuation)
if we explore Binary_Hub_PP, you can see that it is configured as a Reverse Proxy Profile, because the front side handling will be the actual SSL server on the connections that will be received. Therefore, you need to configure a Reverse Crypto profile, Binary_Hub_CP.
Binary Hub AS2 FSH SSL Proxy Profile configuration
This shows the Binary_Partner_CP. We need to include the ID credentials that this B2B Gateway Service will present to the incoming clients,so that the SSL connection can be established.We use the Binary_Partner_ID Cred object that we created in“Step 1: Creating all the necessary crypto objects”.
Binary Hub AS2 FSH Crypto Profile configuration
On the Archive configuration tab,we have set the archiving up as Purge only and entered 3 days of Archive Document Age,even though, depending on the use case,this property might need to be resized.
Binary Hub B2BGW Archive configuration tab
There are no XML Formats,because we are trading with binary files.
Binary Hub B2BGW XML Formats tab
This shows the Advanced configuration tab. We need to set the Default AS2 MDN Return Path. This information comes in the AS2 headers when the partner sends any AS2 messages to the Hub,so the Hub knows where, by default,it sends the AS2 MDNs back, which is why we are indicating the port number that matches the Partner’s AS2 Front Side Handler.
In addition,we have also copied the Binary_routing.xsl to our local directory and renamed it as Binary_hub_B2B-routing.xsl. That way,we do not modify the original XSL file that is provided in case, in the future,we want to start from the beginning for another use case.
Binary Hub B2BGW Advanced tab
This shows how we configured that XSLT. For our specific case, we have coded it so that whenever a message comes via MQ, then we set up the business ID’s in the stylesheet. Therefore, if we had non-binary partners coming from HTTP,they are not affected by this rule. Again, this case is only an example, and a more convenient filter can be coded, depending on your particular needs.
Example -Binary Hub B2B Routing xslt used to assign Partner IDs on binary payloads
After uploading that XSLT (that you can modify with any XML editor available in the market), we have successfully created the Banking Hub B2B Gateway Service.
IBM Websphere Related Tutorials
|IBM DB2 Tutorial|
IBM Websphere Related Interview Questions
|IBM DB2 Interview Questions||Weblogic Interview Questions|
|IBM WebSphere Datapower SOA Appliances Interview Questions||IBM WAS Administration Interview Questions|
|IBM Websphere Application Server Interview Questions||IBM WebSphere MQ Interview Questions|
|WebLogic Administration Interview Questions||IBM DataPower Interview Questions|
|Ibm Websphere Message Broker Interview Questions||Ibm Websphere Cast Iron Interview Questions|
|Ibm Websphere Process Server Interview Questions|
Ibm Websphere Tutorial
B2b Technologies And Standards
B2b Deployment Methodology
Aspects Of B2b Security
Websphere Datapower B2b Appliance Xb60
Device Setup And Administrative Tasks
B2b Configuration Options
Troubleshooting The Appliance
Xb60 And Wtx Integration For Hipaa
Xb60 With Transformation
Trading Outbound Binary Documents Using The B2b Gateway Service
Trading Binary Documents Using A Multi-protocol Gateway Service
Handling Soap Messages With Attachments In A B2b Environment
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.