B2B capabilities in Cloud Platform Integration

With the end of July 2017 release of Cloud Platform Integration customers having “Enterprise License” would be able to process EDI documents. I shall explain to you a few use cases where this capability can be used and how this can be achieved.

Scenario 1: You have a partner who expects documents to be sent in ASC X12 document standard over AS2 protocol.

AS2 is an Internet security standard defined by the IETF (Internet Engineering Task Force) and designed to allow business transactions to move securely over the Internet. See more information at Wikipedia

ASC X12 – The American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for inter-industry electronic exchange of business transactions, namely electronic data interchange.

See EDI document standards for more information on ASC X12 and EDIFACT (also supported in Cloud Platform Integration)

For this scenario you see that IDoc documents are being sent to Cloud Platform Integration.

The documents that are received are mapped to EDI XML. The X12 and EDIFACT schema XSD documents required for EDI processing and mapping step can be obtained from the Cloud Integration catalog. Search for the folloiwng packages in catalog

• ASC X12 – Version: 004010
• ASC X12 – Version: 005010
• UN/EDIFACT – Version: D.01B (Syntax Version: 3, Batch Mode)
• UN/EDIFACT – Version: D.96A (Syntax Version: 3, Batch Mode)
• UN/EDIFACT – Version: D.98A (Syntax Version: 3, Batch Mode)

The XML to EDI Converter supports conversion of both EDIFACT and X12 XML content. To process a specific type of document you would have to upload the document into the processing step.

You will be able to send out the AS2 either use the synchronous or asynchronous. In case of synchronous AS2 you will receive the MDN message in the same session.

In case of asynchronous AS2 option you will have to create another iFlow with AS2 MDN Sender channel to receive the MDN message.

Note: The AS2 Adapter provides a lot of standard settings as required by AS2 protocol example whether you would like to compress, sign and encrypt the message based on your arrangement with your partner.

Scenario 2: You have a partner who sends EDI documents (example EDIFACT) and would like to forward this to your ERP system

In this case, you would receive the EDI messages either via your HTTP Sender Adapter or possibly via AS2 in case the partner is able to send AS2 messages to you.

The partner could possibly send individual documents or multiple documents. In either case, you can make use of the EDI Splitter. The EDI Splitter can also be used to Validate the incoming message. If validation is required, then you would have to provide the schema XSD documents required for the incoming message from the Cloud Integration catalog.

The EDI Splitter supports validation and split (in case of multiple documents) both EDIFACT and X12 message formats.

In case validation is chosen the incoming message with each of the individual documents are validated. You would have to use a Router step to check if the message out of EDI splitter is an acknowledgement message or a spit EDI message. You would be able to check the header ${header.EDI_ACKNOWLEDGEMENT}=’true’ in case the outgoing message is an acknowledgement message.

The 997 and CONTROL acknowledgements are auto-generated by EDI Splitter in case Validation required is chosen for X12 and EDIFACT documents respectively.

After each individual message are split in the EDI messages route you can use the EDI to XML converter to convert the EDI flat message to an EDI XML message. Further on you can use a mapping step to map the message to the required format in this case IDoc XML and send it to your backend system.