Skip to Content
Technical Articles

Comprehensive SAP CPI Guide for Standards & Best Practices

** Disclaimer:While all of you can use these best practices on the projects after evaluating it is relevant for your customer or usecase, you shouldn’t cut and paste this best practice blog as the best practices developed by your organization **

*These best practices are not “One Size that fits all customers” and hence you need to evaluate whether it works for your customer and your use case”

1 Introduction

1.1   Objective

The scope of this blog is to set the development guidelines for Integration developers who will use SAP Cloud Platform Integration Service to develop integrations for Client consistently across the projects in Client.

This blog is an end to end comprehensive CPI standards & best practices that is just an extension of SAP guidelines and insights shared by amazing CPI developers across the world coupled with our real world experience of many projects and recent experience of distributing millions of API messages via CPI.This is a living document which will evolve over the period with our learnings.

1.2   Intended Audience

Integration architect designers and developers who are already little familiar with SAP CPI as an Integration tool can easily infer and implement the guidelines in this book.

2 Architecture

2.1 SAP Integration Strategy for Cloud Transformation

SAP provides many apps for integrating on premise and cloud applications but we should be following SAP strategic direction when advising clients on which integration app we need to procure based on Integration Domain and Use Case Pattern. Please don’t miss my blog on Do’s and Dont’s on SAP Cloud projects.

Useful Links:

Please refer to SAP CIO Guide below for understanding SAP Strategic Direction.

Migration Approach of SAP PI/XI to SAP PO (Hana Enterprise Cloud/On-Premise) or Cloud Platform Integration Apps or API Management

Explosion of SAP Cloud: Data/Integration SAP Tool Procurement Guidelines to Migrate/Integrate data into Cloud from/to On-Premise Systems

Do’s and Don’ts of SAP CLOUD PROJECTS – Moving from ASAP Methodology to Agile SAP Activate

 SAP CPI Tutorials

2.2  Licensing Model

The following table can be used as a guideline for choosing the right licensing model and you can use scp license estimator to determine the approximate costs for your requirements.

Component Use Case Licensing Model
SAP CPI Process Integration It is used when we need to transfer messages between multiple systems and orchestrate processes between different systems that doesn’t need EDI integration. Cloud Credit & Subscription
SAP CPI Data Integration

It is used when we need to extract large volume of data from on premise/cloud systems and transform before loading data during data migration into cloud systems or into Big Data lakes/data ware houses or IBP system.

However, we have to carefully evaluate this option as SAP Data Hub and SAP HANA Smart Data Connectors is the future strategic direction of SAP.

Subscription Only
SAP CPI Enterprise Edition

A bundle that includes process integration, data integration, application programming interface (API) management, and Open Data Protocol (Odata) provisioning.

It also includes EDI/ICA license though we still need to pay for X12/EDI XSD libraries on top of SAP CPI enterprise Edition License.

It also contains Integration Content Advisor which can accelerate EDI projects.

Subscription Only

 

2.3   SAP CPI Design Guidelines – API Business Hub Package

It is recommended that every developer should go through the  CPI Cloud Exemplar package  and SAP CPI Integration Design Guidelines and SAP CPI Troubleshooting Tips templates published by SAP to constantly and share the best practices on Cloud Integration in the form of FAQs, do’s and don’ts, code snippets, integration flow templates, how-to guides, troubleshooting tips, etc. 

The packages  CPI Cloud Exemplar package  and SAP CPI Integration Design Guidelines and SAP CPI Troubleshooting Tips  includes not only detailed documentation or FAQs, but also working samples and templates that help you:

  • Understand how you can perform basic tasks
  • Identify the common pitfalls while designing your flow
  • Discover optimal ways of modelling an integration flow
  • Determine techniques to achieve better memory footprint
  • Define what to keep in mind in order to create performant integration flows
  • Solve commonly known errors with ready solution

3 Development Guidelines

3.1   Development Tool Strategy

SAP CPI offers development in two different environments namely eclipse and Web IDE.

3.1.1 Eclipse

Eclipse is java based IDE for software development which needs to install in developer machine.  CPI extensions are required to be added in eclipse software.

3.1.2 CPI Web UI

Web UI is SAP’s own browser based platform for the CPI development.

3.1.3 Recommended Development Tool

As per the SAP roadmap, eclipse based development tool will be obsolete soon and hence all the CPI development should be carried out in CPI Web UI where ever possible and integration flows should be imported from Eclipse to CPI Web UI if developer used Eclipse due to any current limitations of Web UI.

3.2   Naming Conventions

The table below summarizes the naming convention to be adopted in Client for SAP CPI development.

Object Type Definition Convention Syntax Example
Custom Package Name A collection of related APIs or services, belonging to one product or product area, packaged and delivered together. Name: 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 in the example.

Point to Point:

Name: SAP Hybris Cloud for Customer Integration with SAP Hybris Marketing.

If you are developing generic interfaces like EDI or API(S)  and you don’t want to tie IFLOWS to a specific system then use naming conventions like below.

Generic:

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

Ex:EDI Integration Templates for SAP Cloud Platform Integration Advisor

Ex: EDI Integration Templates for Successfactors

Ex: S4 HANA API(S)

Country Specific

If you are developing  package specific to country like tax interfaces then I would follow:

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

Ex: Payroll e-Filing of Employees’ Payments and Deductions for UK HMRC

Point to Point:

Technical Name: Z_<Sending System Name>_Integration_ With_<Receiving System Name>

Generic:

Z_<Business Object/Domain Description><Sender or Reciever System>

Country Specific:

Z_<Business Object/Domain Description><Country><Sender> OR/AND <Reciever System>

Point to Point :

Technical Name: Z_Salesforce_Integration_With_SAPC4HANA

Generic:

Z_SupplyChain_S4HANAAPI

Country Specific

Z_PAYROLL_UK_HMRC

