fiori wave 2 - architecture blueprint

SAP®

Internal & Confidential Specification

© 2013 SAP AG

Dietmar Hopp Allee 16 D-69190 Walldorf

SAP Fiori Wave II

Architecture Blueprint

of 23

Authors:

Holger Bohle Frank Brunswig Markus Cherdron Reiner Hammerich Alexander Lingg Hans-Juergen Richstein Tobias Stein Gregor Tielsch Luc Walterthum


FIORI WAVE II

History

Version Status Date

0.10 Created 2013-08-02

0.80 Draft 2013-09-02

0.85 Draft 2013-09-11

1.00 Final 2013-09-13

SAP® SPECIFICATION Internal & Confidential

© 2013 SAP AG


SAP Fiori Wave II


of 23

Content

1 Overview ............................................................................................... 3

2 Boundaries ........................................................................................... 4

3 Architecture Archetypes ..................................................................... 4

4 Hybrid Scenarios ................................................................................. 5

5 Frontend Server ................................................................................... 8

6 Software Components ....................................................................... 10

7 UI App Development Infrastructure ................................................. 11

8 Frontend Technology ........................................................................ 12

9 Kapsel Enterprise Browser ............................................................... 14

10 Security .............................................................................................. 15

11 User Management .............................................................................. 18

12 Performance ....................................................................................... 19

13 Implementation .................................................................................. 19

14 Extensibility ....................................................................................... 20

15 Architecture Response ..................................................................... 20

16 Appendix ............................................................................................ 23

This is a technical specification for internal use and documentation purposes only. No part of this documentation may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. SAP reserves the right to change the information contained in this document without prior notice. Copyright © 2013 SAP AG. All rights reserved.


© 2013 SAP AG


SAP Fiori Wave II


of 23

1 Overview

The SAP Fiori Wave II program is focused on a set of 250 Apps developed for smartphone, tablet, and desktop including the corresponding OData services for the SAP Business Suite on HANA. The Fiori apps are written using HTML5 and SAPUI5/M. For some potentially required extensions the underlying jQuery JS library may be used. All supported form factors and operating systems are supported with one development project and a single code line per user interface app.

The SAP Business Suite on HANA system consists of an ABAP engine used for transactional applications and an XS Engine used for analytical applications running on the same HANA database instance. The artifacts of the backend applications and the application content are stored in the HANA database as illustrated in figure 1.

Figure 1: High-level Fiori Wave II Architecture Overview

In addition, the UI apps are deployed1 on a central SAP ABAP Netweaver server which contains

also the UI Service Add-on for the shell services and the Gateway Add-on for the OData enablement of the ABAP-based Suite system. The HANA XS Engine provides a separate

1 Currently there are three options for the deployment of the UI apps like on standard web server, in the XS Engine

repository, or as BSP content in the ABBAP server. Due to lifecycle and supportability aspects the Fiori Wave II Central Architecture Team decided to deploy the UI apps for Fiori Wave II on the ABAP server.


© 2013 SAP AG


SAP Fiori Wave II


of 23

OData channel. The Web Dispatcher provides the proper routing of the HTML and OData requests.

2 Boundaries

What are the boundary conditions for Fiori Wave II architecture?

HANA 1st, which means that a Fiori Wave II app must best run on HANA.

There will be a certain subset of Fiori Wave II apps that must be portable to any database.

o Transactional apps must be also optimized to run best on HANA.

o Transactional apps are built on the ABAP stack, very similar to Fiori Wave I architecture.

There will be a certain subset of Fiori Wave II apps that run on HANA only.

o These analytical HANA only apps are built on the 2-tier architecture on HANA XSE.

The Fiori Shell is the central service for making all Fiori apps available to users.

Make things as simple as possible for application developers. We do not want to confuse

developers with too many options.

Fiori Wave II will be assembled from existing apps (Wave I, C’est BON, Search, 2-tier apps)

and new apps.

o We do not want to massively change the architecture for existing apps in cases where

this is not really required.

o We do not want to heavily invest into workarounds which would require migrations in the

next wave after Wave II.

o For the backend parts we want to use the existing software delivery channels that are

already established and the existing development and test system landscape (infinity

landscape) as far as possible.

o Existing architecture guidelines for HANA optimization in ERP EHP7 and in HANA Live

shall be applied as far as possible.

Due to the legal obligations, we want to avoid accidental dependencies from suite core

ABAP packages to HANA packages.

3 Architecture Archetypes

Based on above assumptions there are three categories of apps in Fiori Wave II. These three categories help developers to guide their architecture and development effort

2.

Archetype I: These are mainly apps that run best on HANA but can also be ported to

other databases with reasonable efforts and acceptable performance. These scenarios

