SAP CPI

SAP CPI stands out with its versatility to integrate almost any system imaginable, whether built-in SAP connectors or third-party APIs are being utilised to design powerful integrations for any purpose imaginable.

Not only can  SAP CPI support SAP systems, but it also enables full-scale enterprise integration.

We conducted our exploration over two consecutive weekends, allowing us to cover one module per week and ensure everyone understood its basics, including its role as middleware and how it’s used to construct end-to-end integration flows.

SAP CPI plays an invaluable role for businesses that rely heavily on SAP applications, acting as an integrator between systems to support integration between them and creating value across them.

It goes well beyond traditional middleware tools such as Mulesoft or Dell Boomi to offer deeper integration between SAP systems, making SAP CPI an exceptional option.

SAP CPI and the Evolution from PI/PO

SAP unveiled its middleware solution as Exchange Infrastructure. Since then, however, its functionality has grown into  SAP PI (Process Integration) and PO (Process Orchestration), eventually merging Java/ABAP stacks under SAP PO 7.5 into one single stack platform.

SAP CPI has become the new industry standard; it provides cloud-first integration capabilities between cloud environments and on-premises infrastructures, and SAP is actively encouraging customers to transition away from  SAP PI/PO towards SAP CPI, especially as PO support will eventually cease, making this move towards cloud architecture an attractive future option.

Why SAP CPI Is the Middleware of the Future

As businesses transition towards cloud environments, SAP CPI provides businesses with the agility necessary for seamless cloud adoption.

SAP and its partners, getting started with common integration scenarios has never been simpler – SAP CPI allows us to take advantage of them via its Discover section within the design tenant.

SAP CPI tenants consist of three primary components: Discover, Design, and Monitor, which help build and manage integration flows for business applications.

From handling parameterisation requests, setting message mappings or accessing service data directly – SAP CPI has everything needed for the efficient operation of integration flows.

SAP CPI in the Middleware Market

SAP CPI stands strong as one of the go-to middleware offerings currently. Although tools such as MuleSoft have experienced more traction, customers continue to opt for SAP CPI due to its reliability and integration abilities.

Customers frequently switch middleware platforms due to dissatisfaction with integration quality or communication issues, with SAP CPI meeting both needs by providing its robust adapter framework and support for various system types hence why many continue recommending SAP CPI as part of enterprise integration projects.

One key reason clients switch from MuleSoft to SAP CPI is cost.  MuleSoft licensing can cost nearly twice what SAP CPI’s is in some instances, making the latter the superior economic choice in many cases. Due to these financial and performance aspects, SAP CPI has quickly become the integration suite of choice across numerous scenarios.

Getting Started with Configuration in SAP CPI

Configure is one of SAP CPI’s most useful options and will often prove indispensable when working within this environment.

Clicking Configure allows you to see who the sender and receiver are, as well as all externalised parameters from within an I-Flow, providing a much-needed view to help manage critical details without changing its core logic.

Because editing I-Flows directly can’t happen during production, externalisation allows any parameter marked external to appear under Configure for editing without altering or rebuilding its flow directly.

Getting Started with SAP CPI: Converting CSV to XML

One of the initial challenges encountered when working with SAP CPI was handling CSV files from third-party systems that did not adhere to an established format, meaning we needed a converter tool to convert these into XML and continue message mapping.

A CSV-to-XML converter helped transform these incoming payloads by using its data as a source, creating an XML schema from within each CSV file itself and saving us valuable time.

To do this, uploading the CSV file into Liquid Technologies’ converter tool and specifying root and element names yielded an XML structure that Liquid Technologies converted into an XSD (XML Schema Definition), providing the basis for SAP CPI message source message structures.

Converting CSV to XML for SAP CPI

Since our input file was in CSV format, a conversion step had to take place before mapping.

Utilising SAP CPI’s converter enabled us to transform its flat CSV structure into well-formed XML documents, creating an XSD schema out of them; uploading this XML into SAP CPI as source definitions.

SAP CPI integrations often necessitate creating our schemas when working with files without predefined schemas, like CSV formats.

Business Systems with SAP CPI

SAP CPI has always been my go-to for integrating S/4HANA systems, whether public cloud, private cloud, or on-premise.

SAP CPI works excellently with SuccessFactors, particularly payroll and HR-related workflows. Its robust yet user-friendly environment, connecting all business processes is effortless with SAP CPI.

Tenant Landscape in SAP CPI

Logging onto SAP BTP Cockpit, users will generally see tenants organised according to environment – Development, Quality Assurance (QA), and Production.

SAP CPI offers both two and three-tier setups depending on cost and complexity, making this a handy way of segregating testing from production environments.

AWS or Azure powers each tenant and includes the Integration Suite–home to SAP CPI– to ensure scalable integrations for projects of various scales.

SAP CPI in ECC to S/4HANA

SAP ECC was once at the core of many enterprises, housing critical business data in-house.

SAP S/4HANA, we’ve entered an exciting new era: it can be deployed either on-site, in the public cloud, or private cloud for greater deployment flexibility – CPI being key in helping facilitate such integrations.

On-premise S/4HANA users must often configure partner profiles and utilise T-codes to access specific screens – an indispensable means of navigation within the system.

When working in public or private cloud environments, however, T-codes may be replaced by  Fiori apps and search-based navigation; SAP CPI is built to adapt seamlessly into either climate, making it an invaluable solution for integration scenarios of all sorts.

Designing Interfaces with SAP CPI

Within SAP CPI, we have an incredible design environment for building custom integrations or copying from standard content in the Discover Catalogue; this process is seamless and effortless.

When working with SuccessFactors or its related partner products.

If none of those suits your use case exactly, copy one tenant and modify it as necessary to build a custom integration. SAP CPI provides this flexibility without diminishing efficiency.

Design Tab in SAP CPI

SAP CPI’s Design tab enables users to create and manage artefacts easily.

Once deployed, users can view details such as the last modified date, the user who made the changes, and the associated ID.

SAP CPI Adapters and Connectivity

Connectivity is another area in which SAP CPI excels, supporting protocols like SFTP, SOAP, and OData, which allow it to connect to nearly every system imaginable, from Salesforce to SuccessFactors to platforms like Facebook or Twitter.

SuccessFactors integration becomes easy; OData consumes entity data for routing to target systems with just a few configuration steps in SAP CPI.

SAP CPI Interface Deployment

SAP CPI should be checking its integration account and seeing that all test interfaces have appeared as expected.

Each interface in SAP CPI has a distinct ID, which is assigned upon creation and displayed just below its name.

While interface names may be reused, IDs must always remain unique – otherwise, SAP CPI will prevent you from creating another interface using that same ID.

After deploying an interface, SAP CPI provides its URL as an endpoint address and must be shared when accessing external systems to call for that interface.

When testing with Postman, share this endpoint along with the necessary credentials (usually client ID and secret), while SOAP-based scenarios often share WSDL instead of sharing credentials.

Testing Interfaces in SAP CPI

Testing is an integral step in SAP CPI. Once an interface has been deployed, test its readiness by simulating external communication using tools such as Postman.

This involves simulating external interactions with the endpoint URL and authentication credentials, provided everything has been appropriately set up. Once configured correctly, the interface should receive messages.

At this stage, if no messages have been transmitted yet, the interface may seem idle. One way to demonstrate this is by logging into Postman and simulating a call using the provided credentials.

To replicate this experience, others must obtain Postman access and possess a valid client ID and secret. Doing this ensures that real-time communications capabilities exist for this interface.

Efficient Testing and Debugging in SAP CPI

As part of development, SAP CPI offers test features to debug and validate mappings.

If, for instance, BURKS doesn’t map correctly, testing various input values helps quickly pinpoint issues without having to deploy an entire iFlow.

SAP CPI makes an unparalleled difference by offering mappings testing in isolation this enables rapid iterations to ensure every component works flawlessly .

