Enabling AS4-Based Message Exchange

Introduction to AS4–Based Message Exchange

Applicability Statement4 (AS4) is a leading standard that aggregates the web service standards to provide necessary transactional features. It standardizes exception handling by defining acknowledgement receipts and error messages, and supports message choreographies. Oracle B2B supports the AS4 protocol in its exchange protocol stack for secure document-agnostic exchange of payloads using web services.

AS4 provides various features such as one-way push, one-way pull, reliability and security over web services. AS4 secures data with authentication, message integrity, non-repudiation of origin, and privacy features.

Exchanging AS4-Based Service Messages with Custom WSDL File

The support for AS4-based messages is available for both inbound and outbound directions. You need to create or use Generic WebService or upload a Web Service Definition Language (WSDL) file that you can customize according to your requirement.

AS4 ebHandler mandates SOAP 1.2, the requirements from BSP 1.1 that depend on SOAP 1.1 would not apply. Similarly, none of the requirements for DESCRIPTION (WSDL) or REGDATA (UDDI) apply here, as these are not used. In the case of SOAP 1.1, the SOAP fault will be received from the service.

It is not necessary to provide a WSDL, because AS4 eliminates WSDL complexity by avoiding the pitfalls of mapping document types and business processes to SOAP operations and actions. The existing Generic WSDL can be used with SOAP 1.2 support.

Exchanging Outbound Messages

From the backend Application (Fabric/AQ/JMS/File/FTP/SFTP) the message will be sent to B2B like other messages. In B2B the Agreement identification will happen based on the From/To/Action and Service or From/To/Doctype and Doc Revision.

Based on the Agreement Configuration, the message (any type of document) will be processed using AS4 Exchange Plugin, SOAP Packing and send through AS4 Transport as configured in the trading partner delivery channel. Based on the Configured delivery channel SYNC/None and Async mode of transport can be supported.

Exchanging Inbound Messages

Based on the registered AS4 WS listening channel the trading partner can post the message with appropriate AS4 headers. The user can register an AS4 endpoint using administration -> Listening Channel. The document will be identified based on the user message soap header or normal document identification flow. The message will be processed by AS4 exchange plugin and deliver to the configured backend application.

The AS4 Exchange can be identified by the following url:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/

AS4 exchange plugin also uses WS-HTTP as transport layer. The generic SOAP exchange will use this for identify the exchange. The AS4 Exchange plugin is added much before Generic WS, so if the exchange is identified as AS4 then Generic Exchange will skip the identification layer.

The document identification will be based on the SOAP Header “CollaborationInfo” -> Action/Service combination. The trading partner Identification will be always based on the ebMS 3.0 specification, PartyInfo ->From/To partyId and type combination. There is no specific identifier for AS4, the user can configure custom identifier as part of the administration->types and use the same in partner profile configuration. Default identifier is name and any other Identified like duns. But there is no specific identifier for AS4 (no AS4 Identifier)

Setting up Trading Partners and Hosts

Oracle B2B provides support for AS4 web-service based message exchange with trading partners. This is achieved by having a composite with B2B binding, or AQ, JMS, File, FTP, or SFTP to initiate the payload from the backend application. The same can be sent to the trading partner using AS4.

On the inbound side, Oracle B2B receives the AS4 message and delivers it to the backend application using a SOA composite or through AQ, JMS, File, FTP, or SFTP. Oracle B2B can identify the incoming trading partner based on the SOAP envelope header “PartyInfo”.

To add the initiating trading partner and configure the trading partner delivery channel:

In Partner Configuration, click Partners.
Rename the host to your company name.
Click + to add a trading partner and enter the name of the partner.
Click the trading partner you just created.
Click the Documents tab to add the supported documents and click + to add the appropriate document.
Click the Channels tab and click + to add the exchange/transport.
In the Protocol list, select AS4-1.0.
If you have defined a custom WSDL file in admin, select it here. If you do not have a custom WSDL file, select the Use Generic SOAP option.
From the Service drop-down list, select Generic SOAPService.
From the Port drop-down list, select Generic Port.
From the SOAP Action drop-down list, select generic/soap/process.
Enter the URL of the endpoint.
An example URL: http://myhost.com:7878/b2b/services/ws/tradingpartnername_listeningchannel
Click Save to save the details.

Note:

Follow the steps above to set up the responder as well, using the name of the responder in step 2.

Message Partition Channels

The Message partition channels (MPC) allows for partitioning the flow of the message from sender to receiver into several flows that can be controlled separately and consumed differently.

MPC allows:

Setting the transfer priorities: Some messages may be transferred with higher priority than others regardless of the order which they have been submitted.
Organizing the inflow of messages on the receiver side: Enables the receiver to dictate each flow in a distinct way.

The following figure shows an example of the MPC work flow for one-way pull transactions.

Description of the illustration as4_mpc.gif

This can be achieved in Oracle B2B’s existing sequencing mechanism. From the backend application, if the messages are sent with the “MPC” property, then MPC is used as a sequence message target. It is inserted into the appmessage table and sequence manager table. The messages cannot be processed by B2B until the pull message request is received.

Based on the pull message request the corresponding message is picked from the sequence manger table and enqueue into event queue. The message thenpasses through the agreement identification based on the From/To/Action/Service or From/To/Doctype/Docrevision. Based on the agreement configuration, the message is processed and sent to the trading partner as per the delivery channel configuration.

The message prioritization can be handled as part of pull request and response.

Duplicate Message Detection

The duplicate message detection feature provides the ability to detect the message duplication based on the message id. The existing duplicate detection feature is re-used for AS4.

It can be configured as part of the delivery channel. In case of inbound message flow, if the duplicate detection is enabled then the message duplication is identified and a fault message is sent to the message sender.

Example 22-1 Example — Duplicate Message Detection

The following message id is used to detect the message is duplicated or not.

eb:MessageInfo/eb:MessageId.

P-Mode Parameters

B2B supports P-Mode parameters. The parameters relevant to AS4 features are listed here.

Table 22-1 P-Mode Parameters and Descriptions

P-Mode Parameter	Description
PMode.ID	Trading Partner profile, the identifier can be configured.
PMode.Agreement	The Agreement id will be used to provide th agreement Ref.
PMode.MEP	The message exchange pattern(MEP) will be based on the eventName enqueued from backend application.
PMode.MEPbinding	The message exchange pattern (MEP) will be based on the eventName enqueued from backend application. The trading partner delivery channel configuration is available.
PMode.Initiator.Party	While Enqueue set the From Party will be always a initiator
PMode.Initiator.Role	While Enqueue set the ActionName/event Name to set the FromRole
PMode.Initiator.Authorization.username	Set the Auth user in OWSM credentials, incase of Basic Authentication
PMode.Responder.Party	While Enqueue set the To Party will be always a Responder
PMode.Responder.Role	While Enqueue set the ActionName/event Name to set the ToRole
PMode.Responder.Authorization.username	Set the Auth user in OWSM credentials, incase of Basic Authentication
Protocol.Address	There is no need to configure anything specific to this, as part of delivery channel http will be consider always.
Protocol.SOAPVersion	AS4 delivery channel configuration is enough, it will always uses SOAP 1.2
BusinessInfo.Service:	As part of enqueue, set the ActionName/event Name with Service or other wise set as part of Custom Document protocol in case of static service
BusinessInfo.Action	As part of enqueue, set the ActionName/event Name with Action or other wise set as part of Custom Document protocol in case of static Action
BusinessInfo.Properties[]:	Not Supported to add Properties
ErrorHandling.Report.ReceiverErrorsTo	Incase of error/exception B2B will send a exception message to sender
ErrorHandling.Report.AsResponse	Incase of error/exception B2B will send a exception message to sender
[1].ErrorHandling.Report.ProcessErrorNotifyProducer	The errors will be processed and it will also update request message state to Error.
ErrorHandling.Report.DeliveryFailuresNotifyProducer	The errors will not be delivered then the error receipt message will be change the state to Error.
Security.WSSVersion	OWSM configuration handles
Security.X509.Sign	OWSM configuration handles
Security.X509.Signature.Certificate	OWSM configuration handles
Security.X509.Signature.HashFunction	OWSM configuration handles
Security.X509.Signature.Algorithm	OWSM configuration handles
Security. X509.Encryption.Encrypt	OWSM configuration handles
Security.X509.Encryption.Certificate	OWSM configuration handles
Security.X509.Encryption.Algorithm	OWSM configuration handles
Security.UsernameToken.username	OWSM configuration handles
Security.UsernameToken.password	OWSM configuration handles
Security.UsernameToken.Digest	OWSM configuration handles
Security.UsernameToken.Created	OWSM configuration handles
Security.PModeAuthorize	OWSM configuration handles
Security.SendReceipt	OWSM configuration handles
Security.SendReceipt.ReplyPattern	OWSM configuration handles

Local Policy Attachment

You can attach multiple policies to a delivery channel using LPA (Local Policy Attachment). As part of the delivery channel configuration, you select the OWSM policies and attach to the particular endpoint.

This is used to handle the policies attached for the webservice endpoint. The list of policies can be selected from the drop -down list and then provide the necessary information. For example, message protection policy will be used to protect the messages (sign+encryption) based on the certificate alias configured in the policy.

Use-Case Scenarios

Scenarios about exchanging documents between two partners.

In the following scenarios, we are assuming that two partners, Acme and GlobalChips, want to exchange documents using AS4 Protocol. For this purpose, we assume that Oracle B2B AS4 is installed on two separate servers (one for each partner). One of the servers, called Acme, acts as the initiator and sends an XML document using the AS4 protocol to the responder, called GlobalChips.

Inbound Messaging

The sending and receiving MSH are configured to exchange a particular message type using reliable messaging. The sending MSH sends a signed message of this type.

The expected result is that the receiving MSH returns a synchronous AS4 non-repudiation receipt. The content of the NonRepudiationInformation element in the returned receipt MUST match the Signature of the received message. This can be determined using Message logs, message trackers and/or TCP monitoring tools; the latter requires the to not use TLS.

Setting Up the Responder

To set up the responder, in this case, GlobalChips:

Login to Oracle B2B on the receiver side,
Click Administration to create a document.
In the Document tab, select Custom and add the Document Version, for example 1.0.
Select the Document Version created and add Document Type, for example, ORDERS.
Select the Document Type created and add Document Definition, for example, Ord_def.
Click Definition to provide the schema.
Select the Identification Type as xml.
Provide the Identification Expression (XPath) to identify the incoming document.
Example: /*/*[local-name()='shipto']/*[local-name()='country']
Click Save to save the details.
On the Receiver side, as part of setting up the listening channel, click on the Policy Configuration.
From the policy list, select the oracle/wss10_message_protection_service_policy and attach.
Click + on the above selected policy to provide the certificate alias
Provide keystore.sig.csf.key as the private key alias of the host to verify the signature of the messages.
Provide keystore.enc.csf.key as private key alias of the host to decrypt the message.