are typically transactional and represent views on and interaction with existing business

processes and solutions.

Archetype II: Purely analytical apps that will only run on HANA following the HANA Live

(2-tier) architecture using virtual data models (VDM). Typical representatives are Smart

2 There are cases for which we want to mix these architecture styles, but check the hybrid scenarios below for more

information


© 2013 SAP AG


SAP Fiori Wave II


of 23

business (KPI Cockpits) but also other analytical, predictive and planning applications.

These apps are not intended for being ported to any other database (AnyDB).

Archetype III: C’est BON and Search applications that run on HANA only but require to

run through the ABAP stack as of today and cannot be ported to 2-tier in the given

timeframe. However, the desired target architecture is HANA 2-tier architecture. These

are mainly C’est BON factsheets and Enterprise Search Models. Again these scenarios

are not intended to be ported to any other database (AnyDB).

The OData services of archetype 1 will be shipped as part of the Business Suite 7i 2013 and shall be portable to other databases and older releases. The OData services of archetype 2 will be delivered as part of HANA Live which is a separate product independent of the Business Suite. The services of the archetype 3 are also shipped as part of Suite 7i 2013 but they run on HANA only

3.

Figure 2: Archetypes for Fiori Wave II Applications

4 Hybrid Scenarios

First, the Fiori Wave II Shell must support a mix of applications from different archetypes in a way that users can navigate from an “Insight”-App to an "Action”-App which means from an archetype II analytical applications or archetype III C’est BON factsheet to a transactional archetype I application. In addition, the Fiori Wave II Shell must support “Homepages” which represent again a mix of these archetypes. UI services for navigation, personalization, SSO, Search and other must be supported as consistent as possible across the different archetypes. Therefore there should a central place where a Shell connects

4 to and is served from with

respect to necessary meta-data and services5.

3 TREX option exists for customers that need an alternative for an AnyDB installation.

4 See below discussion about Frontend Server

5 For hybrid scenarios within a single application, we will allow an application to call both into ABAP and XS backends,

on an exception basis.


© 2013 SAP AG


SAP Fiori Wave II


of 23

Figure 3:Hybrid Scenarios via UI Navigation

4.1 Deviations6

ART-DEV-1: Hybrid Scenario Insight to Action and Embedded Analytics

We are already in contact with Ganapathy Subramanian and Sudipto Shankar Dasgupta. Their team is porting Fiori Wave I transactional applications to a 2-tier architecture and their team did prototypes to which extent a Fiori Shell can be connected to UI services in HANA. As of today it cannot be judged to which extend this architecture will be generally available for Fiori Wave II. This depends on the learning and effort to provide respective services on HANA.

6 Such deviations for special apps must be approved by the Fiori Wave II Central Architecture Team.


© 2013 SAP AG


SAP Fiori Wave II


of 23

Figure X: Hybrid Scenario within a single App

The investigation of the 2-tier architecture is that we allow calling ABAP logic from within HANA XSE as a means to trigger actions and do updates while we use HANA and VDM as a means for reading data. This approach enables a single end point implemented by HANA XSE for both analytical as well as transactional applications. As mentioned above, we do not oversee all implications of this architecture and therefore a general recommend of this architecture for Wave II is not easy. This architecture can be applied in a case by case manner in the given Wave II timeframe. In addition, C’est BON as well as Search is currently implemented on the ABAP stack leveraging HANA and Search via ABAP. This will not change in Fiori Wave II. The desired target state would be to have C’est BON and Search also on the 2-tier architecture with respective Insight2Action support. Timeline for moving this from ABAP to HANA is unknown.


© 2013 SAP AG


SAP Fiori Wave II


of 23

Figure X: Hybrid Scenario via XSE Outbound Calls

The target architecture (no timelines decided yet) no longer makes this distinction. Here we always use HANA XSE as the Gateway entry point and call from XSE into ABAP as needed. Since the 2 containers (XSE versus ABAP) are quite different in nature, we do not foresee high frequent calls between XSE and ABAP but logic is either in one or the other container. However, both are running on top of the same HANA and VDM which can enable both I2A as well as Embedded Analytics. Here the ABAP stack is leading for Embedded Analytics scenarios and the HANA XSE stack is leading for Insight2Action scenario. Embedded analytics scenarios should be enabled by allowing direct access to the VDM from ABAP-based Apps in future, which was ruled out for Wave II due to legal obligations. Also depicted on the next diagram is the Frontend Server, which will still be required in a multi system landscape.

5 Frontend Server

With the assumption that the UI apps are deployed in a standard way7 for all apps there are

currently 3 technically deployment options available: standard web server, ABAP repository, and XSE repository. Due to lifecycle management and supportability the ABAP repository is used as deployment and delivery channel for the UI apps in Fiori Wave II.

