Lesson 6 of 7
Connected systems in shared test environments
9 min
Listen to this lesson
An SAP process rarely ends in SAP. Contoso's order to cash sends order confirmations and invoices to customers, transmits delivery data to carriers, and receives payments through the bank; procure to pay exchanges purchase orders with suppliers; and side-by-side extensions on SAP BTP read and write S/4HANA data. A test environment is only as end-to-end as its connections. This lesson covers how to plan connected systems so integration tests can run, and so a test system never talks to a real partner by accident.
Map every connection per environment
| Connection | CMQ client 100 | CMR client 100 | Rule |
|---|---|---|---|
| SAP BTP extensions | cmc-ext-test | cmc-ext-preprod | Paired subaccount only; destinations checked after every refresh |
| Interfaces on Process Orchestration | XQ1 | XQ1 (shared, scheduled windows) | Until each interface moves to SAP Integration Suite |
| Bank (payments, statements) | Bank test endpoint | Stub returning canned files | Never a production bank channel |
| Carriers | Stub | Carrier test endpoint, booked | Book the carrier's test window in advance |
| Customer and supplier EDI | Stub | Stub | Real partners never receive test messages |
| Email and print output | Test mailbox | Test mailbox | SAPconnect redirects all mail to the test mailbox |
Contoso's connection map for two test environments. Every external connection has a rule that prevents real partners from receiving test traffic.
Note that CMR shares the Process Orchestration test system XQ1 with CMQ until the interfaces move to SAP Integration Suite after hypercare. Shared middleware is a common source of confusion: a message from CMQ can land in CMR's inbound queue if the routing is not environment-specific. Theo's team keeps routing by sender system and client, and the readiness check sends one test message per critical interface after every refresh.
Stubs, test endpoints and virtual services
There are three ways to give a test a partner. A partner test endpoint is the partner's own test system; it is the most realistic, but it has its own calendar, data and outages. A stub accepts messages and returns fixed responses, such as a bank acknowledgment or a payment status file; it is always available and gives the same answer every time, which is ideal for regression. A virtual service is a smarter stub that returns responses based on the request, such as a carrier rate that depends on weight. Use stubs for regression and automation, and partner test endpoints for the few end-to-end tests each release that must prove the real handshake.
Keep connected data in step
Refreshing S/4HANA alone can break integration tests, because connected systems keep their own data. After CMR is refreshed from CMP, the extension data in cmc-ext-preprod still reflects the previous copy, and documents referenced across systems may not exist on both sides. Contoso's custom core return agreements are a good example: they live in a custom table in S/4HANA and are maintained through an app on SAP BTP, so a refresh of one side without the other leaves the app showing agreements that the system no longer has. Decide per connection whether the partner system is refreshed at the same time, reset to a baseline, or tolerant of mismatches, and write that into the refresh runbook.
What would you do?
After a CMR refresh, the carrier's test endpoint is down for two days, and the release regression is due to start. What should Priya do?
- Map every connection per environment: BTP subaccounts, middleware, banks, carriers, EDI partners and output.
- No outbound path from a test system may reach a real partner; use stubs, partner test endpoints or test mailboxes.
- Use stubs for regression and automation, partner test endpoints for a small set of real handshakes.
- Decide per connection how partner data stays in step with S/4HANA refreshes, and prove critical interfaces in the readiness check.
Check your understanding · not graded
Lesson check
1. Why is a stub usually preferred over a partner test endpoint for nightly regression?
2. What must happen before background jobs run in a freshly copied system?
3. Why can refreshing CMR alone break a BTP extension test?
4. CMQ and CMR share the Process Orchestration test system XQ1. What prevents a CMQ message from landing in CMR's inbound queue?