Adressing Special Technical/Functional Topics

Objective

After completing this lesson, you will be able to analyze and address special technical/functional topics to ensure a comprehensive migration plan.

ABAP Proxy Migration

ABAP proxy interfaces are often used in SAP Process Orchestration. These interfaces are defined in the Enterprise Services Repository (ES Repository), which then generates the ABAP objects using the SPROXY transaction on the SAP side.

With the availability of the XI Adapter in SAP Integration Suite, you can migrate your ABAP proxy interface. After successful migration, the proxy interfaces will still run as they did in SAP Process Orchestration. However, please note that you will not be able to make any further changes to these objects because the underlying ESR or SAP Process Orchestration will no longer be available.

Please consider that the migration of ABAP proxy interfaces from SAP Process Orchestration to SAP Integration Suite has some limitations as described in the following table.

Known Limitations

Limitation	Workaround
ABAP proxy generation using transaction SPROXY on the SAP system is not supported if you're using Cloud Integration.	Use the Enterprise Services Repository to create or update ABAP proxies, but run these interfaces on Cloud Integration. Migrate your existing proxy, if possible, or create a new proxy interface using Metadata Repository (MDR). Maintain your WSDL on your preferred tool and import them through transaction SE80.
Acknowledgment is not supported.	There's currently no workaround for this limitation.
Exactly Once In Order (EOIO) is not supported.	A custom solution can be built to read the messages from a data store and based on their entry sequence, using for instance a timestamp and/or sequence ID, deliver the message in order.
There is a limit on the JMS resources.	Analyze your landscape and according to the expected usage of the resources and decide on the number of queues, consumers, etc.

For detailed migration steps, in the Migration Guide for SAP Process Orchestration, choose Interface Migration → Migrating Proxy Interfaces.

Java Mapping Migration

Many customers are using Java Mappings instead of Message Mappings to map their complex messages. For customers that do not have the documentation or knowledge required, Java mapping can be migrated with less coding efforts using Apache Groovy script templates.

When you transition from SAP Process Orchestration to the Cloud Integration capability within SAP Integration Suite, you can use Groovy scripts instead of Java mappings. Groovy has a few advantages over Java mappings. For example, Groovy scripts have a more concise and expressive syntax, which reduces the amount of code needed for common tasks. Groovy's flexibility and simplicity make it well suited for quick development cycles and easy maintenance. It also seamlessly integrates with Java, which eases the transition for developers familiar with Java. Overall, using Groovy in your Cloud Integration environment leads to more efficient development and easier management of integration processes.

The following table provides an overview of the different functions used in Java mappings and Groovy script. For more information regarding differences between Groovy and Java, follow this link: https://groovy-lang.org/differences.html.

Header Function	Java Mappings (SAP Process Orchestration)	Groovy Script (Cloud Integration)
Message Input and Output Classes	AbstractTransformation.getInputPayload: Get the input payload (message) in the Java mapping. AbstractTransformation.getOutputPayload: Get the output payload (message) in the Java mapping.	Access input and output messages using the message object. For example, use message.getBody() to get the input payload and message.setBody()to get the output payload.
XML Processing	Java mappings often involve XML processing. Use classes such as DocumentBuilderFactory, DocumentBuilder, or Document for reading, creating, and manipulating XML documents.	Groovy has built-in support for XML processing. To read and create XML documents, use Groovy's XMLSlurper or XMLBuilder classes.
Logging and Tracing	AbstractTransformation.getTrace().addInfo: Add informational messages to the mapping log. AbstractTransformation.getTrace().addWarning: Add warning messages to the mapping log. AbstractTransformation.getTrace().addError: Add error messages to the mapping log.	The message processing log (MPL) stores data about the messages processed on a tenant. It also stores information about the individual processing steps for each processed message. For more information on using the MPL in your Groovy script, see Add Information to the Message Processing Log.
Exception Handling	Java mappings handle exceptions appropriately using try-catch blocks. Use AbstractTransformation.getTrace() to write additional messages on the log console.	Groovy supports try-catch blocks for exception handling. Additionally, you can use the object CamelExceptionCaught to retrieve more information about exceptions thrown in your integration flow. See Script Example for Exception Handling in HTTP Receiver.

You can directly migrate small Java mappings to Groovy scripts. For more complex scenarios, you can still reuse some of your existing Java mappings from SAP Process Orchestration in Cloud Integration, but you must use a Groovy script wrapper. Also, your Java mapping must use supported functions and methods on Cloud Integration.

In all cases, make sure to retest the Java mappings after the import and adapt them if necessary.

The following use cases found in Java mappings might not be supported using this Groovy wrapper approach in Cloud Integration:

Binary attachments (for example, PDF)
Process Microsoft Office documents (for example, Word, Excel)
Encryptions and decryptions
Java mapping lookups
File system operations
Message signature using certificate in keystore
Dynamic properties and headers

