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

Lesson 4 of 5

Quality controls

10 min

Listen to this lesson

0:00 / 8:14

Integrations fail differently from transactions. A sales order screen either saves or shows an error to a user who can react. An interface can fail silently at 02:00, partially, or successfully with the wrong data, and the first person to notice is a customer. Quality controls for integration therefore span the whole lifecycle: design, build, test, cutover and operations. Sign-off covers all five, not just a passed test run.

  1. DesignContract and pattern reviewMessage or API contract, error handling, idempotency, monitoring attributes agreed
  2. BuildUnit and mapping testsMappings tested with representative and edge-case payloads; static checks for secrets
  3. TestContract, integration and end-to-endStubs for unavailable partners; real partners in CMQ; volume and failure tests
  4. CutoverSwitch and verifyQueues drained, endpoints switched, first messages verified, counts reconciled
  5. OperateMonitor and alertBusiness-context search, alerts to owners, reprocessing procedures
Quality controls across the integration lifecycle.
The Sign-Off Table · thesignofftable.com/academy/sap-int-401

Design-time controls

  • Contract first. The message or API contract (fields, formats, mandatory rules, error responses) is agreed and versioned before either side builds.
  • Idempotency. Every receiver can process the same message twice without creating two documents, for example by checking an external reference such as the customer's PO number.
  • Error handling pattern. Which errors retry automatically, which go to a business user, and where failed messages wait (an error queue or a monitoring tool) for reprocessing.
  • Monitoring attributes. Business keys (PO number, delivery number, material) travel with the message so it can be found later.
An idempotent receiver checks an external reference, so the same fleet order arriving twice still creates only one sales order.
The Sign-Off Table · thesignofftable.com/academy/sap-int-401

Test levels for integrations

LevelProvesContoso example
Mapping/unitEach field transforms correctly, including edge casesFleet order with 0 quantity, long text, missing ship-to
ContractBoth sides honor the agreed contractPayload validated against schema in the build pipeline
Integration (system)The flow works between real systems in the test landscapeOrder from partner test endpoint creates sales order in CMQ
End-to-end processThe business process works across systemsOrder to delivery to invoice to payment advice
Volume and resiliencePeak load, partner outage, duplicate delivery, out-of-order events3x daily peak; partner down 2 hours; same order sent twice
SecurityAuthentication, authorization, data exposureExpired certificate rejected; technical user cannot post finance documents

Integration test levels. Stubs or virtualized partners stand in when a real partner test system is unavailable.

Negative and resilience tests find the defects that matter most in production: what happens when Lakeside's system sends the same order confirmation twice, when the bank file arrives late, or when an event arrives before the master data it refers to. Write these cases from the error handling design, not from the happy path.

Operations: monitoring as a quality control

In production, monitoring is the quality control. SAP Cloud ALM provides Integration and Exception Monitoring: SAP describes end-to-end visibility into interface calls and message flows across cloud services and systems, message monitoring per component or scenario, message search by business context attributes such as an order number, and alerting on failed messages or exceptions with an alert inbox where processors are assigned. Statuses from different components are normalized into status groups (for example ERROR, WARNING, SUCCESSFUL), which makes cross-platform views possible.

Business process viewOrder-to-cash health: orders received vs created vs delivered
Scenario viewFleet order intake: messages by status group across components
Message viewSearch by PO number; payload and log of one message
AlertingERROR on scenario → alert to integration team; business errors → Maria's team
ReprocessingDocumented procedure per interface; who may reprocess and how duplicates are prevented
Layers of integration monitoring. Business users see processes; the integration team sees messages.
The Sign-Off Table · thesignofftable.com/academy/sap-int-401

Reconciliation

Monitoring shows failures; reconciliation shows silent losses. For important interfaces, compare counts and totals at both ends on a schedule: orders sent by the partner versus orders created, payment amounts in the bank file versus postings. A daily reconciliation report that shows "1,184 received, 1,184 created, 0 in error" is the strongest evidence an interface works.

A daily reconciliation compares counts at both ends; matching numbers with zero errors are the strongest proof the interface works.
The Sign-Off Table · thesignofftable.com/academy/sap-int-401

What would you do?

After mock conversion 2, all fleet order interface tests passed, but the alert rule for the scenario has never fired. What should Priya require before sign-off?

Key points
  • Integration quality spans design, build, test, cutover and operations.
  • Design for contracts, idempotency, error handling and business-key monitoring before building.
  • Test mapping, contract, integration, end-to-end, volume, resilience and security; write negative cases from the error design.
  • SAP Cloud ALM Integration and Exception Monitoring and scheduled reconciliation are the production quality controls.

Check your understanding · not graded

Lesson check

  1. 1. What does idempotent processing protect against?

  2. 2. Which Cloud ALM function lets you find a message by an order number?

  3. 3. What does reconciliation add beyond monitoring?

  4. 4. Where should negative integration test cases come from?