In addition, there are several other reasons to put a logically separate frontend server on top of Fiori Wave II application services:

Decoupling the lifecycle of the UI apps from the backend, especially for the apps that

must also run on anyDB.

o Allow faster iterations for the UI apps

o Allow changes to UI by LOB without the need for development privileges in the

backend

7 No distributed deployment but always all UI apps at the same location

Fiori Shell

Hybrid Scenario (insight to action)

SoH (Suite 7i2013)

R

SoH Optimizations

Suite Data Model

IWBEP

Fiori ABAP OData

Views / Stored

Procedures

Read / write

VDM

XSE

Views / Stored

Procedures

Read-only

Read-

only

Fiori XS OData

App Data

Model

Read /

write

R

HANA

Transac-

tional App

Analytical

App

Smart Business KPI Framework

KPI Model,

Drilldown

Read /

write

Archetype II

R

R

write


© 2013 SAP AG


SAP Fiori Wave II


of 23

o Single point of UI maintenance issues like browser support & versions or UI5

provisioning

Central place for theming and branding

Single place for configuration, personalization, and Fiori shell services

Rules based dispatching of request in a multi system landscape like for approvals or

timesheets

Security considerations:

o Similar to an ALG with protocol switch, whitelisting

o Admin for UI meta data does not need to have admin rights in backend (Data

Sensitivity)

Figure 3: End-2-end Runtime Archtiecture for Fiori Wave II

What is the right technology for the Frontend Server in Fiori Wave II and beyond?

This question cannot be answered with a straight-forward delivery and deployment plan because it depends on future product and deployment strategies. Technically the UI apps can be deployment on any standard web server including the ABAP and HANA repository. So therefore beyond Fiori Wave II there are several options:

In case ABAP components are in the game then the Netweaver ABAP Stack provides a

feasible and maintainable option

In case of HANA-Live in which only HANA is involved the HANA repository provides a

feasible and maintainable option.

Web Dispatcher

SoH (Suite 7i2013)

SoH Optimizations

Gateway Backend Enablement (IWBEP)

Fiori ABAP OData Provider

XSE

Suite Data Model

Fiori XS OData Provider

HANA (Archetype I on AnyDB as well)Search Views

(generated)

Fiori Shell

Views / Stored

Procedures

Read / write

Enterprise Search

C’est Bon Infrastructure

Search Model

C’est BON OData Provider

Factsheet Annotation

R

Read-only

R

Frontend Server - Gateway and UI Add-on

UI2 ABAP OData Provider

PFCG, Launchpad Page, Personalization


R

VDM

Views / Stored

Procedures

Read-only

Read-

only

App Data

Model

Read /

write

R

KPI Model,

Drilldown

Read /

write

Fiori Homepage

2-tier Apps

Smart Business

KPI

Drilldowns

Analytical Fiori

App UI

R

„ABAP“ Apps

Transactional

Fiori App UI

C’estBON

FactsheetHANA Search UI

R

Gateway OData AddOn


© 2013 SAP AG


SAP Fiori Wave II


of 23

An alternative can also be the simple industry standards such as Tomcat or Apache.

Most likely flexibility to adapt to a customer specific landscape is needed such as:

o In a simple single system landscape it is HANA

o In a multi-system landscape it can be HANA, Netweaver ABAP or an Enterprise

Portal. However, enabling all of them is a remarkable effort.

o For customers without Enterprise Portal it could be a cloud infrastructure for a

multi-system landscape.

We need to clarify how many of these deployments we will support finally, because this

also has impact on the implementation of the UI services required by the Fiori Shell

6 Software Components

Gateway/OData services are implemented in the native model of a given backend system. In Fiori Wave II this is ABAP and HANA XSE. This also implies that the implementation is lifecycle managed with means available in respective platform. This is done via EhP7 SPs and HANA DUs.

Figure 4: Fiori Wave II Software Components – Archteypes I + II


© 2013 SAP AG


SAP Fiori Wave II


of 23

Apps and UI meta-data such as roles, navigation, launch pads, homepages, et cetera shall be ideally managed in a decoupled lifecycle supporting the desired flexibility with respect to the above mentioned frontend server deployment. Therefore mid-term the use of a separate design time repository and development landscape for all UI app related artifacts needs to be considered. In Fiori Wave II this is Git/Gerrit/Jenkins and Nexus for the UI apps. This content is packaged and deployed for installation on the Frontend Server. The content and UI configuration relies on the UI add-on in Fiori Wave II, and is based on the transport and repository infrastructure of the Frontend Server (NW ABAP).

Figure 5: Fiori Wave II Software Components – Archetype III

