Anypoint B2B is a set of protocols and message templates for standards-based Business to Business (B2B) messaging-based integration.
Anypoint B2B adds trading partner integration using EDI over AS2 into Anypoint Studio and Mule ESB’s runtime environment.
Contents of Anypoint B2B
At its first public release, the Anypoint B2B integration set contains
- AS2 Connector (GA-1.0.0) – Requires Mule 3.5.0+
- Adds EDIINT AS2 communications protocol support to Anypoint Studio and Mule runtime
- EDI Module (BETA-1.0) – Requires Mule 3.5.0+
- Basic starter pack of ANSI X12 and EDIFACT message templates
- EDI parsing, custom mapping and response messages
- Anypoint B2B Portal for Trading Partner Management (BETA)
Notably missing, though, is EDIINT AS4 support, anticipated for a future version.
What is EDI?
Electronic Data Interchange (EDI) is a term for standards based message exchange by prior agreement. EDI can apply to the message; the agreements defining the trading relationship and messages and message standards to be used; the systems processing the messages.
The message ‘interchanges’ are typically batched, with multiple mandatory, optional and repeating header, detail and trailer records used to construct delimetered, row-based messages. Specialist EDI packages (such as IBM Sterling Gentran, Atlas EDI and many more) were required to map between local data and EDI standard messages.
The messaging standard defines specific business processes along with the messages in each direction and in which order fulfil the process purpose. Each message defines a range of record types used, some of which are reused and some of which are specific. Each row in the batch interchange starts with an identifying record type. A range of delimeters are used for representation of fields within a record to include separation of fields, field groups and optional fields.
See the WHISHWORKS blog on EDI Mapping with Mule ESB
An example of EDI standard components could be:
- Standard: X12
- Industry: Retail / Supply Chain
- Process: Order fulfilment
- Messages: Forecasts, Order, ASN, Goods Receipt, Acknowledgements
- Records: Line item, Name and Address (multi-location use e.g. warehouse, depot, customer, etc)
The above could be developed independently such that a retailer could build the functionality to trade with a number of EDI standards compliant suppliers in a repeatable, reusable manner.
For more detail on EDI please see http://www.edibasics.co.uk/what-is-edi/
There are a number of EDI standards which have been developed over the years, often differing by originating geography, time period and industry.
- ANSI X12 (or ASC X12) – Used extensively in the USA (also in Canada and Latin America)
American National Standards Institute chartered the Accredited Standards Committee to develop and maintain the X12 message standard and supporting architecture for standardised message interchange based business processes
For X12 EDI format see http://www.parse-o-matic.com/parse/pskb/ANSI-X12-EDI-Format.htm
- UN/EDIFACT – Used extensively in Europe and (non-American) rest-of-world
(United Nations Electronic Data Interchange For Administration, Commerce and Transport) is a standard created by the UN/EDIFACT working Group on behalf of UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)
An international standard developed under the United Nations and approved as ISO 9735
EANCOM is a widely used subset of EDIFACT
There is partial mapping based compatibility between EDIFACT and X12.
XML/EDIFACT is an XML Schema-based set of EDIFACT messages
- ANA Tradacoms – Used for UK retail [deprecated by EDIFACT]
An EDI messaging standard supporting barcoding developed by the Article Numbering Association for the UK retail industry, now largely replaced by EDIFACT
- ebXML – Standards defined, schema based XML replacement of non-XML EDI
Electronic Business Extensible Markup Language is set of XML-based electronic messages adopted by the OASIS working group as part of their an open standard, defining the transport, routing and packaging of e-business transactions, intended as an EDI replacement using EDIINT AS2 or AS4.
In summary, Anypoint B2B adds EDI capabilities to Mule by way of X12 5010 and the earlier 4010 messages, and provides ESL (EDI Schema Language) to create custom X12 EDI messages represented by transactions, segments, composites, and elements.
What is AS2?
Very simply, AS2 (Applicability Statement 2) is an abbreviation for a statement of requirements which became a standard to replace EDI Communications Infrastructure and Protocols using the internet.
Background and VANs
Traditional EDI pre-dated the internet, using VANs (Value Added Networks – private networks connected to via ISDN and other digital bi-directional lines, such as IBM, AT&T, GEIS, BT, et al.). VANs offer value-added network and messaging services such as encryption, compression, data retention for error recovery by way of message resubmission along with protocol conversion and message translation. Some VANs also offer paper- and fax-to-electronic messaging services and electronic-to-archiving and long term records warehousing.
This network was (and in some cases still is) quite good in terms of reliability given low data volumes and very good throughput given the low contention ratios. But these VANs required specialist network support and (mostly) dedicated ISDN, which was already a fair price pre-2000 but the VAN also charged to have a connection (setup) and send data (usage). Since 2000 most VAN users (especially the larger ones) have embraced the internet as a cost saving communications medium. But, there was a gap. The reliability provided by the VAN’s where message mailbox applications allowed administrators to verify delivery and be assured of the identity of their trading partners and recover from failure automatically, often without it ever being noticed.
The software applications which performed EDI assumed a safe, reliable network and were therefore unsuited to the wild-west of the internet.
EDI over the Internet – Applicability Statement 2
EDIINT is an initiative to enable sending EDI messages over the public internet in a way that satisfies business requirements around security and reliability. There are a number of flavours of the EDIINT paradigm, the most popular and pervasive by far of which is Applicability Statement 2 (AS2) for EDI over the INT using HTTP with message security.
The business requirements for VAN replacement principally included
- Data security through encryption, while allowing dynamic routing by intermediaries
- Guaranteed once and only once delivery
- Nonrepudiation of origin and receipt
Using S/MIME, Message Integrity Check (MIC) data hashes, PKI encryption and digital signatures collectively permitted EDIINT to satisfy organisations B2B security, authenticity and non-repudiation requirements. Guaranteed once and only once delivery required the combination of a standard-based processing strategy along with dynamically generating acknowledgement messages (called MDNs – Messages Disposition Notifications in EDIINT) such that the sender could be informed of the status of the message with regards to receipt and initial processing of the request by the ultimate recipient.
These capabilities made EDIINT valuable as a standard for replacing VANs to drive down supply chain costs. AS1 was SMTP based and didn’t achieve the same adoption as AS2 which is HTTP based remains the de facto method of implementing EDIINT. These requirements also haven’t changed much in the B2B scenarios currently faced. Especially where there are many parties involved, the use of an existing standard can vastly improve take up and delivery turnaround time.
In summary, EDIINT AS2 defines the exchange of structured business data over HTTP(s) where, Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats.
The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message.
Excerpt of the AS2 specification abstract at www.ietf.org/rfc/rfc4130.txt
EDIINT ASx Versions
- AS1 – RFC 3335 for Secure MIME batch messaging over the internet using SMTP
- AS2 – RFC 4130 for Secure MIME batch messaging over the internet using HTTP
- AS3 – RFC 4823 for Secure MIME batch messaging over the internet using FTP
- AS4 – Commercial standard for EDI/ ebXML/other messaging over the internet using web services
But why add what can be considered legacy capability? Who needs it? Who are the intended users? These are interesting questions. Let’s consider them next.
If you would like to find out more about how APIs could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at email@example.com.
Other useful links: