Sometime ago, we developed a dashboard solution that is applicable to the customer’s service area. Upon analysis, SAPUI5 was chosen as the technology that the solution would be implemented. There has always been an understanding and agreement to the chosen technology for Data Retrieval . The customer uses SAP Business Intelligence (BI) and which complies to the requirements of the Info provider’s displayed data. The project can be implemented quickly, since the Easy Queries are in a position of providing the data direct as OData service. During the implementation phase we spoke to the customer regarding the geographical representation of the service messages which was based on Google maps. The idea was well received and we implemented this feature. This feature can be implemented at a reasonable cost, thanks to the enrichment of the existing OData Services-Data with Geolocation that we enquired over a REST-API.
What does the customer project have to do with the blog series?
In preparation of going live, the dashboard displayed the service messages so well that it became obvious that some messages in the backend system were unstainably maintained. To view the messages you had to select those on the dashboard and change to SAP GUI in order to display the service message. The associated media break disrupts the user experience, is inconvenient and inefficient. The dashboard is also user friendly.
OpenUI5/ SAPUI5 and SAP Gateway
BI Easy Queries as Gateway-Services
There are various possibilities in obtaining data from the SAP system. In addition to the remote enabled function modules (RFCs), SOAP Webservices and other techniques, SAP developed the SAP Gateway. Note: Older and more experienced readers should not confuse this new wording with the old SAP Gateway. In brief, the SAP Gateway is used to provide data from the SAP backend system via REST API’s that are provided, as a rule, in OData format (also JSON). For this purpose there is an established trusted connection between this gateway and the backend system. The gateway system in particular can access data in the backend system. The basic functions that are normally supported by the gateway are the CRUDQ-operations such as create, read and delete a record. There is also an additional function of quering data lists. Additionally, there are other possibilities such as navigation of header data to item data. Neither REST nor OData are SAP inventions but are used by SAP as well as by others. They are, therefore, open to other programming and script languages. As an example, one can in the same manner provide REST and O-Data from an SAP-System and Sharepoint.
We have briefly spoken about the history of UI5 and what a gateway can do. There is, though, the question of what Fiori really is. SAP develops its own applications under the name of Fiori. These applications are developed (with Apple partnership) in SAPUI5 and use the SAP Gateway. Furthermore, they are in a framework that takes care of the display in the so called Fiori Launchpad as well as authorizations. Thanks to the Fiori Design Guide from SAP, all applications can be seen and behave in the same manner. This enables companies, such as ours, to create Fiori-like applications that behave the same way as normal Fiori applications do. Fiori Overview Pages (OVP) The Dashboard functions pretty well and fulfills all project requirements. It is used by employees as it illustrates the relevant information very clearly. SAP has developed the Fiori Overview Pages for scenarios in which an employee can gain an overview of a particular area and delve deeper into the data base and initiate follow up activities. The OVPs are created for various subject areas (e.g service, sales, purchasing) and indicate the so called cards. Cards are available in table and list formats such as a diagram and in a form of a stack of cards. The OVPs can be personalized and thus every employee can control which cards are displayed on the overview page. A global filter ensures that the information can be filtered on the cards. This, for example, enables information on a customer to be filtered and these customers can be considered more accurately. The abilities of navigation is another attractive property of the card. This makes it possible that one can search the last service orders and with a single click can access the display of the service order. Relevant information can be chosen and if necessary changes can be carried out. Different OVPs cards are obtained based on the examples of the service order. The earliest and latest service orders can be illustrated and displayed on the list and table cards. Service orders with „standstill“ can be shown as a stack of cards. The core information on the service orders is shown by clicking on the stack of cards. The user can prioritize different jobs or to confirm the succesful processing of an order by using the buttons at the footer of the card. Let us once again go back briefly on the global filter. Have you ever experienced the situation where your supervisoris with you and some information is needed about the customer whom he is currently calling? It is convenient that the displayed customer summary page can be filtered and open service orders and their current status can be immeditaley viewed. There is no need for retrieving values in various lists but only obtain information where and when is needed. The biggest drawback is the lack of ability of creating your own map types. Standard scenarios can be covered by the existing map types but the desire to create your own map types and fulfill customer requests still remains.