4. SAP Backend Validation Approach 3 - E2E Interface validation

How to Validate the IDoc Output and Handle Expected Differences

Hands-on tutorial - Part 4 of 5: SAP Backend Validation Series

This guide shows you the third validation approach: end-to-end interface validation. You will configure the Automation Object to capture and compare the IDoc generated by SAP PO middleware, then learn how to handle expected differences (dates, timestamps, system-generated numbers) using the payload validation ignore list.

Overview

In the previous guides you learned how to:

• Part 1: Simulate an external system sending a Purchase Order

• Part 2: Make each simulated message uniquely identifiable

• Part 3: Validate the Sales Order created in the SAP backend using database rules

This guide adds middleware output validation. After the simulation, Int4 Suite will capture the IDoc produced by SAP PO and compare it field-by-field against the reference IDoc stored with the test case.

Because some fields are expected to differ between runs (Purchase Order number, creation date, creation time, SAP PO message ID), you will also learn how to manage these differences using the payload validation ignore list.

At the end of this guide you will have:

• Middleware output validation enabled on the Automation Object

• A new test case that contains both input and output payloads

• A clean, repeatable comparison in which only meaningful differences are flagged

Step-by-step instructions

1. Enable validation of the middleware output message

The earlier setup already simulated the external system message and validated the reference Sales Order against the QA Sales Order. The next goal is to validate the IDoc generated by SAP PO middleware as part of the processing.

1. Open the existing Automation Object and switch it to edit mode.

2. In the test case validation section, select Validate message output.

3. If you are using the standard SAP PO message version, you do not need to fill in a message version after processing.

4. Only specify a post-processing message version if you are using a different caption - for example one coming from an adapter module like EDI.

2. Create a new test case so output messages are captured

Existing test cases only contain the input payload - they cannot validate the newly added output message. Create a new test case so both input and output are downloaded together:

1. Create a new test case using the same Automation Object.

2. Choose the same test type: PI GUID E2Einbound.

3. Select the Production PO environment and the relevant document number.

4. Generate the test case with the desired number of messages (for example, 10).

5. Save the test case so the system collects both:

   • The input message

   • The output message / IDoc generated by middleware

💡 Why a new test case? Existing test cases were created with only the input payload because validation of the output was not yet enabled. Re-running them would not capture the IDoc. Always re-generate test cases after enabling output validation.

3. Run the test case in QA and compare production vs. generated IDoc

1. Execute the newly created test case in the QA environment.

2. After the run completes, open the test case details.

3. Review the payload comparison:

   • Left side: the production IDoc saved with the test case

   • Right side: the IDoc generated during the QA execution
     
     

     

4. Expect to see differences in fields that change every time the message is injected - for example, the dynamic PO value from your variable.

These differences are normal and will be handled in the next step.

4. Add expected differences to the payload validation ignore list

To finalize the scenario, mark fields that are expected to differ as exceptions:

1. Re-run the test case in debug mode with detailed logging enabled.
   

   

2. When the test fails on an expected difference, use the new option next to the failed field to create an exception.
   

   

3. Add a short explanation for why the difference is acceptable (for audit purposes).

4. Save the exception.

5. Repeat for other expected differences, typically:

   • Creation date

   • Creation time

   • SAP PO message ID inside the IDoc

   • Any other system-generated, run-specific field

⚠️ Best practice: Always add a meaningful description for each exception. Months later, anyone reviewing the test case should understand why a field is being ignored without having to ask.

5. Revalidate to confirm the ignored fields no longer fail the test

1. After adding the exceptions, run the test case again.

2. Use Revalidate to recheck the comparison results.

3. Fields added to the payload validation ignore list should no longer cause failures.

4. Repeat the process for any remaining fields that are expected to vary between runs.

When done, only meaningful regressions will fail the test - exactly what you want for continuous regression testing.

Troubleshooting

Together, these guides cover the full Int4 Suite simulation-plus-validation pattern: from importing real production messages, through making them safe to replay, to validating both the backend document and the middleware output.

What's next

• Part 5: Create database validation rulesets from scratch

Video reference

🎥 Full walkthrough on Loom: https://loom.com/share/3d55b8b7fd9b41e88454531266e38398