Testing with WE19

A fix is not finished until it is proven. For IDoc interfaces the proving ground is WE19, the IDoc test tool. It lets you build a test IDoc, usually by copying an existing one, change what you need, and run it through processing in a test system without the partner and without middleware. Used well, it turns "I think the customizing fix works" into evidence.

What WE19 does

• Create a test IDoc from an existing IDoc number (the usual route), from a basic type and extension (an empty structure you fill), or from a file.
• Change the control record: sender and receiver partner, partner type, port and direction, so the test IDoc matches the partner profile you want to test.
• Change data records: open a segment and overwrite field values, for example a different PO number, quantity or tax rate.
• Process inbound with Standard Inbound, which uses the partner profile and process code exactly as production would, or with Inbound function module, which calls a function module you name directly, optionally in debug mode.
• Process outbound with standard outbound processing to test the port and the partner profile for a test IDoc.

Every IDoc WE19 creates is a new IDoc with its own number; the copy source is not touched. Inbound test IDocs are marked as created by the test transaction (status 74, or 42 for outbound) before processing continues, so they are easy to separate from real traffic in reports.

Standard inbound or function module?

Use Standard Inbound for anything you want to sign off, because it exercises the partner profile, process code and processing mode. Use Inbound function module for developer debugging, for example to step through a customer exit that reads a custom segment. A test that only ran the function module directly has skipped the partner profile check, so it cannot prove a status 56 fix.

A worked example

The status 51 ORDRSP for PO 4500002210 from Lesson 2 was fixed by adding confirmation control key 0001 to the PO item. Priya wants evidence that the same fix works for every Lakeside PO created from the purchasing info record, which the buyers corrected too. In CMQ she creates PO 4500003105 for 500 rotors CMC-RTR-200 from the corrected info record, copies a real Lakeside ORDRSP IDoc in WE19, replaces the PO number in E1EDK02 (qualifier 001) and E1EDP02, and runs Standard Inbound. The test IDoc posts with 53, the PO item shows the confirmation with creation indicator for EDI, and the confirmed date matches the 855.

1. Test IDoc number, copy source IDoc number and system/client (CMQ 100).
2. The fields changed in WE19 and why.
3. Processing route (Standard Inbound) and resulting status sequence.
4. The business result: PO 4500003105 item 10 confirmation overview, with confirmed quantity and date.
5. A negative test: the same IDoc against a PO item without a confirmation control key returns 51 with the expected message.

WE19 has limits worth stating in a test plan. It tests the SAP side only: not the Process Orchestration mapping, not the AS2 or VAN connection, not the partner's translator. A complete regression for an interface still needs at least one end-to-end run from the partner's test system through XQ1 into CMQ, and Lesson 6 covers how to monitor that run.