When OData V4 was introduced, it came as an evolution rather than revolution over the successful predecessor version 2. Most importantly, it has been ratified as ISO standard (ISO/IEC 20802), making it the protocol version of choice for serious enterprise business. A lot of important features where added or improved, like singleton support, containments, service inclusion, deep filtering/searching, action improvements, optimized protocol, to just name a few significant ones.
So it came as a logical consequence that the very successful SAP Fiori elements floorplans framework based on version V2 would get support for OData version 4 also. However, with the experience gathered from the version 2 stack we decided to not simply include V4 support in the existing framework, but rather to completely renovate the stack by starting from scratch and implementing a new and more flexible and resilient core architecture.
UI frontends generated on our V4 stack generally look and feel the same like on V2. The Fiori design guidelines are the overarching ruling principles for interaction and design consistency, but will obviously be also extended by additional V4 functionalities like 1:n filtering or OData Singletons. The complex structures and features of the UI are generated once based on the exposed data and additional annotations, and then stored efficiently in a so-called view cache. The app is then available to you like custom-developed frontend application code. Re-generations are triggered automatically in case the service indicates changes through its metadata.
Editing data through an OData V4 service will always be supported by a fully integrated draft mode. The active object isn't touched until all your changes are consistent and complete and you want to apply them finally to the object. While you are in the process of editing the data, all changes are maintained in a separate storage on the backend, making automatically sure that your work isn't lost even under volatile network conditions (working mobile, erratic connectivity etc.). Browser timeouts or network outages are threats from the past that way. And for the development of your service in the backend, the RAP (ABAP) and CAP (Cloud) programming models do all the heavy lifting for you to automatically provide the mechanisms required behind the scenes for this.
A major change over the former breakout-based extension concept of the V2 stack is the flexible programming model. Using so called building blocks allow you to assemble your custom design from ready-made UI pieces, similar to those we use to generate your application UI based on the backend service and its annotations. Implementing or overloading controller extensions gives you all the flexibility to implement your individual requirements. You can extend your floorplans on different levels of granularity, like individual actions, sections, columns or even complete pages. You could even start from a bare blank page and so create a full freestyle app, all still orchestrated by the SAP Fiori elements runtime. By using only our building blocks, the timelessness of your application is still ensured with respect to design and interaction evolution.
Flexible programming model: custom artifacts
Another integral part of the new architecture are reuse components. While they were rather balconies in your V2 SAP Fiori elements app (retrieving their data from somewhere, which is not directly a network administrators dream setup in general) and displaying them in a mostly isolated manner, for V4 we'll merge the reuse data already on the backend side and so make it part of your one and only OData service. And on the frontend side, consumption of such data can be seamless and highly integrated through according building blocks (attachments, RTF editor, ...) or via integrated features like the Situations handling.
SAP will continue to support the V2 stack for the foreseeable future, as thousands of apps are being built on it already, and there is no need to migrate or upgrade existing apps. They will continue to live up to the value proposition of automatic design and interaction evolution adoption. However, major additional functional innovations will be introduced on the new architecture only. Collaborative draft handling, Situations integration, AI based automatic property value recommendations etc. are considered for SAP Fiori elements floorplans for OData V4 exclusively, and the general guidance for new applications is to start with OData V4 development only, for all the various reasons explained above.
Almost the full SAP Fiori elements V4 framework (with a few exceptions due to technical constraints) is also publically available for free as an open source stack. It can be downloaded as an additional component into the also free UI5 version (open.ui5) and so be tried out without any upfront SAP license costs.
For more information on SAP Fiori elements and specifically the OData V4 incarnation, check out this blog containing a comprehensive overview of according knowledge resources.
- SAP Managed Tags:
3 Comments
