Introducing sap.ui.mdc – A New Generation of Smart Controls

[bendkt]

We are excited to announce that the open beta phase of the sap.ui.mdc library started with the release of UI5 1.115. After a period of successful internal use in framework and application development, the library is ready for public use and experimentation.

Releasing sap.ui.mdc is a significant milestone for OpenUI5, as it brings the concept of smart controls to the open source world. While not being dependent on a specific model or data protocol, developers can now achieve a level of development efficiency that was not possible before. With sap.ui.mdc they can streamline their development processes and create robust metadata-driven applications and reuse components.

We look forward to the innovative ways you will find to use it. Check it out and let us know what you think!

Key Features

UI5 developers and architects should know about the advantages of the sap.ui.mdc library and how it combines several strengths of UI5:

Smart Predefined user experience through metadata-driven UI components. Support of the powerful UI5 development concepts and enterprise-ready qualities.

Open Open for extension through implementable delegates and well-defined APIs for metadata in a unified format. Free and open source with OpenUI5.

Adaptable Adaptable UIs with SAPUI5 flexibility. Integrated user and key user personalization and support for private, shared, and key user variants.

It’s all metadata-driven

For those who are already familiar with the concept, you might want to skip this paragraph. If you really want to understand the added value of the sap.ui.mdc library, it is crucial to first have an idea of how metadata-driven applications work.

In contrast to regular application development, a metadata-driven approach focuses on generating the UI based on a description of the actual data, which we refer to as metadata. By interpreting this metadata, a component can present itself to the user without additional logic. That enables components to be reused with different data, removing the need of implementations for specific scenarios.

A simple example: You have stored entries in your database that should be listed in a table. Instead of defining the table with rows and cells individually each time depending on the data you would like to present, a metadata-driven table would only require knowledge about the metadata of the relevant properties to create a standardized and UX-compliant column with a dedicated control representation. One table for any kind of data. How convenient is that?

Thinking one step further, the approach allows you to even use this metadata for user personalization. With a well-described set of properties, a metadata-driven UI can be highly configurable. For example, if the user would like to see some other column of the table, which was not displayed initially. A table that even adapts to the user’s preferences – amazing!

The most prominent way for metadata-driven development at SAP is SAP Fiori elements. Based on OData V2 or V4 services, developers can quickly build applications with predefined full-page templates. If you are not familiar with the topic, it is definitely worth to have a look at what SAP Fiori elements has to offer!

MDC versus Smart Control

The concept of MDC (metadata-driven controls) is not entirely new to UI5. In fact, the smart controls (sap.ui.comp library) already implemented the idea for the OData V2 protocol in SAPUI5, as outlined in this blog post. They scored with their unique ability to evaluate OData annotations and the resulting development efficiency. It is safe to say that the majority of SAPUI5 applications are based on or at least use smart controls, for example, as part of SAP Fiori elements patterns. Unfortunately, lots of developers cannot use them because of their dependency on OData V2 and because they are not available in OpenUI5.

The sap.ui.mdc library was established to overcome this issue and provide additional value by being decoupled from a specific data protocol. Several internal stakeholders welcomed this and started their own implementations in OData V4, FHIR (find more info here), and other more proprietary protocols. Meanwhile some of those implementations are in productive use.

Furthermore, the new implementation could incorporate the latest UI5 development concepts of its time. Leveraging XML view caching and preprocessing as well as involving SAPUI5 flexibility for the persistence of personalization changes achieved a minimal XML view footprint and the least possible number of required requests for starting up a metadata-driven and personalizable application.

Being part of the OpenUI5 repository opens the doors for an even broader adoption. Developers can benefit from increased efficiency when it comes to building metadata-driven applications that integrate seamlessly into an SAP landscape, independent of the back end, service, or model that is available. Plus, all the benefits of open source come on top.

We ❤️ open source.

The OData V4 Question

In the last years, the question about support for OData V4 smart controls came up quite often. Good news for everyone who didn’t know this: There is a full-blown implementation of sap.ui.mdc available, provided by SAP Fiori elements. Their flexible programming model is what you are looking for and where you will find many useful building blocks for OData V4 and annotation-driven development. See this blog post for more information.

Our controls and what they do

Enough of concepts and history, cards on the table! The sap.ui.mdc library contains many helpful controls that can be used standalone or in combination with each other. Although there are a few more rather specialized controls, let us focus on the most prominent examples in the following table for now:

Filter Bar Personalizable set of filter fields Connectable to other controls via interface
Table Responsive (sap.m.Table) or grid table (sap.ui.table.Table) Customizable toolbar Personalization options, such as column selection, filtering, sorting, and grouping
Field Input field with metadata-based appearance, for example a date picker for dates Metadata-based validation features, for example allowing only numbers for Integer types
Value Help Support for value selection from small or large lists via drop-down list or dialog Fully composable/customizable value help content Mapping of relations between associated fields, such as for example postal code and city and related filtering
Link Support of navigation to related entities via popover Fully composable/customizable link popover content
Chart Full sap.ui.chart.Chart integration (SAPUI5) Support of custom chart integration via chart delegate (OpenUI5)

A word about adoption

To give you an idea of what it means to adopt sap.ui.mdc controls and leverage their advantages in metadata-driven application development, it is crucial to understand the underlying architecture at least on a high level. As explained earlier, the metadata interpretation is exchangeable in sap.ui.mdc controls and does not come out of the box. This is the part adopters must (and probably want to) take over.

Delegate & PropertyInfo

Indispensable for a metadata-driven control is the knowledge of how to interpret the metadata. In sap.ui.mdc that logic is contained in a delegate, which serves as connector between the control and the corresponding metadata provider, for example, the data service. Adopters need to implement and associate a delegate to the sap.ui.mdc control, as shown in this example.

The most important information is delivered to the delegate via propertyInfo objects, which must be provided in a well-defined JSON format. They contain all relevant details about properties that should be presented by the metadata-driven control and they are documented in detail for each sap.ui.mdc control.

Whenever required, the control calls the fetchProperties function on the delegate. The delegate now must provide the metadata in propertyInfo format containing the information about the items a control should display. These items could be columns for a table or filter fields for a filter bar, for example. The control can then create and orchestrate these items based on the passed information.

Personalization and Variant Management

To benefit from the great personalization features of sap.ui.mdc controls and variant management for users and key users, all you have to do is implement the relevant delegate callbacks. There is a small set of relevant callbacks, like addItem or removeItem, which instruct the control how to modify its items aggregation.

Internally, the sap.m.p13n.Engine takes over the communication with the SAPUI5 flexibility layer. Please note that SAPUI5 flexibility features only work when using SAPUI5 applications hosted on SAP BTP, SAP S/4HANA, or ABAP platform. For more information, see Features and Availability.

There are several additional callbacks, which might request control-behavior-related information or are just there so that the standard control behavior can be adapted to the application’s requirements. For more details, please have a look at the individual API Reference of each delegate.

General Availability

As you now know the most important facts about the sap.ui.mdc library, we are very much looking forward to your feedback. With UI5 2.0 we plan to be generally available with a solid offering, hence we reserve the time until then for important changes. At the same time, we will be working on additional documentation, tutorials, and compelling examples that will make it easy to understand and adopt the sap.ui.mdc concepts.

Moreover, we plan a UI5ers live with the latest news regarding the topic. In the meantime, you can check the references below for more detailed information. Stay tuned and if you already have feedback or questions please leave comment!

For more information on UI5 and sap.ui.mdc

• MDC Library: Documentation | API Reference | Samples | UI5Con Talk


• Exchange knowledge: SAP Community | Q&A | Blog Post | Slack


• Learn more: SAPUI5 Demo Kit | openSAP | UI5 NewsCast | UI5ers live


• Try UI5 for free:  SAPUI5 | OpenUI5 | OpenUI5 on NPM | SAPUI5 on NPM


• Follow us: Twitter | YouTube

[vobu]

I ❤️ Open Source as well 🙂

And it‘s great to have these metadata-driven controls available in OpenUI5 👍👍👍

