Splitting interchanges

Partners rarely send one document per file. An X12 interchange (ISA to IEA) can hold several functional groups (GS to GE), and each group can hold many transaction sets (ST to SE). Lakeside Components, for example, sends one file each evening with all of the day's 856 ship notices. Cloud Integration's conversion steps work on one message at a time, so the first job in an inbound EDI flow is to validate the interchange, split it and acknowledge it. That is what the EDI Splitter does.

What the EDI Splitter does

You add it from the palette under Splitter > EDI Splitter. It splits inbound bulk EDI messages into individual messages, can validate them, and can create the functional acknowledgment for the interchange. It handles EDIFACT, ODETTE, EANCOM, TRADACOMS, VDA and ASC X12. A few documented limits shape your design:

• It supports only one functional group per interchange, with multiple messages of the same type (homogeneous transaction sets).
• It can't be combined with the Gather, Join or Aggregator steps in the same flow.
• Version matters: for example, newer versions support more EDIFACT syntax versions and LS/LE loop segments, and from version 2.9 you can use the same X12 XSDs in your tenant as in Process Orchestration. Update the step version in old flows before you rely on newer behavior.

Validation and transaction mode

For X12, Validate Message offers No Validation or Standard Validation against the structure defined in the XSD. For EDIFACT you switch validation on and choose Envelope or Envelope and Message. The Transaction Mode then decides what a failure costs:

In Message mode for EDIFACT you can also enable Process Invalid Messages. You then route split messages with a router after the splitter: the condition ${header.SAP_EDI_MESSAGE_STATUS} = 'failure' catches invalid messages and ${header.SAP_EDI_INTERCHANGE_STATUS} = 'failure' catches interchanges with errors, so they can go to an error-handling branch instead of disappearing.

Schemas

The splitter validates against XSD schemas you attach to the flow under EDI Schema Definition (Integration Flow), or names in a header at runtime (Header). File names must follow one of two conventions, and the content must match the name:

Functional acknowledgments

Create Acknowledgement has three options: Not Required, Check EDI Envelop (create one only if the envelope asks for it), and Required. For X12 the splitter creates a 997; for EDIFACT it creates a CONTRL message, and you can choose the CONTRL version and whether to include a UNA segment. You then route the acknowledgment with a router condition on the acknowledgment header documented for your standard, and send it back to the partner, usually over the same AS2 connection.

For X12 you also control the 997's envelope numbers. Interchange Number can be read from the incoming message or taken from a Number Range; with Unique Interchange Number set to Required, every acknowledgment gets a fresh number from the range. Group and transaction set numbers have similar options, including predefined values of 1 and 0001. If a unique number isn't required, SAP documents that a duplicate incoming message gets the same number for 30 days. Exclude AK3 and AK4 leaves out segment- and element-level error detail and keeps AK1, AK2, AK5 and AK9.

Two acknowledgment questions come up with almost every new X12 partner. Some partners, particularly in healthcare, expect the 999 implementation acknowledgment instead of the 997, and some also want a TA1 interchange acknowledgment that answers for the envelope alone. SAP's EDI Splitter documentation describes the 997 for X12, so if a partner insists on a 999 or TA1, confirm what your splitter version supports or produce it in your own mapping, and write the decision into the partner's specification. The second question is what the 997 proves: that the interchange was received and was, or wasn't, syntactically valid. It does not prove the order was accepted. A clean 997 followed by a missing 855 is a business problem, not an EDI one.