SAP SCPI Development &

Design Standards

Page 1 of 14 CPI Naming Document www.itelligencegroup.com

1
Document History

Version Date Author Description of Change

0.1 09th June 2020 Aswini Kumar Upadhyaya

Page 2 of 14 CPI Naming Document www.itelligencegroup.com

2
TABLE OF CONTENTS

DOCUMENT HISTORY 2
1. INTRODUCTION 4
1.1 Document Purpose 4
2. CLOUD PLATFORM INTEGRATION (SCPI) 4
2.1 Features 4
3. IFLOW OBJECTS 5
3.1 SAP Platform Cockpit 5
3.2 Package 5
3.3 Integration Flow 6
3.3.1 Participant 6
3.3.2 Process 6
3.3.3 Events 7
3.3.4 Mapping 7
3.3.5 Transformation 7
3.3.6 Call 8
3.3.6.1 External Call 8
3.3.6.2 Local Call 9
3.3.7 Routing 9
3.3.8 Security 10
3.3.9 Persistence 11
3.3.10 XML Validator 11
3.3.11 Value Mapping 11
3.3.12 Communication Channel 11
4. IFLOW LOOK AND FEEL GUIDELINES 12
5. EXTERNALIZE CONFIGURATION PARAMETERS 12
6. RESTARTING MESSAGES 12
6.1 AS2, JMS, SF Adapters 12
6.2 Other Adapter 13
7. OPTIMIZING IFLOW MEMORY FOOTPRINT 13
8. ERROR HANDLING 14

Page 3 of 14 CPI Naming Document www.itelligencegroup.com

3
 1. Introduction

1.1 Document Purpose

This document describes the SCPI development and design standards for the iflow / integration
development.

The aim of this document is to establish a set of standards and guidelines to be used within Itelligence
Group for all development work related to SAP Cloud Integration Platform (SCPI).

The document describes in detail the naming conventions and design principles for SCPI within
Itelligence Group. In addition, design principles relating to the development and configuration within
SCPI also
form part of this document. The document is not intended as a training manual for SCPI developers;
rather it is assumed that the reader is already experienced in SCPI development work.

Please note that this is a living document and subject to change as and when necessary.

2. Cloud Platform Integration (SCPI)

SAP Cloud Platform Integration (Cloud Integration) for process integration facilitates the integration of
business processes spanning different companies, organizations, or departments within an
organization.
This service helps you to connect cloud and on-premise applications with other SAP and non-SAP
cloud and on-premise applications.

This service runs in the Neo and Cloud Foundry (CF) environments. Integration content artifacts
designed in Neo environment is also compatible in CF environment with certain limitation as mentioned
in the SAP note 2752867.

2.1 Features
Implement diverse scenarios: Integrate processes and data in application-to-application (A2A)
and business-to-business (B2B) scenarios.

Connect to multiple endpoints: Integrate various applications and data sources from SAP and
non-SAP, on premise, as well as the cloud. SAP Cloud Platform Integration comes with a set of
prebuilt adapters.

Customize SAP integration scenarios: Benefit from prepackaged integration content to jump-
start integration projects and to set up productive scenarios with only minimum effort. You can
extend predefined integration flows according to your requirements.

Develop custom adapters: Use the adapter SDK to build your own custom adapters for additional
connectivity needs.

Page 4 of 14 CPI Naming Document www.itelligencegroup.com

4
 Access public APIs: Customize the access to SAP Cloud Platform Integration with our public
OData APIs.

Set up secure and reliable communication: Use our core integration and security capabilities for
the safe and reliable processing of messages. Configure the way how messages are exchanged
within an integration scenario so that the data involved is protected according to the newest security
standards.

Implement various communication modes: Orchestrate business processes and integrate data
in synchronous as well as in asynchronous scenarios. SAP Cloud Platform Integration also
supports reliable messaging processes based on asynchronous decoupling implemented by using
queuing mechanisms.

Integrate with SAP Process Orchestration: Use SAP Cloud Platform Integration and SAP’s on-
premise integration Platform, SAP Process Orchestration, seamlessly integrated.

3. Iflow Objects

3.1 SAP Platform Cockpit

SAP Cloud Platform Integration in the Neo Environment, depending on the subscribe of SAP Cloud
Platform Integration editions, you receive one or two e-mails from SAP. Log on to the SAP Cloud
Platform cockpit with your SAP S-user ID. Create subaccounts in your global account. This allows you
to divide your account model and structure it according to your business needs. You can manage
member authorizations.

Subaccount: <customername> - <ServerLocation> <Environment>

EX: abc-ASP Dev (for Austrila Sydney)

3.2 Package

