Use Fiori Elements and smart controls for custom Fiori apps

Why are Fiori Elements a good idea?

While limiting customization initially sounds like a drawback, it is one of the bigger advantages of a smart template-based approach to applications. The SAP Fiori concept requires the creation of several small, targeted, reusable applications to serve a business process. Using a templated approach whenever possible ensures that these applications will have a similar look and feel and will adhere to the Fiori Design Guidelines and whatever themes you have developed as an SAP customer. Users will know what to expect in new applications that are based on Fiori Elements, so less training will be required, even if strong design oversight wasn't in place during application development.

Additionally, templates and standard smart controls provide technical benefits. They cut down on the need for maintaining custom solutions and JavaScript expertise (you should still have such expertise, but you can stretch it further with standard solutions). They provide predictable performance on the front end. And using smart controls together in templates ensures they are being used in the way they were intended, and you'll get fixes and enhancements just by updating your SAPUI5 libraries.

What are the downsides for Fiori apps?

Following the strong development mindset laid out by SAP has its advantages, but sometimes you are forced to stray from the beaten path. In the context of Fiori Elements, you are working atop a number of abstractions that were put in place to expedite the creation of Fiori apps. Thus, customizing or extending these applications can become a tedious exercise. SAP defines rules for extending applications, and, whenever possible, you should work within these guidelines to avoid breakage when upgrading SAPUI5.

Annotations also require a bit of understanding before using them to shape the behavior of Fiori Elements and smart controls. The two flavors of annotations (SAP and vocabulary) are often both required to implement a given behavior for a control.

An example of this is the declaration of a fixed-value range filter for a smart filter-bar control (drop-down list). The SAP annotation may define a specific field as fixed-value, but the vocabulary-based annotations would define the OData service call that is required to populate the set of fixed values. While not terribly complicated, it does require an understanding of the possible settings the vocabularies can define and how they could work together to accomplish the goal. Currently, there is an annotation builder in the SAP Web IDE for the HANA Cloud Platform that allows for configuration of some vocabulary-based annotations. This tool is a work in progress, so developers may find themselves manually editing the annotation file's XML to get the desired result.

Additionally, using Fiori Elements and smart controls doesn't free you from the need to localize your Fiori apps. So, if you need additional languages, you'll still be defining l18n resources.

Of course, there will still be use cases that require fully customized Fiori apps. For these applications, you'll still need to have the capability to design, develop and maintain them based on SAPUI5 or another platform. But making good use of Fiori Elements and smart controls where possible should free up time to tackle these more complex projects in high-value scenarios where they make strategic sense.

About the authors
Ethan Jewett is an independent consultant and SAP Mentor, and owner of Coredatra LLC.

Joe Rupert is senior technical consultant at Bowdark Consulting Inc., which is based in the Dallas area. He focuses on application design and custom development on SAP platforms.