Mid-term we should be prepared to support different web server style infrastructures as needed and as effort permits. Examples for these infrastructures are NW ABAP, HANA XSE, Enterprise Portal, HANA Cloud Platform or even simple industry standards such as Tomcat or Apache. In case of Tomcat/Apache UI services required by the Fiori Shell most likely also needs to be provided via that Web Server. Ideally it would be a customer decision which infrastructure to use.

7 UI App Development Infrastructure

The design time for Fiori Wave II app development will be Eclipse based tools for UI5 development as illustrated in figure 4. UI/App development is done in Eclipse. Developers can easily test their apps through a built-in Tomcat that immediately can run the app against a given Gateway end point. In order to make apps available for others they run through a development infrastructure with Git as repository and a Jenkins build server. In this process it is possible to extract language property files for translation of Fiori applications. As a last step the final Web


© 2013 SAP AG


SAP Fiori Wave II


of 23

Resources are uploaded to an ABAP Gateway Server or also to a HANA XSE. This approach harmonizes the way how Fiori apps get developed on a single infrastructure and Git serves as a foundation to decouple the lifecycle of the UI/Apps from the services.

Figure 4: Development Infrastructure Fiori Wave II

In Fiori Wave II development will not have a similar approach for UI meta-data such as roles and navigation. These artifacts will be developed based on the ABAP UI add-on. This content will be developed and packaged on the ABAP Frontend Server. Content is thus able to span multiple Fiori apps, so that customers can be given out-of-the box consumption and insight-to-action scenarios.

In order to increase development efficiency as well as consistency it is investigated to use Gateway Productivity Accelerators (GWPA) tools for generation of Fiori Apps based on templates and recurring design patterns for Fiori Wave II apps. The GWPA is an Eclipse based framework that can generate UI5 apps from Gateway/OData meta-data based on Velocity. AppDesigner is not ready for Fiori Wave II development.

More details can be found in the corresponding Architecture Blueprint:

https://wiki.wdf.sap.corp/wiki/download/attachments/1423055092/Web+Development+Infrastructure+Architecture+Blueprint.pdf?version=2&modificationDate=1376996571641

8 Frontend Technology

Fiori UI apps are HTML5 applications that are being built on the SAPUI5/M (mobile) library, which is enabled for desktop usage also by implementing responsive design patterns that adapt to existing screen real estate and device specifics. All supported form factors and operating systems are supported with one development project and a single code line per application. The self-contained package of the mobile business application consists of referenced libraries, HTML files, CSS including fonts, icons, images, and Javascript files. Runtime data is retrieved through OData services that are tailored to tightly fit the application demand. For an efficient development process and for demo purposes, local JSON files with mock data can be fed into a central connection management instead of real backend data.




© 2013 SAP AG


SAP Fiori Wave II


of 23

Figure 5: Development Infrastructure Fiori Wave II

Beside the SAPUI5/M control library shared between all apps, there are other components and services, which are not covered by the SAPUI5/M library. For example, the Fiori shell container and the corresponding services provides techniques for context sharing between and navigation to different apps, services for personalization, enterprise search, and many more. In addition, there is the request for Fiori Wave II specific business semantic controls, technical logging and tracing, or support of native features like camera of a smartphone device. Also these components and services shall be shareable between all apps.

The application logic itself is structured in the model-view-controller approach. The models are provided as JSON (demo data) / OData (productive data) models from the connectivity manager and the views are defined as XML views using the controls and components provided by SAPUI5 and maybe the common reuse library as illustrated in figure 5. The glue code is included in the corresponding controllers, which are written in Javascript. In addition, the developer of the app must provide at least one property file containing the texts in English and at least one JSON file containing the corresponding demo data.



© 2013 SAP AG


SAP Fiori Wave II


of 23

https://wiki.wdf.sap.corp/wiki/download/attachments/1423055092/Shared+UI+Components+and+Services.pdf?version=3&modificationDate=1377608648230

9 Kapsel Enterprise Browser

Fiori applications usually run in a web browser (Safari, Chrome, IE9+ …). Beside the beneficial abstraction from specific device hardware and operating systems, there are also certain drawbacks. The application resources that make up the actual program have to be loaded from a remote webserver, which costs some additional startup time and can provide a non-responsive experience at runtime. To work around that, browsers make use of caches. However, in the mobile world, caches are extremely limited and don’t survive long. You’ll usually face loading penalties over and over again.

Smart Phone / Tablet / Desktop

Kapsel Browser (Cordova)

UIWebView

Fiori App

Cordova Plugin

Web ServerSAP Mobile Platform

Server (optional)

R

Managed

Optimized

RBasic

R

Cache

Persistent Cache

R