For more information regarding the Groovy Script Wrapper, use the Migration Guide for SAP Process Orchestration.

Use the following blog for practical guidance: Migrate Java Mapping from SAP PO to SAP CPI/Integration Suite.

SAP Process Integration Pipeline Concept

The pipeline concept allows you to set up your asynchronous integration scenarios in Cloud Integration in a similar way to how messages are processed in SAP Process Integration and SAP Process Orchestration, in pipelines. The pipeline concept is mainly aimed to existing SAP Process Orchestration customers that plan to migrate their scenarios to the Cloud Integration capability of SAP Integration Suite. However, it can also be generally applied to any asynchronous integration scenario that you want to implement and run on Cloud Integration.

Pipelines in SAP Process Orchestration

The static pipelines play an important role in SAP Process Integration and SAP Process Orchestration. Each pipeline consists of a fixed number of pipeline steps in a fixed order. For example, when a message is processed within the SAP Process Orchestration runtime, first the receiver is determined, then the interface, and then the mapping is carried out.

The figure below shows the pipeline steps in the Advanced Adapter Engine.

The pipeline steps involved in sending a message from the sender system to the receiver system: Sender Adapter Processing, Inbound XML Validation, Receiver Determination, Interface Determination, Mapping, Outbound XML Validation, and Receiver Adapter Processing.

Using the Pipeline Concept

The pipeline concept can be used either as an alternative approach or as an additional approach to the individual migration of single integration scenarios supported by the migration tools within SAP Integration Suite.

While migrating only a few integration scenarios to Cloud Integration, it might be easier to create individual integration flows for each of your original integration scenarios. If you have a large number of integration scenarios, the pipeline concept can speed up the migration project and reduce effort and cost, for example, for operating and monitoring your integration scenarios in the Cloud Integration.

Handling JMS Queues

JMS (Java Message Service) queues are an integral part of integration flows in the SAP Integration Suite. They provide powerful capabilities for ensuring reliable message delivery and facilitating decoupled communication between sender and receiver applications.

Outline of JMS Queues in Cloud Integration.

A JMS queue acts as a holding area for messages that are sent from one application to another. Instead of the sender application having to directly communicate with the receiver, the sender simply sends the message into the queue. The queue then holds the message until the receiver is ready to process it. This enables the sender and receiver to operate independently of one another, which is advantageous in scenarios where the receiver might not always be ready or able to receive messages immediately.

Within an integration flow (or iFlow) on the SAP Integration Suite, you might use a JMS queue to handle the transfer of messages from one part of the flow to another. For example, if a flow is designed to receive a message, process it in some way, and then send it to another application, a JMS queue could be used to hold the message after it's received and before it's processed. This decouples the receiving and processing stages of the flow, so if there's a hold-up in the processing stage, it won't impact the ability of the flow to continue receiving messages.

With the pipeline concept, you can reduce the number of JMS queues you need to run your integration scenarios on Cloud Integration. With proper usage of JMS queues and ProcessDirect adapters and relying on the Partner Directory to be able to dynamically configure your integration flows, you can reduce the number of required JMS queues to four. With four more JMS queues for the retry and dead letter handling, you arrive at eight required JMS queues. Even if you duplicate the set of integration flows to build up multiple pipelines, for example, to handle low, medium, and high priority scenarios, you only need a low number of JMS queues. These few JMS queues are easier to handle than the thousands of JMS queues in a typical migration use case

Thus, JMS queues contribute to the robustness and flexibility of integration flows in the SAP Integration Suite, enabling them to handle messaging traffic in an efficient and fault-tolerant manner.

Explaining Key Elements

Integration Flows

In the pipeline concept, each step corresponds to an integration flow. There are two types of integration flows: Generic integration flows and scenario-specific integration flows. The generic integration flows are used across all integration scenarios and must only be deployed once. Scenario-specific integration flows handle the scenario-specific message conversions and mappings. They're either created manually or generated using a migration tool. In both cases, integration artifacts such as message types and mappings can be reused.

ProcessDirect Adapters

Use the ProcessDirect adapter to call the scenario-specific integration flows. The adapter establishes fast and direct communication between integration flows by reducing latency and network overhead. A disadvantage of using the ProcessDirect adapter is synchronous connection between the integration flows. If the integration flow called by ProcessDirect fails, it remains in the status Failed even if the calling integration flow can handle the retry of the message. Replacing the ProcessDirect connection with a JMS connection isn't an option because it would again result in a large number of JMS queues.

Partner Directory

The Partner Directory helps to define the message processing behavior. For example, you can define a scenario-specific maximum number of retries or receiver-specific outbound queues. You can also use the Partner Directory to dynamically configure the generic integration flows, which helps to reduce the number of required JMS queues.

Note

Please refer to the Migration Guide for SAP Process Orchestration for more details.

There's also a blog series available: Introducing the new pipeline concept in Cloud Integration.

Continue to quiz