XB60 B2B services - IBM Websphere

Each of the DataPower services available in the XB60 device has built-in features andfunctionality to handle many types of transactions and protocols that can be used to route data. Because the XB60 was built on top of our core Application Integration appliance, the XB60 has many services that are application integration services in nature. We only discuss the B2B-specific services and objects.

From the Control Panel under B2B, there are three shortcuts specifically for B2B:B2B Partner Profiles, B2B Gateway Service, and B2B Transaction Viewer. This section will briefly describe each function.

Control Panel view of B2B objects B2B Partner Profiles

Control Panel view of B2B objects B2B Partner Profiles

The B2B Partner Profile is the configuration object where the trading partner information is defined. This information includes the profile name, profile type, business IDs, AS security, destinations for document routing, and contact information.

A trading partner is either an internal or external trading partner based on the understanding that an internal trading partner exists within the corporate enterprise and an external trading partner exists outside of the enterprise.

Trading partners have unique business IDs. However, if a profile is defined as internal, that trading partner might also have the same business ID defined in their external definition, because an internal trading partner and an external trading partner are different objects.

Whether a trading partner is internal or external also affects the options under the AS Security tab. Internal profiles will only use private security credentials, and external profiles will only use public security credentials. When you trade documents between two hubs, the internal profile is the private side of the profile and contains private keys, and the external profile is the public side of the profile and contains only public certificates. depicts how the hub owner’s private side of the profile is stored on the owner’s B2B hub and communicates with the public side of the owner’s profile, which is stored on the partner’s B2B hub. The partner’s B2B Gateways will also work in the same manner.

Internal and external profile linkage

Internal and external profile linkage

The B2B Partner Profile contains four tabs that are used for service configuration: Main, AS Security, Destinations, and Contacts tabs.

The Main tab
The main tab identifies the name of the profile, the Admin State (enabled or disabled) that allows the profile to be used in a B2B Gateway object, the Profile Type (internal or external), and the Partner Business IDs associated with the profile.

The Business IDs must be equivalent to identifiers that are expected in the transactions, such as:

  • A value for an AS header: AS2-To or AS2-From for AS2 transactions and AS3-To or AS3-From for AS3 transactions
  • A value that is extracted from the ISA or UNB headers of the EDIX12 or EDIFACT documents
  • A value that is extracted from a configured XPATH entry (configured in the B2B Gateway) of an XML document

Main tab: Internal partner profile

Main tab: Internal partner profile

The AS Security tab

Internal profiles:

  • For internal profiles, AS security is optional, but if it is used, the AS Security tab contains a place for credentials to be identified for decrypting inbound AS messages. The AS Security tab also contains a place for credentials to be used when signing outbound AS messages and AS Message Disposition Notifications (MDNs). Internal profiles use private keys.
  • For inbound security optionally selectRequire Signature to indicate whether inbound messages must be signed. You can also (optionally) specify whether inbound messages must be encrypted by selecting Require Encryption and selecting the identification credentials necessary to decrypt the message from the Inbound Decryption Identification Credentials list. Credentials can be selected from the drop-down list or created by clicking + (the plus sign). Existing credentials can be modified by clicking . . . (the ellipsis).
  • For outbound security, outbound messages can (optionally) be signed. To sign messages, select Sign Outbound Messages and select the signing identification credentials to be used to sign outbound messages. Credentials can be created by clicking + (the plus sign) or existing credentials can be modified by clicking . . . (the ellipsis). Also, select the hashalgorithm from the Signing Digest Algorithm list.

Internal profile AS Security tab

Internal profile AS Security tab

External profiles
For external profiles, AS security is optional, but if used, the AS Security tab contains a place for credentials to be used to verify signatures and validate signature certificates from the partner. External profiles use public certificates:

Note:Although this setting controls whether to sign outbound messages, the Send Messages Unsigned property in the Partner Profile Destinations tab can override this setting. You override this setting if you have selected partners who do not require signatures.

  • For inbound security, optionally set the Inbound Signature Validation Credential. Credentials can be selected from the drop-down list box or created by clicking + (the plus sign). Existing credentials can modified by clicking . . . (the ellipsis). Additionally, if you expect to receive MDNs over the Secure Sockets Layer (SSL), you must configure the MDN SSL Proxy Profile field by selecting an existing profile from the drop-down list box or by creating a profile by clicking + (the plus sign). Existing proxy profiles can be edited by clicking . . . (the ellipsis).

External profile AS Security tab

External profile AS Security tab