Managed Direct R

Managed Optimized

Figure 6: Kapsel Enterprise Browser

Furthermore, browser controls in the standard browser are blocking rare screen real estate, device hardware is not or only partially accessible and no additional security protocols beyond standard web authentication as supported by current browsers can be implemented, and some more drawbacks that we can’t control or work around.

Together with the SAP Mobile Platform (SMP) department, we plan to release a new browser, the so-called Kapsel Enterprise Browser. First of all it is a very regular browser that can be used for normal browsing (called BASIC MODE). When it runs a Fiori app, though, it will start to provide special support for it (called MANAGED DIRECT mode). For one, it will provide a life-long local cache persistency that will not be purged unless it gets a specific signal that an app update took place. Secondly, it will cover additional needs from Fiori, like full screen operation and attachment handling. These two options will be free, so that every customer can easily improve the Fiori usage experience.

A third option (MANAGED OPTIMIZED mode) will be available if the customer runs an SMP environment. This will enable Fiori applications to make use of device hardware capabilities




© 2013 SAP AG


SAP Fiori Wave II


of 23

(e.g. camera), allow for additional security protocol implementations and optimized delta updates.


https://wiki.wdf.sap.corp/wiki/download/attachments/1423055092/Kapsel+Browser+-+Architecture+Blueprint.pdf?version=3&modificationDate=1376642390347

10 Security

10.1 Connectivity

In the Intranet scenario the Web Client to Gateway connectivity is based on HTTPS HTML and OData requests with security credentials as illustrated in figure 7. In addition, Cross-Site Request Forgery Protection (CSRF) token is supported. The HTML requests are routed by the Web Dispatcher to the ABAP frontend server which is managing the content of the UI apps. The OData requests are either routed by the Web Dispatcher to the Gateway Add-on or directly to the HANA system. The connectivity form the Gateway Add-on to the Suite on HANA system is based on Trusted RFC including authentication. The connectivity from the Web Dispatcher to the HANA business system is based on HTPPS OData with security session token.

The identity provider for authentication is an optional component in the system landscape. The identity provider can be the SAP Portal, Microsoft Active Directory Federation Services (MS ADFS), or any other SAML 2.0 compliant like identity provider. In this case the single sign-on authentication is based on SAML 2.0 front channel authentication based on HTTP redirects.

In addition, the identity provider can be an SAP Portal and the single sign-on authentication is based on MYSAPSSO2. In this case the Web Client connects to the SAP Portal via HTPS HTML to get an SSO2 ticket which can be used to connect to the ABAP server when starting the UI app.

In the Internet scenario the HTTPS HTML and OData requests will be routed by a mandatory reverse proxy who is located in a demilitarized zone (DMZ). In addition, the SAP Mobile Platform (SMP) can be used to support enhanced performance (e.g. Kapsel managed optimized mode), security (e.g. CA SideMinder), supportability (e.g. logging and tracing), and device management (e.g. Fiori Apps pre-deployment).

https://wiki.wdf.sap.corp/wiki/download/attachments/1423055092/Shared+UI+Components+and+Services.pdf




© 2013 SAP AG


SAP Fiori Wave II


of 23

Figure 7: SAP Fiori Wave 2 Security Architecture Overview

10.2 Authentication

The following authentication mechanisms including single sign-on and single logout are supported:

Security Assertion Markup Language (SAML 2.0)

The logon procedure can be based on front channel SAML 2.0 SSO which requires an identity provider like SAP Portal or Microsoft Active Directory Federation Services (MS ADFS). In addition, this requires client side managing of HTTPS redirects and assertion handling. In case of SAML 2.0 single sign-on also the SAML 2.0 single logout feature shall be supported to close all open internet communication manager (ICM) security sessions with one single button click of the end user.


© 2013 SAP AG


SAP Fiori Wave II


of 23

SAP Log-on Tickets (MYSAPSSO2)

The logon procedure can be based on SAP Log-on Tickets (MYSAPSSO2) based on the SAP Portal as identity provider. In this case the single logout feature will be supported by an explicit SLO request to the ICM.

X.509 Client Certificates

If a device management system is available at customer side like SAP Afaria also X.509 client certificate based procedure may be possible. In this case the logout feature will be supported by an explicit SLO request to the ICM.

Form-based and Basic Authentication

For testing or demo purposes it may be possible to fall back on a simple form-based8 or basic

authentication which may be based on the Portal required in the system landscape or even using the user information maintained in SU01 of the Gateway system. In this case the logout feature will be supported by an explicit SLO request to the ICM.

10.3 Session Security Protection

It is recommended to activate HTTP security session management using transaction SICF_SESSIONS. In particular it is recommended to activate extra protection of security-related cookies.

