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.
In case you have not attended our SAP Community Call last week, take a look at the recording on Youtube to see how to leverage the SAP Cloud SDK for continuous delivery in SAP Cloud Application Programming Model projects.
Java Libraries: Release Highlights 3.5.0
You can update your dependencies of the SAP Cloud SDK for Java to version 3.5.0 and consume the new version from
Maven Central.
We have made the SDK more lenient when looking for an access token in incoming HTTP requests. Previous versions of the SDK only recognized an access token in the authorization header if "
Bearer
" was spelled in title case. Now, corresponding methods do a case insensitive check for "
bearer
". That means, "bearer" and "Bearer" are now equally supported as correct authorization header. This makes the SDK also usable in environments where the header is not capitalized according to the standard.
The
OData VDM generator now identifies which CRUD operations an entity set supports by first consulting the
annotations based on the OData specification. Only when these annotations are not declared, the custom SAP specifications are considered as before.
With version 3.5.0, we no longer always require a binding to an XSUAA service instance when consuming the destination or connectivity service via the SDK.
Several further improvements are listed in the
full release notes.
Java Libraries: Release Highlights 2.22.0
We have also released the SDK for Java in a new maintenance version 2.22.0. Everyone who did not yet
migrate 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.11.2
The
JavaScript libraries of the SAP Cloud SDK are now available in version 1.11.2. Please note that we have not released a new version 1.11.2 of the OData client generator (module
@Sisn/cloud-sdk-generator
) due to technical reasons. 1.10.0 remains the current version of the generator. As a consequence, the new features of the OData client mentioned below (such as batch and CSN files) are not yet available for custom OData clients generated with the generator. We plan to release a new version of the generator soon.
Batch support
The
OData client for SAP S/4HANA Cloud APIs now supports
batch processing of
update
,
create
, and
delete
operations, as well as retrieve requests (query and read-by-key) within batch requests. With this, you can group several OData operations as a single request to a system to improve performance and achieve transactional behavior via change sets.
Take a look at the following code snippet to get an impression of how the SDK makes it easy to construct and send a batch request. At the example of the business partner service, it shows how to batch a sample retrieve request with a change set that groups exemplary create and delete requests.
import { batch, BusinessPartner, changeset } from '@sap/cloud-sdk-vdm-business-partner-service';
// construct requests as usual, but do not execute them
const retrieveRequest = BusinessPartner.requestBuilder().getAll().top(10);
const createRequest = BusinessPartner.requestBuilder().create(entityToCreate);
const deleteRequest = BusinessPartner.requestBuilder().create(entityToDelete);
// construct changeset and batch request
const transaction = changeset(createRequest, deleteRequest);
const response = await batch(retrieveRequest, transaction)
.execute({destinationName: 'S4HANA'});
In general, use the new method
batch
that each module for a OData service exposes (see
this example for the business partner service) to
construct a batch request. Pass prepared query and by-key request builders as parameters to the method (instead of executing them), as well as change sets. To construct such transactional
change sets, use the new method
changeset
that each module for a OData service exposes (see
this example for the business partner service). Pass prepared create, update, and delete request builders as parameters to the method (instead of executing them). Then, pass the constructed change set to the
batch
method. Execute the batch request like any other request builder using the method
execute
, which returns a promise of a list of
BatchResponse
.
BatchResponse
is a union type, representing the response of an indiviual retrieve request or change set that was passed to the batch request. Use
isSuccess
to verify that the retrieve request or change set was successful. Then, use a type assertion like
response as ReadResponse
based on your knowledge of the expected response to further work with the response. The following snippets gives an impression of how to deal with the response.
import { ReadResponse, WriteResponses, ErrorResponse } from '@sap/cloud-sdk-core';
if(response[0].isSuccess) {
const queryResult : BusinessPartner[] = (response[0] as ReadResponse).as(BusinessPartner);
// do something with result
} else {
const statusCode = (response[0] as ErrorResponse).httpCode;
console.log("Query in batch failed with status code " + statusCode);
}
if(response[1].isSuccess) {
const changesetResponse = (response[1] as WriteResponses);
const createdEntity = changesetResponse.responses[0].as!(BusinessPartner);
// ...
} else {} // handle error case as before
For more details, take a look at the
full release notes or stay tuned for a tutorial on this feature.
CSN files for OData services
When modeling a business domain using Core Data Services,
SAP Cloud Application Programming Model (CAP) uses
Core Data Services Schema Notation (CSN) files. The SAP Cloud SDK now delivers CSN files for all SAP S/4HANA Cloud APIs out-of-the-box as part of the virtual data model (VDM) for SAP S/4HANA Cloud. This way, you can directly reference entity types from these services in your CDS files. The CSN files for VDM modules are available from the corresponding folder in
node_modules
after npm-installing an SDK module.
Online retrieval of JWT verification keys
In preparation for an upcoming change to the way how the XSUAA service supplies verification keys to applications, the SAP Cloud SDK for JavaScript from version 1.11.2 onwards retrieves the key from an endpoint of the XSUAA service instead of relying on a verification key to be present in the XSUAA service binding credentials. Projects should update to the latest version of the SAP Cloud SDK to ensure that their application continues to work after the change has been implemented by the XSUAA service.
The SDK now validates user access tokens issued by the XSUAA service with the verification key retrieved from the XSUAA service. The retrieved key is cached for 15 minutes. Depending on feedback, we may change the cache duration in the future.
Note: this change has already been implemented in the SAP Cloud SDK for Java in the
previous release.
Further improvements
We have improved the
fromJson
method of entity builders to properly parse a JSON in the notation used elsewhere in the SDK, with links and attributes in camel-case. That means you can convert an entity to JSON and later again initialize an entity from a similar JSON object with this method.
Version 1.11.2 also fixes compilation issues that occured when using any entity builder and
"strictNullChecks": true
was set in the
tsconfig.json
file of the project.
As usual, the
full release notes contain a list of all improvements in this release.
We have also released version v25 of our
out-of-the-box continuous delivery offering consisting of a ready-made Jenkins server and a complete delivery toolkit.
Debug log
The Pipeline now automatically creates a debug log file which should make it easier to diagnose issues.
The file is created as a build artifact in Jenkins with a name like
confidential_debug_log_${fileNameTimestamp}_${projectIdentifier}.txt
or
redacted_debug_log_${fileNameTimestamp}_${projectIdentifier}.txt
. By default, the log is created in a
redacted version. To create a more detailled log which might contain confidential information, you can enable the
shareConfidentialInformation
setting as described in
the documentation.
The file uses markdown formatting, so you can conveniently paste it (or individual parts of it) into a GitHub issue. Please note that
you still need to verify yourself that you do not share confidential information regardless if you're using a
redacted or
confidential debug log.
Further improvements
We have made the WhiteSource stage more resilient in cases where npm fails. In the same spirit, the npm audit stage is now more resilient if the upstream "npm audit" service does not respond.
Version v25 improves the SAP Cloud SDK specific PMD ruleset to avoid some false positive findings.
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
3.5.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.5.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.5.0.
Of course, you can also generate a new project that uses version 3.5.0 from the start by running the Maven archetypes for
Neo or
Cloud Foundry with
-DarchetypeVersion=3.5.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