Lesson 5 of 6
Extensions and integrations
9 min
Listen to this lesson
Standard processes are where SAP helps most. Extensions and integrations are where upgrade regressions most often hide, because only you know they exist and what they are supposed to do. Public Edition's extensibility model is designed to be upgrade-stable, since extensions are built on released interfaces, but "designed to be stable" is a reason to test efficiently, not a reason to skip testing.
Build an inventory first
You cannot prioritize what you cannot list. Keep an inventory of every extension and interface with an owner, the processes it touches and the test that covers it. For the Contoso what-if, Kenji's team would maintain it: custom fields on sales orders and journal entries, a custom approval rule for supplier invoices, a custom analytical query for Dan, two developer extensions, and interfaces to a logistics provider, a bank and a tax service.
| Extension or interface | Typical upgrade risk | Test focus |
|---|---|---|
| Custom fields (key user) | Field placement, mandatory logic, field flow to follow-on documents | Create, change and display through the full document flow |
| Custom logic (key user) | Behavior after changes in the standard process around it | Positive and negative cases of each rule |
| Custom analytical queries and reports | Changed data sources or new fields | Reconcile totals against a known baseline |
| Developer extensions | Released APIs used, behavior of called objects | Developer tests plus business-level tests |
| Inbound and outbound interfaces | Payload changes, communication arrangements, certificates, partner behavior | End-to-end message tests with the partner system |
Prioritize by risk
- Touches money, stock or compliance: test every release, with business acceptance.
- Area changed by the release: raise priority when RASD or the What's New Viewer shows changes in the apps or processes the extension sits on.
- No automated test yet: plan manual coverage now and automation for the next release.
- Stable, low impact, automated: run the automate and review the result.
- Does the extension or interface touch money, stock or compliance?Yes → must test this release · No → next question
- Did the release change the process or app it sits on?Yes → must test · No → next question
- Is there a reliable automated test?Yes → run it and review · No → one manual pass, add to automation backlog
Testing integrations in the window
Integration tests need the other side. Agree in advance with each partner team that their test system is connected to your upgraded test system during the window, and who will send and check messages. Test both directions: an outbound advance shipping notice to the logistics provider and the inbound confirmation; payment files to the bank test environment and bank statement import back. Check communication arrangements, users and certificates as well as message content. Integration steps in automates run with communication users, so keep those current too.
Developer extensions deserve two layers of evidence. Kenji's developers keep their own automated developer tests (for example ABAP Unit tests for custom logic) and rerun them in the upgraded test system, because a released API can gain fields or change behavior within its contract. Then the business-level test proves the extension still does its job in the process. A green developer test with no business test tells you the code runs; it does not tell Dan that the posting is right.
What would you do?
In the what-if, the What's New Viewer shows changes to the sales order app for the coming release. Contoso has a custom field on sales orders that must flow to the billing document for Great Lakes Fleet Services. No automate covers it. What should Priya plan?
- Keep an inventory of extensions and interfaces with owners and the tests that cover them.
- Prioritize by business impact, by whether the release changed the area, and by existing automated coverage.
- Integration tests need partner systems and people booked for the window; test both directions.
- Freeze extension changes around the upgrade; importing key user extensions across a release may not be possible.
Check your understanding · not graded
Lesson check
1. Which extension should rank highest for testing in this release?
2. What does an integration test in the window need that a single-system test does not?
3. Why freeze key user extension transports around an upgrade?