Planning the Migration Process

SAP Process Orchestration offers several landscape deployment solutions that can be categorized as central, distributed (model 1), or distributed (model 2) domains.

A single integration server communicating with all business systems. Central deployment of SAP Process Orchestration is a common architecture for most organizations because it represents the smallest possible installation footprint and holds associated total cost of ownership (TCO) benefits.

A single integration server with one or more decentralized adapter engines communicating with relevant business systems. It's often found in organizations where performance or security reasons dictate a more complex solution compared to centralization. This is a hybrid approach between central and federated models combining the benefits around performance and security with the benefits from centralized governance, maintenance, and monitoring.

Two or more integration servers (domains) within a single landscape tier communicating with relevant business systems. Use of additional decentralized adapter engines per integration server is also possible and adds a further level of complexity. Due to the more complex architecture, the second distributed domain model allows greater flexibility, however at the expense of a higher TCO. Such organizations are usually larger in size and require a high degree of abstraction in their landscape.

In contrast to customer-driven reasons for this model, there are also some SAP-driven reasons, such as isolation for upgrade path independence or decoupling of business systems and portal UI bindings.

The SAP Business Accelerator Hub (https://hub.sap.com) is a web application hosted by SAP to discover, explore, and test SAP and partner APIs (application programming interfaces) that are required to build extensions or process integrations.

APIs in SAP solutions use various protocols, documentation, and access mechanisms. Application and integration developers must have a consistent overview of the APIs available in the relevant SAP systems (deployed on-premise and in the cloud). Testing APIs and building prototypes also involves organizing access to relevant systems and tenants for developers.

SAP Business Accelerator Hub addresses these challenges by offering a central catalog of APIs, along with an integrated test environment in the cloud for easy testing. SAP Business Accelerator Hub covers APIs from SAP S/4HANA, SAP SuccessFactors, SAP BTP, SAP Hybris, and more.

The Aggregator pattern is a fundamental Enterprise Integration Pattern used in systems such as SAP Integration Suite to group multiple related messages and process them in bulk. This pattern is crucial for scenarios where individual messages need to be collected and managed together, such as collating multiple order items into a single order document. The aggregated message is then sent to the actual receiver.

The figure Aggregator Pattern explains the differences between the pattern implementation on SAP Process Orchestration and SAP Integration Suite.

Because the Aggregator pattern keeps a state, SAP Business Process Management (SAP BPM) is required to orchestrate the message flow. For the actual exchange of messages with the involved systems, the SAP Process Integration runtime of SAP Process Orchestration is used.

As you can see in the integration flow model, SAP Integration Suite comes with a dedicated Aggregator flow step. Therefore, you do not need to model the pattern in a loop as seen for SAP Process Orchestration. In the Aggregator flow step, you actually define your correlation condition as well as the completion conditions. Currently, last message condition and completion timeout are supported. Unfortunately, maximum number of messages is not yet supported. The rest of the flow steps are used in order to map the collection of items to the right message format, in our case an order with order header information and all items, hence removing redundant information.

This pattern is used when a message with multiple elements needs to be handled, and each element requires different processing. The message is split into sub-messages and sent to different destinations for processing. The results are then recombined into one single message.

In this example, a General Splitter is used to break up the order into multiple individual messages, according to the number of items within the original order. In a subsequent step, the Router forwards the items to a different inventory system, depending on the product category. The Content Enricher then reads data synchronously from an external system and appends the additional information to the original message before routing to the actual receiver. Finally, the Gather step reaggregates the multiple responses back into a single message within the original order.

With the Scatter-Gather pattern, you can broadcast a message to multiple recipients and reaggregate the responses back into a single message.

The reference Scatter-Gather Pattern integration flow consists of two integration processes: one for the scatter part and one for the gather part.

In this example, the Scatter part takes the request and broadcasts it to multiple banks. Prior to this Scatter part, the timer is triggered via a separate message sent to the Gather part.

The Gather integration process receives the quotes from the banks, aggregates them, calculates the best quote, and finally returns the best quote to the requester.

The Content Enricher reads data synchronously from an external system, and appends the additional information to the original message before routing to the actual receiver.

The figure Content Enricher Pattern explains this pattern on SAP Process Orchestration and on SAP Integration Suite.

In the above example, the process starts gathering an order list for a specific employee. The customer details are missing. They need to be retrieved from a different system. Therefore, you loop over the list of orders and, within each loop pass, you do a web service call using an automated activity. Within the automated activity, the additional information is then mapped to the respective order item, hence enriching the message.

On SAP Integration Suite, you can either model the Content Enricher via the Request Response pattern or via a dedicated Content Enricher flow step.

The Content Enricher flow step automatically matches the responses to the different items of the original message. It is particularly suited to enriching bulk data. Using this option is much better in terms of performance compared to a request response pattern. Here, you do not need to loop over all items carrying out individual lookup calls, you simply do one call and the matching is done automatically based on your key.

Depending on the use case, there are several options available for the Splitter pattern. With the Splitter pattern you can break up a message into multiple individual messages according to the number of elements.

There are two use cases:

• Splitting a bulk order message into multiple orders
• Splitting a single order with multiple items

Variant with Iterating Splitter

When Splitting a bulk order message into multiple orders, you can use the variant with Iterating Splitter.

The figure Variant with Iterating Splitter illustrates this simple scenario containing an iterating splitter step.

Variant with General Splitter

The General Splitter allows you to split a single order with multiple items into individual messages. The General Splitter automatically duplicates the header information of the order for each individual message.

The integration flow Variant with General Splitter contains a general splitter step.

Variant with Message Mapping

Use this variant if you have specific requirements that aren't covered by the General Splitter or you want to reuse the mapping from your SAP Process Orchestration system.

The figure Variant with Message Mapping illustrates the required flow steps.

Content-based routing allows you to forward messages to the right recipient, depending on the content of a message.

For each receiver, you can maintain a condition in the form of an XPath expression. The XPath expression can be either based on the payload data or the message header. During message processing, Cloud Integration evaluates the condition, and if met, routes the message to the respective receiver. If no receiver can be determined, Cloud Integration can proceed according to the following variants:

• Send message to a default receiver
• Ignore message
• Raise an error

Send Message to a Default Receiver

In the example integration flow, the message is routed to different receivers depending on a certain routing condition. If neither routing condition is met, Cloud Integration sends the message to a default receiver.

The figure Variant Send Message to a Default Receiver shows the iFlow.

Ignore Message

In this variant, no receiver can be determined at runtime as no routing condition is met.

For each receiver, the routing condition is configured accordingly. In addition, a route is configured that points to an End event.

Raise an Error

In this example, an error is raised if no receiver can be determined, depending on the XPath expression. Now the default route leads to an Error End event.

Different message processing options are modeled for the Exception Subprocess. The options depend on whether the event is triggered by the Error End event within the main integration process or any other error that can occur during message processing.

The Recipient List Integration Pattern allows you to send one or more messages to different recipients. Similar to an order, you want to send to different suppliers depending on the product that you want to order. Therefore, the particular suppliers are dynamically determined based on the respective goods. Other than for the content-based router, a copy of the message, is sent to multiple receivers.

There are two options when implementing the Receiver List pattern:

• Static routing with XPath conditions
• Dynamic routing using mapping to determine the receivers

Static Routing

In this variant, a fixed list of potential receivers exists. The recipient list pattern is realized via a combination of multicast and message filters.

The figure Variant Recipient List with Static Routing shows an example iFlow. The Multicast step is used to send copies of the same message to multiple routes. The Message Filter is a specific type of the message router that has only one single receiver channel. The Message Filter evaluates every incoming message. If the message meets the criteria specified by the Message Filter, the message will be routed to the receiver, otherwise it's discarded.

Dynamic Routing

Other than for the static routing variant, you don't need to maintain a fixed number of receivers in the integration flow.

As shown in the above figure, the receiver determination part is decoupled from the receiver-specific delivery of the message. Therefore, a main integration process is modeled that contains the receiver determination, and an integration flow is modeled for each potential receiver. The main model and the individual integration flows are coupled via the ProcessDirect adapter. The ProcessDirect address is set dynamically based on the receiver determination.

With the Message Filter pattern, you can remove any data from a channel that you are not interested in. The Message Filter is a specific type of the Message Router pattern that has only one single receiver channel. Any incoming message is evaluated, and if it meets the criteria specified by the Message Filter, the message is routed to the receiver, otherwise it's discarded.

The Message Filter pattern is similar to the Content-Based Routing pattern where the message is ignored if you cannot determine the receiver.

However, for the Message Filter pattern, you define only one single receiver.

In the Pattern Message Filter integration flow, you define a routing condition that is based on the product category. If the routing condition is not met, the message will be discarded. You can achieve this behavior by adding a default routing pointing to an end event.

The Content Filter Pattern allows you to remove data from a message that is not required in your application system.

There are two options when implementing such a scenario:

• Using a Filter step
• Using Message Mapping

Using a Filter Step

In this variant, the filter is used to remove all unnecessary data items from the message. However, the message header is kept.

The figure Variant Using a Filter Step illustrates this simple scenario.

Using Message Mapping

In this variant, Message Mapping is used to remove all unnecessary data items from the message, but the message header is kept.

The integration flow only contains Message Mapping.

Edge Integration Cell is included as a part of the existing SAP Integration Suite (for standard and premium editions and Cloud Platform Enterprise Agreement (CPEA) and pay-as-you-go (PAYG). Additional Edge Integration Cells can be acquired through a separate add-on Stock Keeping Unit (SKU). Only 50% of the messages that are processed by Edge Integration Cell are chargeable (excluding unmodified standard content for SAP-to-SAP software).