B2B Transaction-Processing Framework

Anypoint Partner Manager V1.0 was deprecated in March 2021. Its End of Life is March 31, 2022. Support for Anypoint Partner Manager 1.0 continues in accordance with the Product Support and Maintenance Terms but is not available for new customers or upgrades. For the latest version of Anypoint Partner Manager, contact your Customer Success Manager to determine how you can migrate to the current version.

A B2B transaction-processing solution serves as a translation layer between internal systems and the various formats (X12, EDIFACT, XML, CSV, and others) and transport protocols (AS2, FTP/S, and others) commonly used in electronic transactions between companies. Because a company cannot typically dictate that all its trading partners adhere to a single configuration, it is often necessary to develop custom solutions for each trading partner. When custom software development is required for each trading partner, the effort and time required to onboard new trading partners increases dramatically, thereby limiting the business relationships a company can pursue.

B2B Transaction Processing Framework enables developers to build a single set of Mule Runtime flows that can process a wide range of messages from many different partners by dynamically applying rules and configuration data stored in Anypoint Partner Manager (APM). Thus, non-programmers such as data analysts can use APM to onboard new trading partner relationships and support new transaction types without having to develop, test, or deploy new Mule Runtime flows.

This section identifies high-level framework components and their roles in end-to-end B2B transaction processing.

Functional Architecture

B2B transaction processing typically proceeds through some combination of the stages shown in Functional Architecture.

Processing stages and their sequence can vary between implementations.

Figure 1. Functional Architecture

Receive

Each incoming transaction from a partner or internal system is delivered through a transport protocol endpoint configured to receive the message.

Resolve

Using data that may be inside a document or in incoming metadata (such as HTTP headers or filenames), this stage identifies the partner and the transaction type, then uses these to retrieve corresponding processing details from APM. These details include:

Endpoint to which the transformed message is to be delivered
Schema to use for validation
Map to transform the message into the required target format

Transform

Each incoming message is translated into a message format appropriate for the target service being invoked. This translation is performed dynamically using a Map retrieved from the Trading Partner Management (TPM) API.

Validate

Makes sure the required data is present in the required format. This validation is performed dynamically using a Schema retrieved from the TPM API.

Deliver

Using endpoint configuration data retrieved from the TPM API the flow dynamically delivers the message to the Business Service endpoint address.

Technical Architecture

B2B Message Processing Framework shows the primary components of the framework and how these components interact to process B2B transactions. Component definitions follow the diagram.

Figure 2. B2B Message Processing Framework

MuleSoft-Provided Components

Anypoint Partner Manager

Anypoint Partner Manager (APM) is the B2B Transaction Processing Framework user interface, enabling you to:

Trading Partner Management (TPM) API

The Trading Partner Management (TPM) API manages storage and retrieval of configuration data for partners, including the details for processing their transactions.

Tracking API

The Tracking API manages storage and retrieval of metadata from processed transactions.
For example:

Sender
Receiver
Time stamps
Message type
Acknowledgement status

This includes, but is not limited to correlation logic for matching acknowledgements to original messages and identifying duplicate messages.

Partner Manager Connector

The Partner Manager Connector (PMC) runs inside Mule Runtime and coordinates all interaction with the APM APIs (TPM and Tracking).

Object Store

The Object Store is a distributed cache in Mule Runtime that replicates data across nodes in a cluster. TPM configuration data, once retrieved, is cached in the Object Store. Caching minimizes calls to the TPM Service, thereby improving performance and reliability. PMC manages this caching.

Customer-Built Flows

At this time the flows identified below must be developed by the customer. MuleSoft may provide these components as part of the product in the future. However, in order to provide full extensibility and customization, the option will remain for customers to provide their own implementations .

Receive Flows

Each receive endpoint corresponds to a Mule flow that consists of the appropriate protocol connector and the appropriate endpoint configuration. After receiving a message over a particular protocol, each receive flow:

Tracks the message using the Partner Manager Connector (PMC) in order to persist a copy of the message as it was received from the partner.
Places a queue message with headers populated with any important metadata from the inbound protocol, such as transport headers and filenames, on the Resolve queue.

Receive flows are activated dynamically by a Receive Endpoint listener flow which polls the TPM system for the list of endpoints that should be active. This flow creates a specific endpoint for each flow based on a template for the required transport protocol. It then dynamically instantiates that flow into the Mule Runtime and starts it, so that the required connector endpoint is active and listening for messages.

Resolve Flow

Pulls together from the message and any transport headers the needed metadata fields for identifying the specific document type.
Passes the metadata fields to the TPM service to look up the document type and associated configuration settings (Map, Schema, target Endpoint) and adds this information to the context headers that travel with the message to be used by later stages.
Passes the message to the next processing stage.

Transform Flow

Dynamically applies the configured mapping script from the context header to translate the message into the canonical format for the target Business Service.
Does any necessary data translation, such as resolving partner values to your company’s values using lookup tables functions, and flows.
Uses the PMC to track the mapped, canonical version of the message.
Passes the updated message body to the next processing stage.

Validate Flow

Dynamically applies the configured schema script to validate that the message is in the required format.
Uses the PMC to track the validation result for the message.
Passes the message to the next processing stage.

Deliver Flow

Invokes the target service by passing the transformed message to the configured transport endpoint.
Uses the PMC to track the result from the target service.

Message Payload Persistence Flow

