Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Testing IDoc interfaces

10 min

Listen to this lesson

0:00 / 8:14

An IDoc test has two halves. The technical half proves the IDoc moves: it is created, routed, received and processed. The business half proves the result is right: the sales order has the right customer, material, quantity, price and dates. Most weak IDoc testing stops at the technical half. Sign-off needs both.

Test levels for an IDoc interface

Unit test of the mappingIntegration team checks that each source field maps to the right segment and qualifier
Technical connectivityIDoc moves end to end between the systems with real ports and partner profiles
Functional postingInbound IDocs post the right documents; outbound IDocs carry the right values
End-to-end business flowThe interface runs inside the full process, such as order to cash with Great Lakes
Volume and timingPeak volumes and batch jobs, such as 2,000 orders on the last day of the month
IDoc testing builds from the mapping up to the whole business flow.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

Creating test IDocs with the test tool

SAP's IDoc test tool, WE19, creates an IDoc by hand and sends it into inbound or outbound processing. You can start from an empty IDoc type or, more usefully, copy an existing IDoc as a template and change values. For inbound testing you can choose standard inbound processing, which checks the partner profile like a real IDoc, or call the inbound function module directly, which is useful for developers testing a new function. For outbound tests, SAP's documentation notes that the test IDoc is passed to the port regardless of the partner profile.

WE19 offers two inbound routes: standard inbound processing tests the partner profile too, while calling the function module directly skips it.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

Every change in the test tool creates a new IDoc number. That is fine in a test system and wrong in production, where it creates documents with no partner origin. Keep WE19 out of production roles.

MethodGood forLimits
Real message from the partner or middlewareEnd-to-end proof, including mapping and connectivityNeeds partner availability and coordinated test data
WE19 copy of a real IDocFast variants: other materials, quantities, negative casesSkips the middleware mapping; proves only the SAP side
WE19 standard inboundChecks partner profile and posting logic togetherNeeds a correct partner profile in the test system
WE19 direct function callDeveloper testing of new inbound logicSkips profile checks; not evidence for sign-off
Ways to create test IDocs and what each one proves.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

Designing the test cases

Design IDoc test cases the way you design any functional test: from the business rules. For Contoso's inbound orders, Priya's set includes:

  • Happy path: a standard Great Lakes order for CMC-ALT-100 posts as a sales order in sales area 1710/10/00 with the right prices and ship-to.
  • Variants: multiple items, a different ship-to, a requested delivery date in the past, a free-text note.
  • Negative cases: unknown material, customer blocked for sales, missing mandatory segment. Each must end in 51 with a clear message, and no document.
  • Duplicates: the same customer PO number sent twice. Check how the system or the process detects it.
  • Reprocessing: fix the cause of a 51 and confirm reprocessing posts exactly one order.
  • Outbound reply: the order confirmation goes back to Great Lakes with the confirmed date and quantity.
  • Volume: the expected month-end peak in one hour, with the inbound job schedule used in production.
Priya's happy-path evidence follows the message through every system and ends with the business document, not with the IDoc status.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201
  1. Cycle 1SAP side onlyWE19 copies of real ECC IDocs posted in CMQ; partner profiles and posting logic proven
  2. Cycle 2With middlewareReal messages from the platform with test partner data; mapping defects found and fixed
  3. Cycle 3With partnersGreat Lakes and Lakeside send and receive test messages; end-to-end order to cash
  4. Dress rehearsalProduction-likePartner profiles created from the cutover list; one live-like message per interface
Contoso's IDoc testing grows from the SAP side to the full partner chain over the cycles.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

What would you do?

Kenji's team changed the inbound order function for a new Contoso field. The developer tested it with WE19, calling the function module directly, and asks Priya to mark the interface as passed. What should Priya do?

Key points
  • Test both halves: the IDoc moves (technical) and the business result is right (functional).
  • WE19 creates test IDocs from templates; standard inbound processing checks the partner profile too.
  • Include negative, duplicate, reprocessing and volume cases, not only the happy path.
  • Sign-off evidence needs the posted document checked against the source and a run through the real chain.

Check your understanding · not graded

Lesson check

  1. 1. What does the WE19 option "standard inbound" check that a direct function module call skips?

  2. 2. Why is a test IDoc created with WE19 not end-to-end evidence?

  3. 3. A negative test sends an order for an unknown material. What result passes the test?

  4. 4. Which test proves reprocessing works?