But pardon the question: from a UI5 freestyle perspective, how do the mdc controls relate to the building blocks/macros of the Flexible Programming Model? For example, there‘s now a Table „smart control“ available both in mdc and FPM (https://ui5.sap.com/#/topic/3801656db27b4b7a9099b6ed5fa1d769).
When should we use which in UI5 freestyle development?

 

[bendkt]

Hi Volker,

Thanks for your question! This is rather easy to answer: Use the Flexible Programming Model whenever it is possible! 🙂

It saves you a lot of time, as the whole delegate part (which needs to be provided by the adopter who wants to use MDC directly) is already prepared and provided by Fiori elements for OData V4. It makes sense when you have an OData V4 service and annotations, which is the case if you are using CAP or RAP.

MDC comes into play, if those prerequisites are not met. If you are dealing with a different data protocol, or also in cases where your specific OData service implementation does not support the corresponding SAP annotations it makes sense to think about a specific implementation of sap.ui.mdc. Just not to miss that: There is a big difference in the effort for adoption. Given a compatible backend, using the Flexible Programming Model is just a fraction of the effort which is required, to provide an equivalent implementation with sap.ui.mdc.

Please let me know if you have more questions! 👍

[vobu]

Thanks for the detailed explanation!

Do the FPM "smart controls" (building blocks/macros) re-use the sap.ui.mdc implementation?
Or are these separate code lines?

[bendkt]

My pleasure!

Regarding the implementation of the Flexible Programming Model, I gave the info already above - maybe a bit hidden:

There is a full-blown implementation of sap.ui.mdc available, provided by SAP Fiori elements. Their flexible programming model is what you are looking for and where you will find many useful building blocks for OData V4 and annotation-driven development. See this blog post for more information.

 

[Marian_Zeis]

Hi Benedikt,

This is a good addition to use mdc in openui5 with JSON Models.
I have tried to implement this as a test.
Of course I am used to Fiori Elements, so I found it quite tedious to implement or the example was too complicated.
Is the plan to make this simple in the future, i.e. "just" specify the metadata for the JSON model like in FE?

In addition, the example is still missing important files that I then only found in the GitHub repository.
They should also be in the example in the documentation (like JSONPropertyInfo.js) and also in the download zip file.

Cheers,
Marian

[bendkt]

Hi Marian,

thanks for the feedback!

If I get you right, you would like to use Annotations with a JSON Model. That would rather be a feature request for Fiori elements. MDC is not limited to JSON Models, we just use them as an example. You have basically two ways to use it: Either implement own metadata-driven controls with generic delegates, that do, what Fiori elements does: Interpret service metadata (like OData annotations) and provide them to MDC via Delegate and PropertyInfo objects. Or you just would like to benefit from the nice feature set, which the MDCs have to offer. In the second case you can bind the JSONModel and provide an application specific set of PropertyInfo, as shown in our example.

I guess you were looking at an older version of the example, which was indeed lacking some of the files and had some unnecessary complex code. This has been improved in the meantime and the latest version should be more comprehensive. See: sap.ui.mdc/sample/sap.ui.mdc.demokit.sample.TableFilterBarJson/code

Best regards,

Benedikt

[PradeepJena]

Hi @bendkt :

This information is really helpful.

We have a requirement to create a smart tree table but since the data source is OData v4, we need to make use of SAP.UI.MDC library.

In the existing sample provided by SAP, it makes use of JSONPropertyInfo for Metadata, but in our case the metadata will be coming from the OData v4. So not sure how to make use of it in the Delegate file.

Below is the reference method provided for extracting the metadata annotations from the JSONPropertyinfo.js file from the sample in SDK. We want to make use of the OData v4 metadata directly instead of this.

const _createColumn = (sId, oPropertyInfo) => {
    const sPropertyName = oPropertyInfo.name;
    return new Column(sId, {
        propertyKey: sPropertyName,
        header: oPropertyInfo.label,
        template: new Text({
            text: {
                path: "mountains>" + sPropertyName,
                type: oPropertyInfo.dataType
            }
        })
    });
};

Looking forward for your expert advise on how this can be done, as there is no example available currently in the SDK for this.

SAPUI5 

Thanks & Regards,

Pradeep

[bendkt]

Hi @PradeepJena!

Thanks for your interest and you have a very good question there. There are a lot of options how to solve that and the optimal solution depends on your requirements, which is why we do not have an example for it (...yet. But to be honest: It can become quite a complicated endeavor). 

• If the table should be completely metadata-driven, did you consider using the Fiori Elements Flexible Programming Model? Even if the tree table is currently not supported, it might be worth to ask for the support there.
• If you need to build a metadata-driven tree table yourself, the way to go is probably to use the Meta Model for OData V4 to access the metadata and map it to the according Table PropertyInfo.
• If you just want to use this specific table in one project, you could also hardcode the PropertyInfo to whatever you would like to display (similar to the JSONPropertyInfo in our example).

So I hope one of these options would work for you! 

Kind regards

Benedikt

SAPUI5 SAP Fiori Elements