Custom CDS Views – What’s New in 2111
The upgrade to 2111 is right around the corner, but has not started yet. So until it is completed, my blog post is to be considered as a “labs preview”. That just means that this time I am not late for once 😉
[TLDR] For the impatient ones, here is the brief summary of the news:
- All custom CDS views created from scratch will now be saved as view entities
- In the definition of association conditions, it is now possible to use projection fields.
It is not possible any more to use path expressions in the association expression though
- Fields of the primary data source that have the “mandatory filter” property, will now be automatically included in the projection
- In the where condition, the like operator was introduced for text comparisons
- Previewing draft views is back
CDS View Entities
You might remember, that in 2108, we allowed view entities to be used as data sources in custom CDS views. I also briefly explained, what view entities are in the blog post on 2108.
This time, we persist the custom CDS views themselves as view entities. For the time being we do this only when you create a new view from scratch. Existing custom CDS views will not be changed (or migrated) to view entities, as there are some prerequisites that have to be fulfilled. You will see that when we talk about the projection fields next.
Still, we want to get rid of the old CDS views in the long run, therefore the view entities topic will also make it to the next release again.
Don’t worry: As a key user you will not be bothered with the view entities at all. The goal is that the topic remains behind the scenes and will completely be managed by the Custom CDS Views app internally.
Projection Fields in the Association Condition
One of the side effects of view entities is, that they do not allow to use path expressions in the association condition any more. They require that you either connect to the target data source via fields of your primary data source or via fields of your own custom CDS view (these are so called projection views).
Before 2111 you could choose to connect with arbitrary fields of your data sources, even going through several associations. This never was a good practice, but it was allowed. In most cases it lead to the fact that such associations could not be used (e.g., to expose fields) anyhow.
Nevertheless there are situations where you need to draw in fields from other data sources to define a meaningful association condition to a third data source. In these cases, you can now just add this field to your own view and then use it (via “My Fields”) in your association condition.
If you do have such a rare situation in one of your existing views, this is not a problem. It is still allowed to keep them as such in existing associations in your views. However if you create new associations, you need to stick to the new rules already.
Until now you could only use text filters in the expression based filters if you happened to know the correct syntax. That was quite uncomfortable which is why we included the like operator into the form based filter now as well.
The only thing you have to know is how to use wildcards SAP style, where “%” is used as placeholder for any string, whereas “_” stands for any single character.
You may have noticed, that there is an element property called “Mandatory Filter” in the Custom CDS Views app. It can be applied to fields and makes sure that (especially in the analytics scenarios) the field must be used as a filter criteria in the runtime. In order that the runtime can bring up the field as a filter input, it has to be part of the projection though. Therefore, we are now adding fields of your primary data source that carry the “Mandatory Filter” property to your custom CDS view automatically, while keeping the “Mandatory Filter” setting.
If you are using your custom CDS view with the analytical cube scenario in a custom analytical query, the query runtime will now always ask the user to set a filter on that field before executing the query. This will of course also happen when you are using SAP VDM views that carry fields wit the mandatory filter property.
Technically, this property is equivalent to the Consumption.filter.mandatory annotation that is documented in the ABAP RESTful Application Programming Model help (Reference -> CDS Annotations -> Consumption Annotations).
Finally the preview for drafts is back! You don’t have to publish a view any longer to see the preview now. Just check and preview as you were used to. I am really sorry that it took us so long to resolve this. Thanks for your patience!
One for the developers: Until now, you had only few options to code ABAP or ABAP CDS in SAP S/4HANA Cloud directly. For ABAP CDS that meant that you had to use our Custom CDS Views app when you wanted to create your own CDS views. This is convenient and you don’t have to know the syntax. It is great if you are a key user, but can block you if you are a developer and especially if you have larger projects in mind than just building a custom cube in order to adjust the SAP delivered version to your needs. The answer is the so called “Developer Extensibility”. This means you can now* use ADT/Eclipse to create your projects as well. We call that “Embedded Steampunk” and there is an excellent overview available here as blog post: Steampunk is going all in. You may also want to check out the official documentation.
The “Key User Extensibility” with the convenient Fiori Apps will not vanish, but stay available to provide convenient standard solutions for extensibility tasks! You can also read that in Thomas comment to Haralds blog post 🙂
Stay healthy & thanks for reading!