SAP S/4HANA Cloud SDK: Version 2.1.2 is Available

[HenningH]

The new version of the SAP S/4HANA Cloud SDK Java libraries is available since today. You can update your dependencies to version 2.1.2 and consume the new version from Maven Central.
In this blog post, we will walk you through the highlights of the release. For a complete overview, visit our release notes for the Java libraries. 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 version.

Java Libraries: Release Highlights

Fine granular control over request headers for OData requests

Already since version 2.0.0, the Java Virtual Data Model (VDM) for easily accessing OData services provides the option to specify custom HTTP request headers. These were always applied to both the actual OData request (e.g., GET business partners), as well as any necessary preflight requests (fetch metadata or CSRF token). However, sometimes it may be necessary to only supply a specific header to the actual request (for example, supply an If-Match header with an ETag only for the actual request).

With this new version, we improved the handling of custom request headers to also allow specifying a header that shall only be sent for the actual request. To this end, we provide a new method on fluent helpers called withCustomHttpHeader, which provides the same functionality in a fluent manner and additionally has the option to specify headers only for the actual OData request, but not any preflight request.

The syntax is slightly different than the now deprecated previously-existing withHttpHeader method. For example, to supply two headers only for the request, use code similar to the following snippet.

 service.anyOperation()

    .withCustomHttpHeader("Some Key", "Some Value")

    .and("Another Key", "Another value")

    .onRequestOnly()

    .execute()

If you want one header for all HTTP requests and another one only for the actual request, use the following:

service.anyOperation()

    .withCustomHttpHeader("Some Key", "Some Value")

    .onRequestOnly()

    .withCustomHttpHeader("Another Key", "Another value")

    .onRequestAndImplicitRequests()

    .execute()

Improvements to the Java VDM generator

We have made several improvements to the Java VDM generator that improve its usability when used in automated processes.

The generator now provides an option to exclude files from the input folder, for which no Java VDM should be generated. The option is available in the Maven plugin (<excludes>), for the command line interface (--excludes), and for the Java class (withExcludeFilePattern). It accepts an ant-style pattern such as "*us_en.xml,*DE_de.edmx". All files matching the pattern will be excluded.

Furthermore, the generator will exit normally (that is, with a non-error code) if no metadata files are found in the input folder, as well as in other error situations. Instead of throwing an exception, the generator will print a warning message in the log.

We have introduced a new annotation Key for fields in Java VDM entity classes that are defined to be part of the key of the entity in the metadata document. The annotation will be added by the default annotation strategy of the Java VDM generator. Pre-delivered Java VDM entities have this annotation applied to all key fields as well. The annotation can be used at runtime to identify the key of an entity, if needed.

Improvements to the scp-cf-tomcat archetype

The new version improves the scp-cf-tomcat archetype in order to make the setup of generated projects more aligned with the Tomcat runtime on Cloud Foundry.

Generated projects use the cargo-maven2-plugin instead of jetty-maven-plugin in local deployments to use a pure Tomcat, similar to what is used in the Cloud Foundry runtime. Accordingly, instead of mvn jetty:run, now run the local deployment in newly generated projects with mvn package cargo:run.

Furthermore, the archetype now correctly uses Tomcat instead of TomEE in integration tests.

Also, projects generated from the archetype have context and dependency injection enabled out-of-the-box using Weld.

Further Improvements

A new blog post gives a deep dive on how to use the ScpCfService class introduced in version 2.1.0 to access the Blockchain service on SAP Cloud Platform.

We fixed an issue of the previous version 2.1.0 where using a proxy with scheme http would throw an UnsupportedSchemeException. Now, you can define a proxy on destinations that is using the http scheme, instead of https.

Projects generated from the scp-cf-tomee archetype now use the jaxrs profile of the TomEE Maven plugin for parity between local deployment and deployment on Cloud Foundry with the SAP Java Buildpack.

Several further improvements are listed in the full release notes.

How to Update the 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 2.1.2.

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

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