We have released new versions of the SAP Cloud SDK (formerly known as SAP S/4HANA Cloud SDK). In detail, the following components are now available in new versions:
The biggest news of this week, however, was probably the announcement of the SAP Cloud SDK as the next step and new name for the SAP S/4HANA Cloud SDK. Read more about how this enables you to leverage the benefits of the SDK for extending many more SAP solutions in this news article. For now, technical artifact names on source code level remain unchanged. You do not need to change your source code or dependencies; simply continue to use the SDK as known from the SAP S/4HANA Cloud SDK to leverage the SAP Cloud SDK.
In this blog post, we will walk you through the highlights of the new releases. For a complete overview, visit our release notes for the Java libraries, for the JavaScript libraries, and for the continuous delivery toolkit. The release notes also include the change log of all our releases so far.
At the end of the article, you will find a set of instructions on how to update to the new versions.
You can update your dependencies of the SAP Cloud SDK for Java to version 2.16.0 and consume the new version from Maven Central.
This week also saw the SAP Cloud Platform Extension Factory becoming generally available. Extension Factory is SAP's cloud-native extensibility framework. One major benefit is that it allows you to easily connect SAP S/4HANA Cloud systems to your account on SAP Cloud Platform, with a few simple steps. The SAP Cloud SDK is then the final piece of the puzzle to communicate with the thus-connected system from your application's source code.
As such, version 2.16.0 of the SAP Cloud SDK brings native support for communicating with SAP Cloud Platform Extension Factory. With the following new capabilities of the SDK, you can start leveraging Extension Factory in your application right now .
A bit of background: SAP Cloud Platform Extension Factory represents connected APIs of SAP S/4HANA Cloud as named service instances and binds those service instances to applications on Cloud Foundry. Thus, SAP S/4HANA Cloud APIs essentially become services bound to your application, contained in the
This comes in addition the well-known destination service, which you will still use for APIs not yet available in Extension Factory, for multi-tenant applications, or in other cases where you or your customers may not use Extension Factory.
To support Extension Factory and destination service, version 2.16.0 of the SDK brings two new capabilities. First, we introduce a
Assuming the common use case that you want to allow connections via Extension Factory, but at the same time still use the destination service on Cloud Foundry, you can achieve this by running the following code at startup of your application to declare the destination lookup strategy:
With the above configuration applied before instantiating any
The OData VDM now supports sending update request to OData APIs with
We have updated the version of the Tomcat server used in projects created by the
Several further improvements are listed in the full release notes.
The JavaScript libraries of the SAP Cloud SDK are now available in version 1.2.1.
Version 1.2.1 allows connecting to SAP S/4HANA on-premise via the Cloud Connector and SAP Cloud Platform connectivity service. When executing an OData request using the OData VDM, the SDK will apply the necessary steps to connect to SAP S/4HANA on-premise where required.
No code change is necessary to use this feature. On-premise connections are handled transparently by the SAP Cloud SDK where configured. The SDK will proxy requests to destinations with proxy type
Version 1.2.1 allows to mock the destination service of SAP Cloud Platform centrally during tests. In addition to the previously available feature to load destinations manually from
To centrally mock all destinations defined in
We have fixed an issue with error handling for OData requests that would result in
As usual, the full release notes contain a list of all improvements in this release.
We have also released versions v18 and v19 of our out-of-the-box continuous delivery offering consisting of a ready-made Jenkins server and a complete delivery toolkit.
This release significantly enhances the support for projects based on the SAP Cloud Application Programming Model. All stages listed in the MTA column of the feature matrix are supported. We will describe the requirements to be fulfilled by projects to use this capability in a future blog post.
For JavaScript projects, the pipeline now checks the line code coverage of unit and integration tests. It will show the correspondings graphs in the Jenkins user interface. The pipeline will fail once code coverage drops below 65%.
The pipeline for JavaScript projects now also supports the handling of credentials for systems like SAP S/4HANA used in integration tests via the configuration options known from the pipeline for Java.
You can find further fixes and improvements in the complete release notes.
To update the version of the SAP Cloud SDK Java libraries used in an existing project, proceed as follows:
With this, you are already done thanks to the "bill of material" (BOM) approach. Your dependency should look like this:
If you are using the SAP Cloud SDK in a project of the SAP Cloud Application Programming Model, replace
You can now recompile your project (be aware of the compatibility notes, though) and leverage the new features of the SAP Cloud SDK in version 2.16.0.
Of course, you can also generate a new project that uses version 2.16.0 from the start by running the Maven archetypes for Neo or Cloud Foundry with
To update the version of the SAP Cloud SDK JavaScript libraries used in an existing project, use the command
If you are using the pipeline with a fixed version (as recommended since v7), update the continuous delivery toolkit with the following command, that you run on the server hosting the cx-server:
- Java libraries in version 2.16.0
- JavaScript libraries in version 1.2.1
- Continuous delivery toolkit in versions v19
The biggest news of this week, however, was probably the announcement of the SAP Cloud SDK as the next step and new name for the SAP S/4HANA Cloud SDK. Read more about how this enables you to leverage the benefits of the SDK for extending many more SAP solutions in this news article. For now, technical artifact names on source code level remain unchanged. You do not need to change your source code or dependencies; simply continue to use the SDK as known from the SAP S/4HANA Cloud SDK to leverage the SAP Cloud SDK.
In this blog post, we will walk you through the highlights of the new releases. For a complete overview, visit our release notes for the Java libraries, for the JavaScript libraries, and for the continuous delivery toolkit. The release notes also include the change log of all our releases so far.
At the end of the article, you will find a set of instructions on how to update to the new versions.
Java Libraries: Release Highlights 2.16.0
You can update your dependencies of the SAP Cloud SDK for Java to version 2.16.0 and consume the new version from Maven Central.
Support for SAP Cloud Platform Extension Factory
This week also saw the SAP Cloud Platform Extension Factory becoming generally available. Extension Factory is SAP's cloud-native extensibility framework. One major benefit is that it allows you to easily connect SAP S/4HANA Cloud systems to your account on SAP Cloud Platform, with a few simple steps. The SAP Cloud SDK is then the final piece of the puzzle to communicate with the thus-connected system from your application's source code.
As such, version 2.16.0 of the SAP Cloud SDK brings native support for communicating with SAP Cloud Platform Extension Factory. With the following new capabilities of the SDK, you can start leveraging Extension Factory in your application right now .
A bit of background: SAP Cloud Platform Extension Factory represents connected APIs of SAP S/4HANA Cloud as named service instances and binds those service instances to applications on Cloud Foundry. Thus, SAP S/4HANA Cloud APIs essentially become services bound to your application, contained in the
VCAP_SERVICES environment variable in Cloud Foundry, much like other services on SAP Cloud Platform.This comes in addition the well-known destination service, which you will still use for APIs not yet available in Extension Factory, for multi-tenant applications, or in other cases where you or your customers may not use Extension Factory.
To support Extension Factory and destination service, version 2.16.0 of the SDK brings two new capabilities. First, we introduce a
ScpXfDestinationFacade to read destinations from the VCAP_SERVICES environment variable in Cloud Foundry (as used by Extension Factory). Second, we introduce a FallbackDestinationFacade to use destination service and extension factory in parallel. The FallbackDestinationFacade allows to specify as constructor parameters one primary DestinationFacade and a secondary facade as fallback that is used if no destination of a given name is found using the primary facade. In essence, this generalizes the destination concept so that destinations do not necessarily only come from the destination service, but also via Extension Factory.Assuming the common use case that you want to allow connections via Extension Factory, but at the same time still use the destination service on Cloud Foundry, you can achieve this by running the following code at startup of your application to declare the destination lookup strategy:
DestinationAccessor
.setDestinationFacade(
new FallbackDestinationFacade(
new ScpXfDestinationFacade(),
new ScpCfDestinationFacade()));With the above configuration applied before instantiating any
ErpConfigContext or other reference to a destination, whenever a destination named s4hana shall be accessed (for example, via execute(new ErpConfigContext("s4hana")) in the OData VDM), the SAP Cloud SDK will first look for a service with this name bound via Extension Factory. It will only consult the destination service for a destination of this name if no such service is found. You can in the same manner also define other lookup strategies. For compatibility reasons, the default behavior remains using the destination service only.Further improvements
The OData VDM now supports sending update request to OData APIs with
PUT semantics (replace). While PATCH remains the default, you can now control the HTTP method and strategy to use for update requests via the following Java methods. To use HTTP method PUT and send the full entity that is meant to replace the current state of the entity, call replacingEntity on any fluent helper for update requests. To revert to using PATCH and only send changed fields (which is also the default if nothing is specified), call modifyingEntity.We have updated the version of the Tomcat server used in projects created by the
scp-cf-tomcat archetype to version 8.5.40 (from 8.5.23) due to a known vulnerability (CVE-2019-0232). If you have created a project using the archetype before, we suggest to update to the new version manually.Several further improvements are listed in the full release notes.
JavaScript Libraries: Release Highlights 1.2.1
The JavaScript libraries of the SAP Cloud SDK are now available in version 1.2.1.
Connection to SAP S/4HANA on-premise
Version 1.2.1 allows connecting to SAP S/4HANA on-premise via the Cloud Connector and SAP Cloud Platform connectivity service. When executing an OData request using the OData VDM, the SDK will apply the necessary steps to connect to SAP S/4HANA on-premise where required.
No code change is necessary to use this feature. On-premise connections are handled transparently by the SAP Cloud SDK where configured. The SDK will proxy requests to destinations with proxy type
OnPremise through the cloud connector if an instance of the connectivity service is bound to the application. Only the necessary setup is required as described in the documentation for on-premise connectivity.Mocking destinations
Version 1.2.1 allows to mock the destination service of SAP Cloud Platform centrally during tests. In addition to the previously available feature to load destinations manually from
systems.json and inject them where needed, you can now mock destinations centrally. Destinations mocked in this way will transparently be available wherever destinations are fetched by name.To centrally mock all destinations defined in
systems.json (together with credential defined in a credentials.json file), call mockAllTestDestinations. To mock a single destination, use mockTestDestination.Further improvements
We have fixed an issue with error handling for OData requests that would result in
UnhandledPromiseRejections.As usual, the full release notes contain a list of all improvements in this release.
Continuous Delivery Toolkit: Release Highlights v18 & v19
We have also released versions v18 and v19 of our out-of-the-box continuous delivery offering consisting of a ready-made Jenkins server and a complete delivery toolkit.
Support for SAP Cloud Application Programming Model
This release significantly enhances the support for projects based on the SAP Cloud Application Programming Model. All stages listed in the MTA column of the feature matrix are supported. We will describe the requirements to be fulfilled by projects to use this capability in a future blog post.
Further improvements
For JavaScript projects, the pipeline now checks the line code coverage of unit and integration tests. It will show the correspondings graphs in the Jenkins user interface. The pipeline will fail once code coverage drops below 65%.
The pipeline for JavaScript projects now also supports the handling of credentials for systems like SAP S/4HANA used in integration tests via the configuration options known from the pipeline for Java.
You can find further fixes and improvements in the complete release notes.
How to Update
Java libraries
To update the version of the SAP Cloud SDK Java libraries used in an existing project, proceed as follows:
- Open the pom.xml file in the root folder of your project.
- Locate the dependency management section and therein the
sdk-bomdependency. - Update the version of that dependency to
2.16.0.
With this, you are already done thanks to the "bill of material" (BOM) approach. Your dependency should look like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.sap.cloud.s4hana</groupId>
<artifactId>sdk-bom</artifactId>
<version>2.16.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
<!-- possibly further managed dependencies ... -->
</dependencyManagement>If you are using the SAP Cloud SDK in a project of the SAP Cloud Application Programming Model, replace
sdk-bom with sdk-modules-bom to only update the version of SDK modules, not further dependencies.You can now recompile your project (be aware of the compatibility notes, though) and leverage the new features of the SAP Cloud SDK in version 2.16.0.
Of course, you can also generate a new project that uses version 2.16.0 from the start by running the Maven archetypes for Neo or Cloud Foundry with
-DarchetypeVersion=2.16.0 (or RELEASE).JavaScript libraries
To update the version of the SAP Cloud SDK JavaScript libraries used in an existing project, use the command
npm update in the root folder of your module. Note that this will also update other modules, unless you explicitly specify which packages to update. If you want to check beforehand what will change, use npm outdated.Continuous Delivery Toolkit
If you are using the pipeline with a fixed version (as recommended since v7), update the continuous delivery toolkit with the following command, that you run on the server hosting the cx-server:
./cx-server update image- SAP Managed Tags:
