Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
raeijpe
Contributor

At lot of people start developing own SAP Fiori Apps, but missing the programming guidelines to build a future proof applications for the Fiori Launchpad. At the SAP Teched 2015 in Las Vegas and Barcelona I presented my 10 golden rules to build future proof freestyle Fiori Applications based on UI5 SDK 1.28 and higher. In this serie I will explain the background of the rules. This blog is about golden rule 2:

SAP Fiori Apps always exist of a UI part and OData part which must be defined in different software components

Before we can go in-depth into this rule, we need the understand the platform. The main part of SAP’s offering is build on top of one of its three supported platform:

  • Netweaver ABAP Stack
  • Java Stack including Netweaver Java
  • HANA platform

Historically SAP built its business logic on top of these platforms and they have all their own API and UI technologies. The ABAP stack for instance has BAPI, RFC, IDOC, WebServices as API's and uses during time al lot of UI technologie like ABAP Dynpro, Internet Transaction Server (ITS), Business Server Pages (BSP), Web Dynpro ABAP (WDA) and Floorplan Manager (FPM), Flash/Silverlight/HTML Islands. Some technologies were combined into a Portal or NetWeaver Business Client. Some specific ABAP systems got there own UI technologie layer like WebClient Ui for CRM or specific end-user tools like for BW and Business Objects. Java Beans, JPA, DAO and JDBC are API's for the Java Stack and present the business logic to the end-user through Java Clients, JSP, Servlets, Web Dynpro Java and iViews. For the HANA platform SAP tool introduces even more API and UI possibilities, but those are prepared for the future decisions like HTML5 and ODATA. But even the HANA platform is open and additional API like XHR service and SINA are provided as API layers to enduser front-ends.  As you can see, SAP needs to support a lot of different UI and data-integration technologies and customers get them all.

SAP decided for S/HANA to simplify and standardise the layers based on the data model, the business logic, API and UI: Core Data Services for the data model layer, Business Object Processing Framework for the Business Logic, OData services for the data access API layer and SAPUI5 for the UI layer. To simplify the migration to S/HANA, SAP already delivers Fiori Apps on the Business Suite. These Fiori apps will reuse the existing business logic and will be based on new standardised data interaction layer and ui layers.

To make existing business suite applications OData ready, SAP helps you to transfer the existing business logic into OData services. On the ABAP stack you can use SAP NetWeaver Gateway to make ABAP code OData enabled. On the Java stack you can use Apache Olingo (donated by SAP) to make Java code OData ready. And in the HANA XS2 engine you can run NodeJS, J2EE and C++ code which can use OData libraries to access data of the HANA database. The presentation layer on top of all SAP solutions will be SAPUI5, which is SAP’s own flavour of HTML5 based on open standards which can run on any device.

The simplification decision of SAP is the basis of all new Business Applications which are and will be developed by SAP and named Fiori Applications. They exist always about two parts: An platform independent UI layer (UI5 package) and a platform dependent business API layer (OData package). This approach makes it easy to replace business logic and/or UI logic without influence each other. So the step from Business Suite to S/4 Hana can be made easily without getting a new UI for the enduser. Also the data access API can be reused or embedded by other applications like internet of things. And in the future SAP can change the UI technology without changing the business logic.

This flexibility by separating UI and API layer force you to build Fiori apps in two packages: a OData package and an UI5 package. The dependency of the API layer with the platform and the independency of the UI5 layer force you to develop them in a separated software component. The OData package can only deployed on the used platform, but the UI5 package can be deployed on every platform which supports the Fiori Launchpad. In an on-premise environment, this can be the ABAP Stack, the Hana platform or the SAP Netweaver portal. In the Cloud this can be Fiori Cloud on the Hana Cloud Platform (HCP) which still can use the OData Service on-premise.

In my next blog I will explain rule 3, SAP Fiori UIs are build on top of SAPUI5  framework with a restricted set of the UI5 Controls and written in AMD syntax. An overview of all 10 golden rules can be found here.

Labels in this area