1.

1 SAP CPI: Centralizing ABAP Proxy Connectivity

Connectivity from SAP ABAP Systems to SAP CPI via ABAP Proxy can be done via XI adapter (XI runtime:
SXMB_ADM) or SOAP adapter (WS Runtime: SOAMANAGER).

In case of XI adapter, we usually have to create a sender id for the outbound proxy in SXMB_ADM and create
an iFlow-specific RFC Destination which is not so nice as we might end up creating a lot of destinations.

There is a way to use a generic RFC destination as well. To achieve this, we need to create a generic
iFlow that accepts all XI calls from the SAP backend systems and distributes them dynamically via
ProcessDirect adapter. The url between the sending and receiving iFlow would be dynamically populated
based on sender service and interface name.

Configuration of Generic iFlow:

1. Allow headers from SOAP Header (XI 3.0 protocol)

2. Assign address dynamically using /<sender>/<interface>

At runtime, you will see 2 messages.

They share the same CorrelationID automatically:

1.2 Runtime Variables available with CPI
This is an overview of useful and commonly used (dynamic) variables and runtime parameters of SAP Cloud
Platform Integration based on Apache Camel´s expression language.

SAP Help: Headers and Exchange Properties

Those variables can be used in Integration Flows (e.g. in artifacts as Content Modifier, Router, Channels, …)

Parameter Description

${in.body} or ${body} Message Payload

${header.var1} Message Header Variable (var1)

${property.prop1} Exchange Property (prop1)

${date:now:yyyy-MM-dd} Current Date/Time with format

${property. SAP_MessageProcessingLogID} Message Guid

${CamelFileName} File Name

${CamelHttpUri} HTTP URI (URL with QueryString)

${CamelDestinationOverrideUrl} SOAP Adapter URL

${exception.message} Error Message

${exception.stacktrace} Error Stacktrace

1.3 Asynchronous Messaging Best Practices in CPI

SAP Cloud Platform Integration does not store message payloads by default (queueing). In case an error
occurs (mapping, routing, connectivity), we have to design the desired behavior ourselves.

For synchronous connectivity it is simple: The errors are immediately sent back to the calling/sending system.
No persistency or message queueing is required as error messages have to be handled outside the
integration flows (outside CPI).

(REST/OData/SOAP) APIs are mainly integrated synchronously, whereas Queue-based messaging is an

asynchronous integration pattern. Asynchronous Message Queueing is a preferred way to enable
decoupled integrations between applications.

For asynchronous connectivity we have several options, depending on the sender adapter used:

 SOAP (1.x)
o You can change the processing settings to “Robust”. This will execute all steps of the iFlow in
a synchronous mode until the message processing is successful. Then the sender will receive
a HTTP 2xx code (OK). If an error occurs at any point, the sender will be informed through a
HTTP 500 code (server error) and the sender must queue and organize the retry
mechanisms.

o The alternative is processing setting “WS standard”: When the message arrives completely
inside the iFlow, the sender will be notified with a success message and the CPI processing
starts. If any error occurs and nothing is done to enable queueing/persistency, the message
will be lost and no retry will be possible. (of-course the sender system may be able to
manually resend a message which was apparently already successfully processed).
 XI (ABAP Proxy) and AS2
o Both adapters are working event-based through an incoming message, however (when
selecting EO mode) the message is persisted temporarily in a storage: Data Store (JDBC
based) or Queue (JMS based). This is the most convenient way of integration as it provides
us with maximum flexibility:
 The sender system was able to transfer the message successfully and the
middleware is now in charge
 Messages in the Data Store or Queue are being reprocessed periodically
o To resolve the situation manually (if the error is not temporary, e.g. due to a network issue,
but permanent): Delete message from Data Store or Queue
 For Queues there is even a more convenient way, as JMS provides Dead-Letter
Queues (DLQ). Messages which are failing repeatedly to be processed are moved
automatically to a DLQ where manual actions can be triggered (e.g. notifying a
responsible person).
 For all other Push based Sender Adapters (sender system triggers message processing) a queueing
must be implemented manually (see below)
o IDoc, HTTP, SOAP (RM)
o ProcessDirect adapter is not listed here, as the communication is only used internally within
CPI, however the same principles apply: no standard queueing available

 For all Pull Sender Adapter (CPI triggers message processing with a periodic frequency): a queueing
exists implicitly – the message remains at its source location until the processing is completed
successfully
o SFTP, Mail, SuccessFactors, Ariba

How to define Manual Queueing

 JMS adapter: Queues

