Message implementation guidelines: one partner's usage

A standard X12 850 can carry far more than any one partner sends. Great Lakes Fleet Services uses a handful of segments, two partner roles, two product ID qualifiers and one unit of measure. A message implementation guideline (MIG) records exactly that usage: which nodes are selected, how often they occur, which code values are allowed, what each field means, and examples. SAP Help puts it simply: the MIG contains all the information for implementing a customized message interface.

Creating the MIG

Go to Design > MIGs and choose Create. The wizard walks through Type System (ASC X12), Messages (850), Versions (004010, the version Great Lakes' spec names), Envelopes, an optional Sample Payload step, Node Selection and MIG Creation. In the last step you give it a name, a summary, a direction and at least one business context value.

The Sample Payload step saves the most time. Upload real files and Integration Advisor auto-selects every element present in them. Supported formats include SAP Cloud Integration XML, SAP Process Integration XML and, for ASC X12, UN/EDIFACT and its subsets, Odette, Tradacoms and VDA, the raw EDI flat file. A ZIP can hold up to 25 payloads and 10 MB. Theo's team pulls 20 recent Great Lakes 850s from the XP1 message archive and uploads them as one ZIP. In Node Selection, nodes whose qualifier values appear in the payloads can be qualified automatically.

Direction is easy to get wrong. It describes the message from a B2B point of view: In means the partner is the logical sender, Out means you send it, Both covers either, or A2A. SAP Help's own example: when an inbound EDIFACT message is mapped to an IDoc for the back end, both the EDIFACT MIG and the IDoc MIG are classified In. So Contoso's 850 MIG and its ORDERS05 target MIG are both In; the INVOIC02 source MIG and the 810 target MIG are both Out. Direction and business context sharpen the proposal service.

Qualifiers: giving generic segments a meaning

X12 reuses generic segments. The N1 loop is just "a party"; only N101, the entity identifier code, says whether it is the buyer (BY) or the ship-to (ST). In a MIG, a qualifying leaf node with a codelist can qualify its parent group or a peer. A gray qualifier marker shows that qualification is possible; a blue arrow with the code value shows a qualified instance. Each instance gets its own properties, documentation and mapping later.

Codelists and node properties

Integration Advisor knows four codelist kinds: type-system codelists that come with the standard, reusable codelists such as ISO country and currency codes or UN/ECE units, MIG codelists you define inside one MIG, and local codelists tied to one element. In the node's Codelist tab you deselect every value the partner doesn't use. Restricting PO103 to EA means a file with CA (case) fails validation instead of creating a sales order with the wrong quantity unit.

Select a node's checkbox to edit it. The Details pane holds cardinality, a fixed value, example values, documentation, and for leaf nodes the primitive type, length, date-time format and XSD patterns; group nodes can carry XSD assertions (boolean XPath). Patterns and assertions go into the generated XSD and tighten runtime validation. The Notes tab takes notes in the categories Comment, Constraint, Example, Usage and Technical Information, and the Status tab records a review status per node for multi-user review.

Simulate before you map

On the Structure tab, Simulate offers Simulate with MIG Example Data or Simulate with Payload Data (XML or EDI flat file). With example data, Integration Advisor generates a payload: repeating nodes appear twice, and each leaf takes its example value, else its fixed value, else its selected code values, else a generated dummy. With a real payload, nodes the MIG doesn't define are reported in a dialog, which is how the team found that Great Lakes sometimes sends a PER contact segment their written spec never mentioned.