The Destinations tab
Message destinations define the routing information for the partner. The first destination is the default destination. The gateway uses the default destination when no specific destination is selected from within the B2B Gateway. If the destination protocol is AS, AS attributes can be configured to support security, MDNs, transaction time to live, and resend logic. B2B partner profiles can have multiple destinations. For those individuals familiar with DataPower terminology, it might be helpful to think of internal partner destinations as a “Backend URL. ”

Tip: An internal partner profile can have multiple destinations defined, but the first entry in the list will be the default destination. To change the default destination, move the desired destination up to the first position.

When you select the Destinations tab, you will be presented with the Destinations list view as seen in Figure below. From this view, you can create a new destination by clicking Add or by editing an existing destination by clicking the pencil to the right of the destination.

Destinations list view

Destinations list view

When you click Add, you are presented with a Destinations detailed view where you can configure attributes related to your destination of choice (refer to Figure below). The XB60 provides a wide range of destinations from which to select. Supported destinations are:

In addition, you must provide:

  • Destination Name: This field is a descriptive name given to the destination; destinations must have unique names within a profile.
  • Enabled Document Type: In this section, you can enable the types of documents that this destination will support. The choices are XML, X12, EDIFACT, and binary. The
  • default behavior is to enable all document types.
  • Attributes: Each of the previous destinations has different connection and configuration attributes that can be set to determine how to route data and whether a B2B messaging envelope is applied to the file.

Destinations detailed view

Destinations detailed view

The Contacts tab
The contacts section allows contact information to be entered for the profile. To create one or more contact records, enter information into the the provided fields. The Contact tab is optional; it is not meant to be treated as a contact manager but rather to provide the users of the system with the ability to store contact information about key technical people who are responsible for data that is sent or received to that profile.

B2B Gateway Service

A B2B Gateway Service is an object that defines the characteristics of B2B transaction processing and the association of trading partners allowed to trade data with the B2B Gateway. The B2B Gateway Service includes handling AS2 and AS3 data flows as well as the generation and consumption of the MDNs that are associated with each transaction. If you click B2B Gateway Service Add, a new B2B Gateway template is displayed.
An example of the new service is depicted.

New B2B Gateway Service

New B2B Gateway Service

The B2B Gateway Service contains four tabs that are used for service configuration: the Main, Archive, XML Format, and Advanced tabs. In this section, we discuss the properties of each tab in detail.

Main tab
The Main tab of the service contains the general configuration parameters, such as what protocol or protocols this service will accept and what partner or partners are allowed to access this service. The mandatory fields are:

  • Name: The name of the service object; this name is a unique name within the application domain.
  • Admin State: Enables or disables the object. If an object is in the disabled state, it willnot execute.
  • Document Storage Location:The URL where saved copies of inbound documents, outbound documents, and intermediate documents are stored. The location can be on the local encrypted area of the hard disk, an iSCSI server, or a Network File System (NFS) mount, which stores documents off of the appliance in an unencrypted storage location.
  • XML Manager: This object is responsible for management of the service. The “default” XML Manager is assigned to this service by default. There is typically one manager assigned to a service. The XML Manager controls XML document caching and XML parsing and contains the User Agent, which can control how the service connects to external services. If any customizing is needed, we recommend that you create a “new” XML Manager and not to make changes to the “default” XML Manager.
  • Front Side Protocol Handlers: The Front Side Protocol Handlers are the entry points into the service. They can be listeners that wait for transactions to be sent into the gateway or pollers that periodically look for transactions from a specific location. They contain the IP address or Host Name (recommended) and the port on which the handler is listening or from which the handler is getting data. There are many Front Side Protocol Handlers in the B2B Gateway. The AS2 and AS3 handlers expect that messages sent into them are wrapped in an AS envelope and meet all of the security requirements and attributes supported by the AS2 and AS3 specifications. All remaining handlers expect that documents received into the handlers have no special formatting requirements and are of type EDIX12, EDIFACT, XML, or binary.

The supported Front Side Protocol Handlers for the B2B Gateway Service are:

_ Active Partner Profiles: Partner definitions, such as AS security, business IDS, destinations, and contact information can be predefined in the Partner Profile section. When defining a B2B Gateway Service with message routing, you can simply select a preexisting internal or external trading partner relevant to the message flow or a new profile can be created within the B2B Gateway.

Archive tab
The archive mode is a required gateway configuration item. There are two modes of archiving: Archive and Purge or Purge only. the mandatory fields for the archive configuration when the archive mode is “Archive and Purge” are:

  • Archive Directory URL: The directory to store documents. The documents can be stored locally or off the device.
  • Archive Filename Template: This name is the unique base name of the archived file.

Archive and Purge mode

Archive and Purge mode

