Simulating and testing MAGs: the outbound 810

A MAG is code, even when it is drawn. It needs tests with known inputs and expected outputs, and Integration Advisor lets you run them where you design. This lesson uses Contoso's outbound invoice to Great Lakes: INVOIC02 from S/4HANA CMP mapped to an X12 810 (version 004010), using invoice 90001877 for sales order 1000457, 50 × CMC-ALT-100 at 240.00 = 12,000.00 USD, tax-exempt.

Two ways to simulate

Open the MAG, expand the nodes on the Mapping tab and choose Simulate. Simulate with MIG Example Data runs the mapping on a payload generated from the source MIG's example values. Simulate with Payload Data asks for a real Source Payload (XML, or EDI flat file for EDI type systems) and, optionally, an Expected Target Payload. A Simulation Data column then shows source values and transformed target values side by side; errors open a dialog that links straight to the failing node.

The expected target payload turns a demo into a test. Integration Advisor compares the simulated and expected values, shows an Expected Data column, counts the differences, and lets you step through them with Previous Difference and Next Difference. Group nodes are compared by instance count and leaf nodes by value.

Where do expected payloads come from? While Process Orchestration still runs the interface, it's the best oracle: the 810 that XP1 produced for the same INVOIC02, minus envelope control numbers. After the move, expected payloads come from the partner's spec examples and from approved earlier runs. This is the same equivalence idea as Contoso's PO migration replays, applied inside the design tool.

The first run for 90001877 showed one difference: TDS01 came out as 12000.00 instead of 1200000. X12's TDS amount has two implied decimal places, so the mapping needed a function that removes the decimal point after scaling. A second difference appeared in a two-line test invoice: the CTT count was 1 because it was mapped from the header. Both were mapping defects that a field-by-field eyeball check would likely have missed.

Keep the test set with the guideline, not in someone's downloads folder. Contoso stores each case as a pair, source payload and expected target, in the SAP Cloud ALM test case for the MAG, named after the partner and message (for example GLFS-810-02 two lines). Every new draft version of the MAG is rerun against the full set before activation, so a change for one depot can't quietly break another. Testers with the iadv-content-read role can run simulations without being able to edit the guideline they are testing, which keeps the roles clean.

Getting the output out

After a run, Download simulation result saves the target payload. The default is XML in Cloud Integration format without Integration Advisor's qualifier suffixes; for EDI targets such as ASC X12 you can choose Download as EDI Flat File. Priya's team attaches that file, the input and the difference count to the test case in SAP Cloud ALM. Clear Simulation removes the data when you are done.

Building a test set that lasts

• Happy path: one-line and multi-line orders and invoices, such as 90001877 and a three-line invoice.
• Qualifier coverage: every N1 role and product ID qualifier the MIG allows.
• Code values: one case per entry in each code value mapping, so a missing entry fails a test, not production.
• Boundaries: maximum line count, longest text fields, zero-price or free-of-charge items if the spec allows them.
• Negative: unit CA instead of EA, missing BEG03, unknown depot code; these belong to MIG validation and the runtime, so record where each is expected to fail.