Lesson 5 of 6
Moving and maintaining EDI configuration
8 min
Listen to this lesson
EDI configuration is a mix of objects that travel differently. Get this wrong and the classic go-live surprise follows: everything worked in CMQ, and on Monday morning nothing goes out from CMP because the partner profiles were never created there, or worse, CMP still points at the test middleware.
| Object | Where it lives | How it reaches CMP | Differs by system? |
|---|---|---|---|
| Message types, basic types, process codes | Repository and cross-client settings | Normal transports from CMD | No |
| Output types, condition tables (NACE) | Customizing | Customizing transports | No |
| Condition records for EDI output | Master data | Created per system or loaded | No, but must exist |
| Logical systems (BD54) | Client-independent table | Created per system | Yes: CMQCLNT100 vs CMPCLNT100 |
| RFC destinations (SM59) | Client-independent | Created per system by Basis | Yes: XQ1 vs XP1 |
| Ports (WE21) | Client-independent | Created per system | Yes: XQ1_PO vs XP1_PO |
| Partner profiles (WE20) | Per client, tables EDPP1, EDP12, EDP13, EDP21 | Recreated per system from a signed spec, or moved deliberately | Only the port should differ |
How each EDI object moves through Contoso's landscape.
Why partner profiles need special care
Partner profiles are stored in four tables: EDPP1 (general profile), EDP13 (outbound parameters), EDP12 (message control) and EDP21 (inbound parameters). They behave like master data, not like Customizing that rides along with every transport. Teams handle them in one of three ways: recreate them by hand in each system from a signed specification; move them deliberately with a transport where the release and team practice support it; or distribute them with SAP's own tools (WE20 can send partner profiles as IDoc type SYPART01 to another system that has the matching profile). SAP also offers default outbound and inbound profiles (WE24, WE27) for fast entry. Whatever the method, the port inside the profile is different per system, so a blind copy from CMQ to CMP would point production at XQ1.
System copies and refreshes
When CMQ is refreshed from production for a test cycle, the copy brings production's partner profiles, ports and logical system names with it. Sam's post-copy steps convert the logical system names with BDLS, restore CMQ's own RFC destinations and ports, and reapply CMQ's partner profiles so that test IDocs go to XQ1 and Great Lakes' test system, never to production partners. A good post-copy checklist ends with a deliberate test message each way to prove the routing.
- Before the copySave CMQ settingsExport CMQ's partner profiles, ports and destinations; note the logical system name
- CopyProduction data arrivesCMQ now contains CMP's profiles and identity
- Immediately afterLock the doorsStop outbound jobs and set risky partner rows inactive before anything runs
- Re-identifyBDLS and restoreConvert logical systems, restore destinations, ports and CMQ partner profiles
- ProveTest message each waySend a test ORDRSP to XQ1 and receive a test ORDERS from it
Naming and change control
- Ports and destinations named after the target system (XP1_PO, XP1_IDOC_AAE) so a wrong system is visible at a glance.
- One spec per partner, versioned, listing every inbound and outbound row with its values, signed by the integration lead and the business owner.
- Every production change through a ticket, even though partner profiles are maintained directly: who changed which row, when, why and with what evidence. Luis, as release manager after go-live, treats WE20 changes in CMP as planned changes in the release calendar.
- Inactive, not deleted: when a partner relationship ends, set the profile status to inactive first, and delete only after the partner confirms nothing is in flight.
Configuration also drifts quietly after go-live. A consultant adds a row in CMP to fix an urgent problem and forgets CMQ; a test client gets a new port that nobody documents. Contoso runs a quarterly comparison of partner profiles between CMQ and CMP, using the same export it used for the go-live review, and treats every unexplained difference as a ticket. The comparison takes an hour and has twice found production rows that were never tested.
What would you do?
After Mock 2, a tester reports that CMQ sent a test 855 to Great Lakes' production EDI address. CMQ had been refreshed from production the week before. What is the most likely cause and fix?
- Repository objects and Customizing travel by transport; logical systems, destinations and ports are created per system.
- Partner profiles (EDPP1, EDP12, EDP13, EDP21) behave like master data; build them from a signed spec in each system.
- After a refresh from production, re-identify the copy (BDLS, destinations, ports, profiles) before any output runs.
- Name ports and destinations after their target system and control production WE20 changes like any release.
Check your understanding · not graded
Lesson check
1. Which tables hold partner profile data?
2. Why must a partner profile not be copied blindly from CMQ to CMP?
3. Which IDoc type can WE20 use to send partner profiles to another system?