Simplify extensions and integrations using SAP Cloud Platform Extension Factory Kyma Runtime and SAP Cloud Platform Integration Suite
This blog provides guidance on using “SAP Cloud Platform Extension Factory, Kyma runtime” (aka SKR) and “SAP Cloud Platform Integration Suite” (aka CPIS).
It includes details and real-world use cases to help you understand how these two products suit best for different use cases and serve complementary needs for customers and partners. The aim is to help customers and partners make reasonable choices between CPIS and SKR when solving a business problem.
- No business logic into the integration platform.
- No integration logic into business applications.
- Business events can trigger extensions as well as process integrations.
At a glance
|SAP Cloud Platform Extension Factory, Kyma Runtime (SKR)||SAP Cloud Platform Integration Suite (CPIS)|
|Use Cases||Business logic extending an existing solution||Integration logic|
SAP Cloud Platform Extension Factory, Kyma runtime (SKR)
SKR is a recommended solution when business cases require adding business logic as extensions. It supports asynchronous extensions using event-driven architecture as well as synchronous extensions with APIs and microservices.
The typical extensibility scenarios revolve around:
- Customer-specific or industry-specific business logic
- Enabling third parties or hyper-scalers service usage (e.g. Azure Cosmos DB) for business extension logic
The extension logic itself may interact with 1 or more SAP or third-party applications as required for the business logic.
You can achieve side-by-side extensibility with SKR either through business events or cloud-native extensions.
Using SKR for side-by-side extensibility provides the following benefits:
- Out-of-the-box solved connectivity with SAP Systems using an application connector and management plane.
- Ability to consume services from hyper-scalers as well as SAP Cloud Platform using Service Catalog.
- Deploying microservices and lambdas to implement extensions for customizing business logic.
- Enable developers to build true cloud-native extensions where the operational and security concerns such as monitoring, tracing, alerting, auto-scaling, and secure inter-service communication are already solved out of the box.
The extension patterns that are best suited for using SKR when extending business logic:
|Event Consumer||Trigger custom logic with business events (e.g. Address validation)|
|Call-Out||Trigger custom logic by REST API call from an application (e.g. Payment Processing)|
|Logic OnDemand||Serverless extensions augment added features in User Interface (e.g. Product recommendations)|
|Decorator||Extension serves as the entry point backed by application (1 click checkout on top of existing stack)|
The various problem domains where SKR is a preferred choice are described by the following sample use cases.
1. Extend by capturing system activity (Event Consumer)
In this case, the business scenario requires capturing a system activity that the end-user directly or indirectly triggers. The trigger then extends the application logic with new functionality using side-by-side extensibility.
An example here can be the “Opportunity Created” activity in SAP Sales Cloud which is sent as an event to SKR where the users can implement extension logic that fits their business needs.
Such a model is based on the Business Activity Event trigger. In this concept, any business occurrence in the application will send an event to the SKR, thereby triggering a compute (serverless or a microservice) that can execute the business logic for the extension.
The next section describes a real-world business case that you can use as a reference for such business activity events.
As it is often the case, validating an order in a commerce system is one of the most essential requirements.
It poses the following business challenges:
- Validation logic can be complex and specific to the business, region, or other contexts and will require customization.
- The logic itself might need to be changed frequently to adapt to customer behavior and identify fraudulent orders.
- The solution needs to be able to easily integrate with notification mediums such as Slack and others for quick turnaround and action.
If we summarize the above-mentioned business needs, the technical requirements are:
- Ability to extend SAP Commerce Cloud with extension logic that is more than mediation.
- Support for frequent changes and deployments.
This in turn manifests as a scenario where you extend the core business logic (validate order) of the SAP Commerce Cloud. For such use cases, SKR is the preferred technology to use for the following reasons:
- The implementation of a custom business logic such as fraud check works better as a lambda or a microservice in SKR with the flexibility of low-level code.
- Ability to quickly deploy extensions via lambdas and microservices with faster time-to-market.
- Ability to easily and quickly implement any changes in the logic thus making the extension adaptable to external factors. This is an important requirement as there can be new ways of fraudulent orders and adapting the fraud check logic quickly is important.
Below is a recommended approach to solve such business use cases using SKR.
The extension logic is triggered by acting on the system activity which is sent as an event to SKR.
2. Building cloud-native extensions (Call-out)
Some business scenarios which require writing new microservices or serverless functions augmented by new frontend components or extending the business flow in a synchronous manner. This requires adding additional business logic outside the application. Additionally, this business logic may require interacting with one or more SAP or third-party systems.
For such business scenarios, the recommended approach is to implement serverless functions or microservices in SKR and expose them as API with out-of-the-box security.
This is an example of a real-world business case where building cloud-native extensions using SKR is recommended:
Commerce Pricing Service
In a commerce system, you need a scalable, highly efficient, and easy to adapt price service for some of the following business challenges:
- Prices are volatile and can vary frequently.
- Large volumes of diverse data (e.g. customer or context-specific prices).
- Using an ERP backend can pose scalability issues.
- Price calculation needs to be scalable and fast to process high volumes of requests efficiently.
- The calculation logic might need to be adaptable to meet everyday business needs such as discount campaigns.
If we summarize above business needs, the technical requirements are:
- High Scalability
- Frequent changes and deployments
This in-turn manifests as scenario where we extend the core business logic (price calculation) of the SAP commerce cloud. For such use cases, SKR is the preferred technology to use:
- Complex Custom business logic (price calculation) are better realized using SKR using lambdas or microservices with the required flexibility.
- Leverage out-of-the-box integration with hyper-scaler services using the Service Catalog.
- Ability to quickly adapt the changes in the price calculation logic and faster time-to-market.
Below is a recommended approach to solve such business use cases using SKR.
The price lambda service is deployed as a cloud-native extension in SKR.
SAP Cloud Platform Integration Suite (CPIS)
The SAP Cloud Platform Integration Suite. (CPIS) is the recommended approach for end-to-end process integration. CPIS service helps you connect cloud and on-premise applications with other SAP and non-SAP cloud and on-premise applications. CPIS covers this broader integration scope by supporting all required integration that includes:
- Process – Covers the chaining of distributed business processes between two or more applications.
- Data – Covers the movement and synchronization of data between applications, databases, and data lakes outside a transaction context.
- Business 2 Business (B2B) – Deals with the integration between business partners.
- User Experience (UX) – Covers the rapid recombination of user interfaces (UIs), the consistent mash-up of the task-specific UIs.
- Business to government (B2G) – is related to B2B but focuses on integration between companies and government agencies.
- Analytics – Includes integration of data (especially from 3rd party data sources) for analytical purposes
- IOT – Covers all scenarios where data from a device, asset or machine must be integrated with business applications.
Using CPIS for integration provides the following benefits:
- Pre-packaged integration packs handling the E2E business scenarios connecting. The integration packs are maintained against the underlying system changes. They also provide specific extensibility hooks (pre and post hooks) for adding your custom business logic.
- Provides a web-based low-code integration content designer to design, develop, deploy, and monitor your custom integration flows.
- Provides multiple adapters like AMQP, AS2, AS4, LDAP, HTTPS and more (See the full list) and connectors for 3rd party SaaS solutions like Salesforce, Workday, Coupa, SharePoint, OneDrive, Google Drive, Amazon S3 (See full list)
- Supports multiple integration patterns like Mapping, Content Modifier, Converters, Encoders/Decoders, Routers, Splitters, Join, Gather, Local Process call that simplifies the complex integration projects for your business scenarios (Refer full list of supported integration capabilities and patterns) and policies to your APIs either from SAP or non-SAP systems for your internal or external application developers/partner. For more details, refer the help documentation ).
Various domains where SAP Cloud Platform Integration Suite can be best explained with following real-world business case
Integration of systems
This scenario describes the integration of either SAP to SAP systems or SAP to non-SAP both on cloud and on-premise. SAP and its partner ecosystem provide a wide variety of pre-packaged integration packs to support the integration of SAP services as well as third-party applications. Prepackaged integration packs are built and released by SAP or its partner ecosystem following a cloud-first strategy: new content is built on CPIS to leverage fast innovation cycles in the cloud, and shipped through SAP API Business Hub.
Customers and partners can use the web tooling provided by SAP Cloud Platform Integration to create, configure, and monitor cloud integration content. For system integration, the recommended approach is to use the SAP Cloud Platform Integration Suite.
This is an example of a real-world business case where building cloud integration using CPIS is recommended:
Data Integration for SAP Commerce Cloud with SAP Marketing Cloud
The integration of SAP Commerce Cloud with SAP Marketing Cloud features replication processes that conveniently keep the data up to date in asynchronous manner for both systems. For this integration, data such as customer information, products, product category, order, saved cart, product review, consent, return order, abandoned shopping cart, single code coupon, promotion or coupon redemption data from SAP Commerce Cloud needs to be kept in sync with the SAP Marketing Cloud.
To successfully perform this integration, you start with the prepackaged integration packs delivered by SAP on SAP API Business Hub and then add to your custom extension in the predefined Pre-Exit and Post-Exit Custom Extension hooks available in individual integration content.
Use SAP Cloud Platform Extension Factory, Kyma Runtime (SKR) when solving business logic extension problems that involve
- Customer/region/industry-specific business logic
Use SAP Cloud Platform Integration Suite (CPIS) when solving integration problems that involve
- Mapping data structures from sender to receiver
- Routing of messages
- Connectivity via various protocols (FTP, RFC)
- Data Integration with 3rd party systems (160+ Open connectors)