Custom Package: A collection of related APIs or services, belonging to one product or product
area, packaged and delivered together.

The name of the package should refer to the two products plus product lines between which the
integration needs to take place if it is point to point. If you are developing generic integration
packages or country specific packages then refer to generic and country specific sections.

Example:

Point to Point: SAP Cloud for Customer Integration with SAP Hybris Marketing.

Generic: <Business Object/Domain Description>for<Sender or Reciever System>

Ex: EDI Integration Templates for Successfactors

Page 5 of 14 CPI Naming Document www.itelligencegroup.com

5
 Country Specific: If you are developing package specific to country like tax interfaces then:
<Business Object/Domain Description> for <Country><Sender or Reciever System>
Ex: Payroll e-Filing of Employees’ Payments and Deductions for SG Tax

3.3 Integration Flow

The integration flow is added to the list of artifacts for the selected integration package.

Integration flow template opens that contains the following shapes: Sender (this represents your
sender system), Receiver (this represents a receiver system), Integration Process (this will later
contain all the processing steps that define how a message is processed on the tenant). The
Integration Process shape contains a Start and an End event.

Syntax: <Interface Action

end/Receive>/Create/Publish/Update/Delete/Replicate/Insert/Maintain><Interface Business Object
ShortDescription>

EX: Asynchronous scenarios:

Replicate Delivery Consignment from S4HANA To Commerce Cloud
Service Creation from Commerce Cloud To C4C
Synchronous Scenarios:
Dealer Booking Summary From Commerce Cloud To C4C Sync

3.3.1 Participant

● Sender: Sender Endpoint

Syntax: S_<Sender Partner>
EX:  S_S4HANA

● Receiver :Receiver Endpoint

Syntax: R_<Receiver Partner>
EX: R_  SIEBEL, R_SAPC4C

1.1.1 Process
● Integration Process:
The process names should be self-explanatory and closely related to the
corresponding action name. Use upper camel.

Syntax: <Process Name>

EX: Payment Process, Replicate Delivery

● Local Process Flow

Local Process flows are used to modularise the complex integration flow.
Page 6 of 14 CPI Naming Document www.itelligencegroup.com
6
 Syntax: <Description of the objective that local process flow is designed to
achieve>
EX: Local Process B2B Customer
● Exception Subprocess
Exception subprocess to handle exception in case of any errors.
Syntax: <Description of the objective that exception subprocess process flow is
designed to achieve>
EX: Exception subprocess for the <iflow name>

1.1.2 Events
Provide appropriate message. Timer, Terminate Message, Start Message, Start Event, Esclation, Error
Start Event, Error End Event, End Message and End Event.

Syntax: <Timer/Terminate/Start/Esclation/Error/End <Process>

EX: Start Replicate Order Process.

1.1.3 Mapping
● Message Mapping
Message Mapping enables to map source message to target message

Syntax: MM_<SourceMessage>_to_<TargetMessage>
EX: MM_MATMAS_to_ProductCategoryReplication

● XSLT Mapping
XSLT Mapping enable to map source message to target message

Syntax: XSLT_<name>
EX: XSLT_RemoveNamespace

1.1.4 Transformation
● Content Modifier
This Step is used to modify content

Syntax: Modify_<Details of modification>

EX: Modify_logHTTPHeader

● Converter
Converts JSON or CSV to XML and vise versa.

Syntax: Convert <fomatt>

EX: Convert JSON To XML

Page 7 of 14 CPI Naming Document www.itelligencegroup.com

7
 ● Dcoder and Encoder
Compression, decompression, encoder and decoder of the message.

Syntax: <ZIP or GZIP Compression/ ZIP or GZIP decompression/ Base64 or MIME Multipart
encoder/ Base64 or MIME Multipart decoder>
EX: ZIP Compression Sales Order Data

● Filter
Filters information by extracting a specific node from the incoming message

Syntax: <Filter> <payload>

EX: Filter Delivery Payload

● Message Digest
Calculates a digest of the payload or parts of it and stores the result in a message header.

Syntax: MD_<Payload>
EX: MD_InvoicePayload

● Scripts
This step is used to create groovy script or Java script to handle complex flows

Syntax:GS_<Objective of script>
JS_< Objective of script>
Ex: GS_formatMessage

1.1.5 Call

1.1.5.1 External Call

● Send: To connect to external system in between the process steps

Send <external process>>

EX: Send Mail

● Request Reply: For sunchronous call with external system.

RequestReply<Process>>
EX: RequestReply Account Details

● Content Enricher: To enrich the payload with other payload.

ContentEnricher <Payload> and <Payload2>

EX: ContentEnricher acoount and service

Page 8 of 14 CPI Naming Document www.itelligencegroup.com

8
 1.1.5.2 Local Call

● Process Call:

Add a call process step to execute steps defined under the local integration process pool

ProcessCall <Local Integration Process>

EX: ProcessCall Read B2BUnit

● Looping Process Call:

Add a process call step to repeatedly execute steps defined in a local integration process

LoopingProcessCall <Local Integration Process>

EX: LoopingProcessCall

3.3.7 Routing
● Aggregator: Aggregates several incoming message to a single one

EX: Aggregator account and employee

● Gather: Define the Aggregation Strategy. Supports various formatts.

EX: Gather account and employee

● Join: Sends multiple incoming message to a single outgoing path.

EX: Join Payload1 Payload2

● Multicast: Sends same message to more than one path.

o Sequential MultiCast: Sends same message to more than one path in defined
sequence.
EX: SequentialMultiCast Header LineItem

o Parallel MultiCast: Sends same message to more than one path in parallel.
EX: ParallelMultiCase OrderDetails

● Router: Exclusive decision and merging.

EX: Router verify GroupCode

● Splitter: Breaks down a composite message into a series of individual messages

o Tar Splitter: Breaks down a tar file into individual messages

o General Splitter: Breaks down a message into individual messages keeping the
encapsulating elements

Page 9 of 14 CPI Naming Document www.itelligencegroup.com

9
 o Ierating Splitter: Breaks down a message into individual messages without
encapsulating elements

o IDOC Splitter: Breaks down a composite message in to a series of individual

messages

o Zip Splitter: Breaks down a zip file into individual messages

o PKCS#7/CMS Splitter: Breaks down a composite message in to a series of

individual messages

Syntax: <Tar/General/Iterating/IDOC/ZIP/PKCS#7/CMS> Splitter <Payload>

EX: GeneralSplitter OrderDetails
IteratingSplitter MATMAS etc

3.3.8 Security
● Decryptor: Decrypts the encrypted data contained in the body of the incoming message
o PKCS7 Decryptor
o PGP Decryptor

EX: PKCS7 Decryptor Employee etc

● Encryptor: Encrypts the content of the incoming message body

o PKCS7 Encryptor
o PGP Encryptor

EX: PKCS7 Encryptor Employee etc

● Signer: Digitally signs the message content

o Simple Signer: Sign an incoming Message
o PKCS7 Signer: The PKCS#7/CMS signer allows you to sign the messages with one or
more private keys
o XML Digital Signer: Create digital signature for a XML message

EX: Simple Signer Payment

● Verifier: Verifies the signature of the message content

o PKCS7 Signature Verifer: Verifies that the signed message is authentic
o XML Signature Verifier: XML Validate the XML signature contained in the incoming
message body

EX: XML Verifier Payment

Page 10 of 14 CPI Naming Document www.itelligencegroup.com

10
 3.3.9 Persistence
● Data Store Operations: Performs operations with data store
o Select, Delete, Get and Write

EX: Select Employee Data etc.

● Persist: Stores message payload at a process step

EX: Persist sales Data

● Write Variables: Define Variable to store the payload.

EX: Write Variable Account Details

3.3.10 XML Validator

Validation of XML Documents

EX: XML Validator PO

3.3.11 Value Mapping

Value Mapping is used to map source system values to target system values.

Syntax: VM_<Source Agency>_to_<Target Agency>_<functionality>

EX: VM_S4HANA_to_ HYBRISMARKETING_ SALUTATION

3.3.12 Communication Channel

Communication Channel is used to convert Source message protocols into target message
protocols.
Syntax: < Adapter Type>_<Sender/Receiver>_<System>_<Interface Short Description>
EX: ODATA_SND_S4HANA_BusinessPartnerReplication

4. IFLOW Look and Feel Guidelines

The following guidelines should be used to design integration flow layout for simplifying
maintenance.
Page 11 of 14 CPI Naming Document www.itelligencegroup.com
11
 ● Try to avoid overlapping sequence flows
● Avoid kinks (or confusing twist/turns) in the sequence and message flow connectors
– try to keep them as straight as possible.
● Avoid overlapping process steps – in case you need many process steps,
try expanding the canvas and arrange the process steps neatly.
● Modularize wherever possible – in case of complex logics, try to break it down into
small, easy to understand modules. Move the logic of each module into a sub-
process. Name the sub-process appropriately to describe the module’s operation.
● Do not mix multiple transformations in a single script or sub-process – one sub-
process should only contain the logic for one function.
● Do not assign the whole XML message to a header or a property unless necessary.
Clear it once done.
● Always keep the flow direction from left to right. The sender always comes on the
left and the receiver on right.
● It is recommended to limit the total number of steps in integration flow to 10 and use
the steps local integration process to modularize complex integration flows for
reducing TCO and ease of maintenance.
● Limit Step types to 10 for better readability
●
5. Externalize Configuration Parameters
Externalizing parameters is useful when the integration content should be used across multiple
landscapes, where the endpoints of the integration flow can vary in each landscape. This
method helps you to declare a parameter as a variable entity to allow you to customize the
parameters on the sender and receiver side with a single change in landscape. Partial
Parameterization enables to change part of a field rather than the entire field. This variable
entity of the field is entered within curly braces.

