Skip to Content
Author's profile photo Jochen Saterdag

Planning the SAP Fiori Front-end Server (FES) – Architecture Questions

Kindly notice that the blog further below is now outdated and will not be further maintained. In particular, for S/4H scenarios, the information is not correct any more. Related up-to-date information can be found here here:

 

 

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:

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.

 

Basics: Sizing

For the sizing the FES, please refer to:

 

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:

http://service.sap.com/sap/support/notes/1978213

http://service.sap.com/sap/support/notes/2016014

 

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

 

Official reference:

 

 

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.

DON’T!

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.)

Assigned Tags

      32 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo soujanya bhaumik
      soujanya bhaumik

      very informative and well articulated blog.

      Author's profile photo Steven De Saeger
      Steven De Saeger

      Thanks Jochen for this great article ...

      I just asked a related question on whether a SAP PI system can act as a Fiori Front-end server .. judging on your article here it seems it can and it is the best likely candidate in the given existing environment ...  it would be great if you could provide an opinion 🙂

      Author's profile photo Jochen Saterdag
      Jochen Saterdag
      Blog Post Author

      Hi Steven,

      thanks - interesting question. On the PI, that's something where I would be hesitant:

      • 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.

      So my gut feel tells me: rather keeep them seperated.

      Makes sense?

      Cheers

      Jochen

      Author's profile photo Steven De Saeger
      Steven De Saeger

      Hi Jochen,

      Thanks for your insights & feedback 🙂

      It is indeed an interesting question ... I agree that a PI system is typically sized for asynchronous processing and by nature has a different profile in terms of usage ... on the other hand for this particular system there are already alot of synchronous PI message flows and we already have an operational SAP Gateway hub and a couple of UI5 applications ( with limited usage though ) running ... so the system is already having a 'dual alike' role ... nevertheless you make good points in upgrade paths & patching & stability... I will take your points into consideration for our SAP basis guys to decide on where to take it next ...

      Author's profile photo Miguel Angel Sanz Espinosa
      Miguel Angel Sanz Espinosa

      Hi Steven, I know this post is rather old, but I’d like to know what the outcome was with your issue: Did you re-use same server for both fuctionalities or did you keep the functionalities apart on different servers?

      Author's profile photo Steven De Saeger
      Steven De Saeger

      Hi,

       

      If I recall well we didn't install the FES on PI as we were not interested in using Fiori Launchpad ... but we did run several UI5 apps for several years on the PI server ...

      Later on a separate FES server was installed though.

      Steven

       

      Author's profile photo John Patterson
      John Patterson

      Hi Jochem

      You raise an interesting point about splitting FES into 2 systems.

      <My Opinion>


      Up until recently I actually thought the Central Hub FES/BEP model was being wrongly promoted as the default solution for Fiori, a single point of entry is one thing, but security has many layers, I see this as just one layer which is subjective and not consistently promoted (see OSI Model for example).

      I thought it was really targeting customers who could / didn't want to put gateway on "legacy" SAP systems. I often see customers take this option because they are reluctant to upgrade CRM or SRM systems for example, just wanting to keep the lights on until its no longer needed. Most customers I see have a long term plan for HANA and see this a place where they will start rationalizing. I point out that in HANA by default the FES/BEP is combine to one and independent of the Gateway pattern adopted there is still work to do on those legacy systems regardless.

      When you go into customers its always an interesting discussion to have AMS, has not changed since the MySAP WorkPlace days, they want to reduce the operation costs and your basically telling them they need 5+ (D,T,Q,PP,P) new instances to deploy a PO approval app and then you say wait there is also a Mobile Platform and an IdP and ... given everything is virtual nowadays, spinning up a new instance should take seconds not weeks and managing should be automated (Puppet, Docker whatever)

      </My Opinion>

      When i heard SAP had partnered with Apigee to create an API Management Solution I had very similar thoughts about splitting the Gateway instance into Data vs UI for load, availability and governance etc.

      The OData API that Netweaver Gateway provides is your App, there should be no business logic in your UI and therefore splitting this FES into 2 makes perfect sense.

      The UI content is really just static resources (akin to the WGATE of old) and shouldn't be tied to a SAP system for various reason like CI, Cloud and patching etc. (SAPUI5 dependencies like patches should be discoverable from Git or Bower for example) would love to see the ability for example of configurable deployment of NGINX containers which could easily deploy the static content close to the users.


      I think as customer start deploying more and more Gateway services, these services really need to be properly managed, consistency, re usability, SLA's and metrics etc.


      I guess my point is, with HANA customers are moving to a monolithic architecture which scales up, however to get where the users are you need to scale out as well, splitting out the front end definitely opens up the options for adopting best practices.


      hope some of this makes sense

      JSP

      Author's profile photo Former Member
      Former Member

      I agree with John on splitting the FES system into two separate systems. In fact, I think "Frontend Server" is an ill-named term for a system role in a system architecture for SAPUI5 / Fiori applications. The role for Gateway is to expose SAP backends as an OData REST Web Service API. This is one step towards SOA, in which all systems communicate in a service-oriented way. Imagine all SAP backends can communicate using only OData API.

      The role for a Web Server is to serve static and dynamic web contents. In modern Web application design, the presentation layer goes completely to the client side (runs in a browser). So other than loading static contents (HTML/CSS/JS files and images etc.) from Web server, the client only sends REST requests for data to the Web Server and got JSON response. These REST requests are screen-based, i.e., it asks for data to populate its screen.  The requests are not domain-based, i.e., it need not have an understanding of underlying business objects and their complex APIs.

      To separate the screen-based API with the Gateway-provided domain-based API, there needs to be a separate layer in the architecture above Gateway to provide the data service for the UI screens. Typically this can be implemented with NodeJS (along with a DB to cache results for performance)

      For static Web content, Nginx would suffice.

      Author's profile photo John Patterson
      John Patterson

      To separate the screen-based API with the Gateway-provided domain-based API, there needs to be a separate layer in the architecture above Gateway to provide the data service for the UI screens. Typically this can be implemented with NodeJS (along with a DB to cache results for performance)

      Not sure I understand where NodeJS or a DB fits in maybe you could elaborate.

      One of the opportunities you get using API Management solutions like Apigee would be transformation, you could take generic services like for example content and document management and make them a better fit for the client app, not sure it fits in with current Fiori patterns though. A question i get asked a lot is around SAPUI5 consuming AIF data, maybe a good use case.

      JSP

      Author's profile photo Former Member
      Former Member

      In "SAP Fiori Architecture Topics", which is a doc #U59 in the Fiori Design RDS, one of the best practices is to minimize the # of calls from the browser client to FES. Ideally there is one call per screen. This call is very specific to retrieve data that's only necessary to populate the UI. That's why we need a JSON API at the server side just to serve this need for screens. This does not need to be OData API, just a plain old REST API.

      This data API layer de-couples with the Gateway API layer, because they serve different purposes. Ideally the Gateway API for a particular SAP backend, e.g. SAP CRM, will provide a open standard web services and full-function interface with which SAP CRM is willing to interact with other systems.

      Check out LinkedIn's mobile architecture, for screen-based REST API.

      Author's profile photo John Patterson
      John Patterson

      wrt minimize the # calls

      - use Component and Library pre-load files, this condenses and concatenates all your UI5 code (controllers,views, i18n, css, images etc) into single file and massively reducing round trips

      - design your OData services to use $Expand so new views will load faster, idea is to  inline multiple Entities into the initial payload, reducing round trips

      - take advantage of cache headers in your Gateway service

      - take advantage of app cache on the UI5 side

      is a good start

      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic

      Hi Jochen,

      I checked the page you recommended for non-ABAP deployment options but could not find information on that topic: http://scn.sap.com/docs/DOC-58340

      Could you please help me with the more specific link and examples, which non-ABAP options are available?

      Thanks,

      srdjan

      Author's profile photo Jochen Saterdag
      Jochen Saterdag
      Blog Post Author

      Hi Srdjan,

      The only non ABAP deployment options that are supported are:

      • SAP Enterprise Portal
      • SAP HANA Cloud Platform

      Please see my additions above in the blog, or refer to: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0b8f7bc-244b-3210-3ea2-cf9a3c3bc908?QuickLink=index&…

      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 would strongly advise against this.

      Kind regards

      Jochen

      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic

      Hi Jochen,

      thank you very much for the link to excellent document, exactly what I was looking for.

      On a page 4, in Supported UI Technologies row, the "URL" is listed together with technologies like SAPUI5, WebDynpro, Personas etc. Why the term "URL" is put here, at the same level with UI technologies - the only thing I could not figure out ?

      Comment on this highly appreciated.

      Kind regards,

      srdjan

      Author's profile photo Jochen Saterdag
      Jochen Saterdag
      Blog Post Author

      Hi Srdjan,

      the term "URL" describes the ability to access generic Web Resources via Launchpad. (resources that can be called via URL and run inside the browser).

      Best

      Jochen

      Author's profile photo Tobias Trapp
      Tobias Trapp

      As always you provide excellent content 🙂

      I have another question that deserves clarification. Note 2217489 - Maintenance and Update Strategy for SAPUI5, NW AS ABAP UI Technology and UI Add-On and 2219596 - SAP Fiori front-end server 2.0 - General Information introduces a new term "Fiori Froentend Server 2.0". I think this would be a good topic for a new blog entry.


      I have a question in this context. If those note right an AS ABAP NW 7.40 with SAP_UI 750 and SAP_GWFND 750 if an FES 2.0 and so can serve as a FES for a NW 7.5 backend. Is that true?

      Best Regards,

      Tobias

      Author's profile photo Oliver Stiefbold
      Oliver Stiefbold

      Hi Tobias,

      AS ABAP 7.40 always has an Gateway Foundation 7.40.
      AS ABAP 7.50 always has an Gateway Foundation 7.50.
      No matter if with or without FES 2.0 on top.
      FES 2.0 always has an SAP_UI 7.50 build in - thats the idea of FES 2.0.
      it can be deployed on AS ABAP 7.40  with Gateway 7.40 or on a  AS ABAP 7.50 with GW 7.50
      (or on AS ABAP 7.31, which i do not recommend)

      Author's profile photo Paul Abrahamson
      Paul Abrahamson

      Excellent round-up. Thanks.

      Author's profile photo Daniel Munoz
      Daniel Munoz

      Thanks for the useful post. It helped on clarifying some aspects, however I still have one doubt I have been unable to answer.

      We are planning to install a front-end server to run Approve Requisitions and Approve Purchase Orders fiori apps from product FIORI ERP APPLICATIONS X1 (SAP Fiori Principal Apps 1.0 for SAP ERP) which according to note 2200415 it has been released for SAP_UI 750. Backend release is ERP 6.0 SPS15

      You mention in your post that there are no per-se restrictions on the DB layer from FES 2.0, however, whan planning an Installation of SAP front-end server 2.0 on Netweaver 7.50 and FIORI ERP APPLICATIONS X1, only SAP ASE, HANA or MaxDB OS/DB files are shown to be selected./wp-content/uploads/2016/08/fes20_1013889.png

      /wp-content/uploads/2016/08/fes201_1013903.png

      If we try to launch Maintenance Planner from fiori app reference library, we get no choice for Netweaver 7.50

      2016-08-11 16_31_20-WKI_MaintenancePlanner_FioriAppReferenceLibrary.docx - Word.png

      Also, from the fiori apps reference library, only Netweaver 7.31 / 7.40 is shown as option for the given product.

      I would appreciate if someone could throw some light on this, stating if it's possible or not to use FES2.0 on NW750 to run mentioned fiori apps on a backend ERP6.0 SPS15.

      Regards,

      Daniel

      Author's profile photo Oliver Stiefbold
      Oliver Stiefbold

      Hi,
      in general all Fiori apps should run with its newest product version with FES 3.0.  (However, some Fiori apps might not be already released for FES 3.0 or there might be some/few Fiori apps or versions, which will not support FES 3.0 for technical reasons. Please check in Fiori reference library)

      In case of FIORI ERP APPLICATIONS X1 you choosed the instance "Central App ui 2.0". In my system I see, that it is released for FES 2.0 and FES 3.0 - so should work. If not, please open a support ticket.

      Author's profile photo Hernan Enriquez
      Hernan Enriquez

      One question I have about the deployment of FES. What is the best approach for architecting  FES when we have a mix of S4HANA systems + Business Suites 7.40. Should we look for a Hub installation of FES with HA to serve all? Should we go with a FES for S4HANA(s) and one for Business Suites 7.40?
      Also, I was told recently (I need to get more context) that SAP recommendation is to have one FES per S4HANA instance is this true?

      Author's profile photo Oliver Stiefbold
      Oliver Stiefbold

      Hi Hernan,
      One FES per S/4 in general is not true. this is the embedded scenario which can make sense if you want to run the system separated e.g. for lifecycle reasons.
      General setup is hub deployment - one for all. Means one FES 3.0  (wit dev, test and prod) for S/4 HANA 1610 and BS with NW 7.40.
      S/4 HANA 1511 however isnt released for FES 3.0, so needs to be upgraded to 1610.
      However FES 3.0 has a new default theme "Belize", which would be then the theme for all Fiori apps. If you dont wnat this, you have to split the FES again, and you loose the FES-Fiori Launchpad as central integrator.
      For more infos see e.g.: https://experience.sap.com/news/sap-fiori-2-0-now-available-for-sap-s4hana/

      BR, OLiver

      Author's profile photo Kevin Ooi Wen Chong
      Kevin Ooi Wen Chong

      A very good blog, covers the many 'creative' alternative architecture deployment possibilities (as well as why they are not best practice) which are usually not covered in the SAP Landscape Deployment Recommendations.

      Author's profile photo Former Member
      Former Member

      Thanks Jochen for such an informative blog. I have a quick question: Do we have any way to login to FrontEnd using the backend login credentials without using SSO?

      Scenario: We have different ECC systems (EC1 / EC2) where users might have different passwords. And we are planning to get a front end (Hub-implementation) for Fiori. But users will have to use separate password to login to this system until we have SSO. Is there any SAP standard way we can use so that our end users will be able to use same password as they use in ECC to login to Fiori Front End.

       

      Author's profile photo Bernard Le Tourneur
      Bernard Le Tourneur

      Hi Ravinder - did you get a response to this question?

      Author's profile photo Oliver Stiefbold
      Oliver Stiefbold

      Hi, I am not a security expert, but due to my knowledge, this what the CUA - Central User Adminstration does:

      https://wiki.scn.sap.com/wiki/display/Basis/Central+User+Administration(CUA)+configuration

      https://uacp2.hana.ondemand.com/viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.5.3/en-US/cd16b0d4100711d295750000e82de14a.html

      Author's profile photo Bernard Le Tourneur
      Bernard Le Tourneur

      Hi Jochen.

      We are implementing the Central Hub Deployment option as concerns the Fiori Front End Server. I am curious about the proposed database and the size to service the FES. We have 2 x HANA appliances spec'd with the following specs: 256GB RAM / 1TB HDD / 16 vCPUs

      From my perspective I am unsure how the appropriate sizing of the db for FES is obtained - can you help by pointing me in the right direction?

      With appreciation.

      Author's profile photo Oliver Stiefbold
      Oliver Stiefbold

       

      Hi Bernard,

      did you check the sizing information? http://service.sap.com/sizing

      http://service.sap.com/sizing

       

      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      Hi Jochen

      Thanks for this. Just noting that the direct link to the Sizing Guide doesn't work... best to just leave the menu to it perhaps

      Rgds,

      Jocelyn

      Author's profile photo Jochen Saterdag
      Jochen Saterdag
      Blog Post Author

      Thank you Jocelyn, I have fixed this?

      Author's profile photo Sankara Bavirisetti
      Sankara Bavirisetti

      I have upgraded my SAP NW 740 to 750 ( I got SAP_UI 750, SAP UI, SAP_GWFND etc) and when we see the Product Versions I could see any FIORI 2.0 Front-End add on  in the list , my question is " Does NW 750 ABAP stack automatically bring FIORI 2.0 part of SAP_UI or does we need to plan separately ? while I am trying to run maintenance planner to install FIORI Front end 2.0 there is no option to chose NW 750 only I have NW 740 ?  it sounds during my NW 750 upgrade all required components for FIORI 2.0 included in SAP_UI 750 component?

       

      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      Hi Sankara

      Please note that Fiori Frontend Server 2.0 does not give you Fiori 2.0  - it's still Fiori 1.0 look and feel.

      Actually Fiori 2.0 requires Fiori Frontend Server 3.0, i.e. module SAP_UI 7.51

      You need to be on at least NetWeaver 7.40 and at the relevant support pack level to add module SAP_UI 7.51

      You can find more information here...

      If you have further questions please do NOT add it as a comment to this blog. Instead raise it as a separate question tagged with SAP Fiori.

      Rgds,

      Jocelyn