The HttpOnly9 flag instructs the browser to deny access to the cookie through client

side script. As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser will not reveal the cookie to a 3

rd-party.

The Secure10

flag tells the browser to send the cookie only if the request is being sent over a secure channel such as HTTPS. This helps protect the cookie from being passed over unencrypted requests.

10.4 Deviations

SEC-DEV-1: Search Frontend Protocol

For the SAP Fiori Wave 2 search capabilities the connectivity from the web client to the ABAP server is based on the HANA HTTPS Information Access (InA) protocol.

SEC-DEV-2: Search Backend Protocol

For the SAP Fiori Wave 2 search and smart business capabilities the connectivity from the ABAP server to the HANA system is based on the TREX DB API.

8 Form-based authentication is currently not supported in HANA. There are no UI-requests to

HANA that can be responded with a login form.

9 Profile parameter „ICF/SET_HTTPONLY_FLAG_ON_COOKIES“

10 Profile parameter „LOGIN/TICKET_ONLY_BY_HTTPS“


© 2013 SAP AG


SAP Fiori Wave II


of 23

11 User Management

The ABAP and HANA environments are supporting different user management topics in different ways which shall be harmonized in a single SAP Business Suite powered by HANA system.

User Names

The valid characters for user names on ABAP and on HANA are different. On ABAP only uppercase characters are allowed including code page specific special characters like “Ö” or “Ä”. Special characters like “!” are not allowed. The user name on ABAP is limited to 12 characters. On the other hand code page specific special characters like “Ö” or “Ä” are not allowed on HANA. HANA allows only 7-bit ASCII case-insensitive characters for user names. The user name on HANA is limited to 127 characters

11.

For the first release the intersection set of allowed characters on ABAP and HANA will only be supported for user names. In addition, the length of user names is restricted to 12 characters.

Authorization

The support will be limited to the integrated assignment of ABAP and HANA roles in ABAP user maintenance (transaction SU01) and user mass-synchronization report. Analytics Authorization Assistant (AAA) delivered with HANA Live for the Business Suite supports the generation of HANA analytic privileges and HANA roles based ABAP PFCG authorizations. No further functional improvements like automatic synchronization of authorizations are feasible for the first release.

A typical workflow for onboarding:

1. Prerequisite:

a) PFCG authorizations are already assigned to the ABAP users.

b) Each analytical app delivers a HANA role including the required object and application privileges.

2. The administrator uses the AAA tool in the HANA studio to generate for a VDM view used by an analytical app HANA analytic privilege based on the users’ ABAP PFCG authorizations and HANA roles.

3. The administrator uses the ABAP mass-synchronization report or SU01 for single user maintenance to create the HANA users and assign the HANA roles from step 1.b) and step 2).

4. The administrator assigns the required PFCG navigation roles for the Fiori Launchpad to the users.

A typical workflow for changed ABAP authorizations:

1. The administrator assigns to the ABAP user the new or changed PFCG authorization roles.

2. The administrator uses the AAA tool in HANA studio to update the analytic privileges for a user. An already generated HANA role by AAA tool will be automatically updated.

Important: There is no automatic authorization synchronization. The administrator has always to perform the steps in ABAP and HANA.

11

The complete list of differences can be found in the corresponding security guides.


© 2013 SAP AG


SAP Fiori Wave II


of 23

12 Performance

A major cornerstone for the overall user experience is the end-to-end performance as perceived by a user while using a Fiori app. It is the sum of the backend response time (the time to retrieve data and process the requested response), the time to transport request and response data between client and server, and the time to finally render the result on the client browser.

The desired end-to-end response time shall be 1 second in general, with an acceptable stretch to 3 seconds for obviously more complex scenarios. The first startup of an app should be as fast as possible and never exceed 1 second. More complex requests shall be delayed to a later stage of using the app (sub-screen).

On slow networks (Edge radio, 3G, long distance WAN), mobile users typically accept a small additional performance penalty. By showing a spinning wheel after 1 second has passed without an incoming response, the perceived waiting time can be additionally reduced by a certain degree and should therefore be built into the applications.

Network latency (affecting the data transport between server and client) can be as high as 300ms on average for a single one-way data transport (Edge cellular radio), and as low as neglectable on a typical Ethernet LAN infrastructure. To cope with such highly inhomogeneous transport KPIs, and assuming a rendering time between 100-200ms on the client side, backend response times shall not exceed 500ms. To achieve that, OData calls shall be optimized for the individual use-cases and not call and aggregate slow legacy APIs that don’t produce the exactly needed amount of data, but rather need to be post-processed to strip off unnecessary data, thus additionally incurring server load penalty for time and resources.

