SAP Fiori workshop review
This week I attended the SAP Fiori workshop in Bangalore conducted by Masayuki Akiyama and Claudia Polster from SAP RIG. And here is my review and some thoughts on SAP Fiori and this workshop.
Overview & GTM information
Some highlights from my side:
1) License Strategy:
Current license strategy is applied to the 25 apps in a collection right now. But normally customers always start with 3 or 4 apps as a start. And in the future there might still be more apps added to the set, but there is no saying about how the license strategy will adapt then (I think the pricing will be different and existing customers will get upgrade promotion or sth.)
2) Language Support:
As for SP00 (original version), only English and German were supported. With SP01, the available languages has been increased to 8. (Simplified Chinese, Japanese, Thai, Portugal, French and Spanish?). However, as the apps are all HTML5-based apps, the other languages support only involves the web page resource’s translation work, thus for customers from other regions/countries, this should not be a concern to stop you trying SAP Fiori.
3) Push Notification
In the current version (SP00/SP01) of SAP Fiori, the notifications are not provided in realtime but through a periodic refresh (send request to backend for updates). The realtime Push/Notification is on the roadmap and might be available in later version.
4) Support Packages
SP00 is the original version. SP01 includes a list of technical improvements and language supports. SP02 will include some functional value-adds.
SAP Mobile Portal Integration
The SAP mobile portal will be provided as optional combination with Fiori. Differences? Well, mobile portal is more like a multichannel entry point of all business suites backend and it should be an enterprise level info-center but not for mobile workflow/business operations.
And this mobile portal is mainly for the those SAP Portal customers. Mobile portal acts like the Web Portal to provide the different interfaces how JCo could communicates with backend. And if the Fiori is integrated with Mobile Portal, the layout looks better for me.
A highlight of such a combo is the Security Value-add. With the mobile portal, SSO would be available for sure. So as what you could do in traditional SAP solutions landscape, you can use SSO to take care of the authentication of Fiori.
Currently the Fiori application’s architecture involves the SAP ERP backend server, SAP NetWeaver Gateway and the front-end devices only. As a easy-to-deploy solution set, this looks quite lean and ensures the efficiency of implementing SAP Fiori at customer side. A typical landscape might still contains a DMZ area with Rely Server or SAP’s Web Dispatcher for reverse proxy and load distribution.
And for Gateway Server deployment, you could still have two choices (one central separate Gateway server with multiple backends connected / completely integrated with the ERP backend if the backend is with some latest version).
Installation & Configuration
One important hint is that for Fiori implementations, the installations and configurations work is minor, while the prerequisite check would even take much more time for that. So enough attentions should be paid to the pre-requisites.
You could find enough information about the pre-condition of implementing Fiori in your landscape at http://help.sap.com/fiorid and the guide pdf document. Roughly they are like this: NetWeaver should has SAP_BASIS with 7.00 SPS21. ERP should be with version 6.0 SPS15. Gateway should be with version 2.0 SP6. And the client…should be at least Internet Explorer 8, or latest version of Google Chrome / Safari on computer.
SAP Fiori is available at SAP Service Marketplace under the namespace of SAP Mobile Solutions. For most of the applications, normally there will be two add-ons for each that you need to download. Components start with ‘UISIA’ is for UI. the other type starting with ‘SIA##’ is for OData. But there are also some exceptions, and they are mainly because that the native apps released previously are still sharing the same backend OData add-ons.
The UI add-on should be installed with Gateway Server, while the OData add-ons should be installed with Backend ERP server.
Two steps you cannot missed before you start the configuration will save you a lot of time on trouble shooting.
1) Notes implementation. -> Check the administration guide for all the necessary Notes.
2) Double check the backend corresponding functionalities and make sure there is no issue at the backend.
Important Reminders also include that you should create Trust RFC connections from Gateway to ERP (and backend user with S_RFCCAL authorization). And you should maintain two system alias in Gateway’s connection settings. One for default usage and the other one should be created with “For local app” checked and Software Version being /IWPGW/BWF.
Within 25 apps, SAP Fiori includes 7 Approve apps out of the box. And you can easily add any workflow with Approve scenarios just providing the generic contents to the SAP Fiori Approve Request app. And this is the easiest extendibility Fiori has. To do this you need to configure the customizing on GW, implementing corresponding BADI and make changes on the Fiori Launch Page (on the backend). No modifications from the UI side are needed.
For the other standard apps, saying if you want to add fields on the screen, you need to extend the oData services, prepare the corresponding BAPIs and then change the UI accordingly.
For more complex customizing requirements like functional enhancement, it is recommended to consider developing custom apps from scratch. And the difference is that you need to design you oData service and finish the data fetching BAPIs and also the UI developing of cause.
Process Gateway inside Gateway server has provided integration possibilities with SAP Business Suites, NetWeaver BPM and 3rd Party workflow backends.
Gateway OData Basics
It is a solution for multi-channel businesses. For enterprise computing, if there isn’t an uniform Data model and under it uniform API, different channel would need different developments through the data model and API levels which will bring poor scalability, and would cost more system maintenance cost and administration efforts. Gateway OData provides the possibilities of developing different clients from any platform, any environment. And with this the frond-end developing could be done without SAP knowledge but could still integrates with SAP Business Suites well.
OData extended the definitions to include the Simple Types, Complex Types, Associations between entries, Navigation Paths, standard QCRUD operations and even custom behaviors (via Function Import). It is more advanced than ATOM because it contains the metadata describing the message itself, which makes it fully RESTful. And the message format could be either XML or JSON.
Entity Data Model is corresponding to the business objects in business suite but with more information like Navigations and Function Imports. With the service parameter $metadata, you can easily get the complete EDM xml description of the OData service (this is only in XML but not JSON). OData provide all kinds of operations (like ReadEntity, ReadEntitySet etc..) and different parameters including $filter, $top, $skip, $expand, $value, $select and $count to thandle the result sets from backend or manipulate the processing in backend system.
Gateway Service Architecture consists of two parts: the Model Provider Class which describes the data models of the gateway service in ABAP, and the Data Provider Class which implements Gateway service’s functionality based on the MPC. This part should exist with where component IW_BEP is installed. External Name provided by the DPC instance will be the key that maps to the final Service in the Service Catalogue on Gateway server.
There is also an API Class exists in backend which mainly provide the access to the standard business suite API’s. As we mentioned in the advantage of OData, we do want to make sure all the OData service consumers keep consistent, but don’t forget they all should also keep consistent with the SAP GUI the backend! – this explains perfectly why SAP will not provide new functionalities in the backend in Gateway Mobile scenarios.
Gateway Service Development
This skill is required because every customer need customizing and support, either creating a new one or extend the existing MPC/DPC is needed. Manual work on the MPC is boring and useless in my mind because the real time should have already been used in the service model design phase. Fortunately, NetWeaver Gateway provides a tool for the service generation (transaction: SEGW). And this can generate both the MPC and DPC class and then you can make minor changes on that. More information about the Gateway Development could be checked out in SAP Help Page.
SAP UI5 Overview
SAPUI5 stands for SAP UI Development Toolkit for HTML5, so there was never SAPUI4… 😉
And it is the toolkit for quickly building lightweight business UIs on different platforms. As I had little Web developing experiences, I have no idea what the other advantages like “Cutting-Edge Controls”, “Powerful Theming & Branding” and why it will bring up the efficiency and performance of Web Applications…
Although the web app source code exists only in one place, but apps using SAPUI5 on Desktop or on Mobile does matters because the implementation is actually different from each other.
Browser Support includes the main four browsers with the latest versions. More specifically for IE 9, no issue. For IE 8, it is supported with graceful degradation for CSS3 features like round corners, text-shadows etc. For Firefox, it supports version 3.6 and the latest FF. For Chrome and Safari, it support both the latest version.
SAP UI5 follows the MVC concept to build up the web apps. Therefore the basic components of an UI5 app will have View files, Controller files and the HTML file containing the base frame app-file referencing all required resources. For example, UI5 app always needs to have a bootstrap file to initialize the application. Parameters or configuration data is contained inside.
SAP UI5 Studio is a set of tools on Eclipse. Via install new software in Eclipse you can import the UI5 functionalities. It contains some Wizards for project/view/control creation, control development, code completion for UI5 controls, TeamProvider for BSP repositories and some other fancy advantages. More information is here: https://tools.hana.ondemand.com/#sapui5
For basic NetWeaver version, the Source Code synchronization needs to be done via report /UI5/UI5_REPOSITORY_LOAD. An important reminder here is that you need to create a brand new folder for the code download, because there is some bug with the download part, it will just overwrite the whole download folder and then import the code. so be careful!!!!
More information for UI5 could be find in UI Wiki page and the SCN community for UI5 (google them!)
UI Theme Designer
To maintain the theme of the mobile apps, manual change on CSS might be complicated. And UI Theme Designer is created to do this in a user-friendly way.The basic idea is to load the application (link) to the them designer, it will read all the theme elements and provide you an UI to check them out and make necessary changes. After the changes are done, you can directly publish the themes to backend after the modification is done.