Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
0 Kudos
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.

One month to go until SAP TechEd 2019. Learn more about the sessions featuring the SAP Cloud SDK in our dedicated blog post.

Next week, we will host the third community call for the SAP Cloud SDK. This time, the topic will be version 3 of the SDK for Java. This series is open to everyone. Each monthly call features the latest news about the SAP Cloud SDK as well as deep dives into specific topics, as explained in this blog post. Register here for the next sessions in the series.

Java Libraries: Release Highlights 3.2.0

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

Asynchronous resilient execution

Version 3.2 introduces new methods to execute code asynchronously while making it resilient. Use the new methods queueCallable and queueSupplier of ResilienceDecorator and supply the code to execute asynchronously as a Callable or Supplier. Both return instances of CompletableFuture.

Corresponding methods are also available from ResilienceDecorationStrategy. You should also use these when you need to manually specify the executor to use.

Further improvements

In the OData VDM, we have added deprecation information to service classes that represent SAP S/4HANA Cloud APIs which are deprecated on the SAP API Business Hub, such as ChangeMasterService, ProcessOrderConfirmationService, and ProductionOrderConfirmationService. Take a look at the corresponding Javadoc and use the appropriate successor service listed therein.

Version 3.2.0 fixes an issue with function imports where special characters in query parameters, e.g. spaces, led to wrong URLs.

We have also fixed an issue with XsuaaService where it always forcibly used the provider tenant when calling retrieveAccessToken... methods. Now the methods retrieve access tokens for the tenant that called the method.

Several further improvements are listed in the full release notes.

Java Libraries: Release Highlights 2.20.1

We have also released the SDK for Java in a new maintenance version 2.20.1. 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.8.1

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

Retrieve Destinations from Subscriber and/or Provider Account

This version introduces additional selection strategies for retrieving destinations that only select destinations defined in the provider account (alwaysProvider) or in the subscriber account (alwaysSubscriber). You pass the strategy to use as part of the DestinationOptions when retrieving a destination, if you do not want to use the default, subscriberFirst. All strategies are available from an object helper DestinationSelectionStrategies.

A bit of background: The SAP Cloud SDK relieves developers from menial tasks otherwise required to retrieve the configuration of destinations. You can define destinations that point to downstream services or systems using the SAP Cloud Platform cockpit and easily reference them by name from your code. The SAP Cloud SDK takes care of everything else, from retrieving the configuration to executing necessary authentication flows as defined by the configuration.

In a multi-tenant software-as-a-service (SaaS) application, there may be different kinds of downstream destinations, some of which are tenant-specific and defined by customers subscribed to the application, and others defined by the application provider. For example, each customer will define his own destination configuration to connect to his SAP S/4HANA system, while a microservice may use the destination service to define a common destination to connect to another microservice. In the latter case, it may be highly undesired if customers could overwrite the application-internal destination, while this is necessary in the first case.

The new strategies introduced with version 1.8.1 of the SDK for JavaScript give consumers more fine-granular control over where to look for destinations. One differentiates between the provider account, which hosts the application, and subscriber accounts for each tenant (customer) of the application. The SDK now allows developers to specify whether the configuration shall be retrieved exclusively from the provider account or from the subscriber account. It is also possible to explicitly choose the default of subscriberFirst, which falls back to the provider in case the current subscriber tenant does not define (that is, overrides) the destination.

Further improvements

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

Continuous Delivery Toolkit: Release Highlights v23

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

The support for MTA extension files now supports substituting credentials at runtime from Jenkins credentials of type secret text. This allows you to not include credentials in the extension file, but a placeholder that is replaced at runtime with the corresponding secret text. Refer to the documentation for details.

Several quality checks have been updated for version 3 of the SAP Cloud SDK for Java. The resilience check is no longer coupled to Hystrix, as it is in hibernation mode and has been replaced by resilience4j in the SDK for Java. Consider the migration guide for switching over.

The integration test stage has been split into backend integration tests and frontend integration tests. This allows for more flexibility, as the frontend integration tests can make use of a web browser now if desired. For more details, consider the documentation.

Due to recent issues with connections to the SAP API Business Hub, the build result will now only be unstable instead of failed in case SAP API Business Hub is not available.

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

With this, you are already done thanks to the "bill of material" (BOM) approach. Your dependency should look like this:
<!-- possibly further managed dependencies ... -->

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

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