Monitoring Interfaces in SAP CPI

Monitoring is one of the key capabilities in SAP CPI. The Monitor tab enables you to closely monitor every aspect of message processing, including message statuses, integration flows, and API calls.

By setting different time frames – such as one hour, day or week–I get an accurate picture of how my system is operating.

The “Message Status Overview” tile can be especially beneficial. It displays the number of messages processed, failed, retried, or escalated, enabling quick identification of issues and efficient corrective actions.

Furthermore, switching over to the Integration Flows view allows users to zero in on specific artefacts’ performance more closely.

Secure SAP CPI

Security SAP is of utmost importance when we integrate SAP CPI.

Recently, we worked on a project where MuleSoft alert notifications needed to be connected via MuleSoft for alert notification purposes; and three authentication methods (username-password authentication method, OAuth authorisation code authentication method, and another more specialised form) were considered as possible methods of connection.

Authentication and Security Options in SAP CPI

Authorise role wisely within SAP CPI; user roles or client certificates, depending on your scenario, usually work best.

When using user roles for communication purposes, senders must possess the ‘ESBMessage.

SAP CPI also features Cross-Site Request Filtering (CSRF) protection that is activated as necessary against cross-site requests that attempt to exploit vulnerabilities on websites.

When setting up trial accounts, leave this unchecked until required.

Configuration Scope in SAP CPI

SAP CPI ‘Configure, is all parameters are organized into three distinct groups based on Sender, Receiver and More categories; anything between Sender and Start Message falls in this group while any further parameters–like general parameters–are placed under Receiver or More sections respectively.

SAP CPI will display no parameters in these sections if nothing has been externalised; instead, it displays an error message for configuration: no attributes available for configuration, indicating something may be missing from an adapter, like URLs or security tokens.

Therefore, always externalise any values that may need externalisation, such as adapter values like URLs or security tokens, so SAP CPI can detect an issue and display the error.

Once you enter an externalisation like “httpAddress”, SAP CPI prompts for a default value that can then be saved and edited under “Configure”, to allow you to easily maintain environment-specific values across adapters that interact with external systems.

Externalised Parameters in SAP CPI

SAP CPI allows users to externalise adapter-level parameters. Within HTTP adapter settings, curly braces can be used to define dynamic parameters – for instance, putting an HTTP address inside double braces with an appropriate name assigned – before SAP CPI marks its box as externalised.

If the default value for an I-Flow is blank, SAP CPI prompts you to provide one. After filling it in and saving, click “Deploy” to deploy and take effect. I-Flow leaves the draft state, and “Configure” now shows the externalised parameter ready for use.

Once all variables have been externalised and are stored in the Configure Tab, this approach becomes your single source of truth and ensures an error-free system compared with editing I-Flow directly.

Externalising SAP CPI artefacts ensures smooth transitions and complete control after deployment, even though editing artefacts directly is prohibited by policy.

Without externalisation, editing processes would remain stuck despite attempts at direct editing if you attempted it directly in production mode.

Externalisation allows smoother transitions while giving fuller oversight, making it not only convenient but also necessary.

SAP CPI Versioning and Best Practices

Version control in SAP CPI can be your greatest ally. The version number rises accordingly, and ensure production deployment mirrors what was tested during development.

SAP CPI treats deployed artefacts as inalterable once deployed; therefore, once something goes live, it’s locked down permanently.

Locking down production edits while taking advantage of external configuration is one of the most successful patterns I’ve come across with SAP CPI, keeping everything uniform and eliminating surprises post go-live.

Target Structures in SAP CPI

The CSV to XML and creating its corresponding XSD file, I uploaded both the source schema and the target schema into SAP CPI for processing.

If the target system required a SOAP XML structure instead, refer back to the official documentation for assistance in retrieving necessary details.

Import of SOAP structure into SAP CPI was completed successfully using the Create Confirmation operation of the message mapping setup, thus precisely setting target expectations within SAP CPI.