Introduction

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.

“Historically” the SAP Cloud SDK was named SAP S/4HANA Cloud SDK and the original goal was to support developers in building side-by-side extensions for SAP S/4HANA. It was renamed at SAPPHIRE 2019, and the focus was broadened beyond SAP S/4HANA. It is currently available for the programming languages Java and JavaScript.

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

Wrap-up

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.

Additional Resources

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:

• Now available – The SAP Cloud Platform Extension Factory
• SAP Cloud Platform Extension Factory – FAQ