there are no mandatory fields for the archive configuration when the archive mode is “Purge. ” The three basic configuration parameters are:

  • Archive Document Age: This number is the maximum number of days that themdocuments will be retained on the device before they are purged.
  • Disk Use Check Interval: This number is the interval in minutes to check for documents that exceed that archive document age.
  • Maximum Disk Usage for Documents: This number of Kilobytes is the maximum storage allocated for this service.

Purge Only mode

Purge Only mode

Using Archive
Each B2B Gateway object has an Archive tab and can be independently configured to archive documents and metadata before purging or to purge the documents without archiving. As a best practice, we recommend that a remote file server (transferred through HTTPS or FTP) or a mounted iSCSI or NFS be used to store archived data. The relevant settings are (and can be seen in the example in Figure below):

  • Archive Mode:Archive and Purge.
  • Archive Directory URL:local:///foo, which in this example is a mounted external file system using the iSCSI protocol. Optionally, you can set this value to a local drive location or an NFS mount point.
  • Archive Filename Template:hubowner, which is the base filename for your archived files. The files will be appended with the current date time stamp(hubowner20090319193930. gz)
  • Archive Minimum Size:1024 Kilobytes. Archiving will not occur unless the amount of data stored is in excess of this number.
  • Archive Document Age:10 days. Documents that are older than the specified number of days will be archived.
  • Archive Minimum Documents:100. This value is the minimum number of documents allowed on the system before archive will be triggered for this service.
  • Disk Use Check Interval:60 hours. Specifies how often to check for documents to archive. This field defaults to hourly.
  • Maximum Disk Usage for Documents:25165824 Kilobytes. This value is the maximum cumulative size of all documents used by this gateway before the archive process is triggered. The value needs to be based on the number of gateways in use, your transaction load, and how often you want archives to happen.

B2B Archive and Purge example

B2B Archive and Purge example

XML Formats tab
The XML Formats tab is used to allow the user to configure the XPATH statements that are needed to find the Sender and Receiver information from incoming XML documents. Sender and Receiver IDs are needed to properly route XML documents through the B2B Gateway Service. The XML Formats tab has one parameter called XPath Routing Policies. The XPath Routing Policies contain the xpath statements used to extract the Sender ID and Receiver ID. The appliance has a built-in XPATH Tool that can easily build the statement used in this policy. These xpath routing policies can be shared by other B2B Gateway Services in the application domain.

Advanced tab
The Advanced tab on the B2B Gateway contains global settings for the B2B Gateway:

  • Service Priority: Sets the priority level for the service in this application domain. This setting will allow you to give a higher quality of service for a specific service. For instance, if you receive transactions from 200 trading partners and two of those partners are responsible for about 90% of your transactions, you can configure two B2B Gateways: one for high priority trading partners and one for normal priority trading partners. The high priority B2B Gateway will process data faster than thelower priority gateway, giving your high priority trading partners a higher quality of service than the remaining tradingpartners.
  • Default AS2 MDN Return Path: Set this path to the default location where you want to receive asynchronous MDNs for AS2 transactions for the entire service. This property can be overridden by the destination for the external partners; refer to for the external partner profile.

External partner AS2 asynchronous MDN destination

External partner AS2 asynchronous MDN destination

  • Default AS3 MDN Return Path: Set this path to the location where you want to receive asynchronous MDNs for AS3 for the entire service. This property can be overridden by the destination for the external partners:
  • Document Routing Preprocessor: This field is used to select the stylesheet that is used to process binary transactions, transactions that are not X12, EDIFACT, or XML. The B2B Gateway Service requires Sender and Receiver IDs in order to use profile management to route B2B data. Typically, binary data is not parsable for IDs. Therefore, you need to set business IDs to route binary data through the B2B Gateway, which is what the binary routing files were designed for. If you do not need profile management for your binary data, we advise that you route binary data through a Multi-Protocol Gateway. However, if you want to use it in conjunction with Profile management, the Multi-Protocol Gateway coupled with a B2B Gateway will provide you with an extremely flexible way of routing binary data through the XB60.

B2B Transaction Viewer

The XB60 brings a new generation of transaction viewing capabilities to the DataPowerappliance concept. In the XB60, all data that flows through a B2B Gateway Service is displayed in an easy to read, at a glance viewer where users can see the status of their B2B transactions. Because we have to monitor the state in the B2B Appliance to support industry standard B2B messaging protocols, we needed the capability to easily monitor that state without having to navigate large log files. In the addition to being able to monitor B2B transactions, the B2B Transaction Viewer gives the user the ability to manually resend transactions and view “off-the-wire” files as well as viewing the decrypted payload and the MDN. Because the payloads by default are stored in the encrypted portion of the RAID volume, the only way to see them in the clear is with the appropriate permissions in the B2B Transaction Viewer or after they are archived off of the device.

