I am pretty sure a lot of you are familiar with SAP Cloud Application Programming Model (CAP). It simplifies building enterprise grade services and applications by guiding developers along a ‘golden path’ of proven best practices. Since best practices are served out-of-the-box with generic solutions for many recurring tasks, developers can focus on the business logic without having to worry about the underlying technical details. This results in accelerated development, minimized boilerplate code as well as increased quality. When it comes to building enterprise grade side by side extensions on SAP BTP, SAP CAP Model is the recommended approach.
However, there is yet another offering from SAP named the SAP Cloud SDK which predates SAP CAP Model which some of you might be familiar with. And even within the subset of folks who are familiar with SAP Cloud SDK, there is confusion on when to use SAP CAP Model, when to use SAP Cloud SDK and when to use them together.
For example, you will see examples online on how to query the Business Partner API using both SAP CAP Model and SAP Cloud SDK. They both pretty much do the exact same thing and as you can see there is quite a bit of overlap between SAP CAP Model and SAP Cloud SDK. And you might be wondering – why do I need to use the SAP Cloud SDK, when I can do the same thing with SAP CAP Model using the CDS Query Language ?
Overview of SAP Cloud SDK
Before we jump into the discussion of when should I use SAP Cloud SDK, let us take a step back and look at the capabilities of SAP Cloud SDK. The SAP Cloud SDK is a set of libraries and tools for developers that can do the following…
- Consumes SAP BTP services like Destination, Connectivity, IAS, XSUAA and others
- Supports multitenancy
- Provides advanced enterprise grade features like resilience and caching
- And more…
Relationship between SAP Cloud SDK and SAP CAP Model
The features of SAP Cloud SDK are invaluable for SAP CAP Model. SAP CAP Model is fully compatible with SAP Cloud SDK. In fact, SAP CAP Model uses SAP Cloud SDK behind the scenes to perform a variety of tasks. For example, to connect to any remote system in the SAP CAP Model, we make use of the following code snippet…
await cds.connect.to("remoteService");SAP CAP Model behind the scenes uses the SAP Cloud SDK to access the Destination service, fetch an access token from XSUAA service, retrieve the technical information about the remote target system from the destination configured in SAP BTP. It is then able to make a connection to the remote system depending on the authentication flow used.
Similarly, when it comes to multi-tenancy support, SAP CAP Model needs to be aware of the tenant context in the request object. This again is supported by SAP Cloud SDK. So, we see how SAP CAP Model leverages the capabilities of the SAP Cloud SDK to simplify application development.
In the example presented in the Introduction section, where we are querying the Business Partner API using both SAP CAP Model and SAP Cloud SDK, what is the recommended approach ? The recommended approach is to use the SAP CAP Model to query the Business Partner API using the CDS Query Language. For the most part, when building applications using the SAP CAP Model, you will not even be aware that the SAP CAP Model is using SAP Cloud SDK behind the covers. In fact, the recommendation in SAP CAP Model when connecting to remote services is not to directly leverage the SAP Cloud SDK in majority of the use cases.
When to use SAP Cloud SDK?
Scenario 1
There are times when you would directly leverage the capabilities SAP Cloud SDK within your SAP CAP Model application. For example, if you have a requirement within your SAP CAP Model application to retrieve the JWT token from the request object, then you can do so with the following code snippet.
const { retrieveJwt } = require("@sap-cloud-sdk/core");
const jwt = retrieveJwt(req);
Scenario 2
If you are planning to build your application using MongoDB for persistence, then you will not be able to use the CAP Model (since it only supports SAP HANA for production). In this case, you will have to build your application without using the CAP Model. In such scenarios, more than likely you will need to use the SAP Cloud SDK for connecting to remote systems, consuming APIs in a type-safe manner etc. You can also use the SAP Cloud SDK to secure your application, provide multi-tenant support etc.
Of course, this scenario is not restricted to supporting MongoDB – but any scenario where you decide not to use the CAP Model for any reason. In all these scenarios, you will use the SAP Cloud SDK directly to build your extension applications.
Scenario 3
Kyma offers a service known as function-as-a-service (FaaS) that provides a platform on which you can build, run and manage serverless applications in Kubernetes. They contain simple code snippets that implement a specific business logic. Currently, you can create these code snippets in Node.js or Python. These functions can later be consumed by applications built with a variety of UI frameworks – and even applications built using SAP Build Apps. In this scenario, you can use the SAP Cloud SDK if you are creating these code snippets using Node.js.
Scenario 4
Let’s assume that you are building a complex data model where you need to query and represent nested structures with nested references. This becomes quite difficult with the SAP CAP Model as it doesn’t provide the necessary flexibility. For example, if you need to represent HL7 FHIR resources (https://www.hl7.org/fhir/index.html) with its nested structures and nested references, then using SAP Cloud SDK is recommended.
Scenario 5
The SAP Cloud SDK for JavaScript can also be used as a frontend library when used in a browser. In a productive environment, you would configure the xs-app.json file of the approuter with the destination property pointing to the name of the destination in Cloud Foundry.
{
"source": "/service/(.*)",
"target": "/$1",
"destination": "destination_on_CF"
}
Scenario 6
If you already have an existing Java application that was built without using the SAP CAP Model and you want to add more features to it. Here again, you can make use of the SAP Cloud SDK toolset.
Scenario 7
If you need advanced features in your app (currently, not provided by SAP CAP Model) – for example, Resilience (currently not supported in the JavaScript flavor of SAP CAP Model at the time of writing this blog). SAP Cloud SDK also allows you to generate the Virtual Data Model (VDM) of custom OData Services as well as standard SAP OData Services. This VDM can then be readily consumed by your application.
Wrap up
If you are planning to build an enterprise grade side by side extension application on SAP BTP, you should start with the SAP CAP Model. If within your SAP CAP Model application, you have the option of performing a certain action using either tools provided by SAP CAP Model or SAP Cloud SDK, then you should choose the tools provided by SAP CAP Model as it abstracts the complexity involved. For example, if you have the option of consuming a remote service using CDS Query Language in your SAP CAP Model application (see example in Introduction section), then you should use the SAP CAP Model option.
If certain actions cannot be performed using tools provided by SAP CAP Model, then you should directly leverage the capabilities of SAP Cloud SDK within your SAP CAP Model application. For example, if you need to interact with certain services from SAP BTP.
Lastly, if SAP CAP Model is not an option for building your enterprise grade services or application, then you can build your application directly using the SAP Cloud SDK Java Maven archetype or TypeScript NestJS. For example, if you need to use MongoDB for persistence, then you can build your application using SAP Cloud SDK.
If you are interested in getting certified in SAP Cloud SDK, you can access the free SAP learning journey here.
Fill the gap through upskilling and enjoy SAP’s learning offerings on the SAP learning site. This article is created and brought to you by SAP Product Learning CoE experts !