In compliance with SAP performance product standards, no single screen shall require more than 2 application (OData) calls. OData services shall be tailored to the exact requirements of the consuming application (UI first approach).

Additional performance considerations shall be made throughout the whole architecture (keep APIs simple, use OData optimizations, always use server side compression). The most crucial task, though, is optimizing the backend OData performance with respect to time and resource consumption (the latter mainly affecting sizing for the involved servers).

At build time, the required application resources shall be minified and accumulated in larger libraries to reduce the amount of individual resources to be loaded. Especially on slow radio networks or in general in high-latency networks, the number of individual calls is a much bigger threat to performance than fewer calls transporting much larger amounts of accumulated data.

13 Implementation

Up until now, key focus within SAP has been on business functionality and, with Fiori and related programs, also on the user experience.

In addition, to make Fiori a success at the customer, we need to ensure that the initial implementation is simple and smooth as well. Overall in IT, the project failure rate is around 68% (http://www.techrepublic.com/blog/tech-decision-maker/study-68-percent-of-it-projects-fail/). This is not specific to SAP or Fiori (we don’t have any numbers) but it shows that there is a significant risk for any product to fail at a customer before it even sees the light of the day. A further failure point after a successful implementation is the silent death due to lacking stability, traceability and performance during operations.

It is the objective of the implementation experience to ensure both a smooth, simple, effective and mostly successful implementation of Fiori. And – following that – successful ongoing operation.

http://www.techrepublic.com/blog/tech-decision-maker/study-68-percent-of-it-projects-fail/

http://www.techrepublic.com/blog/tech-decision-maker/study-68-percent-of-it-projects-fail/


© 2013 SAP AG


SAP Fiori Wave II


of 23

Achieving this experience will require additional efforts during the architecting and development of the solution. At the same time we need to be aware that this centralized effort will provide savings at our customer, with a large multiplier – thereby helping the product and reducing manual handholding and support efforts from our side.

Some of the FIX2 goals may be colliding with overall Fiori Wave2 constraints / boundary conditions – or general strategic direction given by upper management. In this case, we want to document these conflicts and the resulting decision.


https://wiki.wdf.sap.corp/wiki/download/attachments/1423055092/Architecture_Blueprint_FIX2_v1.0_final.pdf?version=1&modificationDate=1378816220398

14 Extensibility

Who? When? What?

15 Architecture Response

This chapter describes the differences between the architecture in execution and the architecture described in this blueprint including missing features and the consequences for the product. The requirements are separated to the three corresponding domains User Interface, Gateway, and XS Engine:

User Interface Requirements (UI5):

https://wiki.wdf.sap.corp/wiki/display/FastFioriplanning/Requirements+to+UI5

Gateway Requirements (GWA):

https://wiki.wdf.sap.corp/wiki/display/FastFioriplanning/Requirements+to+Gateway

XSE Requirements (XSE):

https://wiki.wdf.sap.corp/wiki/display/FastFioriplanning/Requirements+to+XSE

15.1 Frontend Technology

The provisioning of local JSON files containing operational consistent mock data for testing the app without any backend connection to an OData service has been replaced by the request to use the Gateway DSP instead of. => The usage of the GW DSP needs additional local installation of the HANA Cloud with the corresponding DSP plugin. Central provisioning of the DSP is not available so far. In addition, the app developer has to use the right URL for the real OData service or the mock OData service. This is not transparent. Therefore app developers do not provide mock data. The consequence is that the app developers, designers, architects, and product owners have to wait until the OData service is available to test their apps.

15.2 Security

1. XSE Req-ID 5: The support of arbitrary SAML IDPs (arbitrary = same as AS ABAP) is not supported. => Most of the customers have identity provider from others vendors like e.g. Microsoft Active Directory Federation Services with no SAML 2.0 support from SAP.

https://wiki.wdf.sap.corp/wiki/download/attachments/1423055092/Shared+UI+Components+and+Services.pdf



https://wiki.wdf.sap.corp/wiki/display/FastFioriplanning/Requirements+to+UI5

https://wiki.wdf.sap.corp/wiki/display/FastFioriplanning/Requirements+to+Gateway

https://wiki.wdf.sap.corp/wiki/display/FastFioriplanning/Requirements+to+XSE


© 2013 SAP AG


SAP Fiori Wave II


of 23

2. XSE Req-ID 16 and UI5 Req-ID 5: SAML with OData: SAML has to work although HANA is only OData provider in context of unified shell. AND in UI5 - Handling of SAML-flow for OData-calls that failed due to missing backend session. Not feasible in Wave 2. => The main impact of not having SAML based authentication at the HANA level is to impose matching user IDs between the ABAP and HANA systems. This in turn could be an issue for multi-tenancy support. In addition, this causes some issue for logout implementation (as we cannot rely on SAML single logout). In the simple situation of a single Gateway and a single HANA system, shell will be able to handle logout. In more complex landscapes, a proper logout solution (with system discovery) would require significant developments. Finally, Fiori applications will not be able to properly handle session expiration (the problem being related to the SAML one). Thus, users will have to reload the HTML page and restart the application in case of session timeout.

3. Search communication with the backend is based on the HTTPS InA (TREX) protocol which does mean that the frontend UI app is communicating directly with the ERP backend system without routing through gateway. => Violation of the SEC-219 product standard (SAP products shall support to be deployed and run securely in segmented networks).

4. XS Engine communication is based on the HTTPS OData protocol which does mean that the frontend UI app is communicating directly with the HANA backend system without routing through gateway. => Violation of the SEC-219 product standard (SAP products shall support to be deployed and run securely in segmented networks).

15.3 Performance

1. XSE Req-ID 5: The HTTP compression for OData requests is out of scope. => Impact on performance.

15.4 User Synchronization and User Mapping

1. XSE Req-ID 11: Mass-enabled user synchronization will not be supported for side-by-side scenario. Customers would have to create the required HANA users for Fiori Archetype II Apps fully manually on the HANA box in a side-by-side landscape. => Customers will not create more than 200 users in this way because it is not manageable. Update 2013/09/12: a report for mass enablement will be provided for RTC.

2. XSE Req-ID 12: New usernames in HANA (additional characters) is not feasible until TechED. If a customer cannot fulfill uniform user IDs between ABAP and HANA because of the character set limitations at HANA side, the customer will be limited to use SAML as SSO mechanism. => Technically restriction which hopefully will not encounter to many users.

3. XSE Req-ID 14: Mapping between ABAP and HANA user is not feasible until TechED for the side-by-side scenario. HANA views that retrieve data for the session user depending on the ABAP user, e.g. HCM personal number from ABAP user ID will not work for the side-by-side scenario. => If users in ABAP and HANA are identically it should work. So similar to Req.-ID 12.

4. XSE Req-ID 19: Requested close integration between ABAP and HANA for authorization administration is not feasible until TechED. Customers will have double maintenance of authorizations in ABAP and HANA. Priority of this requirement has not yet been decided from Fiori side but even with priority 1 it is seen as out of scope from HANA and SAP Basis side. => Customers will not create more than 50 users in this way because it is not manageable

12.

12

There is a tool (Analytics Authorization Assistant) from Suite available for VDM Views which allows for an ABAP user to generate based on the user’s ABAP authorizations HANA Analytic Privileges. It helps for VDM to reduce the TCO for onboarding but it is only a generator. The tool does not support an automatic synchronization of authorizations. The


© 2013 SAP AG


SAP Fiori Wave II


of 23

15.5 Extensibility

1. XSE Req-ID 2: Modification free extensibility of HANA Artifacts is out of scope. It will not be possible for customers/partners to change SAP delivered HANA artifacts, modification free. => SAP cannot protect customer investments on extensions.

generated authorizations have to be assigned manually to the HANA user and a manual regeneration is required after a change of ABAP authorization assignment.


© 2013 SAP AG


SAP Fiori Wave II


of 23

16 Appendix

16.1 HANA 2-tier Target

SoH (Suite 7i2013)

GW Backend Enablement

Fiori ABAP OData Provider

XSE

Suite Data Model

Fiori XS OData Provider

Search Views

(generated)Views / Stored

Procedures

C’est BON OData

R

UI2 HANA ODataNav, Site,

Page, Pers.


VDM

Views / Stored Procedures

App Data

Model

R

KPI Model,

Drilldown

Enterprise Search

C’est Bon Infrastructure

Search Model Factsheet Annotation

HANA

Business Logic

SoH Optimizations

R

(for write-

enabled

scenarios)

Business Logic

Write-enabled scenarios (switched)Switched

transaction

control

Fiori Shell

Fiori Homepage

Frontend Server

(optional, for landscapes

with multiple backends,

technology stack tbd.)

UI2 OData

Provider

Nav, Site,

Page, Pers.ROData, http (write) Insight-to-Action

ABAP-based Fiori App UIs

Transactional Fiori App UI

DispatcherR

OData. http

ROData. http

Gateway OData

ROData. http

HANA-based Fiori App UIs

Smart Business KPI

Drilldowns

C’estBON

FactsheetHANA Search UI Analytical Fiori App UI

R

fiori wave 2 - architecture blueprint

Documents

walldorf sap fiori wave

sap ag dietmar hopp

sap business suite

express permission of

architecture blueprint

fiori apps

architecture archetypes

architecture response