The Mystery of CAP(M), SAP Cloud SDK and SAP Extension Factory
Reading the blog post “SAP Inside Track RuhrPOTT 2019” by Paul Hardy the following statement struck me:
Find a way to explain the relationship between the extension factory, the Cloud SDK and the CAPM in a way that a human being can understand
I came across that statement across several times when talking with customers and colleagues about the side-by-side extensibility of SAP applications as well as building new add-ons in a side-by-side manner (and I am sure I will in the future). SAP indeed did its best to get quite some confusion in that area by renaming parts (their favorite strategy ?) as well as not delivering a story gluing those parts together.
Although I am not an SAP employee (as wished by Paul in his blog) I want to give it a try to explain how the different parts play together. Let us start with the SAP Cloud Application Programming Model.
The SAP Cloud Application Programming Model
Let us take one step back and ask ourselves: what is a programming model? The answer I found is: a programming model, in general, is “… an abstraction of the underlying computer system that allows for the expression of both algorithms and data structures.” Furthermore, “a programming model exists independently of the choice of both the programming language and the supporting APIs.” [taken from LLNL Lawrence Livermore National Labs: “Programming Models”].
Okay, so a Programming Model helps us to focus on the development of data models as well as the logic to work with the data without caring too much of the underlying technological stuff. This is exactly the point the SAP Cloud Application Programming Model is targeting: its goal is to support the developer in creating business applications i.e. the corresponding data models as well as the domain logic to interact with the data model without having to know how things play together “under the hood” (that’s the idea, developers are technical folks, so they anyway will look under the hood, but that is a different story). The programming model is based on best practices and therefore should help to avoid pitfalls when creating such applications
The lingua franca in the SAP Cloud Application Programming Model is Core Data & Services (CDS). You use CDS to define the data model of your domain (with some additional nice features that come out of the box with the programming model). The persistence layer is then derived from that model. Using annotations, you can also define the UI representation (specifically for SAP Fiori elements). In addition, it provides hooks to implement the business logic of the services exposed by the application.
What is the use-case of the programming model? It helps you to create business applications in an opinionated way, i.e. CDS as the base for the data structures, OData for exposing services, support of SAP Fiori elements and Cloud Foundry as the preferred deployment target. Nothing more and nothing less. So, if you want to create an application that will run in the SAP Cloud Platform, the Cloud Application Programming Model supports you with it.
However, in most cases, you certainly want to integrate with an SAP solution like SAP S/4HANA. Does the SAP Cloud Application Programming Model help you there? Nope, it is intended to build applications in general, not dealing with the specifics to integrate with SAP solution A or B. You can integrate with SAP solutions, but you must deal with the integration tasks on technical and business level (aka data model of the SAP solution) yourself. This is possible, but no fun and causes additional efforts. But that is okay – this is not the duty of a programming model.
However, this gap is addressed by SAP and this is where the SAP Cloud SDK comes into play.
The SAP Cloud SDK
Let us again start with a general definition of Software Development Toolkits (SDKs): an SDK is a set of tools that support you with the creation of applications for a specific platform (like a specific software framework). The SAP Cloud SDK perfectly fits here as it provides a set of tools to extend SAP solutions.
The central part of the SDK is the Virtual Data Model of SAP S/4HANA (
I am not sure if there is already support for other solutions – renaming is one thing, supporting other solutions technically is a different story Update after comment by Henning Heitkoetter: A list of supported solutions beyond SAP S/4HANA is available here: SAP S/4HANA Cloud SDK Transforms into SAP Cloud SDK) that tells you what business objects are exposed by SAP S/4HANA, which data is contained within the models and how you can interact with the model. This is encapsulated in a fluent API that makes your life easier and gets you rid of a lot of boilerplate code when interacting with SAP S/4HANA. The Java-based SDK offers more tools like an extension of the Hystrix framework with respect to multi-tenancy. In addition, the SDK provides an out-of-the-box CI/CD build pipeline (highly appreciated btw).
In one sentence: the SAP Cloud SDK makes your life easier when you build applications that extend SAP solutions (first and foremost SAP S/4HANA – at least as of now). It is opinionated with respect to the deployment i.e. the preferred way to deploy the solution is the SAP Cloud Platform Cloud Foundry environment.
Now you might have some questions that I am trying to anticipate:
Q: Must I use the Cloud Application Programming Model to build side-by-side extension with the SAP Cloud SDK?
A: No. You can also create e.g. a Spring Boot application integrating the SDK.
Q: Can I use the SDK together with the Cloud Application Programming Model.
A: Yes, you can.
Q: Can I combine the SAP Cloud SDK with other SDKs and frameworks
A: Of course, you can.
Q: Can I use other SDKs/Frameworks together with the Cloud Application Programming Model?
A: Of course, you can.
The SDK and the Cloud Application Programming address different aspects of the development of business applications. The SDK covers very specific aspects with respect to integrate with SAP solutions while the Programming model provides a generic approach to build business applications in an SAP-opinionated manner in the SAP Cloud Platform.
That leaves one topic open, the SAP Extension Factory.
The SAP Extension Factory
The SAP Cloud Platform Extension Factory has its roots in the C/4HANA ecosystem. It is based on the open-source project Kyma. The goal of Kyma is to easily connect to and extend enterprise applications. Kyma itself is built upon open-source tools and frameworks and leverages open standards like OpenAPI for the connection/integration part. The platform addresses the following pain points when extending applications:
- Securely connecting to the applications that should be extended via a “one-click” approach
- Providing an overview of APIs and events that are exposed by the connected application
- Extending applications in a serverless manner
To make one point clear: there is no SAP flavor in Kyma, it can basically be used with any application (that provides some prerequisites to be fair).
The extension factory is built upon Kyma and enhances it with respect to an “out-of-the-box” integration with SAP solutions (current focus C/4HANA), so the goal is that whenever you subscribe to a C/4HANA solution, you get the extension factory as part of the C/4HANA foundation and the integration is already done for you (this is not yet reality).
The preferred way to extend solutions with Kyma/Extension Factory is event-based in a serverless way (leveraging Knative). When it comes to focus on the business logic in an extension this is doing an extension on steroids (I admit I am biased when it comes to serverless).
What is the difference to the other two approaches? First, the basis of the Extension Factory is SAP agnostic. It is opinionated with respect to the technical basis (Kubernetes and Knative), but that is CNCF “standard”. All the standards, tools and frameworks are established in the Kubernetes ecosystem. The question if you must use SAP to use Kyma is therefore obviously “no”. The Extension Factory provides additional value by giving you more commodity when you connect the Extension Factory to SAP solutions, but that is basically it.
As a bottom line, the Extension Factory/Kyma is a platform for connecting and extending applications (preferred in a serverless approach, but you can also create microservices … but who wants to do so if you can do it serverless ?). You can combine it with any programming model as well as with any SDK. (From my point of view, the main question is how the SAP Cloud Platform and the Extension Factory will grow together to one platform in the future, but that is not the topic of this blog).
Hopefully, I could shed some light on the different topics of Cloud Application Programming Model, SAP Cloud SDK, and Extension Factory/Kyma.
Wrapping it up, the SAP Cloud Application Programming Model is an opinionated abstraction that enables developers to focus on the business logic and the corresponding data model when building applications for the SAP Cloud Platform. It does not address any specifics when it comes to interacting with SAP applications like SAP S/4HANA.
This is the spot that the SAP Cloud SDK fills up with its Virtual Data Model and the corresponding APIs that help the developer to easily interact with the business objects of SAP solutions like SAP S/4HANA.
The SAP Extension Factory is a different story. Its basis is a solution agnostic platform called Kyma that targets the integration with and the extension of business applications independent of any SDK or programming model.
Here is some additional material you if want to dive deeper into one or the other topic:
SAP Cloud Application Programming Model
You want to learn more about the SAP Cloud Application Programming Model, a good starting point is help.sap.com (https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/00823f91779d4d42aa29a498e0535cdf.html)
For a look behind the curtain, I highly recommend the hands-on series of DJ Adams et al. (see: https://blogs.sap.com/2019/01/16/hands-on-sap-dev-with-qmacro-new-live-stream-series/)
SAP Cloud SDK
If you want to learn more about the SAP Cloud SDK I recommend the blog series https://blogs.sap.com/2017/05/10/first-steps-with-sap-s4hana-cloud-sdk/ and the open SAP course on extending SAP S/4HANA (https://open.sap.com/courses/s4h13)
Kyma and SAP Extension Factory
If you want to learn more about the Extension Factory and Kyma the following replay of the session Introducing SAP Cloud Platform Extension Factory (https://events.sap.com/sap-cx-live/en/session/42483) is a starting point. If you want to learn more about Kyma here are some resources:
- Kyma Project Page: https://kyma-project.io/
- openSAP Course on Kyma: https://open.sap.com/courses/kyma1
[Update based on Rui’s comment]
You find additional information about the extension factory in these blog posts by Rui Nogueira:
thanks a lot for compiling this overview of the three components. Glad to see that the individual parts resonate well.
Let me comment on a few statements and address a few of your comments / questions.
That's true. Of course, many of those business applications will integrate with SAP solutions, so the SAP Cloud SDK is out-of-the-box part of the programming model for that specific task.
Good point. This overview lists a few SAP solutions where we have examples of using the SAP Cloud SDK. Please let us know for which solution you would like to see more. Please note that for some, like SAP SuccessFactors or SAP Business ByDesign, a pre-generated VDM does not make much sense, as the OData services will often differ per customer. We suggest the VDM generator of the SAP Cloud SDK for cases like this.
That's right, although the SAP Cloud SDK also supports Neo. In fact, the Cloud Platform abstractions of the SDK allow doing this in a transparent manner and thus make transition from Neo to Cloud Foundry easier.
This question is to some extent covered by this blog post. The SAP Cloud SDK also supports Extension Factory on SAP Cloud Platform.
thanks for the extensive comment. I was not aware of that list of supported SAP Solutions. Thanks for pointing to that resource!
NEO vs. Cloud Foundry: I did not mention the NEO environment intentionally as I personally would not recommend anybody to start their journey on NEO now. Although there is no clear statement about the future of NEO, I would assume that the first picture in the blog post you referenced (https://blogs.sap.com/2019/05/07/now-available-the-sap-cp-extension-factory/) can be interpreted as a statement on the future direction.
Hi Christian, for the SAP CP Extension Factory I’ve compiled a blog post a couple of weeks ago that is also mentioned by Henning.
It also describes the relationship between the open source project Kyma and the SAP CP Extension Factory.
We'll work on a better aligned explanation on how the various concepts relate to each other.
thanks for your comment. I updated the blog and linked your blog posts about the extension factory.
Glad to hear that you are working on an aligned explanation!
Great Article. I am new to the Cloud Environment and have an ABAP Background. I am currently doing OpenSAP Course of Cloud Application Programming Model.
I can see that its similar to RAP. Just wondering how would one decide which one to use - CAP or RAP ? Can CAP be used on S/4 On-Premise or its more relevant for Cloud developments.
RAP and CAP share common concepts. RAP is in my opinion the way to go if you do ABAP development either in the SAP Cloud Platform ABAP environment or on premise in SAP S/4HANA. However, due to the slower release cycles on premise in contrast to the SCP ABAP environment features are available first in ABAP cloud and then on premise. If you do projects it is essential to evaluate the state and in consequence possible limitations of your on prem system.
CAP is intended for non-ABAP development in the Cloud (or on HANA XSA as XSA is based on Cloud Foundry). So if you do side-by-side extensions or cloud development CAP is worth considering. If you do ABAP development e.g. in S/4HANA RAP should be the choice.