We have released new versions of the SAP Cloud SDK. In detail, the following components are now available in new versions:

• Java libraries in version 3.11.0
• Java libraries in version 2.26.0
• JavaScript libraries in version 1.15.1
• Continuous delivery toolkit in version v28

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, for the JavaScript 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 3.11.0

Please note that the previous issues with not-correctly uploaded artifacts is now resolved. 3.11.0 can be consumed from Maven Central as usual.

You can update your dependencies of the SAP Cloud SDK for Java to version 3.11.0 and consume the new version from Maven Central.

Principal from basic authentication

In this version we introduce a new BasicAuthenticationAccessor to read the username and password from a Basic Authentication header of the currently incoming request on Cloud Foundry.

• Use it like the other *Accessor classes at any point while handling a request:

  Try<BasicCredentials> basicCredentials = BasicAuthenticationAccessor.tryGetCurrentBasicCredentials();

• To handle the Try gracefully you can write something like the following:

  BasicCredentials basicCredentials  = BasicAuthenticationAccessor.tryGetCurrentBasicCredentials().getOrElseGet(this::useFallbackCredentials);

• To provide custom logic into the accessor the default logic can be overwritten by using the setBasicAuthenticationFacade method:

  BasicAuthenticationAccessor.setBasicAuthenticationFacade(new CustomBasicAuthenticationFacade());

The PrincipalAccessor now also reads the current principal from the newly introduced BasicAuthenticationAccessor, in addition to the already existing way to read it from the current JWT. This functionality applies to Cloud Foundry. A valid JWT takes precedence over a Basic Authentication header.
The order of resolution is:

1. If a principal is given in the current context (e.g. via PrincipalAccessor.executeWithPrincipal(...)), this will we be used.
2. Otherwise, if a JWT is given in the current context (e.g. via an incoming request or manually set via the AuthTokenAccessor.executeWithAuthToken(...) methods) the principal is read from there.
3. Otherwise, If there is no JWT or the resolution fails the user retrieved via the BasicAuthenticationAccessor used (if existent).
4. If no principal could be found with the steps above the Try returned by PrincipalAccessor.tryGetCurrentPrincipal() will contain an Exception.

Please take note that, as before, the SDK does not validate the correctness of the supplied authentication, which, along with authorization checks, is the responsibility of the application. For example, if you do not want to allow basic authentication, it is your responsibility to disallow corresponding requests. Still, our corresponding tutorial gives hints on how to realize that.

Further improvements

Accessing on-premise systems from SCP Cloud Foundry was updated, so that the authentication now follows the recommended protocol for principal propagation:

• Instead of populating two headers SAP-Connectivity-Authentication and Proxy-Authorization for on-premise requests, the SAP Cloud SDK now takes the recommended approach of just using Proxy-Authorization with a dynamicly resolved User Exchange Access Token.
• We have introduced a PrincipalPropagationStrategy for configuring that the previous behavior should be used.
• If for compatibility reasons the previous approach should be used, you can adjust strategy with the following code snippet:

  import com.sap.cloud.sdk.cloudplatform.connectivity.PrincipalPropagationStrategy;
  PrincipalPropagationStrategy.setDefaultStrategy(PrincipalPropagationStrategy.COMPATIBILITY);

We also added support for self-signed certificates (file extensions .cer, .crt, and .der) as trust store locations for HTTPS destinations.

Several further improvements are listed in the full release notes.

Java Libraries: Release Highlights 2.26.0

We have also released the SDK for Java in a new maintenance version 2.26.0. Everyone who did not yet upgrade to version 3 of the SDK for Java can consume that version from Maven Central.

For a complete view on what has changed, take a look at the full release notes.

JavaScript Libraries: Release Highlights 1.15.1

The JavaScript libraries of the SAP Cloud SDK are now available in version 1.15.1.

Among several improvements, this version fixes an issue where creating batch requests with changeset did not enforce type safety. Now a batch can contain only changesets on entities of the given service instead of entities from different services.

As usual, the full release notes contain a list of all improvements in this release.

Continuous Delivery Toolkit: Release Highlights v28

We have also released version v28 of our out-of-the-box continuous delivery offering consisting of a ready-made Jenkins server and a complete delivery toolkit.

Support for JavaScript in MTA projects

With this release, we officially support JavaScript backends within projects that are build as Multi-Target Applications (MTA). In addition to building those modules as required, JavaScript backends can make use of unit tests and integration tests in the pipeline now. Read our build tools documentation for usage instructions and limitations.

Further improvements

In this version the new Cloud MTA build tool (available as an option since v27) is used by default to build Multi-Target Applications (MTA). Please note that your mta.yaml file might need some adjustments to work with the new MTA tool version. Read the documentation for more details on how to upgrate to the latest MTA build tool version. You can still use the classic MTA build tool by specifying it explicitly in the pipeline configuration.

We also updated the resilience quality check and the check for unofficial API to work with SAP Cloud SDK version 3.

How to Update

Java libraries

To update the version of the SAP 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 3.11.0.

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.sdk</groupId>
            <artifactId>sdk-bom</artifactId>
            <version>3.11.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
    <!-- possibly further managed dependencies ... -->
</dependencyManagement>

If you update from a version prior to 3.0.0, have a look at our migration guide.

If you are using the SAP Cloud SDK in a project of the SAP Cloud Application Programming Model, replace sdk-bom with sdk-modules-bom to only update the version of SDK modules, not further dependencies.
You can now recompile your project (be aware of the compatibility notes, though) and leverage the new features of the SAP Cloud SDK in version 3.11.0.

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

JavaScript libraries

To update the version of the SAP Cloud SDK JavaScript libraries used in an existing project, use the command npm update in the root folder of your module. Note that this will also update other modules, unless you explicitly specify which packages to update. If you want to check beforehand what will change, use npm outdated.

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