Vendor : <Organisation Name> Vendor Name: Wales & East Utilities
Version: The version number should always be 1.0.0 when the package is productionized and should be incremented by +1.0.0 or 1.1.0 or 1.0.1 for every transport based on whether change is major or minor or micro. Version : 1.0.0(when productionised) ,1.0.1(After micro change of first transport of artefact) on whether change is major or minor or micro.
Overview: The full long description of the package describing the usage, functionality and goal of the package. Overview: This integration package enables you to integrate business processes between SAP Hybris Marketing or S/4HANA Cloud Marketing Edition and SAP Hybris Cloud for Customer. The integration scope includes a call center scenario, the creation of leads in SAP Cloud for Customer from a campaign in SAP Hybris Marketing and the replication of accounts, contacts, individual customers, leads and opportunities from SAP Hybris Cloud for Customer to SAP Hybris Marketing.
TAGS: The package should be tagged with country and line of business and industry using relevant dropdowns and a common keyword search should be based on most commonly used in package short description or Interface ID(S) of package. Country:UK
Line of Business: Metering
Industry : Oil and Gas
Keyword : Customer, NI000001
Product : SAP Marketing CLOUD, SAP C/4 HANA
Project Name : “Wales and West Metering DTE
Documents: The API / Interface Documentation should be linked for each interface/artefact in the package and name should match exactly with IFLOW Name. Create Planning Orders
iFlow Integration flow is a BPMN-based model that is executable by orchestration middleware <Interface Action i.eSend/Recieve/Create/Publish/Update/Delete/Replicate/Insert/Maintain><Interface Business Object ShortDescription> Create Planning Orders
Content Modifier This Step is used to modify content Modify_<Details of modification>  Modify_logHTTPHeader
Script This step is used to create groovy script to handle complex flows SC_<Objective of script>   SC_formatMessage
Message Mapping Message Mapping enables to map source message to target message MM_<SourceMessage>_to_<TargetMessage>  MM_MATMAS_to_ProductCategoryReplication
Sender Sender Endpoint S_<Sender Partner>  S_C4HANA
Receiver Receiver Endpoint R_<Receiver Partner>  SIEBEL
Value Mapping Value Mapping is used to map source system values to target system values. VM_<Source Agency>_to_<Target Agency>_<FieldName>  VM_C4HANA_to_ HYBRISMARKETING_SALUTATION
Communication Channel Communication Channel is used to convert Source message protocols into target message protocols < Adapter Type>_<Sender/Receiver>_<BusinessSystem>_<Interface Short Description>  ODATA_Marketing Cloud_C4HANA_BusinessPartnerReplication
Local Process Flow Local Process flows are used to modularise the complex integration flow <Description of the objective that local process flow is designed to achieve> Successfactors_OData_Paging

3.3  IFLOW Description Guidelines

3.3.1 Package Short Description Guidelines

This is the text that is displayed on your package tile in the hub and is very important because it is the first description that support team may use to identify and discover existing interfaces to promote reusability.

3.3.2 Package Overview Description Guidelines

This is a longer description, which can be viewed on the Overview tab of the package. You need to provide high level overview detail about the package and its functionality to make it friendlier for support teams.

3.3.3 General Step Description Guidelines

The step names inside the Integration flow and descriptions in the Integration Flow should be meaningful in the given context. It should follow the below guidelines in addition to the English grammar rules:

    • Start description sentences with a capital, end with a period.
    • Avoid describing low level implementation details and dependencies unless they are important for usage.
    • Avoid repetitions and misplacements of information: for example, don’t write about parameters in an operation description
    • Describe the objective of a step or the task that is executed by a step in the integration flow in plain english.

 3.4 IFLOW Look and Feel Guidelines

The following guidelines should be used to design integration flow layout for simplifying maintenance.

      • 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

Useful Links:

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

3.5 IFLOW Modularisation

Complex IFLOWS can be modularized using the following mechanisms in SAP CPI:

    • SAP CPI Process Direct Adapter – Modularize multiple IFLOWS
    • SAP CPI Local Process Step – Modularize single IFLOW

Useful Links:

https://blogs.sap.com/2018/02/14/processdirect-adapter/

https://blogs.sap.com/2016/10/03/hci-pi-calling-local-integration-process-from-the-main-integration-process/

3.6 Concurrent Development

The following practice should be followed when multiple developers across different SAP Cloud Integration development projects to ensure that other developers don’t modify packages and artefacts of other developers.

  • For Version, enter “WIP” to indicate that the package is work in progress. Enter your name/team name in the Owned By text box to indicate who should the other team/developer contact if they wish to change this package’s artefact.
  • It will help developers to coordinate and contact on how to edit the artefacts in the package. Once the edit is done, then save the package as a version. This will change the version of the package from WIP to the next version number.

4 Peformance Guidelines for Large Volumes

The Bulk Extracts should be avoided wherever possible. Process design must leverage change pointers and deltas rather than repeated bulk transfer. We must not be transmitting data that is not needed. The transmission of large volumes of data will have a significant performance impact on Client and External Partner computing systems, networks and thus the end users.

Hence interface design has to optimize the data transfer , we should also look at alternative tools like sap data services or cpi data services or smart data integration if you have to extract data from multiple source systems and transform and load data into target systems.

4.1 File Adapters Performance Guidelines

In case of huge files, below strategy should be used

  • Check with participating partner to accommodate splitting message into smaller chunks before hitting CPI or use the approaches listed in section 4.3 and 4.4 for enabling multiple node and parallel processing, or the use of delta messages.
  • We need to ensure that the locking mechanisms are built-in the target applications when we are processing large volumes of data.
  • You can ask SAP to increase the nodes and memory to pick and process files in parallel by raising SAP incident on SAP CPI system.

4.1.1 Processing High Volume Concurrent Files

You should change Max. Messages per Poll from value 20 to 1 or 2 when you want the files to be fetched by several nodes.

4.2 REST API(S) Performance Guidelines

API(S) generally are designed for low volumes. We should use other adapters like JMS, Files, JDBC etc for large volumes or CPI Data Services/Smart Data Integration if we have to extract, transform and distribute large amount of data between many systems.

The following are the performance guidelines to optimize IFLOW when you are integrating systems using API endpoints.

Session Reuse

Creating login session is a resource demanding task. Instead of creating a session for each HTTP transaction or each page of paginated data, reuse login sessions.

In reality, a user session is created for each API call. Creating user session is a resource-intensive process. Large number of API calls will increase the stress on the server and drastically slow down response time. To address this, you can enable session on the integration flow to reuse the session. It is described in the below blog.

Useful Links:

https://blogs.sap.com/2017/07/17/cloud-integration-how-to-configure-session-handling-in-integration-flow/

Pagination: 

Pagination is used when we have to fetch large volumes of data from the backend systems i,e it is a feature implemented in SAP Cloud Platform Integration to be able to process large requests in pages. We need to optimize the size of pagination i.e number of records to be fetched in a single call based on API but in general it is 1000 to 5000 records per call.

Useful Links:

https://blogs.sap.com/2017/04/14/cloud-integration-processing-successfactor-records-in-batches/

https://blogs.sap.com/2019/01/16/sap-cloud-platform-integration-enhanced-pagination-in-successfactors-odata-v2-outbound-connector/

https://help.sap.com/viewer/d599f15995d348a1b45ba5603e2aba9b/1811/en-US/93ef8631b93b4d58be235b047dae2b57.html#loio93ef8631b93b4d58be235b047dae2b5

API Timeout: 

Tune your client wait time to match the system wait time, your client should be set to wait a reasonable amount of time before timing out. Complex operations can take as long as 10 minutes and our network and servers will continue to process a transaction for that long.

Useful Links:

https://apps.support.sap.com/sap/support/knowledge/preview/en/2499167

API Retry Mechanism: 

Implement your retry logic properly, Retry logic can help to recover transactions that failed due to internet connectivity or backend server issues, but retry must be done with care based on the type of HTTP error. Only return a maximum number 5 of times before abandoning your task.

OData API Performance Optimization Recommendations:

    • Tune your batch requests into proper sizes, The OData API can return a maximum number of 1000 records in a single page. You should tune your batch sizes to be as large as possible. For more complex transactions, you may need to decrease the size to avoid HTTP timeouts.
    • Use batch or $filter to get multiple records instead of pulling many records one at a time
    • Avoid large $expand statements, the $expand statement can be used to request master-detail data. However, using $expand to join a large number of tables can lead to poor performance. SAP recommends that you first fetch master by batch and get detail via content enricher or expand.
    • Do not query properties and expand entities you do not need or use.

Useful Links:

https://blogs.sap.com/2017/05/10/batch-operation-in-odata-v2-adapter-in-sap-cloud-platform-integration/

https://blogs.sap.com/2017/08/22/handling-large-data-with-sap-cloud-platform-integration-odata-v2-adapter/

https://blogs.sap.com/2017/11/08/batch-request-with-multiple-operations-on-multiple-entity-sets-in-sap-cloud-platform-integration-odata-adapter/

https://blogs.sap.com/2018/08/13/sap-cloud-platform-integration-odata-v2-function-import/

https://blogs.sap.com/2018/04/10/sap-cloud-platform-integration-odata-v2-query-wizard 

4.3 Parallel Processing – Splitter

We should look at options of parallelizing the process within a HCI tenant for optimizing interface performance. At the step “Splitter”, you can activate parallel processing. At this step, the content is split in packages with 1000 entries per package. This process can be parallelized by activating the checkbox Parallel Processing. The splitter step also has concurrency which can limit the number of concurrent parallel processes that CPI can trigger in the SAP destination systems.

4.4 Performance Optimization via Several Nodes

We should request SAP to provide additional nodes via support ticket process well in advance to ensure that interface non-functional requirements of performance critical interfaces are met. Please provide the Interface non-functional requirements in the ticket for SAP to allocate the resources appropriately.

4.5 Performance Guidelines for File to OData Loads

POST: It is recommended to split the file at 100k records each and split 100k file recording into 2000 to 5002 packets with parallel processing and streaming enabled in the   splitter step before calling OData Endpoint to optimise performance.

File Size Object Name Splitter Grouping Performance Throughput
100K Customer 1000 500k records per hour(Post)
100k Interactions 5002 1 million records per hour(Post)

Get: 

It is recommended to read data in 5k packets and write into file without append mode i.e split page data in multiple files.
OData Page Limit is 5000 which means you will get bad request if the page size is more than 4999.

OData Page Size Customer Read Performance File Configuration
1000 1 Million Per hour Append where all records are appended to same file
4900 3 Million Per hour 5002 records per file

5 Externalize Configuration Parameters

Environment specific parameters for communication channel should always be externalised instead of using static URL(S)/Authentication details for easier and central management and maintenance. 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.

Useful Links:

https://blogs.sap.com/2017/06/20/externalizing-parameters-using-sap-cloud-platform-integrations-web-application/

https://blogs.sap.com/2018/08/01/sap-cpi-externalizing-a-parameter-in-content-modifier-from-web-gui/

6 Modularising Scripts

It is recommended to use Groovy scripts rather than java scripts unless there is a good reason on why we can’t use groovy script to fulfil a functionality.

The scripts should be created centrally in a central reusable shared library repository for easier maintenance and handler methods for each integration flow to invoke the script inside the integration flow to minimize the maintenance costs. Scripts should be commented for each logical processing block.

While it is very easy to create Groovy scripts in CPI, when the integration flow becomes more complex, inevitably there may be occasions where the same logic is repeated in different scripts. This presents an opportunity to modularise and simplify the development. One approach to perform such modularisation is by using Plain Old Groovy Objects (POGO), which are the Groovy equivalent of POJO. In short, they are just Groovy classes as opposed to the Groovy scripts that are typically generated by the CPI development tools.

Useful Links:

https://blogs.sap.com/2018/03/15/modularising-cpi-groovy-scripts-using-pogo/ 

7 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. SAP Cloud Platform Integration does not support Quality of Service (QoS) Exactly Once (EO) as a standard feature, however it is on the roadmap. The following sections provide alternative approaches.

7.1 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.

7.2 Other Adapters

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.

Useful Links:

https://blogs.sap.com/2016/05/11/exactly-once-in-sap-hana-cloud-integration/

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

https://blogs.sap.com/2018/01/16/sap-cpi-exactly-once-with-sequencing/

8   Optimizing IFlow Memory Footprint

  1. 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.
  2. 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.
  3. Avoid multicasting wherever possible – it multiplies the data and stores that in the memory.
  4. Use of Byte instead of String reduces the memory consumption, unless you want to process the message as a string in the next step.
    Make sure that the step after the mapping, especially a script can take in a byte data.
  5. Global variables makes use of headers to persist data in DB. Memory  is allocated to these headers even after the flow ends. In case the header is holding a large amount of data, it may fail the iflow processing. It is important to release the memory allocated to the header (having the same name as the global variable) before the iflow exits. This however cannot be performed from a content modifier – it will need to be done via a script.
  6. Local variables are alive even after the iflow execution is over. Even though the local variable is visible only to the iflow, it is important to note that the memory allocated to the variable is not released when the iflow execution is over. It is important to reset the local variable in the beginning of the flow to avoid any values getting used from the previous flow. It is specifically relevant when the previous flow ended abruptly and the variable may be holding invalid data. For better memory management, it also makes sense to reset the local variables before exiting the iflow.
  7. When using XPATHs, try to use absolute path as much as possible; relative XPATH expressions are very expensive.
  8. 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.
  9.  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.

