Hello all, In this blog, I would like to share my pain points while developing an XS application with custom Fiori UX.
Thank you for reading this blog. Before I get into the details, I will assume you already have access to a HANA DB, tables, Calc/CDS views and also are exposing those views via XS Odata. If not, then check out the following blogs for :
CDS views exposed via OData http://scn.sap.com/community/developer-center/hana/blog/2016/02/29/exposing-cds-views-via-xsodata , and/or any others out there on SCN.
Once you have accessed your HANA system – I am using HCP trial – I will create a package where my custom Fiori application lives.
My package structure is as follows:
The DB package contains my .hdbdd files where I created some CDS tables and views
The services package contains an xsodata service I used to expose the data models build inside the db package.
The UI folder contains the index.html file (required), the Component.js file (not required but used for this blog to highlight the separation of concerns and best practices, the manifest.json file (not required but also the focus of this blog), xsapp file (required), xsaccess (required), as well as 2 subpackages (views and controllers) – pretty self-explanatory.
Moreover, there are some files that I would like to focus during this blog due to the time it took me to understand them and their importance in a custom Fiori app.
- index.html – our entry point to the Single Page app (SPA) – we perform the sapui5 bootstrap here on lines 7 – 16
Component.js – component configuration for the application – added from the index.html file on lines 21-24 (above) after being added to the Shell during the attachInit event of the application. Further, the Component is extended below to use the manifest.json metadata and we override the init method to add any additional initialization processes when the app is initialized.
manifest.json – global configuration of the app (setting data services end points, named models, dependencies, etc.)
This file has 3 main sections: sap.app which is the configuration of the app, dependencies, etc. (see below); sap.ui contains configuration information about the ui5, device types and supported themes (default is blue crystal); sap.ui5 contains configuration information about the root view, dependencies of the sapui5 library, models used in the app, css resources, routing configuration, etc (shown below)
Once we have configured the index html file to attach the Component file, and the manifest file is loaded, from the Component file, and we have configured the models, then we can use those models in the xml views as shown next.
views / App.view.xml (and others) – XML view that contains the controls shown on the UI (partial file shown). Notice that within my view, I have a combo box which is supposed to contain data from the CUST end point in my mainSvc named model (from the OData Service I mentioned in the manifest.json file). Similarly, I have another named model called appModel referenced within my view for another purpose which in fact is a JSON model.
controllers/ App.controller.js ( and others) – JS file that reacts to the view changes (screenshot not shown)
I would like to mainly highlight 2 of these files which are the ones that took me the most time to understand and be able to get to work (finally & Cheers!!!).
Component.js – this file is referenced from the index.html and it basically functions as a container for where the application (XML) views will be loaded (show/hide using a router – also configured in the manifest.json file). This file is very important because when the app loads, on its init function, we extend its behavior to load the manifest (json) file, and any other logic that needs to be loaded when the app initializes, such as JSON models, app business rules, etc.
Within the Component file, we make a reference to the manifest.json file which contains the metadata of the application. What does that mean? In this file, we are separating the different components/layers of the application metada as sap.app, sap.ui, sap.ui5. Here is where we make reference to the OData services, data models, app dependencies, and other default configuration of the application, etc. as mentioned before.
Once the initial view of the app is loaded, we can reference any named model that was configured on the manifest.json file. In my example, I have a named model called mainSvc and I use this named model to load data from a CDS view via an OData web service as follows.
Some questions I have encountered while explaining this to others:
What is an OData model? – Server side model that references an OData service, such as .xsodata, or the .svc sample service from the northwind db.
What is a JSON Model? – client side model, usually done when we need to do what if analysis, or we need to work with the model without committing back to the DB.. all operations stay on the client side
Difference between named model vs unnamed model? – models can be bound to the app in 2 ways, unnamed (one and only one) or named model (we can have more than one) – usually when we have more than 1 service providing data to our application and we can access it by name.
Can I add external web services to the manifest.json file? The manifest.json file can also contain a reference to external web services, however, the URL to those web services have to be added to the Destination section of the HCP, so that they do not give errors of the CORS is unable to reach that end point. It is mainly a way to protect from security issues.
Where can we find documentation about the SAPUI5 SDK ?
For Fiori UX and controls used on Fiori apps, please visit the Explored Tab
Is there additional training? Yes and it is free – currently in progress, please join and learn more! http://open.sap.com
Any official SAP end to end scenarios? Yes https://sapui5.netweaver.ondemand.com/#docs/guide/3da5f4be63264db99f2e5b04c5e853db.html
thank you again for reading this blog, please provide your comments, suggestions, and good luck on your implementation of custom Fiori apps.