Lesson 5 of 6
Partner variations
7 min
Listen to this lesson
Every EDI partner is slightly different: another X12 version, an extra reference segment, a different qualifier for the ship-to, its own unit codes. The tempting answer is a copy of the mapping per partner. Twelve customers later, a fix has to be made twelve times and retested twelve times, and the copies have drifted so far that nobody knows which differences are intended. Contoso's rule for the migration is one mapping per message type and direction, with partner differences held as data.
Where partner differences go
| Difference | Where it lives | Contoso example |
|---|---|---|
| Partner-specific settings | Partner Directory string parameters | X12 version, ISA qualifier and ID, SFTP directory |
| Partner-specific schemas or XSLT | Partner Directory binary parameters | An XSD for a partner's 850 variant |
| External partner IDs | Partner Directory alternative partners | ISA06 sender ID → partner GLFS |
| Partner-specific code lists | Value mapping with the partner as agency | GLFS / LOCATION: DET ↔ 1710 |
| Genuinely different structure | A separate mapping chosen dynamically | A partner whose 810 needs a different layout |
Partner differences held as data, from simplest to most structural.
The Partner Directory
The Partner Directory is tenant-specific storage for partner information. SAP's point is that flows read partner-specific parameters at runtime, so you can add a partner without editing or redeploying any flow. It holds string parameters, binary parameters (such as XSLT mappings and XSD files), alternative partners and authorized users. You maintain it in the Monitor or through the OData API, and SAP lists overall limits, for example 3,000,000 string parameters across all partners.
A flow needs a partner ID first. Inbound, Contoso resolves it from the EDI sender ID with alternative partners: getPartnerId(agency, scheme, alternativePartnerId) on PartnerDirectoryService, obtained in a script with ITApiFactory.getApi(PartnerDirectoryService.class, null). Outbound, it uses the IDoc's RCVPRT and RCVPRN the same way. With the partner ID in a property, the flow reads that partner's parameters.
Choosing a mapping per partner, when you must
Sometimes a partner's structure really is different. Then don't copy the flow; select the mapping. A Message Mapping step with Reference Type Dynamic can read its mapping from the Partner Directory with the expression format pd:<Partner ID>:<Parameter ID>, where the parameter's value is ref:<message mapping ID> of a deployed Message Mapping artifact (sap-pim-201, lesson 1). The flow stays the same; one partner entry points to a different, deployed mapping artifact.
SAP's model-based option
SAP Integration Suite also offers Trading Partner Management with Integration Advisor, where partner agreements, message implementation guidelines (MIGs) and mapping guidelines (MAGs) are modeled and runtime artifacts are generated. It is designed for exactly this partner-variation problem at scale. sap-pim-206 covers it. Contoso's migration keeps hand-built mappings with Partner Directory parameters for most partners and moves Great Lakes into TPM with Integration Advisor guidelines. Lakeside, a single SFTP partner, stays outside TPM: in integration wave 1 (December 2026 to January 2027) its 850 flow is rebuilt on SAP's EDI integration templates with a mapping guideline (MAG) from Integration Advisor (sap-pim-206). The Lakeside mapping in this course is the hand-built version of that flow, used to teach the mechanics.
Contoso's partner entries
| Parameter ID | Type | Great Lakes value (illustrative) | Used by |
|---|---|---|---|
| X12_VERSION | String | 004010 | Mapping and converter schema selection |
| ISA_QUALIFIER / ISA_ID | String | The partner's ISA qualifier and ID | Envelope fields in outbound mappings |
| DELIVERY_DIR | String | Partner directory on the SFTP server | SFTP receiver adapter |
| MM_810 | String | ref:<ID of the standard 810 mapping artifact> | Dynamic Message Mapping step |
| Alternative partner | Agency, scheme, ID | ISA sender ID → partner GLFS | Inbound partner resolution |
Contoso's naming for partner entries. Parameter IDs are a convention the team agreed; values come from each partner's implementation guide.
Onboarding a partner
- Get the partner's implementation guide and sample files, and compare them with the standard mapping's guide.
- Create the partner and its alternative partner in the Partner Directory of CMC_TEST, then its parameters.
- Add partner code lists to value mappings, with the partner as agency.
- Run the standard regression pack plus the partner's own samples (lesson 6).
- Connect and test with the partner; repeat the entries in CMC_PROD and run the checks below.
- One mapping per message type and direction; partner differences live in data.
- Partner Directory: string and binary parameters, alternative partners and authorized users; add partners without redeploying flows.
- Resolve the partner ID first (getPartnerId for external IDs), then read its parameters.
- For real structural differences, select a deployed mapping artifact dynamically with pd:<Partner ID>:<Parameter ID>.
Check your understanding · not graded
Lesson check
1. Twelve customers need the same 810 with small differences. What is the most maintainable design?
2. Which method resolves a partner ID from an external sender ID?
3. A mapping step reads its mapping from the Partner Directory. Which expression format does it use?
4. What does the Partner Directory let Contoso do when it adds a new customer?