The new version of the SAP S/4HANA Cloud SDK Java libraries is available. You can update your dependencies to version 2.1.0 and consume the new version from Maven Central. We have also released version v8 of our out-of-the-box continuous delivery offering consisting of a ready-made Jenkins server and a complete delivery toolkit.
In this blog post, we will walk you through the highlights of these releases. For a complete overview, visit our release notes for the Java 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.
Watch out for our new book Extending SAP S/4HANA. Side-by-Side Extensions with the SAP S/4HANA Cloud SDK, in stores since May 30th, 2018. It features the complete end-to-end story of building extensions for SAP S/4HANA using the SAP S/4HANA Cloud SDK, with many code examples and in-depth explanations.
Java Libraries: Release Highlights
Experimental Access to Cloud Foundry Services
Version 2.1.0 contains a still experimental class
ScpCfService that gives easy access to services on Cloud Foundry defined in the
VCAP_SERVICES environment variable. It includes methods for quickly retrieving the URIs and credentials for the service, as well as for adding required bearer token headers according to OAuth2 authentication flow.
You can, for example, use the experimental class to access services on SAP Cloud Platform, Cloud Foundry for machine learning or Blockchain integration. Instantiate an object of the class using the
ScpCfService.of constructor method, access the base URL for calling the service with the method
getServiceLocationInfo, and use the method
addBearerTokenHeader to apply required authorization headers to an HTTP request.
GDPR-Compliant Audit Logging
The new General Data Protection Regulation (GDPR) came into effect end of May 2018. It also mandates changes in the way events relating to personal data shall be audited. As a consequence, SAP released a new version of the audit logging Java libraries for Cloud Foundry (
com.sap.xs.auditlog). The SAP S/4HANA Cloud SDK includes abstractions for easily accessing the audit logging service on SAP Cloud Platform, which we have updated to the new API with version 2.1.0 of the SAP S/4HANA Cloud SDK.
The new libraries required several adaptations to the API of the module
- We have introduced two new classes
AuditedDataObjectfor information about the data being accessed/modified and
AuditableDataSubjectfor the owner of the data being accessed/modified. Wherever the API previously expected String-typed parameters
objectName, it now requires objects of the two new classes instead.
- Tenant identifiers have been added to
AccessRequesterobjects. When using the
ofCurrentRequestconstructor method, the tenant will be automatically retrieved from the current request. If you experience issues with tenant identifiers in tests, make sure to mock the tenant using
- We have removed unused String-typed parameters
messageexcept for security event audit log messages.
New Tutorial Deep Dives
Over the past weeks, we have published several new deep dives as part of our tutorial series.
The blog post Quickly build a prototype with SAP Leonardo Machine Learning Foundation, SAP API Business Hub, and SAP S/4HANA Cloud SDK describes step-by-step how to build an application with the SAP S/4HANA Cloud SDK that leverages machine learning services.
Deep dive 11 explains how you can use the SAP S/4HANA Cloud SDK in SAP WebIDE to call an OData service in SAP S/4HANA.
Deep dive 12 shows how you can easily integrate SAP S/4HANA into applications built with the Business Application programming model of SAP Cloud Platform, thanks to the out-of-the-box integration of the SAP S/4HANA Cloud SDK.
Projects generated from the archetypes of the SAP S/4HANA Cloud SDK now have logging consistently set up. At runtime, Logback is used as the implementation of
slf4j. Furthermore, like the other archetypes, projects created by the
scp-cf-spring archetype log in the JSON format suitable for use in Kibana when run on Cloud Foundry. Locally, a human-readable format is used. Unit and integration tests in all archetypes use
slf4j-simple, so that the log level can easily be configured using the Maven command line parameter
We have replaced the SDK-specific
JwtDecoder classes in favor of using the
java-jwt library and its
DecodedJWT class. The JWT token is now explicitly validated, instead of implicitly relying on the security setup.
This release updates the Apache HTTP client libraries to 4.4.9 (
httpcore) and 4.5.5 (client libraries).
Several further improvements are listed in the full release notes.
Continuous Delivery Toolkit: Release Highlights
Using the cx-server on Windows
The server of the continuous delivery toolkit (
cx-server) that runs the Jenkins instance and other tools is optimized for running on Linux machines. With version 8, you can now use the
cx-server on Windows for evaluation purposes. This feature lowers the barrier to try out the continuous delivery toolkit for all Windows users, because you don’t need to get a Linux server just to try it out anymore.
To test the
cx-server on Windows, simply run the
cx-server.bat script, which is now generated by the archetypes in addition to the Linux script in the folder
cx-server. Both now use a dockerized script for starting the
cx-server – see the architecture decision record for additional background information.
Please note that only a subset of the
cx-server commands is supported on Windows. Running the
cx-server on Windows is not intended for running a productive instance of the
As part of the introduction of
cx-server on Windows, we have also automated the update of the
cx-server script, so running
cx-server update script is not required anymore after you have once updated to this new version.
The WhiteSource configuration has changed. Before, the
orgToken was configured directly in
pipeline_config.yml. Now, it has to be configured as a secret in Jenkins and the
credentialsId needs to be configured in
pipeline_config.yml. See the updated documentation for further info.
Also, we removed the need to configure WhiteSource in two places (
whitesource.config.json for the frontend and
pipeline_config.yml for the backend). Now, the frontend configuration is generated from
pipeline_config.yml, which means that the
whitesource.config.json has to be deleted in order to avoid name clashes.
Checkmarx and WhiteSource checks have been disabled for pull requests to speed up the build. Both checks are only run on the productive branch now, since they usually take quite a lot of time.
Frontend unit tests are by default no longer run with the
--headless parameter. Since we cannot assume that the application developer always implements the
--headless parameter, we instead provide an X server and leave the decision to the application developer. If your frontend unit tests need the
--headless parameter, please add it to your
npm ci-test script in
You can find further fixes and improvements in the complete release notes.
How to Update
To update the version of the SAP S/4HANA 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.1.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> <!-- possibly further managed dependencies ... --> </dependencyManagement>
You can now recompile your project (be aware of the compatibility notes, though) and leverage the new features of the SAP S/4HANA Cloud SDK in version 2.1.0.
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