The new version of the SAP S/4HANA Cloud SDK Java libraries is available since today. You can update your dependencies to version 1.11.1 and consume the new version from Maven Central. We have also released version v7 of our out-of-the-box continuous delivery toolkit consisting of a ready-made Jenkins server and a complete delivery pipeline.
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.

Java Libraries: Release Highlights

Improvements to the Java VDM generator

With version 1.10.0, we have released the Java VDM generator that allows you to create a Java VDM for your OData services. This release 1.11.1 brings a few improvements to the generator. If you have used the generator before, simply update the version and re-generate your VDM to benefit from these improvements.

In detail, we have improved the naming of Java identifiers based on the names from the OData metadata document. If there were name conflicts in generated Java code, for example, due to duplicate labels, the generator now appends an underscore followed by an integer counter to make the identifier unique. This applies to names of entity classes, complex types, member variables within entity & complex type classes, methods for navigation properties, and methods & parameters of function imports.

The generator also by default removes characters from OData property and entity names and labels that are invalid in Java syntax.

To make it clear to which OData entity or property a Java element refers, the generator adds the original name of entities and properties as specified in the OData entity metadata to the Javadoc documentation of the generated classes.

We have added an option to the generator to only generate the entity POJO classes, but not any service classes or fluent helpers. This is helpful for example in OData v2 provisioning scenarios using the SAP Cloud Platform SDK for service development. You can generate POJOs for your metadata document of the OData v2 service that you provide. You can then use them for type-safety and ease-of-use in the Java methods that implement certain OData operations. To only generate POJOs, use the command line option --generate-pojo-only, set the Maven configuration pojosOnly to true, or use the method DataModelGenerator.pojosOnly(), depending on the way you call the generator.

You can control which annotations the generator generates for POJO classes and fields by supplying a custom AnnotationStrategy. This works independent of the POJO only option and allows adapting the POJOs to, for example, different JSON serialization frameworks or other use cases that require specific annotations to be present on the class or fields of POJOs.

Finally, you can now also supply the metadata document in files with the extension .xml, in addition to .edmx.

We have also published a deep dive blog post that explains the usage of the generator in detail.

Update Requests

Update requests with the VDM for OData services send only updated fields of an entity as opposed to sending the entire entity. A field is considered updated if it has been changed using the setter for this field on the Java object.

This is the behavior expected by PATCH requests according to the OData specification.
You can manually include further fields and their values in the request by supplying their representation to the includingFields method of the fluent helper. This may sometimes be required if a service in an SAP S/4HANA system expects certain fields as mandatory input. The syntax of using this method is similar to the select method for query options.

You may need to adapt the logic in your code to explicitly change fields by using the setters of the entity classes, or use the includingFields method to manually specify fields to include.

Further Improvements

We fixed an issue where sorting with the VDM for OData services would not work correctly.

Several further improvements are listed in the full release notes.

Continuous Delivery Toolkit: Release Highlights

Automatic Update

In version v7 of the Continuous Delivery Toolkit, we focussed on making operations simpler. Updating the cx-server of the continuous delivery toolkit so far required to manually backup and stop the server, update the docker image, and restart the server. Also, the cx-server used by default always the latest available state. The following line in server.cfg: specified this: docker_image="s4sdk/jenkins-master:latest". The latest available state referenced by this is not necessarily a released version, but could be a state between versions depending on the time of the manual update.

Starting from version v7, you can automatically and safely update to the latest released version of our s4sdk-jenkins-master Docker image using the command line command ./cx-server update image. The command will automatically create a backup, stop the server, update the image, and restart the server, combining the commands that you previously needed to execute manually. More details can be found in the operations guide. This new feature allows you to stay up-to-date with our latest released version easily, without the issues you might face if you’re on the latest tag, which might change at any time.

To leverage the new update functionality and use fixed versions from now on, we recommend you adapt your server.cfg file and replace docker_image="s4sdk/jenkins-master:latest" with docker_image="s4sdk/jenkins-master:v6". Afterwards, once run ./cx-server update to retrieve the latest version of the script, then run ./cx-server update image to update to v7.

Note: From now onwards, to update the cx-server script itself, you have to use ./cx-server update script (instead of just ./cx-server update).

Further Improvements

We have created a new overview on which qualities are checked in the pipeline.

The step executeMaven was renamed to mavenExecute in order to align with jenkins-library. Please update your pipeline_config.yaml file accordingly. As of v7, there is a mapping of the old and the new name, but this will be removed in a future version.

Deploying the build artifacts to Nexus now happens before the productive deployment to Cloud Platform. Both happened in parallel in previous versions. This change ensures that all artifacts which are deployed to SAP Cloud Platform are in Nexus.

The pipeline will now abort older builds for changes on non-productive branches. This change minimizes the workload on the build server for multiple updates on a feature branch or pull request.

You can find further fixes and improvements in the complete release notes.

How to Update

Java Libraries

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 sdk-bom dependency.
• Update the version of that dependency to 1.11.1.

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>1.11.1</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 1.11.1.

Of course, you can also generate a new project that uses version 1.11.1 from the start by running the Maven archetypes for Neo or Cloud Foundry with -DarchetypeVersion=1.11.1 (or RELEASE).

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