The biggest news of this week, however, was probably the announcement of the SAP Cloud SDK as the next step and new name for the SAP S/4HANA Cloud SDK. Read more about how this enables you to leverage the benefits of the SDK for extending many more SAP solutions in this news article. For now, technical artifact names on source code level remain unchanged. You do not need to change your source code or dependencies; simply continue to use the SDK as known from the SAP S/4HANA Cloud SDK to leverage the SAP Cloud SDK.
You can update your dependencies of the SAP Cloud SDK for Java to version 2.16.0 and consume the new version from Maven Central.
Support for SAP Cloud Platform Extension Factory
This week also saw the SAP Cloud Platform Extension Factory becoming generally available. Extension Factory is SAP's cloud-native extensibility framework. One major benefit is that it allows you to easily connect SAP S/4HANA Cloud systems to your account on SAP Cloud Platform, with a few simple steps. The SAP Cloud SDK is then the final piece of the puzzle to communicate with the thus-connected system from your application's source code.
As such, version 2.16.0 of the SAP Cloud SDK brings native support for communicating with SAP Cloud Platform Extension Factory. With the following new capabilities of the SDK, you can start leveraging Extension Factory in your application right now .
A bit of background: SAP Cloud Platform Extension Factory represents connected APIs of SAP S/4HANA Cloud as named service instances and binds those service instances to applications on Cloud Foundry. Thus, SAP S/4HANA Cloud APIs essentially become services bound to your application, contained in the VCAP_SERVICES environment variable in Cloud Foundry, much like other services on SAP Cloud Platform.
This comes in addition the well-known destination service, which you will still use for APIs not yet available in Extension Factory, for multi-tenant applications, or in other cases where you or your customers may not use Extension Factory.
To support Extension Factory and destination service, version 2.16.0 of the SDK brings two new capabilities. First, we introduce a ScpXfDestinationFacade to read destinations from the VCAP_SERVICES environment variable in Cloud Foundry (as used by Extension Factory). Second, we introduce a FallbackDestinationFacade to use destination service and extension factory in parallel. The FallbackDestinationFacade allows to specify as constructor parameters one primary DestinationFacade and a secondary facade as fallback that is used if no destination of a given name is found using the primary facade. In essence, this generalizes the destination concept so that destinations do not necessarily only come from the destination service, but also via Extension Factory.
Assuming the common use case that you want to allow connections via Extension Factory, but at the same time still use the destination service on Cloud Foundry, you can achieve this by running the following code at startup of your application to declare the destination lookup strategy:
With the above configuration applied before instantiating any ErpConfigContext or other reference to a destination, whenever a destination named s4hana shall be accessed (for example, via execute(new ErpConfigContext("s4hana")) in the OData VDM), the SAP Cloud SDK will first look for a service with this name bound via Extension Factory. It will only consult the destination service for a destination of this name if no such service is found. You can in the same manner also define other lookup strategies. For compatibility reasons, the default behavior remains using the destination service only.
The OData VDM now supports sending update request to OData APIs with PUT semantics (replace). While PATCH remains the default, you can now control the HTTP method and strategy to use for update requests via the following Java methods. To use HTTP method PUT and send the full entity that is meant to replace the current state of the entity, call replacingEntity on any fluent helper for update requests. To revert to using PATCH and only send changed fields (which is also the default if nothing is specified), call modifyingEntity.
We have updated the version of the Tomcat server used in projects created by the scp-cf-tomcat archetype to version 8.5.40 (from 8.5.23) due to a known vulnerability (CVE-2019-0232). If you have created a project using the archetype before, we suggest to update to the new version manually.
Version 1.2.1 allows connecting to SAP S/4HANA on-premise via the Cloud Connector and SAP Cloud Platform connectivity service. When executing an OData request using the OData VDM, the SDK will apply the necessary steps to connect to SAP S/4HANA on-premise where required.
No code change is necessary to use this feature. On-premise connections are handled transparently by the SAP Cloud SDK where configured. The SDK will proxy requests to destinations with proxy type OnPremise through the cloud connector if an instance of the connectivity service is bound to the application. Only the necessary setup is required as described in the documentation for on-premise connectivity.
Version 1.2.1 allows to mock the destination service of SAP Cloud Platform centrally during tests. In addition to the previously available feature to load destinations manually from systems.json and inject them where needed, you can now mock destinations centrally. Destinations mocked in this way will transparently be available wherever destinations are fetched by name.
Support for SAP Cloud Application Programming Model
This release significantly enhances the support for projects based on the SAP Cloud Application Programming Model. All stages listed in the MTA column of the feature matrix are supported. We will describe the requirements to be fulfilled by projects to use this capability in a future blog post.
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.16.0.
Of course, you can also generate a new project that uses version 2.16.0 from the start by running the Maven archetypes for Neo or Cloud Foundry with -DarchetypeVersion=2.16.0 (or RELEASE).
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: