Skip to Content

The new version of the SAP S/4HANA Cloud SDK Java libraries is available since today. You can update your dependencies to version 1.7.1 and consume the new version from Maven Central. We have also released version v4 of our out-of-the-box continuous delivery offering 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 pipeline. 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

On-premise Connectivity on Cloud Foundry

Since version 1.6.0, the SAP S/4HANA Cloud SDK makes it very easy also on Cloud Foundry to access destinations that specify how to connect to an system such as SAP S/4HANA. With this release, the system to connect to can also reside on premise. The SAP S/4HANA Cloud SDK handles everything that is required for the connectivity, like it already does since the first release on SAP Cloud Platform Neo.

Note: the destination service on Cloud Foundry is available in beta.

To enable on-premise connectivity, customers must set-up a Cloud Connector and configure connectivity with Cloud Foundry. Your application needs to bind to the Connectivity Service on Cloud Foundry. A new deep dive explains this connectivity setup to SAP S/4HANA on-premise and Cloud in detail. The SAP S/4HANA Cloud SDK then transparently handles all required steps and HTTP headers. As a developer, you do not need to consider whether the destination is on-premise or Cloud. No changes to existing code using the SAP S/4HANA Cloud SDK are necessary to adopt this functionality.

For authentication, the SDK supports both principal propagation and basic authentication via the corresponding configuration of the destination, again, without any coding changes.

New Archetype for Java EE 7 on Neo

The Neo environment of SAP Cloud Platform provides support for Java EE 7 via the recently introduced Java EE 7 Web Profile TomEE 7. This profile supports Java 8. The SAP S/4HANA Cloud SDK already included an archetype for the Java EE 6 Web Profile. Now, we have introduced a new archetype for the Java EE 7 profile, called scp-neo-javaee7.

To generate a project using the new archetype, use the following command (adapted from Step 2: HelloWorld on Neo):

mvn archetype:generate -DarchetypeGroupId=com.sap.cloud.s4hana.archetypes -DarchetypeArtifactId=scp-neo-javaee7 -DarchetypeVersion=LATEST

Important Note: We plan to retire the support for the Java EE 6 profile on Neo in the near future, as well as to discontinue supporting Java 7 in general. Hence, in a future version we will remove the support for Java 7. If possible, create new projects in the Cloud Foundry environment or use the new archetype for Java EE 7 on Neo, and investigate if you can move to Java 8.

Further Improvements

We provide an API about the state of feature toggles via the FeatureToggleServlet. This can be used, for example, by the frontend of an application to determine the state of feature toggles defined using the Togglz framework integration of the SAP S/4HANA Cloud SDK.

As part of the Liquibase integration, we provide helpers for onboarding and offboarding tenants in case of schema-per-tenant based multi-tenancy on the persistence layer. Take a look at the SchemaPerTenantProvisioner for more details and our blog post Deep Dive 6: Tenant-Aware Persistency on how to integrate this into your application (the SchemaPerTenantProvisioner provides the functionality used by DefaultTenantProvisioningService in the blog).

We added a new LogInputSanitizer that can be used during logging to prevent log forging. When used to sanitize parameters to logging statements, the LogInputSanitizer will append an (END_OF_LOG_ENTRY) token to each entry and remove any occurrence of this token from the log message itself, so that you can clearly identify each separate log entry.

We have replaced the third party library used for mocking server: instead of MockServer, corresponding methods of MockUtil now use WireMock. If you have used methods such as MockUtil.mockErpServer or MockUtil.mockServer before to setup mocked servers during your tests, take a look at Getting Started with WireMock.

Helper classes for managing concurrency on SAP Cloud Platform Neo have moved to a separate Maven module com.sap.cloud.s4hana.cloudplatform:concurrency-scp-neo, which allows you to use a minimal set of dependencies if you only need this functionality of the SDK.

Many more improvements and bug fixes can be found in the complete release notes. Also pay attention to the compatibility notes mentioned therein.

Continuous Delivery Pipeline: Release Highlights

Parallel Execution of Tests

End-to-end tests as well as deployments to production can target multiple Cloud Foundry spaces or multiple Neo accounts. If you define more than one target, you may want to deploy and test each target in parallel. You can now enable the parallel deployment of the application and the parallel execution of tests via a global feature toggle parallelTestExecution.

When the toggle is switched on, deployment during the end-to-end test and during production deployment stages happens in parallel for all of the targets in each stage, as well as the execution of tests in the end-to-end test stage (one test run per deployed target). This can greatly decrease the total time of the pipeline. However, parallel execution is not properly displayed in the Blue Ocean theme, which is why the feature is turned off by default (i.e., deployment and test are each done sequentially, one target at a time). If you turn it on to enable parallel deployment and end-to-end tests, please use the classic Jenkins theme.

Further Improvements

The default npm registry can be configured via the pipeline configuration in the pipeline_config.yml file, for example, if you want to configure a mirror or internal repository to use. See the documentation for the executeNpm step configuration.

We added documentation on the available configuration for the artifact deployment stage. Check out the documentation to learn how you can configure the deployment to Nexus. These options had been introduced in the prior release v3.

The shared memory size of the docker container used during end-to-end tests is explicitly increased from 64 MB to 512 MB in order to load heavy webpages via Chrome.

Last, but not least, we have released a new tutorial step Step 23: Performance Tests, which explains how you can run performance tests written with Gatling or JMeter as part of the continuous delivery pipeline of the SAP S/4HANA Cloud SDK.

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.7.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.7.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.7.1.

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

Continuous Delivery Pipeline

If you are using the pipeline as offered out-of-the-box and did not specify any specific version, you will automatically use the latest version.

To update the Jenkins image as used by the cx-server script, run the following commands on the server hosting the cx-server:

./cx-server stop
./cx-server remove
./cx-server start
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply