Deconstructing the Golden Rules of SAPUI5 Development

Before going further, let’s look at key points to consider while designing and building SAP Fiori apps.

• Use the Design-led Development process as it is valid for all UI scenarios.
• Ensure there is a common and holistic understanding of the end-user tasks to be solved and the app that should be built before starting.
• Ensure that the design complies with the Fiori Design Guidelines (or your own).
• Ensure that the designs only use existing controls and patterns.

• Use SAPUI5 UI technology to build new SAP Fiori applications.
• Use Smart Templates (metadata driven UIs) and, if possible, SAP Fiori Elements and the SAP ABAP RESTful Application Programming Model for standard SAP S/4HANA applications.
• Use UI5 freestyle for pixel perfect applications that do not follow a pattern-like approach.
• Use Smart controls to create applications following pattern-like approach. To provide smart behaviour, smart controls interprets OData metadata.
• Use a combination of UI5 freestyle and Smart Controls for pixel perfect applications that only have minor deviations from Smart Template applications.
• Use technologies like SAP Web Dynpro ABAP, SAP Floorplan Manager and SAP Web GUI for existing apps that are not built from scratch.

Before going further, let’s look at key points to consider while using OData services for SAP Fiori apps.

• An OData service is required for each app.
• Other considerations for building SAP Fiori apps include: 
  • An app must be able to use several OData services.
  • An app must be able to indirectly view reusable app parts.
  • An app must be able to direct data binding at run-time derived from metadata.
  • An SAP Fiori app also relies on the central UI2 services.
  • An SAP Fiori app uses one central reuse service to provide message long texts.
  • An SAP Fiori app may use a separate service to implement value helps.

• The system landscape for SAP Fiori Apps supports two different deployment options: embedded deployment and hub deployment.
• The UI, the gateway, and the business back end are deployed on the business back-end system in the Embedded deployment. 
• The UI and the gateway are deployed on a different system from the business back-end system in the hub deployment.
• The mandate is to package all UI relevant artefact in a separate software component to support Hub deployment, it is mandatory.
• The OData service development package should be treated as an add-on.

• There is a one-to-one relationship between the OData service and the app.
• The individual entity-relationship model is tailored to the data needs of the SAP Fiori app.
• All, and only, the data needed by the application are delivered by one OData-service.
• The 1:1 relationship between SAP Fiori app and Odata service simplifies the life-cycle of an SAP Fiori app and its data access.

Let's have a quick look at key points related to defining metadata for SAP Fiori apps.

• SAP Fiori apps define their set of metadata in an app descriptor (manifest.json) file.
• App descriptors make it easy to orchestrate and automate the development delivery.
• App descriptors are mandatory for SAP Fiori apps.

Time for the next points to consider.

• Note that HTML/CSS generated by UI5 is not part of the public API and may change in patch and minor releases.
• Do not override UI5 with CSS in SAP apps as it bears the risk of breaking the application on updating UI5.
• Use the standard CSS classes of SAPUI5, such as for margins, paddings, or visibility on various devices.
• Make use of the UI theme designer.

These are the points to consider for making your SAP Fiori apps platform independent.

• SAP Fiori apps must be implemented as self-contained UI5 Components.
• Avoid:
  • Using absolute URLs generated in the front- or back-end.
  • Using private UI5 properties or functions.
  • Calling UI2 services directly instead of using the APIs.
  • Using platform-specific functionality without an availability check.
  • Using private UI5 properties or functions. 
  • Using generated IDs for accessing UI-controls.
• SAP Fiori apps must build in platform independence.
• SAP Fiori apps must run from out of the box without platform specific adjustments. It is usually a bug in the app when an app does not run on a particular platform.
• SAP Fiori apps must be implemented as self-contained UI5 Components.
  • noShellIndex.html: local, isolated test without shell services
  • FioriSandbox.html: local, integrated test with mock shell services
  • FioriLaunchpad.html: productive usage 

• The SAP Fiori apps can run on a mobile device within the browser, SAP Mobile Start and as self-contained native-packaged apps.
• An SAP Fiori app must run inside SAP Mobile Start or be deployed as a Packaged App if it wants to benefit from native features.
• The most generic way apps can run on mobile devices and still have access to native features is by running the app inside the SAP mobile start.
• The SAP Fiori apps can be pre-packaged as self-contained native apps. All static web resources are bundled into a Cordova container.