Introduction
This whitepaper is about Anypoint Partner Manager offered by MuleSoft. Anypoint Partner Manager (APM) is a MuleSoft cloud-based solution for handling Electronic Data Interchange (EDI) messages. The APM, being a cloud-based offering, is available only on Cloudhub, and is controlled from Cloudhub control plane.
EDI is conceptualized as a B2B communication system to exchange documents securely, reliably, and efficiently through computer networks. Prior to EDI, enterprises used to exchange documents as paper documents. With EDI such cumbersome processes of physical documents exchange are eliminated. Since EDI is a system for electronic interchange, emphasis was placed on efficiency, and not readability. Since the EDI systems are designed for automatic data interchange between business computing systems with minimal human interventions, it requires standards to be in place. The major EDI standards are X12, EDIFACT et-cetera. EDI is used across many verticals like Airlines, Retail, Healthcare, Telecommunications et cetera.
Anypoint partner manager
The key strengths of APM
The APM is a very robust offering by MuleSoft, under Anypoint platform. The key strengths of APM are
- Modern Architecture – APM is designed based on proven MuleSoft frameworks and best practices, leveraging the Anypoint platform.
- Cloud based – The APM is a Cloud based offering thus minimizing the hardware and IT costs associated with On-Prem implementations (The runtime components of APM can be deployed On-Prem using the Anypoint Hybrid model – Cloudhub Control Plane and On-prem runtimes).
- Seamless integration with Anypoint platform – APM is controlled via the Cloudhub Control plane. Further the APM can be augmented with Mule Apps that follow API led connectivity.
APM Key concepts
As a pre-requisite, we need to understand the key concepts of APM, which are derivatives of EDI standards.
APM Endpoints
The APM endpoints are the gateways through which APM sends and receives EDI messages. APM supports the following endpoints out of box, for both inbound and outbound messages.
- Applicability Statement 2 (AS2)- A secure EDI protocol with HTTPS backend
- HTTP / HTTPS
- FTP / SFTP
Note: If either inbound or outbound messages, do not support the protocols mentioned above, we can create a System API(s), use the same to produce/consume the messages in that protocol and interface with APM using HTTP/HTTPS.
APM Partners
In EDI, a partner is an enterprise with whom the host enterprise has a business relationship. For example, a parts supplier for an automobile manufacturer. Or else a retail chain that resells fashion products of a luxury goods conglomerate. The EDI messages are business to business documents exchange between the host enterprise and the partner enterprise. For each partner, we can have a partner specific endpoint or else reuse a generic endpoint.
APM Message types
As per the context of the message, there are multiple message types. Such message types vary according to the industry or vertical. For example, the X12 EDI standard in retail industry, has many message types like Invoice (EDI 810), Inventory Advise (X12 846), Purchase order (X12 850) et-cetera. Additionally, we can configure custom messages like Common Data Model JSON.
APM Message flows
The APM flows are where the message plumbing between source and destination endpoints happens. More importantly, the message transformation from source format to destination format is defined under APM message flow. A standard DataWave Language (DWL 2.0) script is used to achieve the transformations. The message flow also defines the message validations and message metadata. For each partner, a message flow needs to be defined for each message type. For example, if we have 5 partners, all using three EDI message types (Say, X12 810, X12 850 and X12 856), then we need to define a total of fifteen message flows. For common acknowledgement message type (X12 / EDIFACT 997 message), separate flow is not required, and is handled withing other message flows.
APM content store
The APM content store is the location where all the documents which are received and sent by APM, are stored for Auditing purposes. The implementation can choose any storage mechanism for content storage. For cloud-based solutions, AWS S3 is the recommended storage solution while for on-premises, SFTP server may be considered. Even though these generic recommendations are based on many aspects like reliability of storage solution, the availability of reliable Mule connectors, other storage systems may be considered as per the business requirements. It must be noted that the APM does not directly interact with the content storage, rather it makes use of a content storage system API. This content storage system API is not automatically generated, rather must be implemented as part of the implementation. MuleSoft provides a reference implementation for content storage system API which can be obtained from Exchange. Based on the reference API provided by MuleSoft, the actual content storage API must be developed for the specific storage solution chosen for content storage. Hence for the content storage backend to be considered, it must be possible to develop a robust system API for the same.
The content storage service needs to be manually deployed like any normal system API, preferably via a CI/CD mechanism. The sizing of the content storage API should be determined as per the API volumes and configured during the implementation.
APM Architecture
The APM utilizes robust architecture which is described in this section.
The APM architecture leverages the existing Mule technologies to create a robust EDI solution. The APM relies on a few auto-generated services to handle the EDI messages. The services are automatically deployed when the APM is configured. The interservice communications are handled by Anypoint MQ so that reliability is ensured. The inbound messages are sent to an exchange. This allows multiple queues to listen to the exchange without interfering with each other – One for processing the message and other for auditing. The following are the APM services that are used by APM to handle EDI messages reliably.
Receiver services
For each unique endpoint for receiving messages, a receiver service is generated and deployed, to handle the same. For example, if (S)FTP and HTTP(S) are configured, then there shall be two receiver services, one each for (S)FTP and HTTP(S). The receiver services can be configured to receive messages directly from partners or else from an internal API like a process API. The service naming pattern shall be b2b-inbound-<>-<>. For example, an SFTP receiver service could have a name “b2b-inbound-sftp-cofg". The job of the receiver services is to reliably receive the messages and pass them on, for further processing via queue.
Sender services
For each unique endpoint for sending messages, a sender service is generated and deployed, to handle the same. For example, if (S)FTP and HTTP(S) are configured, then there shall be two sender services, one each for (S)FTP and HTTP(S). The sender services can be configured to send messages directly to partners or else to an internal API like a process API. The service naming pattern shall be b2b-outbound-<>-<>. For example, an SFTP sender service could have a name “b2b-outbound-sftp-sfbu". The job of the sender services, as the name implies, is to reliably send the messages
Document replication service
The document replication service is responsible for ensuring that the messages are sent for processing as well as replicated to the content store. This service also ensures that the transmissions and messages processing for each transmission can be properly tracked.
Document processing service
The document processing service is the service that shall be responsible for processing both incomming and outgoing messages. The document processing service is the one that is responsible for transforming the EDI messages to an internal data structure, preferably a Common Data Model. It is also responsible for transforming the messages from common data model to EDI messages, in case of outgoing messages. The document processing service makes use of the DWL scripts defined in the message flow configuration to do the necessary transformations. Each time a message flow in APM is updated, this service shall be updated to include/update the same.
Why APM
The APM offers a value-added proposition that builds on the strengths of Anypoint platform. With APM, the plethora of features offered by MuleSoft Anypoint platform can be leveraged while the specific EDI functionality is taken care of by APM.
The strength of API Led connectivity
With APM, the well-established architectural pattern of API led connectivity can be leveraged. The various systems can be well integrated with Application network of System and Process APIs whilst using APM as a robust experience layer, interfacing with B2B partners. This enables seamless and robust information exchange with B2B partners.
Robust monitoring
The APM provides robust transmission and message monitoring capabilities out of box, through the APM Monitoring. This capability can further be leveraged using the Anypoint platform monitoring as well as APM REST APIs. The APM also provides a robust mechanism for audit trail of messages through the APM monitoring.
Conclusion
Anypoint Partner Manager is a very compelling value proposition from MuleSoft that allows Enterprises to leverage the robust integration capabilities of Anypoint platform and seamless partner communication capabilities of APM.