9 Centralized Reusable Value Mapping API

Value mapping needs to be maintained and created in a central repository i.e in one value mapping package for promoting reusability and should be accessed using a script for the source values in the integration flow to map it to the target value. Value maps can be accessed programmatically from a script with the help of the getMappedValue api of the ValueMappingApi class.

Useful Links:

Value Mapping Mass Uploads

           Autogenerate Value Mapping XML

Dynamic Value Mapping

10 Operational Guidelines

10.1 Tenant Landscape

SAP provides 2 tenants by default for the test and production landscape.It will  work for small to medium size clients who doesn’t do heavy customization of SAP Cloud product and who have a small set of interfaces.

I recommend a 3 tier (Development where you test bespoke development, Test & Production Client) architecture for large clients who has more than 40 complex interfaces that integrate into more than 10 systems where the SAP Cloud Business Suites is implemented with high degree of customization.

10.2 Transport Mechanism & Naming Conventions

It is recommended to use CTS+ transports for transporting objects from one environment into another environment. CTS+ Transport should contain package name and version number and change description for each transport for customers with complex integration landscape and who has solution manager in the to-be landscape. Customers can evaluate SCP TMS and FIGAF for small to medium complexity integration landscape or if customers don’t have solution manager on roadmap.

CPI Transport Naming Conventions : <CR Number> <CR Description><Package Name/Artefact Name> <Version Number>

Useful Links:

https://blogs.sap.com/2018/04/10/content-transport-using-cts-cloud-integration-part-1/

https://blogs.sap.com/2018/04/10/content-transport-using-cts-cloud-integration-part-2/

https://blogs.sap.com/2018/03/15/transport-integration-content-across-tenants-using-the-transport-management-service-released-in-beta/

10.3 User Roles

The users are given access to SAP Cloud Platform Integration only after obtaining S user from Client Basis Team. It is recommended to either assign a custom or standard authorisation groups of roles (also referred to as authorization groups) to the users.

There is a set of predefined authorization groups (beginning with AuthGroup) that cover the different tasks associated with an integration project. For service users, you need to assign to the associated technical user the specific role ESBmessaging.send. In that case, as Application choose the one which ends with iflmap (corresponding to a runtime node of the cluster which processes the message).

Useful Links:

Standard Integration Role Persona Templates

10.4  Security

Interface should follow the security standards specified by the organization. SAP API management or API management should be used when integrating user facing web or mobile applications with the on premise or cloud systems and sharing data to multiple systems or users via API(S) unless there is a good reason on why we can’t use API management for the project and it should be agreed prior in solution architecture or discovery project phase.

10.4.1 Transport Level Security

Security artefacts like user credentials, SSH known host (for SFTP connections) can be deployed in CPI dashboard. Only S user with admin access can deploy the artefacts. SAP CPI supports both basic (user/password) and certificate,OAuth/Public Key based authentication. To enable maximum security, it is advised to use certificate/OAuth based authentication in productive environment.

Useful Links:

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

https://blogs.sap.com/2018/03/12/part-1-secure-connectivity-oauth-to-sap-cloud-platform-integration/

https://blogs.sap.com/2018/03/12/part-2-secure-connectivity-oauth-to-sap-cloud-platform-integration/

https://blogs.sap.com/2017/06/05/cloud-integration-how-to-setup-secure-http-inbound-connection-with-client-certificates/

https://blogs.sap.com/2018/09/06/hci-client-certificate-authorization/

10.4.2 Message Level Security

SAP CPI provides out of the box options for message level security and it has to be used if the client requires to encrypt or sign the data payload. Please check message  security table for further details on pro’s and con’s of message security policies.

Useful Links:

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

https://blogs.sap.com/2018/10/11/hci-encrypt-with-pgp/

https://blogs.sap.com/2015/12/16/hci-using-pgp-message-level-security-in-hci/

https://blogs.sap.com/2018/12/24/how-to-encryptdecrypt-xml-payload-with-aes256-cbc-and-rsa-algorithm-in-sap-cpi/

10.4.3 Security Algorithms

Some algorithms (like MD2, MD5, DES or RC4) are still supported for legacy reasons, but they are not considered secure any more. We recommend that you check the official recommendations from National Institute of Standards and Technology (NIST) or European Union Agency for Network and Information Security (ENISA) for advice on algorithms.

Useful Links:

https://blogs.sap.com/2015/12/22/sap-hci-security-artifact-checklist/#

11 Monitoring & Tracing the Messages

SAP CPI supports out of box monitoring capabilities and provides comprehensive auditing of the processed message at each level of its life cycle for support teams to resolve issues quickly.

It is recommended to log the payload tracing only in test systems and payload tracing should be activated in production system based on logging configuration of the IFLOW for optimizing system performance unless it is required form audit perspective.

Useful Links:

https://blogs.sap.com/2018/11/22/message-processing-in-the-cpi-web-application-with-the-updated-run-steps-view/

https://blogs.sap.com/2018/03/13/troubleshooting-message-processing-in-the-cpi-web-application/

https://blogs.sap.com/2018/08/23/cloud-integration-enabling-tracing-of-exchange-properties-in-the-message-processing-log-viewer/

https://blogs.sap.com/2016/04/29/monitoring-your-integration-flows/

How to trace message contents in CPI Web Tooling

Message Processing Log: Adapter Tracing

CPI Monitoring OData API

Tracing in Eclipse

12 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.

12.1 Types of Errors

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.

Useful Links:

https://api.sap.com/package/DesignGuidelinesHandleErrors?section=Overview

12.2 Invoke Business Friendly Exception API

SAP CPI provides exception sub flow to raise errors during iflow runtime. It is recommended that we should raise errors using the Generic Exception API Format across all CPI interfaces into SFTP server or HANA tables for helping support teams to quick assess the impact of the interface failure and resolve incident quickly.

Field Description Example
Message ID This field contains the ID of the message 5576767677SDFDFDDF
Interface ID This field contains the interface ID of the message which will reference to interface metadata table which has details like description, criticality, contact details etc BS100134
Exception Point Step in the iFlow where the error occurred Mapping, Adpater call etc
Exception Source System where the error occured CPI, C4HANA,S4HANA etc
Exception Category This field will define the category of exception. Please see Exception Category section below for definitions of each category. Business, System,Technical etc
Error Code This field will contain the appropriate HTTP error codes. Please see the definitions of each code in the error code section. 500,200 etc
Error Description This field will contain the detailed description of the error message. Exception.Stacktrace i.e Message Log
Date/Time Stamp Date and Time of the Error YYYYMMDDThh:mm:ss

