SAPUI5 – Best practises- Do’s & don’t do’s

Introduction  hde

     SAPUI5 and SAPUI5 based applications have pitched into market now. SAP FIORI is one of such application which is running on netweaver gateway, and there is many such running on SAP HANA XS as well. Here I am trying to explain you my experience on creating SAPUI5 application with some best practices along with important dos and don’ts do’s with this quick document.

UI Validations

We used to validate the inputs given by the user in the client side itself sometimes; for example, the email ID format, number format, age limit, date range, age calculation from date of birth etc. It is always good practice to implement such “silly” things in the UI level itself. But, are they really “silly”? I should say NO.  Because, anyone can debug the page and change the validation rules in run time and fake them to end up in a wrong validation or calculations. So we cannot trust it all the time.

What we should do: If there is a validation logic implemented in the UI, same logic has to be implemented in the affected Odata services also. For example, the email id structure validations. Even if anyone changed it in the UI and changed the rule, he will not be able to do it from the netweaver gateway or XS. Implement it there also (This best practise is applicable for all the web applications). This check is applicable for all the configuration/master data loaded in the UI also.

CRUD Operations

                  OData supports CRUD operations, which have been discussed in multiple documents and I am not talking about the features and why we use CSRF token validation etc. I have seen couple entity model updates/deletion logics implemented in GET_ENTITY and GET_ENTITYSET methods by managing the input data with filter value. Never do this. We got beautiful architecture and Odata Model API to manage the CRUD operations smoothly. C, U and D operations should be managed using the corresponding methods (in case of netweaver gateway) provided by the OData protocol and SAPUI5 OData Model APIs. Avoid using direct Ajax calls, if possible.

Login to the application

     In most cases, when we start exploring a UI language, the first screen we develop will be login screen. For learning purposes it is fine, but never develop custom login screen for a productive UI application. For netweaver gateway applications, once we deployed it into the BSP container, application will inherit the BSP login or portal login. In case of FIORI apps, we will get the beautiful FIORI login page.

Internationalisation (i18n simply)

     No story here . Never develop applications by hard-coding the description texts. Apply i18n where ever applicable.

UI version in Eclipse

     One of my friends developed an end to end SAPUI5 application locally in eclipse, where there the UI component version was 1.22.*. On completion, he shared and activated the project in ABAP repository where the UI5 version was 1.16.*. Some of the controls and features did not work properly there and it took around 2 weeks to fix the problems.

  Bottom Line: periodically, share and activate the project to the server (ABAP or XS), to avoid such problems in the future. Or, you can keep the same Ui5 version in both Eclipse and server.

User specific GUI?

                  Sometimes it will be important that the page the user sees should be corresponding to his roles (or some back end configurations or conditions). We can imperative statements in the UI side before loading the specific UI to the screen (sometimes a graph, or a page, or a tab in the tab strip). Remember that, whatever you are writing the UI can be debugged and trick the logic you have written. As I said before, check the user authorizations from the back end (Odata side), before loading the data. In that case, even though he could make the unauthorized UI loaded in the browser, he will not be able to see the data. We tricked him back

Something from OData side

       When you write Odata implementations (in case of NW GW), implement all the possible features (like paging and filtering). This makes the OData consumption from SAPUI5 side easier. Think twice before returning all the records for an entity (wild card is still a nightmare). Even though we are using paging while consuming from the UI5 application, it is very much possible to execute the Odata URL separately using a REST client (sometimes I feel like to call this GET operation in a loop to crash the system downJ ). If we have written the logic to return all the records, it will be a bad approach. So, always limit the number of records. In case of XSODATA (SAPHANA), never expose transaction tables directly via odata. Create information models or views to limit the columns and expose them instead. Sometimes, a GET operation (with multiple records – GET_ENTITYSET in GW) is triggered only via association calls. For example, purchase order items are fetched based on a particular purchase order number. Here, the we can limit the Odata call for the PO items such that, it will give you the items only if there is a valid navigation exists. The benefit is, no one will blindly execute selection with wildcard on EKPO (item table) via OData calls.

General thoughts

• Never make Odata calls in loops. Design the Odata service properly instead.
• Use OData models instead of normal Ajax calls. Odata Models are tightly integrated to the UI5 controls also. When the data changes, all the controls will be updated automatically.
• Remove all the commented codes – Otherwise, all the time it needs to load them from server to client and it is a waste of bandwidth usage.
• Destroy complex controls after the usage.
• Stick on the MVC architecture. Never go for Odata calls from the view.
• Use relative paths for web resources – Otherwise you will struggle when you transport the application to QA or PRD.
• Select only required columns in the odata calls. Lazy loading is by default implemented in some of the controls (like UI5 table). Make sure you implement the same in OData level also.

     I hope it was a worth read for you. If I have missed some points, please let me know so that I can update the document. Share your thoughts below. Suggestions and corrections are well appreciated.

Sree hde