EX: Receiver system address:

Parameter: {{Receiver Address}} Value – URL address

6. Restarting Messages
In Cloud Platform Integration, when message processing fails, there is no means to retry the
message processing automatically by the system out-of-the-box for most of the adapters. It
must be resent from the source system. The following sections provide alternative approaches.

6.3 AS2, JMS, SF Adapters

For the AS2, JMS sender channel, we have Retry Handling, and the following parameters can
be set in the channel configuration:

For the SuccessFactors adapter, it has a parameter called “Retry on Failure” which enables the
adapter to retry connecting to SuccessFactors system in case of any network issues. The
adapter tries to re-establish connection every 3 minutes, for a maximum of 5 times by default

Page 12 of 14 CPI Naming Document www.itelligencegroup.com

12
 6.4 Other Adapter

We can overcome the standard limitation by designing the integration process to retry only
failed messages using CPI JMS Adapter or Data Store and deliver them only to the desired
receivers.

● JMS Approach

In many cases integration scenarios have to be decoupled asynchronously between sender and

receiver message processing to ensure that a retry is done from the integration system rather
than the sender system. This can be achieved, for example, by using JMS queues to
temporarily store the messages in the cloud integration system if the receiver system cannot be
reached, and retry them from there.

Useful Links:

https://blogs.sap.com/2017/06/19/cloud-integration-configure-asynchronous-messaging-with-retry-
using-jms-adapter/

https://api.sap.com/package/DesignGuidelinesRelaxDependenciestoExternalComponents?
section=Artifacts

Data Store Approach

The messages are persisted in data store for many days (as configured in the process step – default
being 90 days); or a variable which stays in the database for 400 days after the last access. In this
approach, messages are persisted for pre-defined period in CPI Data Store and automatically
restarted after failures. You can also configure number of retries in a global variable.

https://blogs.sap.com/2019/11/04/sap-cpi-retry-send-failed-asynchronous-messages-based-on-time-
interval/

7. Optimizing Iflow Memory FootPrint

● When your flow has multiple branches, through a multicast or router, ensure that before
ending the branch, you empty or reset all the data that is not required beyond that step.
Unless explicitly reset, the data will be kept in memory until the process ends. The property
and headers automatically reset when the context switches to the next branch; however,
the body and variables continue to hold the data. Release all unwanted data before exiting
the branch.
● Empty the header and property maps after you are done with retrieving all the required
information in the script. To access a property or header in a script, you retrieve the entire
list into a variable and then get the required property/header value. There are cases when
there are many properties/headers or there is large amount of data assigned to any
property/header.

Page 13 of 14 CPI Naming Document www.itelligencegroup.com

13
 ● Avoid multicasting wherever possible – it multiplies the data and stores that in the
memory.
● When using XPATHs, try to use absolute path as much as possible; relative XPATH
expressions are very expensive.
● SAX/STAX parsers are very helpful when working with huge datasets as they stream the
XML and do not load the entire XML in memory. Moving the XML back and forth may be
expensive with these parsers.
● Keep the tracing turned off unless it is required for troubleshooting. Writing trace adds a
lot of overhead on performance as every stage of message processing is persisted along
with the message at every step

8. Error Handling

There are integration scenarios where the number of error cases exceed the success cases. It isn’t
required to generate alerts for all error cases require alerts but we generally do require that the
right level of error information is captured and logged to aid in troubleshooting.

We should design integrations to handle errors gracefully and provide mechanisms to handle
below errors for every interface:

Errors are broadly classified into two types:

1. Recoverable Errors – Recoverable errors are the errors that Client programs can recover
from to take appropriate alternate execution paths. Such errors are the result of failure to meet
a business rule.

2. Non-Recoverable errors – These are the errors that Client programs cannot recover from. This
kind of errors are result of some unexpected errors during runtime such as programming errors
such null pointers, resources not available etc. This should be minimized by testing NFR(s)
and boundary conditions during testing phases and by identifying it from continuous service
improvement analysis

Page 14 of 14 CPI Naming Document www.itelligencegroup.com

14