This is an optional flow that can be implemented to store message payloads at various stages. It receives a MuleSoft message from the PMC, persists that message payload to the desired data store, and returns a URL that can be used to retrieve the message later using the Message Payload Retrieval Flow. The URL is stored in the related tracking data stored in the Tracking API in APM and displayed to the user in the context of the transaction. Clicking this link will invoke the Message Payload Retrieval Flow and display the message payload in a pop-up window.

Message Payload Retrieval API Flow

The Message Payload Retrieval API Flow is used to retrieve the message payload with a URL (which contains the specific transactionId of the message to be retrieved).

Business Service Flows

For each target internal service, there is typically a Mule Runtime flow that exposes a REST-based API and communicates with the backend system using the appropriate connector or connectors. These Business Service flows are not technically part of the B2B system, but are often part of the overall solution.

Replay Flow

The replay flow coordinates replaying transactions. It polls the Tracking service for transactions that have been marked for replay. When it finds transactions that need to be replayed it:

Pulls the original message body and headers from the Tracking API and the Message Payload Retrieval API.
Constructs a new Mule message with the original payload and headers and passes it to the Resolve flow to reprocess the transaction.
Tracks the fact that the transaction has been replayed.
Updates the TPM service to indicate that the replay is complete

Information Architecture: APM-Configurable Entities and Terms

APM stores the configuration data shown in B2B Transaction in order to support the dynamic processing of different transaction types for different trading partners.

Figure 3. B2B Transaction

Partner

Represents an external company with which your company does business. Your company itself is also considered a Partner.

Partnership

The relationship between your company and an external company with which your company does business. Your company itself is also considered a Partner, and there is a special partnership called the “Home Org” in APM.

Partner Identifier

A predefined identifier of a specific Partner. There are several types of Partner Identifiers used in B2B transactions and configurable in APM. For example, for EDI X12 documents there are ISA identifiers, which are used in EDI interchanges to identify the sender and receiver. AS2 is another type of identifier, used in AS2 transmissions.

Endpoint

An receive endpoint is a URL to which a document can be sent.

A send endpoint is a URL from which a document can be sent.

For information about how endpoints are created, see Endpoint Resolution.

Document, Message, File

These terms are used interchangeably in the B2B world to reflect an instance of a structured payload being passed through a system to convey information about a transaction. For consistency, we use the term document to represent these instances.

Document Type

Document Types are configured in APM. A given document type is identified by the following pieces of information:

Standard
- Examples: X12, EDIFACT, XML, CSV, JSON
Version
- X12 (Examples: 4010, 5010)
- RosettaNet (Example: PIP3B3v11.12.00

For standards that don’t have version, such as XML and CSV, Version is not part of the Document Type configuration.

Message Type
- X12 - 850, 855, 856, etc.
- RosettaNet - 3B3
- XML - root node name, namespace
- CSV, JSON - Name given to the transaction, not necessarily contained in the message

Document Properties

Document Properties are data fields that are extracted from received documents for the purpose of searching, correlation, TPM resolution, or duplicate checking. Document Properties are configured for Document Types. The user provides the Name of the property and the Path (XPath for XML, JSONPath for others) for retrieving the property from the document. These properties are extracted from the document by the Tracking API and stored to be used later for the purposes mentioned above.

Schema

The schema is stored with the Document Type. It is one of the following, depending on the message type:

Message Type	Schema type
XML	XSD file
CSV	NA
EDI	EDI Schema Language (ESL) file
JSON	JSON Schema

Message Type

Schema type

XML

XSD file

CSV

EDI

EDI Schema Language (ESL) file

JSON

JSON Schema

Map

Script (XSLT or DataWeave) for transforming one Document Type to another Document Type.

Source Channel

Details pertaining to how to receive a particular document. Receive is relative to the B2B Transaction Processing flows. For example:

An inbound transaction would have a Source Channel that receives a Document from an external partner.
An outbound transaction would have a Source Channel that receives a document from an internal system.

Target Channel

Details pertaining to how a particular document is sent. Sent is relative to the B2B Transaction Processing flows. For example:

An inbound transaction would have a Target Channel that sends a document to an internal system.
An outbound transaction would have a Target Channel that sends a document to an external partner.

Route

Connects a Source Channel to a Target Channel.

Transaction

Denotes the end-to-end processing of a single instance of a document from the receipt at an endpoint all the way to the desired destination. A TransactionId can be used to find metadata and persisted payloads for the transaction at each stage.

Directional Processing

Transactions are either inbound or outbound.

Inbound transaction: A transaction between an external partner and the home organization, initiated by the external partner.
Outbound transaction: A transaction between the home organization and an external partner, initiated by the home organization.

B2B Directional Processing depicts the relationships between these configuration entities relative to the processing of inbound or outbound transactions:

Figure 4. B2B Directional Processing

In the interest of illustrating a range of usage scenarios, the architecture shown in B2B Directional Processing depicts configuration details that may not appear in a specific scenario.

A common practice is to map each incoming document to a standard internal format, (often called the canonical format). If the target system accepts this format, there is no need to apply a second map. That is, a map can be configured for the Source Channel to transform into the canonical format, and there is no map needed for the Target Channel. However, if there are multiple Target Channels for a given Source Channel, there may be a need to apply an additional map in one of the Target Channels; in that case two different maps would be applied.

For an outbound transaction, the document might originate in the canonical format, so there may not be a map required in the Source Channel. However there would be one in the Target Channel to map to the desired format of the external partner.

User Interface

The APM user interface enables partner configuration, administration and detailed transaction monitoring.

Search and view results of processed transactions.
View end-to-end processing that occurred for a transaction.
Manually cause the replay of failed transactions.