SAP S/4HANA Cloud SDK: Version 1.11.1 is Available
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
I liked your topic and it helped me a lot. I am sure info will help you a lot.
Improvements
Change log (16.05.2018):