12.3 Customizing Message Log with Business Friendly Info

Integration flows should record business friendly information into standard log entries by using script to provide more contextual information to assess business impact.

The following script is an example on how you can write integration flow specific keys in the message log: Ex: Purchase Order Number, Customer Number.

Custom headers are added to the log using the function addCustomHeaderProperty on the messageLog object:

Signature: void addCustomHeaderProperty(String Name, String Value);

Sample: messageLog.addCustomHeaderProperty(“MyCustomeHeader”,”MyValue”); 

Useful Links:

https://blogs.sap.com/2015/01/12/blog-4-modelling-exceptions-in-integration-flows-hci-pi/

https://blogs.sap.com/2018/10/17/cloud-integration-usage-of-general-and-iterating-splitter-with-exception-handling/

https://blogs.sap.com/2018/06/08/how-to-tackle-disguised-errors-in-your-integration-flows/

12.4 Archiving Error Files in CPI SFTP

SAP CPI doesn’t provide out of the box capability to move the error files automatically into an exception folder which will cause issues as the next polling interval will pick the error file and process it again indefinitely which is not ideal for every business scenario.

The following process should be followed to avoid automatic processing of failed files.

Useful Links:

https://blogs.sap.com/2019/07/30/dynamic-setting-of-archive-directory-for-post-processing-in-sftp-sender-adapter/

https://blogs.sap.com/2019/10/31/data-migration-cpi-customer-flow-design-specification-robust-audit-error-handling/

13   Alerts

Alerts should be generated only for business critical interfaces.

For all the custom iflows, it is recommended to capture runtime errors and consume in exception sub-flow. Exception sub-flow will then either send email alerts or log them in CPI monitoring tool or central monitoring tool using an CPI OData Monitoring API based on criticality and severity of the error.

1.Ensure alerts are tied to a schedule
2.Ensure alerts are actionable by providing insightful information
3.Set Priorities! Classify Your Alerts Based on Importance
4.Route alerts to right teams
5.Create a Wiki Process for How Alerts are Resolved

Useful Links:

https://blogs.sap.com/2017/06/15/qforit-error-alerting-for-sap-cloud-platform-integration/

https://apps.support.sap.com/sap/support/knowledge/preview/en/2472429

14 External Monitoring Tool Integration

Cloud Platform Integration Service also provides out of the box monitoring API CPI Monitoring OData API  and SAP Open Connectors to integrate with central monitoring tool chosen by Client Ex: Solution Manager, Service Now, Jira, Slack, Elastic Stack, Dyntrace.

Useful Links:

RealCore CPI Dashboard

The RealCore CPI Dashboard is a lightweight free IFlow-based tool that you can install which allows you to monitor your CPI instance (including system parameters like CPU-, RAM- and disk usage), view passwords and log files as also setup an mail-based alerting.

15 Enhancing SAP Cloud Standard Content

Before starting any development, you must search the integration content catalogue on SAP API Business Hub to check if there is any pre-packaged content or the content you can reuse and enhance to fulfil the customer integration requirement.

  1. If standard content exists then it should be copied to the Client work space.
  2. It is also advised to use “configure-only” approach for standard content but edited only in unavoidable circumstances as there are no auto-updates for modified content.
  3. If you wish to add custom code to the pre-delivered standard content without falling out of the content update contract – request the content developer or SAP to include custom flows/exits in the integration flows.
  4. If the content developer or SAP do not agree to change the content, copy the content package twice to your design view. Ensure that you keep one copy untouched.
  5. Add all your customized changes to the other copy. Whenever a standard update is released by the content developer, update the untouched copy with the latest changes. Then manually merge the custom update to the updated content.
  6. Every change from the content developer is backed by a release note – this gives an idea about what has changed in the content with each release. The customer can then decide if he wants to merge the custom changes manually or standard changes based on whichever is less.

Useful Links:

https://api.sap.com/package/CloudIntegration.LessonsLearnt?section=Overview

15.1 SAP Cloud API Extension  Best Practices

SAP provides two mechanisms i.e side by side or in-app to extend SAP Cloud Business Suites like C4HANA/S4HANA/Successfactors. You can use below table to carefully evaluate which is right mechanism for fulfilling your integration requirement.

Business Scenario Solution Guideline
Extend API Fields to match custom legacy systems for the business process to work Create custom CDS view with additional fields and generate OData API if the fields can’t be derived from other CDS views or OData API(S).
Extend S/4 or C/4 UI with read only Custom Mashup Screen Orchestrate API(S) using SCP Integration and Open Connectors to read data and call it from Launchpad if we need mashup screens to just display information from other systems.
Extend S/4 or C/4 UI with write/read complex Custom Mashup Screen

If data doesn’t needs to be stored in S/4 or C/4 for operational purposes then follow above solution.

If data needs to be stored in S/4 or C/4 for operational purposes then create a custom BO, CDS view and enable OData API(S).

Orchestrate and Join results from different SAP S/4 or C/4 API(S). Ex: Join Shipment and PO/Delivery API(S) together In this case, you can search if there are existing CDS views on SAP API Business Hub and create custom CDS views on top of existing CDS views and expose OData API that CPI can consume.

Useful Links

SAP Cloud Extension Factory

Extensibility Explorer

16 Versioning Integration Flow

The guiding principle to ensure that we release features without breaking existing running scenarios in client systems or in other words we need to make every effort to ensure that the features are always backward compatible especially when we use CPI in multi-country roll out projects. Based on this, new features to components (like flow steps, adapters or pools) are always released through a new version.

The CPI IFLOW will follow the following version management strategy. Each component in SAP Cloud Platform Integration has a version and this version is defined using the paradigm <major>.<minor>.<micro> as depicted below:

FIGAF tool by Daniel Graversen can be used along for CPI version management.

Useful Links: 

https://blogs.sap.com/2017/12/07/versioning-migration-of-components-of-an-integration-flow-in-sap-cloud-platform-integrations-web-application/

https://blogs.sap.com/2016/03/24/standard-hci-version-management-effective-usage-and-review/

17 Deprecating Integration Flow