o The easiest way to ensure a proper queueing is using the JMS adapter (requires CPI
Enterprise Edition or at least Enterprise Messaging)
o This is an internally used adapter, you can only send/receive messages though JMS queues
within your CPI tenant locally.
o The approach is to persist all incoming messages into a queue first (with the unchanged
messages) and then have a second Integration Process polling from the queue and
processing the messages. Like this, the approach works like the XI or AS2 adapter, but with
an additional Integration Process. Luckily this can be placed in the same iFlow. The
messages remain in the queue until the processing of the message is successful.
o When other iFlows are called (via ProcessDirect adapter), you have to make sure that the
transaction handling is using JMS, not JDBC.
o Great is the exponential back off (poll-interval in doubled with each attempt) and Dead-Letter
Queue handling
o The only disadvantage is the limited number of queues (28) available… Setting this up for
each interface will soon use all available queues.
 Data Store (JDBC)
o Using the Data Store, we can also achieve queuing without the limitations above (we can
have many, many Data Stores).
o The approach is similar to the JMS one, but we have to manage the processing more
manually, see the example below.
o If the first message in the queue fails, all following messages remain in the queue untouched.
Therefore, you should design the Select in batch mode (to parallelize processing) and then
iterate by message with a splitter
o Limitations
 Unlike the JMS approach, you will see a message for each poll interval, even if no
entry is inside the Data Store. We must use the gateway to check if a message exists
or not
  The Select Operation only supports XML. In case you want to transfer Non-XML
(binary, text, etc.), you must Base64-encode the payload and add an XML tag around
with a Content Modifier Step.
 The Select Operation reads the set of messages randomly (e.g. 100 messages), not
using a FIFO approach. Like this, blocking messages can stop the interface entirely,
even if some messages could be processed successfully.
 Metadata (e.g. source file name) would have to be stored in the entry id as the data
store only persists the body.

Summary

Each interface is unique and has its own requirements. SAP CPI provides great flexibility here and we ideally
work with integration patterns (helping us to solve requirements in a standardized way). However, for
asynchronous integration with queueing, there is no perfect pattern available yet, unless you can use XI or
AS2 sender adapter. A good alternative is the SOAP 1.x (robust) adapter to push back the errors as well as
the polling adapters where the message remains where it is until the processing is complete. The 2-step
approach of the JMS queues also provide an excellent way, but the number of queues is still limited. Until this
limitation is removed by SAP, we can use the DataStore etc.

Type Adapter Queueing

Push SOAP 1.x Robust Mode possible: errors are pushed back to sender

Push IDoc, HTTP, SOAP (RM) Queueing must be implemented manually

Push XI, AS2 Queueing available (with Data Store/JMS)

Pull SFTP, Mail, SSFS, Ariba Messages remain at source location in case of error
1. Cloud Integration Content in SAP Process Integration

1.1. Introduction

Cloud Integration content from SAP Integration Content Catalogue can be deployed, executed, and
operated in the Advanced Adapter Engine with all the deployment options (PI-AEX, decentral Adapter
Engine, SAP Process Orchestration and SAP PI dual usage type).

 Prerequisites: Integration Gateway component must be enabled in SAP Process Integration.

After enabling the Integration Gateway component, one must change the kernel update
procedure for every SAP PI 7.50 Java system to replace Java Cryptography Extension (JCE)
jurisdiction policy files. For more information, see SAP Note 1240081 .

1.2. Enabling Cloud Integration Content in SAP Process Integration

 Prerequisites:
 You must have an SAP HCI tenant.
 You must enable the Integration Gateway component in SAP Process Integration.
 All the roles mentioned in the Roles section are required.

 Procedure:
 Integration content is discovered in WEB UI tool of CPI under “Discover” tab.
 It is copied in “Design” tab.

 Select the appropriate product profile. For more information, see SAP HANA Cloud
Integration Documentation > Designing Cloud Integration Content for SAP PO 7.5 SP2 >
Product Profiles.

 In the integration flow, sender and receiver channels are configured as required and saved.

 Content bundle is downloaded to local system.

 To deploy the cloud integration content in SAP Process Integration below are steps:

a. Log in to the Cloud Integration Content Management Cockpit

at http://[host]:[port]/IGWGBDeploy/Admin.

b. Deploy the security artifacts of the sender and receiver channels on the Security
Artifacts tab. For more information, see Deploying Security Artifacts.

c. On the Integration Content tab, deploy the content bundle that you downloaded in
one of the above steps.
 More details can be found at
https://help.sap.com/viewer/5cf7d2de571a45cc81f91261668b7361/7.5.8/en-
US/14ff0a6d7cd94540bb252f816fbfecde.html