This is a specific view on the possible deployment options for Fiori on an ABAP based SAP Fiori Front-end server (also referred to as “FES” in this document). For a more holistic view that also considers non-ABAP deployment options, please refer to: http://scn.sap.com/docs/DOC-58340
In the context of Fiori, the FES provides the following key capabilities:
- WebServer: serving the static UI5 resources to the requesting device.
- Gateway for oData calls: routing of oData service calls to the backend that implements the service.
- Fiori Launchpad Provider: providing the services required to run the Fiori Launchpad and keeping the related data model.
For more details, please refer to:
- SAPs online help: Setup of SAP Fiori System Landscape with ABAP Environment – SAP Fiori for SAP Business Suite – SAP Library
- A dedicated link list in SCN: Fiori Front-End Server 2.0 / 3.0 – Important Links
- Landscape Deployment Recommendations for SAP Fiori Front-End Server
When performing the landscape planning for the FES, there are general “patterns” of architectural questions that I have observed with myself and others. I am herewith trying to consolidate these questions and try to give some guidance – by putting down some decision-relevant criteria.
Basics: Installation Requirements
Minimum release / deployment requirements: to run the FES SPS04, you need at least Netweaver 7.31 SP5 (plus GW and UI Addon), Netweaver 7.40 SP8 or Netweaver 7.5 SP1 . A higher level is recommended. Please refer to SAP Help for more information: Installation Requirements (Transactional Apps) – SAP Fiori for SAP Business Suite – SAP Library.
Important: Some Fiori apps running on the FES define higher requirements! Most importantly, S/4HANA apps require the FES to run on an SAP Database (such as MaxDB, ASE or HANA). Please refer to the UI Technology Guide for SAP S/4HANA, on-premise edition 1511 for further information.
For the sizing the FES, please refer to:
- http://service.sap.com/sizing > Sizing Guidelines > Others > SAP Fiori Frontend Server Sizing for SAP S/4HANA
- Direct link: https://service.sap.com/~sapidb/012002523100012595652014E/Fiori_FES_Sizing.pdf
Basics: Unicode / Non-unicode backend
It is not recommend to use Fiori with non-unicode backends. For further information, please refer to the following notes:
Basics: Are there any DB restrictions for the FES
For the Fiori Front End Server 2.0, there are no per-se restrictions for the DB. The restriction depends on the content. For S/4 Fiori content, the supported databases on the FES are restrictured to any of the following DBs:
- SAP HANA
- SAP MaxDB
- Sybase ASE/SAP ASE
- Starting point: http://help.sap.com/s4hana > SAP S/4HANA, on-premise edition 1511 (or …FPS01)
- On the following page, under “Product Documentation”, the “UI Technology Guide” describes amongst others how to set up Fiori Apps.
- Direct link to the “UI Technology Guide”: https://uacp.hana.ondemand.com/http.svc/rc/PRODUCTION/pdffee10356f3b43a35e10000000a44538d/1511%20001/en-US/UITECH_OP1511_FPS01.pdf > Page 8.
HUB Deployment vs. Embedded Deployment
Generally, Fiori can be deployed in the folllowing ways:
- HUB deployment: A dedicated FES system is deployed “in front of” the ERP / business suite backend system.
- Embedded deployment: the FES is deployed into the ERP / business suite backend system.
SAP generally recommends the HUB deployment option. Please also refer to: Deployment Options – SAP Fiori for SAP Business Suite – SAP Library
In addition, certain criteria motivate for a HUB deployment:
- Minimum release requirements, as pointed out above. These requirements must be met
- Exposing the system to client devices: depending on the client device and the access (e.g. unmanaged mobile device from an external network), multiple network boundary lines may be desired or required by company security guidelines. A HUB deployment is strongly recommended from a security viewpoint.
- Load: in a HUB deployment, the workload related to WebServer / Gateway / Launchpad is kept in a dedicated system, thereby not affecting the backend ERP / business suite system. Please also refer to the sizing guidelines above.
- SLA: Fiori Apps / UIs / Basis for FIori might be upgraded in a higher frequency than your regular backend system update / patching cycles. Having a dedicated system will decouple the update cycles.
Embedded Deployment for Development / HUB Deployment for Production
A specific approach for the FES deployment: embedded in Development (and Quality) – HUB in Production. To be more explicit, let is use an example: you have an existing backend system landscape on Netweaver 7.40 with a dedicated instance for development (SID: BED), quality (SID: BEQ), production (SID: BEP). To limit the additional TCO, you want to deploy the FES for development on BED and for quality onto BEQ. To have the advantage of an HUB deployment in production, you however want a dedicated system for FES production (SID: FEP), which then connects to BEP.
This deployment option is possible, but to this date I have never done this, so I cannot rule out any issues. A few things that need to be considered in any case:
- Gateway aliases / RFC destinations for the ERP backend systems will point to a local system for development and quality – and to a remote system in production.
- This means also that a trust relationship needs to be set up for production FES and production backend. This is different than for development and quality and there may be some teething problems for the first app to go live in production.
- Transport paths will need to be defined seperately for FES-related objects (GW config and the UI part of the apps) – and for the existing ERP developments, including service implementations. Since both will end up in different servers in production.
Using an an existing SAP Netweaver Gateway System as FES
Technically any ABAP stack that fulfills the minimum release / deployment requirements lined out above can act as a FES. An existing GW system may be a natural candidate to take over the additional role of the FES. Please consider the additional load that you will encounter on your system – as per the sizing guidelines above.
Using an existing SAP PI System as FES
(Thanks to Steven for asking the question). Generally I would not recommend this. Even though I have never seen that in a project – and thereby cannot judge – it does not seem right. The following reasons come to my midn:
- Typically, PI performs business-critical B2B-type communication, mostly asynchronous. I have seen a lot of PI systems that have been sized and stabilized over time to fit these requirements.
- Gateway on the other hand is synchronous, typically end-user related and not B2B. The sizing / SLAs / etc. might be entirely different.
- Also, you may have very different upgrade cycles. I’d see PI as mostly stable over a longer period, whereas Fiori is still more on the innovative edge. You might de-stabilize your PI operations by appliying Fiori-related patches etc. in a high frequency.
Splitting FES into two ABAP Systems: UI-centric vs. DATA-centric system
Background: you may already have established a GW system, which is defined as the OData Integration Layer – any OData related communication should go through this point. On the other hand, you don’t want your GW system to take on any other responsibility (e.g. for reasons of system load, availability / SLAs / architecture governance).
Answer: There is currently no architectural statement forbidding the “split” of the central ABAP FES system into two systems – one UI-centric and one data-centric system. This split is however clearly not “best practice”. On top of that, the following challenges need to be considered:
- Splitting the system responsibilities requires a proxy (e.g. WebDispatcher) in front of both ABAP Stacks (as the client browser prevents OData calls to any other server than the original server from which it requested the static UI resources).
- Change Management will be complex as UI and OData service changes (incl Cache Refreshes) need to be managed in sync over two ABAP systems.
- Fiori has certain inherent OData Services (for Launchpad User / Role / Catalog management) – including an integrated Fiori data model. Where do these run?
Summary: splitting the Frontendserver into does not solve any currently known problem. It will impose however additional effort and risks. Therefore it is not recommended.
As a simpler alternative: split split by use case. One Fiori Frontend-Server that also handles the OData Requests for Fiori components – and one GW for other integration scenarios.
Using SAP Portal as FES
It is possible to integrate the SAP Portal into the Fiori Frontend-Server infrastructure. This may be a relevant feature when the portal has been defined as the central point of entry for the users / the central point where UI-centric roles have been defined. The portal integration provides the following features:
- Run the Fiori Launchpad as a dedicated Framework Page on the SAP Portal.
- Integrate Fiori Launchpad Content into the Portal role model.
The portal does however not replace the FES, e.g.:
- Application UIs will remain on the FES
- The underlying UI5 libs also need to be on the FES.
- Gateway needs to run on the FES.
For more information, please refer to:
Using 3rd party WebServers as FES
Other 3rd party WebServers could theoretically also serve static UI resources. However you need to have a runtime for your launchpad meta model (roles, catalogs, etc) – and the launchpad related services. And 3rd party options are not covered through support. Therefore, I strongly advise against this option.
2-tier FES for 3-tier Backend – DON’T
To reduce your FES landscape, you might want to think that reducing your FES landscape to a two-staged approach is possible in where the DEV FES connects to a DEV and Q Backend system.
In the past customer reportedly had this working, with some drawbacks, but now that with S/4H also WebDynpro and WebGUI tiles are connected, this results in an unsupported state.
(Just for historical reasons, here the statement from the past, which is no more strong enough
Customers who have followed this approach have provided feedback that this is generally working. Nonetheless, this approach cannot be considered best practice. A few aspects coming to my mind:
- Increases manual effort during testing (are you using the right system alias?)
- Possible intereference between development and test activities
- Possibility of invalid test results (if wrong system alias was set selected)
- In case of upgrades required on IW_BEP in the backend system: need to upgrade both DEV and Q Backend.
- Generally an asymetrical transport in the Backend.)