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 2.19.1
• JavaScript libraries in version 1.6.1
• Continuous delivery toolkit in version v22

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.

On a side note, before we dive deeper into the release highlights: you can now get certified as a developer using the SAP Cloud SDK to validate your proficiency with the SDK. For more information, visit the corresponding SAP Training page.

Java Libraries: Release Highlights 2.19.1

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

Version 2.19.1 is a pure maintenance release as we prepare for the release of version 3.0 – stay tuned!

The improvements for version 2.19.1 are listed in the full release notes.

JavaScript Libraries: Release Highlights 1.6.1

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

Execute any HTTP request against a destination

Already version 1.0 of the SDK for JavaScript allows to execute OData requests involving the SAP Cloud Platform destination service for configuration and authentication out-of-the-box. Version 1.6.1 now makes the transparent interaction with the destination service available for any HTTP request. Simply specify a destination. The SDK will take care of resolving the destination and apply any authentication flow by talking to the destination service.
The highest level of convenience is available when using axios for HTTP requests, but other JavaScript HTTP libraries are supported by generic capabilities as well.

Call executeHttpRequest with a destination and the HTTP request to simply send an HTTP request using axios as HTTP request library. If you need more control, you can use buildHttpRequest to create an object with the minimal configuration for an HTTP request after resolving the destination and applying authentication. The returned object can be used as basis for an Axios request, or inspected manually. The function addDestinationToRequestConfig merges a given HTTP request object with such a minimal configuration.

The following code snippet shows how to use the API, assuming you have defined a destination named “MyDestination” in the destination service on SAP Cloud Platform (or as part of the corresponding environment variable locally):

const destination = { destinationName: "MockServerWithAuth" };
const httpRequest = {
    method: HttpMethod.GET,
    url: "/path/to/resource"
};

executeHttpRequest(destination, httpRequest)
    .then(response => console.log(response.status))
    .catch(error => console.error(error));

buildHttpRequest(destination)
    .then(config => /* use config.headers etc to build request manually */);

addDestinationToRequestConfig(destination, httpRequest)
    .then(config => Axios.request(config) /* or transform for use with other library */)
    .then(...);

Handling JWT

We now provide convenience functions for handling authentication tokes in JWT format. The function retrieveJwt extracts such a JWT as string from the headers of a HTTP request. Additionally, the convenience function verifyJwt allows to decode the JWT, including verification, provided an XSUAA service instance binding exists. A typical usage may look as follow:

const jwtString = retrieveJwt(request);
if(jwtString) {
    verifyJwt(jwtString)
        .then(decodedJwt => ...)
}

Improvements to OData client

The OData client saw several improvements.
First of all, we have published a tutorial on using the OData client generator.
Then, the generator now also emits plain JavaScript by transpiling the generated TypeScript code to JavaScript. This makes it easier to consume the OData client as a library in both TypeScript and JavaScript projects.
Version 1.6.1 of the generator supports function imports that have an OData type as return type and resolved several issues with name clashes.

The OData client classes in version 1.6.1 provide direct access to the methods serializeEntity and deserializeEntity for (de)serializing an OData entity according to the OData v2 standard. Also, custom fields of an OData entity are now serialized when passing an entity to JSON.stringify.

We have fixed an issue in the OData client where complex filters created using and or or functions resulted in an empty filter query option string. Also, version 1.6.1 fixes an issue with update requests where explicitly required fields were not correctly serialized.

Further improvements

The SDK now automatically applies the circuit breaker design pattern to provide resilience out-of-the-box while calling remote services such as destination and XSUAA service. You can disable this by passing ResilienceOptions when executing an OData request or when fetching the destination.

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

Continuous Delivery Toolkit: Release Highlights v22

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

MTA deployment extension description files can now be configured in the pipeline_config.yml for each stage that deploys to SAP Cloud Platform. This gives you more fine-granular control of the deployment with different options depending on the stage. For more information please visit the configuration guide.

The SAPUI5 best practices linting in the lint stage now supports also ECMAScript version 6. To enable es6 linting follow the instructions as described here.

Several scan tools rely on the presence of a package-lock.json file. In case of a missing package-lock.json file, the npm audit as well as the whitesource scan will not fail anymore but instead will install the npm packages and thus generate a package-lock.json on the fly that represents the used packages. To ensure reproducable builds, committing a package-lock.json file to the repository is still recommended, where possible.

We have improved error messages in multiple places to make it easier to solve issues with the pipeline and find solutions in the configuration guide.

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

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 2.19.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>2.19.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
    <!-- possibly further managed dependencies ... -->
</dependencyManagement>

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

Of course, you can also generate a new project that uses version 2.19.1 from the start by running the Maven archetypes for Neo or Cloud Foundry with -DarchetypeVersion=2.19.1 (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