This blog post is part of the series Master Blog: SAP Process Orchestration to SAP Integration Suite Migration – Tool and Guidance exploring how to migrate various integration patterns from SAP Process Orchestration to SAP Integration Suite using the Migration Tool. In this blog, we will explore the Interface Split and Multiple Operation.
Objective of this Blog
The goal of this blog is to explain how the Migration Tool supports the Interface Split and Multiple Operation Integration scenarios. The blog will cover the following key areas:
Interface Split
- What is Interface Split in SAP Process Orchestration
- Migration of Interface Split by Standard Approach and Pipeline Approach
Multiple Operation
- What is Multiple Operation in SAP Process Orchestration
- Not Operation-specific and Operation-specific
- Migration of Multiple Operation by Standard Approach
Interface Split
What is Interface Split in SAP Process Orchestration
Interface Split in SAP Process Orchestration is a mechanism that routes a single incoming message from a sender system to multiple distinct receiver interfaces. Rather than handling multiple receiver interface scenarios within a single, complex integration flow, an Interface Split leverages Content Modifier, Script, and Router Steps in Cloud Integration to evaluate message payloads (JSON/XML fields, attributes, or headers) at runtime and dispatch the message to all receiver interfaces whose conditions are satisfied. This enables decoupled, parallel processing without requiring the sender system to split messages beforehand.
Migration of Interface Split by Standard Approach and Pipeline Approach
Interface Split scenario in the SAP Process Orchestration
In this scenario, two conditions are defined for message splits that route to matching interfaces. The Receiver Determination contains one receiver only, with no receiver condition. Receiver Interface Conditions are inclusive, allowing multiple messages to be sent simultaneously. Each Receiver Interface can have its own operation mapping.
Migration Pattern & Approach
In Step 3 of the Migration Wizard — Choose Pattern and Approach — you select the appropriate migration pattern and the corresponding approach based on your integration scenario.
Interface Split scenarios can be migrated using both the CBR (Content-Based Routing) Asynchronous and RL (Recipient List) Asynchronous patterns.
For this scenario, the RL Asynchronous pattern is recommended because it supports routing the message to multiple receivers simultaneously.
Standard Approach
For the Approach, both the Standard Approach and the Pipeline Approach are supported in SAP Integration Suite. First, let’s go over the interface split scenario using the standard approach.
After a successful migration, a Summary Page is displayed, providing key insights and direct navigation links to the migrated artifacts in Cloud Integration.
Inbound Integration Process
This process receives the message from the sender, sets the sender system and message type, and performs receiver determination along with receiver interface determination, where the defined receiver rules and routing conditions are evaluated.
When a receiver maintains multiple interfaces, specific Exchange Properties with an IFx suffix are generated. Since there are two Receiver Interfaces defined for Receiver_1 in this example, the generated properties are:
- SAP-IFDET-RL_Receiver_1~IF1
- SAP-IFDET-RL_Receiver_1~IF2
The interface split condition is evaluated at this point to identify the appropriate receiver based on the message content. These exchange properties collectively store the migrated receiver and interface rules, enabling the integration flow to evaluate routing logic dynamically at runtime.
For more details of exchange properties for the Receiver determination, see: Migrating Content-Based Routing Scenarios Using the Migration Tool in SAP Integration Suite
The Interface Determination and Merge XML Receivers steps are implemented as a Groovy script that evaluates predefined receiver and interface conditions. Based on these conditions, the script filters and identifies the valid interfaces for the current message, automatically validating them against the receiver list and operation type. It then merges the matching results into a single structured XML payload to enable dynamic message routing.
Outbound Integration
The Outbound Integration Process contains the mappings, receiver communication channels, and configured receivers. It is responsible for delivering the processed message to the final target system.
Router：
During the outbound phase, the routing logic utilizes the receiver interface information captured during inbound processing to link the appropriate interface mappings and communication channels to the specific recipient. Following the SAP_Interface header, the message is dynamically directed along the correct path to ensure accurate delivery to its destination.
Pipeline Approach
This section demonstrates the Pipeline Approach for migrating the same scenario. A pipeline represents the complete set of processing steps for a message. It consists of pipeline elements that call pipeline services — for example, carrying out mappings or routing messages to different receivers.
Key Highlights in the Migration Wizard
Once the Pipeline Approach is selected in Step 3, the Migration Tool enables you to adjust alternative partner details and verify or update the migrated receiver/interface conditions and endpoints, as shown below.
After a successful migration, an overview of all generated artifacts is displayed.
The PID along with the associated parameters will be generated. In the Partner Directory tab you will have an overview.
In the Binary Parameters tab, a specific parameter named receiverDetermination has been successfully created with an XSL content type. It will be used for determining the appropriate receivers.
For more information, See Using the Partner Directory in the Pipeline Concept
Multiple Operation
What is Multiple Operation in SAP Process Orchestration
Multiple Operation in SAP Process Orchestration is a mechanism that allows a single message mapping to process multiple different sources and/or target operations (interfaces) within a single integration step.
Instead of creating separate, individual mapping objects for every single interface pair, a Multiple Operation scenario consolidates them. It enables the integration engine to bundle different message types or operations together, allowing to define complex 1:N (one-to-many), M:1 (many-to-one), or M:N (many-to-many) relationships between sender and receiver operations.
Operation-specific and Not Operation-specific
When configuring integration flows for a Multiple Operation service interface, these two modes determine how routing and processing rules are applied to the different operations within that single interface:
- Operation-specific: This mode allows you to define unique receiver routing and mapping rules individually for each separate operation within the multiple operation interface. At runtime, the system evaluates which specific operation is active in the message payload and executes its dedicated processing path.
- Not Operation-specific: This mode applies a single, unified routing and processing rule across all operations contained within the interface. Regardless of which specific operation the incoming message represents, the system handles it using the same global configuration without differentiating between them.
Operation-specific
This scenario has two different operations (Type1 and Type2), each with a specific condition per receiver — resulting in two conditions defined per operation. In this case, the condition is based on the value of the MANDT field of the incoming message, as shown in the screenshot below:
It is possible to check in the screenshot below that we need to use “operation-specific” option on Receiver tab to use multiple operations.
The Type1 Operation is defined with two different receivers with different operation mappings. As you can see below, for BC_PIMAS_Receiver, the Operation Mapping defined is OM_MaterialMultiOps_Op1_TC2_v2
Integration Flow in Cloud Integration
Inbound Integration Process
The predefined conditions generated in the Content Modifier from the receiver determination and interface determination. SAP-OperationSpecific will be set up as TRUE in this case.
The conditions will be assigned to the following exchange properties. SAP-DYNREC is a prefix added to each Receiver Communication Component present in the migrated ICO.
SAP-DYNREC-Type1~BC_PIMAS_Receiver
SAP-DYNREC-Type2~BC_PIMAS_Receiver
SAP-DYNREC-Type1~BC_PIMAS_Receiver_2
The Boolean true() will be defined for the following. SAP-IFDET is the prefix used for Interface Determination and is also added to the Receiver Communication Component name. The suffix ~IFx acts as an interface index indicator, which increments based on the number of receiver interfaces maintained for that receiver.
SAP-IFDET-Type2~BC_PIMAS_Receiver~IF1
SAP-IFDET-Type1~BC_PIMAS_Receiver~IF2
SAP-IFDET-Type1~BC_PIMAS_Receiver_2~IF1
Outbound Integration Process
These routers will evaluate the condition and then send the message to the correct operation mapping and subsequently send the message for the correct receiver.
The message is first routed to the correct operation via the following Router:
It is then routed to the correct receivers.
The interface has multiple operations (Type1 and Type2) with two receiver systems. After identifying the operation type, the Integration Flow uses two different routers — one for each operation — to identify the correct receiver.
Not Operation-specific
This test case can be interpreted as Interface Split, as there are conditions on the Receiver Interface side. The “not operation-specific” option should be set to “true” on the receiver tab, indicating that one receiver handles incoming messages regardless of the operation type.
In this scenario, all data is sent to two receivers (BC_PIMAS_Receiver and BC_PIMAS_Receiver2) for the two different operations (Type1 and Type2), as shown below:
For BC_PIMAS_Receiver, each operation has three different operation mappings, each defined by a specific condition. These conditions apply rules depending on the incoming message, as shown below for Operation Type1 and Type2.
For BC_PIMAS_Receiver2, each operation has a single operation mapping with no conditions defined for both Operation Type1 and Type2, as shown below:
Integration Flow in Cloud Integration
Migration Wizard
Note: Only Standard Approach is supported for the multiple Operation Scenario.
While the Migration Tool does not currently provide automated generation of a Pipeline-based implementation for Multiple Operation scenarios, the migrated content can be adjusted manually to run within the Pipeline Approach. This mainly involves transferring the receiver/interface determination configuration to the Partner Directory, maintaining the corresponding pipeline parameters, and aligning the generated routing logic with the pipeline services. The required adjustments are typically limited and can be implemented without significant changes to the migrated integration logic.
Inbound Integration Process
The predefined conditions generated in the Content Modifier from the receiver determination and interface determination. No Value has been set up for the SAP-OperationSpecific in this case. It will be used in the next step Interface Determination Script to get the OperationSpecfic dynamically.
Outbound Integration Process
It sends the message to the right receiver first and then route it to the correct operation.
Post-Migration Activities – Key Points to Keep in Mind:
After successfully migrating Interface Split and Multiple Operation scenarios into an Integration Flow, the following activities should be verified and completed:
- Verify Migrated Artifacts: Ensure that mappings (local and global), Function Libraries, imported archives, and Local UDFs are migrated correctly and functioning as expected.
- Adapter Configuration: Adapter parameters are externalized. Verify the configurations and update them as needed to match the target environment.
- Adapter Conversions: Adapter conversions such as JSON-to-XML or CSV-to-XML are migrated automatically. Check the configuration in the conversion flow steps and adjust if necessary.
- Security Artifacts: The Migration Tool does not create or import security artifacts in Cloud Integration. Manual creation of security materials (certificates, keystores, etc.) is a prerequisite before deploying the Integration Flow.
- Reusable Mapping Options: If the “Enable Reusable Mapping” option was selected during migration, ensure that the standalone artifacts are deployed first before deploying the main Integration Flow.
#SAPCHANNEL