We finalized our messaging implementations now and can hereby declare first general availability. In course of this, we also documented key concepts and usage scenarios in the new comprehensive Events & Messaging Cookbook Guide:
CAP supports schema evolution based on migration tables for the SAP HANA database. Compatible changes including column rename can be applied to the database without any data loss and without the cost of an internal table-copy operation.
With hybrid testing, you stay in your local development environment and use services from the cloud. With the new cds bind, you connect your CAP Node.js application to Cloud Foundry services. The cds watch gets the service credentials from Cloud Foundry and keeps it until exit. There is no need to save service credentials on your hard drive anymore.
This release adds thorough support for exists predicates with path expressions, to CDS compiler, as well as Node.js and Java runtimes. Exists path predicates allow to express complex relationships while hiding the complexity of nested subselects. For example:
In the example, only those users may read projects' data which are associated members with role Editor.
Status: Experimental --- Consider status of this features as experimental, which means behaviors might change in details. Always ensure functional correctness for your project when making changes with regards to authorization! Support for draft-enabled entities may be limited.
The CdsModelProvider is now also triggered when using CdsRuntime.getCdsModel(UserInfo, FeatureTogglesInfo) with a UserInfo object, where the tenant is set to null. Earlier, the method always returned the default CDS model directly.
CQL API cleanup
GROUP BY - groups are now represented as a List<CqnValue>
ORDER BY - the sort item is now represented as a CqnValue
Built-in handlers, for example for @assert.range validation, now set the corresponding target in error messages. This ensures that error messages in SAP Fiori are shown directly at the relevant field, instead of in a generic popup.
It's now possible to build a destination for a Remote Service declaratively in the configuration. All destination properties supported by SAP Cloud SDK can be used under the new section cds.remote.services.<key>.destination.properties. For a full list of supported destination properties, look at SAP Cloud SDK's com.sap.cloud.sdk.cloudplatform.connectivity.DestinationProperty class.
New configuration options cds.remote.services.<key>.destination.headers and cds.remote.services.<key>.destination.queries have been added and allow to configure key-value pairs of headers / queries to be added to every outgoing request of the Remote Service.
@sap/xsenv is no longer used for credentials look-up and can be removed from projects.
cds.ql: Keys passed as arguments into SELECT.from() are put into the target path (SELECT.from.ref) instead of adding a where expression at root level. This change is necessary in order to distinguish between resource paths and filters/ restrictions.
The November release includes the beta version of the new REST adapter.
The new implementation uses the CAP-native OData URL to CQN parser. Hence, almost all OData requests are supported. For example, you can use query options like $filter and $expand, request deep resources such as GET /Foo/1/bars/2/baz, as well as (un)bound actions and functions.
Limitations/ out of scope (compared to OData protocol adapter):
OData query option $apply
OData batch requests (/$batch; with or without atomicity groups)
The new REST adapter can be activated via cds.env.features.rest_new_adapter = true. Don't forget that you need to serve to rest, either via the cds.serve() API or the @protocol annotation.
The November release includes a first experimental implementation of a generic GraphQL adapter, which turns each CAP service into a GraphQL server.
The GraphQL adapter can be activated by setting config option:
cds.env.features.graphql = true
Further, you need to install the following additional dependencies:
The adapter serves a single endpoint for all services based on the served event at /graphql. At that path, you'll find a generated UI (via third party library) that allows you to interact with your application.