We have released new versions of the
SAP Cloud SDK. In detail, the following components are now available in new versions:
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.
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