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:
- Java libraries in version 2.16.0
- 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.
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.
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
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.
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.
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
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.
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.
You can find further fixes and improvements in the complete release notes.
How to Update
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
- Update the version of that dependency to
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-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.
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
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