Lesson 4 of 6
Runtime: Partner Directory and generic flows
10 min
Listen to this lesson
When an agreement is activated, its configuration leaves the design-time world and becomes runtime data. This lesson follows a Great Lakes 850 through the runtime to show where that data goes and how a small set of SAP-delivered flows uses it.
The Partner Directory
The Partner Directory is tenant-specific storage in Cloud Integration for information about the partners connected to the tenant. Integration flows can be parameterized with it: a flow step reads a value from the directory at runtime instead of having the value hard-coded. TPM uses this to make one flow serve many partners.
When a trading partner agreement is activated, TPM writes an entry for each business transaction activity in the agreement and for each interchange envelope extraction, depending on the adapter type. The entries are named with partner directory IDs that start with SAP_TPM. You can inspect them without leaving TPM: in Design > B2B Scenarios, the Partner Directory Data tab lists every ID with its Activity Plain ID, an Agreement Link, and created and last-modified dates. The tab is read-only and shows only trading partner content.
SAP documents a limit of 10,000 business transaction activities per tenant. Contoso is far from it, but a company with thousands of partners and four transactions each should plan tenants with that number in mind.
The generic flows
The runtime is the package Cloud Integration - Trading Partner Management V2. You find it under Discover, choose Copy, and then configure and deploy its artifacts from Design. It is configure-only: you set externalized parameters but you cannot edit the flows.
| Artifact | Purpose |
|---|---|
| Step 1 - Sender AS2 Communication Flow V2 | Receives and extracts messages sent with the AS2 adapter |
| Step 1 - Sender AS2 MDN Communication Flow V2 | Receives asynchronous MDNs from partners |
| Step 1 - Sender IDOC Communication Flow V2 | Receives IDocs, for example from SAP S/4HANA |
| Step 1 - Sender SOAP Communication Flow V2 | Receives messages sent with the SOAP adapter |
| Step 1 - Sender Process Direct Communication Flow V2 | Receives messages from your own flows via ProcessDirect |
| Step 1a and Step 1b | Internal: restart and retry intake, and writing the message to the message queue |
| Step 2 - Interchange Processing Flow V2 | Transforms the sender's message into the structure the receiver expects |
| Step 3 - Receiver Communication Flow V2 | Takes the final message from the queue and sends it to the receiver |
The integration flows in the TPM V2 package and what each does.
A few rules from SAP's documentation save trouble. The V2 package uses newer AS2 sender and AS2 MDN sender adapters with more dynamic parameters, and only the AS2 adapter's Profile configuration mode works with it. V2 is not compatible with the 1.x package, and both use the same default sender endpoint, so if you run both during a transition you must change the V2 endpoint through its externalized parameter. Supported sender adapters are SOAP, AS2, AS2 MDN, IDoc and ProcessDirect; supported receivers are SOAP, AS2, IDoc and ProcessDirect. The AS2 adapter also needs the tenant's message queues, so the service plan must include them and the message broker must be activated; check SAP Note 2903776 for which Integration Suite plans include TPM and message queues.
Following one message
The AS2 sender identifies the sender, either from the AS2 partner ID header or from the authorized user, depending on configuration. The interchange extraction reads the envelope (for X12 the ISA and GS sender and receiver IDs, message type and version) and writes them to message headers. From those values the flow computes the partner directory ID, reads the agreement's parameters and binaries, validates against the MIG, runs the MAG's mapping, creates the functional acknowledgment if configured, assembles the outgoing structure and hands it to Step 3. If the computed ID matches nothing, the interchange ends up as unassigned or fails with an agreement configuration error, which is why identifiers matter so much.
Custom logic without editing generic flows
Because the generic flows can't be edited, custom logic goes into your own flows. The ProcessDirect sender lets your flow hand a message to Step 1, and agreements can call a ProcessDirect flow as an alternative mapping. SAP's PO migration guide uses exactly this pattern for mappings imported from the Enterprise Services Repository. Two rules apply: don't reuse SAP's Groovy scripts from the package in your own flows, and don't name your own headers with the prefix SAP_, because the generic flows may overwrite them.
- Is the requirement a partner value, such as an ID, URL or MIG version?Yes → maintain it in the profile or agreement · No → next question
- Is it a mapping rule?Yes → change the MAG in Integration Advisor · No → next question
- Is it logic a MAG can't express, such as a lookup in another system?Yes → your own ProcessDirect flow, called as alternative mapping · No → raise it with SAP before building
What would you do?
Great Lakes' test 850 failed in the B2B monitor with the error category Agreement Configuration Access Failed. The agreement shows as active. What should Theo check first?
- Activation writes SAP_TPM entries to the Partner Directory, one per business transaction activity plus envelope extraction entries.
- Entries hold string parameters (settings) and binary parameters (Integration Advisor runtime artifacts).
- The configure-only TPM V2 package processes all partners in three steps: sender, interchange processing, receiver.
- Custom logic belongs in your own ProcessDirect flows, never in edited generic flows.
Check your understanding · not graded
Lesson check
1. Where can you view Partner Directory entries created by TPM without opening Cloud Integration's own Partner Directory API?
2. Which artifact transforms the sender's message into the structure the receiver expects?
3. Why must you change the V2 sender endpoint if you deploy the 1.x and V2 generic packages together?
4. A developer wants to add a lookup to the Step 2 flow. What is the supported approach?