You can deprecate the package or artefact using below mechanisms:

  1. Delete the package or artefact if no system is using and update the “Change Log of the Package”
  2. Add [Deprecated] as prefix in the short description and in the long description add the link to next version and explain the reason.Additionally,update the “Change Log of the Package”

18 CPI Automated Testing Tools

The biggest challenge in any integration project is not building but test preparation and execution. If client want to optimize the costs of integration projects then we can suggest them to evaluate the below tools to speed up and cut down the costs of integration projects in future.

I am not elaborating details of the tools as it is already done by Raffael Herrmann in his excellent round up blog.

 

 

26 Comments
You must be Logged on to comment or reply to a post.
  • Thanks for the blog – lots of useful information based on real-world experience. Have you had any projects where you (or client) have made use of any of the automated testing tools mentioned in section 18?

    • Hi Malcolm,

       

      We only piloted the tools but not really used in real projects as yet, but we have plans to evaluate them with customers in future. However I think tools would be good as they are developed by SAP gold mentors.

  • Hi Sravya, Its very good blog in CPI with full information, your support to our integration key areas are marvellous, keep up the good work.

    Best Regards

    Venkata Rao .G

  • Hi Sravya Talanki ,

    What a great blog post! Definitely worth a place in my eternal bookmark list. (By the way thanks for linking to my roundup post.)

    I have one question regarding the naming conventions. From where do you got them? Did you/your colleagues create them on your own or is there a source/official document by SAP? I’m asking because for example the convention to include sender and receiver name into the packet name doesn’t make sense anytime from my perspective. If you set up a project for electronic purchases, and you have 20 vendor where you like to order, you would result in 20 packages (Z_ERP_to_VendorX…). I think this isn’t really efficient when it comes to transporting or maintenance.

    I think it makes more sense to create packages (unrespectively by the receiver systems) for interfaces that belong to the same topic/project.

    Best regards,

    Raffael

  • Hi Raffael,

    Thanks, your blog on round up is equally great as well!

    Naming convention is developed by us but it is in line with how SAP names their packages EX: SAP Commerce Cloud Integration with S/4 HANA. Please refer partner content sap guidelines here https://help.sap.com/viewer/4fb3aee633a84254a48d3f8c3b5c5364/Cloud/en-US/b1088f20d18046e5916b5ba359e08ef9.html.

     

    Yours is a good question but if you think something is not specific to a particular system , I will follow naming conventions like EDI To SAP etc Example: EDI Integration Templates for e-commerce customers/Integration Content Advisor or like how SAP packages API(S) i.e S4 HANA API(s) etc.

     

    I don’t think you will have many scenarios where everything is generic and ofcourse you have to balance between too many packages or one complex single package.

     

    The key is some one who doesn’t know your integration has to be able to find it without lot of digging. 

     

    Ex: If I like to find if there is a customer interface as out of the box interface for integrating SAP commerce cloud with SAP marketing cloud then searching the package “SAP commerce cloud Integration with SAP marketing cloud” is more easier and helpful rather than digging down all interfaces to find out which interface is moving data between SAP commerce cloud and sap marketing cloud.

     

    • Hi Sravya Talanki ,

      thanks for your answer. I see your point and understand your examples. If one wants to quickly find a package which integrates between System A and System B this naming guideline may be useful.

      Nevertheless it can get problematic. Let’s take the following (not unrealistic) example.

      Scenario:

      You have three systems: ERP, CRM, Webshop. You have two project teams: Team Masterdata Replication and Team Webshop Integration.

      Team Masterdata Rep. builds an interface to replicate vendors from ERP to the CRM (IF1). Therefore they create a package “Z_ERP_Integration_With_CRM” and place their interface into it.

      Team Webshop Integration builds two interface: 1) An interface to create a business partner in CRM when a user registers in the Webshop (IF2) and 2) An interface to transfer the order history from ERP to CRM (IF3). Team webshop places IF2 into a package called “Z_Webshop_Integration_With_CRM” and IF3 into the existing package called “Z_ERP_Integration_With_CRM”.

      Now we have the following package constellation:

      • Z_ERP_Integration_With_CRM
        • IF1 (from Team Masterdata Replication)
        • IF3 (from Team Webshop Integration)
      • Z_Webshop_Integration_With_CRM
        • IF2 (from Team Webshop Integration)

      If Team Webshop Integration now wants to go live before Team Master Data Replication, they have to…

      • …transport 1 package (Z_Webshop_Integration_With_CRM)
      • …transport 1 single IFlow (IF3) to avoid that the in-dev object (IF1) from Team Masterdata get’s in production.

      One year later, the webshop will be switched off and all interface shall be decomissioned. Now the CPI team has to go through multiple packages to delete the interfaces.

      Wouldn’t it be easier to follow a convention like: “Z_PKG{000}_{Topic/Project}”. For the above example this would result in:

      • Z_PKG001_ERP_to_CRM_MasterdataReplication
      • Z_PKG002_Webshop_to_Many_Integration

      By this naming scheme, the Team Webshop Integration just had to transport one package. Also later for decomissioning only one package had to be cleaned up.

      What doesn’t work that easy in this scheme is finding all interfaces to one specific system, like ERP. But does one really need it? From my experience in the integration sector employees/consultants usually work project/topic based. So I guess they are more interested in finding a package with all interfaces of a project/business case, than all interfaces to one specific system.

      The only situation where one really wants to find all interfaces of a system, if for example when the IP address of a system changes. But therefore I wouldn’t rely on package naming schemes either way, but use the OData api to find all IFlows which contain a reference to the old IP address of this system.

      Don’t get me wrong – I don’t want to discredit your naming scheme, because I see that it has some advantages. But I think before pushing a naming scheme as best practice into the community, it may be worth to discuss it.

      Hey, Morten Wittrock Eng Swee Yeoh Daniel Graversen Vadim Klimov Ariel Bravo Ayala  – do you like to join the discussion? What naming scheme for packages do you use and why? (What advantages/disadvantages do you see in the naming scheme you used?)

      Kind regards,
      Raffael

       

      • Hi Raffael Herrmann ,

         

        I agree with you on your points and I am always open to hearing great ideas and every solution has pro’s and con’s. By any means, I am not saying everyone has to follow these guidelines. They will have to evalute what works for them as specified clearly in disclaimer.

         

        However, I wouldn’t put PCKG001 OR PCK002 in naming conventions as the numbers are not very user friendly for people who didn’d develop these codes (especially when project teams vanish) and project names may not be that useful after you transition interfaces into BAU as support teams may not always be the people who worked on projects.

         

        After projects are live no one remembers project names, support teams will infact more relate to source and recieving systems .. Ex: I have a  CR that asks me to build an interface between A and B, it is easier for me to go and search in a specific package and evaluate whether there is any reusable interface for that specific sender and reciever. I as a support person wouldn’t remember which project implemented this interface or if it is same project vendor supporting BAU there may be new support team who will be maintaining the integrations.

         

        Also, tommorow if I think I want to publish the content on SAP API business Hub as Partner Content then following this model will endure less work as it is line with SAP partner guidelines.

        I like the way SAP named their content on API business HUB ..I  find it more user friendly for non-developers and citizen integrators.

        Hence we use the above guideliness as even non developers like citizen integrators can understand and browse the custom and standard integration content easily in similar way after we go live. It also means custom content is modelled in same way as sap standard content.

        On decomissiong, I think in general requirement is to either decomission a system or a specific interface (not a project) which you still can do with above naming covention.

        I am in no means discarding your view point and you have valid points, but if I am building a long term repository of integrations for a customer landscape then I find it useful to follow above conventions for the reasons stated above as project names are forgotten after it goes live.

         

        ” Integration is always connected to a real system or a virtual system (web commerce/devices” etc”.

         

        Again, These are guidelines that needs to be evaluated case by case.

         

        Note: Conflict of opinions  and debate always results in great innovative ideas ! 

         

         

         

         

         

         

         

        • In SAP PI we used the business process and objects as a way to identify the way objects should be named. Business process could be a either real SAP 1-3 level process architecture. From the old ERP Blueprint where you could Take a procure to pay, and find the different levels in it. We found we could have a couple of those namings in the namespaces. It was probably not logical and something you could give other developers easy.

          But you could group like:

          • Masterdata_BusinessPartners (that contained everything with master data)
          • Masterdata_Other for all the minor parts
          • Procurment_PurchaseOrders
          • Sales_SalesOrders

          As a customer, I probably don’t care if my partners want to promote the integration they made for me to public content.

          It may not be an ideal approach, but could be considered for some scenarios as the exception process.

        • Hi Sravya Talanki ,

          maybe I should add some explanation why I added a package id to my naming convention syntax, so that you can understand my intention behind it. Because even if this looks very technical, it has also an advantage from non-tech user perspective.

          My pattern looks like adding an id to the package name and then adding an id to the IFlow name, which is unique for the specific content. Example:

          • [Package] Z_PCK001_ERP_Integration_With_CRM
            • [IFlow] PCK001_IF001_ERP_to_CRM_Replicate_Vendors
            • [IFlow] PCK001_IF002_ERP_to_CRM_Replicate_Masterdata
          • [Package] Z_PCK002_Hybris_Integration_With_ERP
            • [IFlow] PCK002_IF001_Hybris_to_ERP_Push_Orders

          The advantage of this naming style is better usability in the WebUI monitoring. By adding package and iflow id to the IFlows name, they are perfectly fine sorted in the monitoring. Support users, will remember the ids of interface the handle most the times and then easily can pick them from the list.

          For the same reason we added sender and receiver to the IFlow name, because otherwise (if we would use only <Intention><Object> naming and had for example multiple SendOrder flows, we couldn’t differentiate in the message list to which interface they belong.

          Offtopic: Huge props to the SAP community. I just shared a simple idea below this blog post and within hours a great discussion grew out of it. Great!

          • Hi Raffael Herrmann ,

             

            As I said, every solution has pro’s and con’s . I find above naming convention i.e including codes  geeky and not  business friendly. If there are many interfaces then I would never be able to remember ID(S) or package codes(May be I am dyslexic:().I would never include project names as they will fade and it is something that has no value after interfaces go-live.

            I like the way SAP named their standard IFLOWS on API Business Hub. It is easy to find the interfaces using keyword tagging(never had the need to include numbers for searching iflows). I may instead like to add the business domain name in line with the suggestions made by vadim as it will be more friendlier for LoB Citizen Integrators in the future.

            However different customers want different things, I would always consider customer feedback though I will explain the rationale on why I prefer business friendly convention for future.

            I agree it is always a great result when great people challenge each other.

          • Hi Sravya Talanki,

            what do you mean by “It is easy to find the interfaces using keyword tagging […]”?

            Do you mean the “Tags”/”Keyword” properties of the package? If so, where can you search for them. If we tag a package (via “Tags” tab, “Keywords” field) then the search on the Design-page (where all packages are listed) never works/spits out a result. I thought that this feature was broken/only usable in Discover section (when one decides to publish/list his package in the API hub).

      • I am quite interested to understand the pros/cons of the various options from those experts who have real life experience; once you are settled on a package name and built some iFlows, altering the package name or moving iFlows to other packages could be time consuming.

        I don’t have project experience on CPI, but it seems to me that the question is:
        Should the purpose of a package (and therefore it’s name) be based on functionality of the contained iFlows, or should the package be used to group together iFlows which relate to the same project and are likely to be transported/released together?

        Or put differently, should the package be named in a way that years after the project is complete, assists with locating similarly related iFlows (e.g. between the same systems or by functionality such as master data distribution), or should the package be named in a way that assists development and transports during the project phase (but which might not be so meaningful years after the projects complete)?

        Perhaps the issue is complicated by the fact that in CPI, bulk transport of iFlows occur at package level. PI/PO has a few levels of granularity to organise objects by functionality (SCV, namespace), which is useful long after projects are completed. On other hand, when it comes to transports during a project, we can chose to transport at these levels, or we we can utilize change lists which easily group only objects we’ve changed for a piece of work/project. PI/PO doesn’t (as much as CPI) require you to chose between namings which assist long term understanding of your system’s artifacts vs project life-cycle “convenience”. CPI packages seem to need to perform both of these roles at once. Or am I missing something?

         

        Personally, I’d chose to make a system easier to understand and maintain long term, but it does seem (at the moment) that SAP are “forcing” us to make a choice between project and longer term convenience (until they introduce alternative means of bulk selecting and transporting iFlows, or introduce additional means to tag/group/organise iFlows).

      • Hi Raffael!

        Thank you for the shout out! At first place, Sravya, thanks for such an extensive summary of best practices, this is indeed a very valuable input!

        As for the naming convention for content packages, here are my thoughts…

        Although I see many examples where package names contain indication of involved participants (senders and receivers), I personally feel that this naming pattern makes sense in specific use cases – in particular, when artifacts contained in the package, are developed for specific participants (mainly, point to point) and their implementations are bounded to those participants and are not expected to be extended or made generic / re-usable for other participants in a longer term. In other cases, I tend to gravitate to the package naming convention that only contains indication of the area (or sub-area for complex areas) / functional domain (sub-domain).

        If the entire development is done to satisfy country or region specific requirements (for example, country specific development that originates from legal requirements – electronic invoicing integrations are one of widely met examples here), I would also consider reflecting this in the package name – especially in cases when country roll-outs are supported by different regional teams and it would be preferred to allow them independent maintenance of their packages. Otherwise, for smaller sized developments, the package might still contain only functional area indication, and region / country indication comes to the iFlow name.

        For certain types of developments, it might be a good idea to indicate one of participants. For example, if we deal with publish/subscribe pattern and develop artifacts that are to handle incoming messages from a single master system, and number of receivers / subscribers might grow over time. We can develop the iFlow that accepts incoming messages from the master system, and place it in the package that reflects a name of the master system where messages come from, along with indication of the functional area. Subsequent logic that is specific to each subscriber / receiver, can be modularized and implemented in receiver-specific iFlows that can be placed in their own packages to decouple a generic iFlow that handles messages from the master system for a given entity type, and iFlows that consume them and deliver to – potentially changing number of – receivers.

        An opposite case to the above is when the receiver system is specific, but the sender part is generalized. For example, we have an iFlow that interacts in a specific way with the receiver system, but intention is to generalize the sender part of the iFlow and turn it into a reusable API. Here, we generalize the sender as we only have an abstraction of it (for example, the API Management tool that will proxy it and expose it to concrete consumer systems) and don’t possess knowledge about specific application systems that will be actual consumers, but are specific about how the iFlow manipulates incoming messages and how it accesses the concrete receiver system. In that case, it seems reasonable to indicate the receiver system and the application area, and drop indication of the sender.

        Regards,

        Vadim

         

        P.S. and off-topic from the naming convention: the recommendation regarding usage of Web IDE… Might be, CPI Web UI was meant instead? I don’t think Web IDE (a separate service in SCP) provides tooling for iFlows development currently – SAP encourages developers to use CPI Web UI (a part of CPI service) for major part of CPI-related development activities.

        And recommendation regarding usage of CTS+ – while it makes perfect sense for customers who invest in Solution Manager, I think we will see alternative recommendations for cloud-focused customers who migrate their operations to the cloud or who for some reason would not like to make long term investment in Solution Manager. Those might look for SAP Cloud Platform Transport Management service as a longer term option. At the moment, feature comparison of CTS+ and SCP TMS in part of support of CPI artifacts’ transport will highlight quite a lot of differences, but to put it generically, I think the recommendation is to ensure that more advanced, automated and auditable software logistics / transport tools are used, and not file based manual exports/imports, but the choice of the tool will depend on how much the customer is committed to Solution Manager, and how comfortable they are with the hybrid model.

        • Hi Vadim,

          Regarding the transport then we at Figaf does offer much better solution for software logistic of SAP CPI than solman does. It does require a new partner tool, but it gives a more flexible delivery model for iflows.

        • Hello Vadim Klimov ,

           

          I broadly agree 100% with all your views and in line with my views that are expressed in my responses above, if it is generic then I would put them like how SAP packaged them in specific area..EDI Templates to ICA or EDI Open Connectors or S4 HANA Cloud API(S) or EDI to SAP etc just like https://api.sap.com/search?searchterm=edi&tab=all. I will try add something up for generic guidelines.

          I initially had country and functional area in naming conventions but then I preferred how SAP created tags and keywords which we can use to search UK or USA interfaces unless we are developing some thing very specific to a country like https://api.sap.com/package/SAPS4HANAStatutoryReportingforUnitedKingdomIntegration?section=Overview.

          I am thinking of updating naming convention in the above section by adding some examples for above usecases, what do you think?

           

          Yes, I meant CPI Web UI. On CTS+, i will update with your and daniel comments. It is a good point as I generally referred CTS+ from best practice perspective for complex integration landscapes but not for all clients. SCP TMS and Daniel Figaf could also be used .

           

           

           

           

          • Hi Sravya,

            Yes, absolutely agree – examples are always useful to demonstrate the naming pattern in action. Might be that other fellow members will come up with some different use cases, and this can be extended and new examples can be added, but this is a very thorough baseline that can be used as a solid starting point.

            Regards,

            Vadim

      • Hi Raffael,

        I do like the approach as you mention that just write what you are integrating the name of systems involved. Thought it will probably be the main focus.

        Thought probably not with project prefixes. They can be in the iflow if you use this numbering for some internal document structure.

        And probably webshop is a pretty vague naming, that once you start on C4/Hybris is that then the webshop or is that the old name.

        If it is EDI with a lot of partners it may make sense to create a specific naming convention like “Customers_EDIFACT_Orders_In”. But it would depend on the number of partners you are involved with on how specific you want it.

        I think you may end up having a lot of exceptions in the process. Because of the flexibility and it would not make sense to have too much in a package or make a design that really does not scale.

        The important parts are to be able to identify which integration is involved with a specific system and how business objects my flow. I assume that this can be achieved using the search function.

         

        • Hi All,

          Thanks for such great feedback!

          I updated the naming conventions with some edge case use cases as well based on all your feedback, thanks for making it better!

           

          As we go into next decade, we should use naming conventions that is not alpha codes which only a set of people will know but a business(not tech) friendly convention that citizen integrators or developers or business teams can understand..

          The above conventions are just guidelines which has to be evaluated for every edge case.

          • Hey

            Agreed there should not be too much decoding and also allow a business to work on the project.

            And yes it should be used as best practice, but can be evaluated each time depending on the customer requirment and future wishes..

             

  • Hi Sravya,

    a really impressive blog. I’m pretty sure it will be very helpful for all the flow developers out there.

    I would have a question on chapter 8, point 5 and 6. Why do you assume that the headers that are used to persist the content in the local and global variables keep existing after the flow has ended? I would be interested in your experience. Usually all objects that are kept in memory will be cleared once the flow processing is over.

    Also I would like to make you aware that you can delete headers via Content Modifier.
    See https://blogs.sap.com/2018/01/18/sap-cpi-clearing-the-headers-reset-header/

    best regards,
    Axel