Interfaces and performance at merged volume

A consolidation rewires the edges of the system. Partners send to new addresses, banks receive new files, tax authorities receive documents from a new sender, and old connections must stop at the right moment. At the same time, every batch job now processes more data. Both kinds of failure show up after go-live, when customers and suppliers are involved, which is why they need their own tests in every mock rather than a line in the cutover plan.

The interface rewiring inventory

Interface	Before (legacy)	After Wave 2	Tests
CFDI electronic invoices for 1910	Legacy ERP to its authorized certification provider (PAC)	SAP S/4HANA eDocument processing for Mexico, through SAP Integration Suite to the PAC	Connectivity, stamping, cancellation, rejection, volume
Bank payments and statements, MXN	Legacy bank files	Payment medium formats and bank statement import for 1910	File format with the bank, rejection handling, statement matching
Orders between Contoso and Alternadores	Contoso purchase orders sent to Alternadores as a supplier	Intercompany in one system; the old order channel retired	Switch-off test: no order may still go out the old way
Alternadores' customer EDI	Legacy partner IDs and maps	New partner profiles and maps built in Cloud Integration	Partner-by-partner tests with each customer
Legacy ERP outbound feeds	Reports to the seller's group	Retired at go-live; history read-only	Confirm no consumer still expects the feed

An extract from the Wave 2 interface rewiring inventory (illustrative course data); check the Mexico eDocument scope for your release.

Three kinds of change hide in that table. Endpoint changes: new URLs, logical systems, RFC destinations (SM59) and partner profiles (WE20). Identity changes: a new legal name, tax ID or partner ID that the other side validates. Retirements: connections that must stop, such as the order channel that sent Contoso's purchase orders to Alternadores as a supplier. If that channel survives go-live, the same demand can arrive both as an intercompany order and as an EDI order. Contoso builds the new Mexican interfaces in Cloud Integration from the start, so Theo's team tests them in CMC_TEST against CMQ before each mock.

The CFDI round trip for company code 1910: a test must cover both the stamp and the rejection path.

The Sign-Off Table · thesignofftable.com/academy/sap-dmg-305

Before and after Wave 2: the supplier order channel disappears into intercompany, and new interfaces run through Cloud Integration.

The Sign-Off Table · thesignofftable.com/academy/sap-dmg-305

Test types for each rewired interface

Connectivity: the endpoint answers, certificates and credentials work, from the system the interface will run in.
Functional: a real business document goes through and the partner accepts it, with the new identity data.
Negative: a deliberately wrong document is rejected, and the rejection reaches the team that must act.
Switch-off: the retired channel no longer sends or receives.
Volume: a day's peak volume passes inside its window.
Cutover: the switch from old to new endpoint is rehearsed in the W2 dress rehearsal with timings.

API checks are the fastest way to cover connectivity, identity and negative tests on every mock, because they need no screen. In ACCELQ, the worked example for the automation layer, an Action can carry a REST call (+ API > Insert REST call) with the endpoint as a parameter, verify the status code and response fields, and extract values for later steps. ACCELQ's documentation describes REST and SOAP but does not mention OData by name, so treat OData services as REST with JSON responses.

Hands-on lab · ACCELQ

Check a rewired endpoint with a data-driven API test

Practice the endpoint-change test: the same request runs against an old and a new endpoint, each response is verified, and a negative row proves the check catches a missing record. TripPin is a public OData V4 reference service, not SAP, but it uses the same protocol as SAP's OData APIs.

Practice on TripPin OData V4 reference service (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first. Open https://services.odata.org/V4/TripPinServiceRW/People in a browser: it redirects to an address with a session segment. Copy that redirected address; it is your new endpoint. The read-only https://services.odata.org/V4/TripPinService/People is your old endpoint.
Create a Library Action Check People endpoint with an Action Parameter endpoint.
Click + API and choose Insert REST call. Set the method to GET and the Endpoint URL to the endpoint parameter. Click SEND REQUEST with the old address as a test value.
In the response, click the status to add a verification for 200, and click the first person's UserName value to add a response verification. Save the call.
Build a Scenario with the Action. In Test Cases, add a row old with the old endpoint and a row new with the new one.
Add a negative row: the new endpoint with ('no-such-user') appended after People. This service answers a missing record with status 204, so give this row its own expected status of 204 (add an expected-status parameter if needed).
Run the Scenario. Both endpoints must return the same first UserName, and the negative row must return 204, not 200.

Done when Old and new endpoints pass with identical verified values, and the negative row passes on 204. Keep the Test Report as the template for the Wave 2 interface pack: one row per endpoint, one negative row per interface.

Learn more in ACCELQ’s docs: REST API Test Automation in ACCELQ · Verifying API Responses in ACCELQ

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Performance at merged volume

Adding a company code adds load to jobs that were sized for the old business. Asda's chair named a lack of capacity planning among the causes of its separation problems. For Wave 2, Sam and Priya list every job whose volume grows with 1910 and measure it in CMQ after W2 Mock 2, when 1910 is loaded at full volume: MRP for plants 1710, 1720 and 1910 (MRP Live, MD01N), the billing run that now includes CFDI requests, the payment run (F110) with MXN payments, intercompany billing, and the period-end close chain. The test compares run times and system load against the batch window, not against last month's run time.

W2 Mock 1Inventory jobs and volumesList every job and interface whose volume grows with 1910
W2 Mock 2Measure at full 1910 volumeMRP, billing with CFDI, payment run, intercompany billing, close chain
Before W2 Mock 3Tune and retestJob splitting, parallelization, scheduling changes, transported and retested
W2 dress rehearsalConfirm in the real sequenceFirst day's jobs run in the cutover timeline with production-like timings

Volume testing for Wave 2 follows the mocks: inventory, measure, tune, confirm.

The Sign-Off Table · thesignofftable.com/academy/sap-dmg-305

Job	Window	Measured before 1910	Measured with 1910	Verdict
MRP Live, plants 1710, 1720, 1910	Nightly, 02:00–04:00	48 min	71 min	Inside the window
Billing run with CFDI requests	Hourly	6 min	19 min	Investigate PAC response times
Payment run, all company codes	Daily, 14:00–15:00	22 min	31 min	Inside the window

Illustrative volume test results after W2 Mock 2; the numbers are course data, not benchmarks.

What would you do?

In W2 Mock 2 every new interface passes. During the dress rehearsal review, Theo finds that the old EDI channel that sent Contoso's purchase orders to Alternadores is still active in the production plan. What should happen?

Key points

Inventory every interface by endpoint change, identity change and retirement.
Test connectivity, function, rejection, switch-off, volume and the cutover switch, after every mock.
API checks with endpoint parameters cover rewired interfaces quickly; treat OData as REST with JSON.
Measure jobs at full merged volume against their windows, starting with W2 Mock 2.

The interface rewiring inventory

Test types for each rewired interface

Performance at merged volume

Lesson check