The B2B Transaction Viewer can be configured to allow an external client access to only transaction (row) specific data, for example, to only transactions related to a particular partner ID. The transaction viewer can also limit the following: view access to the columnar metadata, view access to transaction message documents, and the ability to resendtransactions. These options will be outlined in “Manage transaction viewing with RBM”.

Enabling transaction viewing for external partners
The Web B2B Viewer Management Service can be set up and enabled to allow external partners access to view transactions. You will need to log in as admin in the default domain to configure this service.

To configure browser access to the viewer, use the following procedure:

  1. Select Objects B2B Configuration Web B2B Viewer Management Service.
  2. Retain the default setting for the Admin State toggle. To place the object in an inactive administrative state, click disabled.
  3. Define the connection from the browser to the appliance:
    1. Specify the IP address to accept requests in the Local IP Address field. The default is 0. 0. 0. 0, which indicates that the service is active on all IP addresses.
    2. Specify the listening port in the Port Number field. The default is 9091.
  4. Select the instance of the Access Control List object to associate from the Access Control List list. The default is web-b2b-viewer.
  5. Specify a descriptiveobject-specific summary in the Comment field.
  6. Specify the timeout for the connection in seconds in the Idle Timeout field.

    The default is 600.

  7. Click Apply to save the object to the running configuration.
  8. Optionally, click Save Config to save the object to the startup configuration.

Manage transaction viewing with RBM
The XB60 Transaction Viewer allows controlled access to transaction data by authorized user accounts. This access is controlled by the XB60 administrator using the standard DataPower Role Based Management (RBM) functionality.

This section will outline RBM techniques for limiting authorized user account access to data through the implementation of user groups. These user groups define the rights that the user has to the DataPower B2B Viewer resource with respect to column visibility, partner visibility, and send/view actions.

User accounts
Viewing transactions starts with creating user accounts for the B2B Transaction Viewer. The user account will allow the user to log in to the B2B Transaction Viewer browser. User accounts can be assigned to a predefined group upon creation.

User account list

User account list

Managing user group accounts
A user group represents a collection of users who perform similar duties and require the same level of access to the Data Power appliance. User groups are assigned rights to one or more DataPower resources. When adding these rights to the access profile of the specific user group, each right is known individually as an access policy. A collection of access policies is known as an access profile.

User group account
Related trading partner user accounts can be combined into one user group. Theseindividual user accounts are limited to the access profile of the user group account to which they are assigned. For instance, multiple partner IDs from one company can be combined in one group account for access to related transactions.

Limiting column visibility
Filtering of column data restricts the resultant dataset to specific metadata associated with each transaction. This type of filtering uses the b2b/column-visibility resource of the RBM policy. When defined, the user can view transactional data for the explicitly defined columns only. The policy can contain one or many columns that can be exposed for viewing. This granularity can be further refined by combining the partner visibility access policy. The policy string has the format that is shown in Example below, where each column added to the policy string will be viewable in the Transaction Viewer.

B2B Transaction Viewer policy string that defines column visibility resource

Tip:To allow all columns, set the access policy to:

This shows the mapping of B2B Transaction Viewer column labels to dataset fields.

Mapping of labels in B2B Transaction Viewer to dataset fields

Mapping of labels in B2B Transaction Viewer to dataset fields

Limiting partner visibility
Filtering of partner-sensitive data (rows) restricts the result dataset to specific transactions associated with previously configured user accounts. This type of filtering uses the b2b/partner-visibility resource of the RBM policy. When a partner-visibility policy string is defined for a user account, the user can view transactional data for the explicitly defined users only. Each policy string can contain only one user account entry. Therefore, to explicitly allow a user to view data for specific users, add a policy string for each account.

The policy string has the format.

B2B Transaction Viewer policy string that defines partner visibility resource

The administrator can add one or more partner visibility access policies to a user group. The RBM B2B logic will look for these policy strings and filter the resultant data sets returned to users.

Limiting B2B access control to actions
There is a requirement to allow the B2B administrator the ability to control access to certain B2B Viewer operations. These operations provide the ability to resend (retransmit) B2B transactions and to retrieve B2B documents associated with transactions. When the resend transaction access policy is enabled in a user group, it only applies to transactions for the trading partners that are listed in the B2B Partners Visibility RBM string.

The policy string to limit the ability to resend transactions has the format that is shown in Example below, where access to the function is unavailable unless explicitly listed in anaccess policy.

B2B Transaction Viewer policy string allowing resend transaction access

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

IBM Websphere Topics