Skip to Content

Implementing SAP Fiori in a Productive Environment.


Over the past six months at Sheffield University we have been working on a project to install, set-up and configure SAP Fiori Apps.

The aim of this blog is to describe the process, the architecture of our deployment and the “Apps” we have set-up and installed.

Some of you will have seen me demoing an early proof of concept of the apps at Sap Inside Track Sheffield over the summer.

SAP Landscape Background.

I suspect we are a fairly typical customer. We have Full financials, SD,MM, PS, etc all running along with full HCM, SRM and SAP E-Recruitment, with ESS and MSS via SAP Enterprise portal. Our E-Recruitment system is EHP6, financials are EHP5, SRM is SRM EHP1 or NW7.02 and our Portal is 7.02

We have 6,500 ish SAP user licenses as every member of Staff has access to SAP Enterprise portal to view their Payslip, Book Leave etc. With managers being able to use SAP MSS HR Functionality etc. etc.

Scoping SAP Mobile

Due to our wide ranging infrastructure SAP Fiori wave one applications touch about 90% of our user pain points, such as approvals in SAP Portal and requesting leave.

In the initial scoping of the project, it was decided to implement three initial applications for a “Pilot” before a full scale launch.

The Initial applications selected were Approve Leave, Request Leave and Paystubbs.

The scale of the “Pilot” is about 1000 Users with a full roll out to 6500 people depending upon its success.

As one of our assistant Director of Finance said when we talk about a “Pilot” to approx 1000 end users that number is larger than 90% of Businesses in Sheffield…. But i digress.


When deploying Fiori there are two potential routes to go down, embedded vs a Hub option. For those that saw my demo at SitShef, this was based on a embedded architecture as a “Proof of concept system”

This proof of concept system was a standalone copy of our development system which we upgraded to NW 7.40 and installed gateway and the FIori apps on, to get a feel for the technology and most importantly to see if they would actually work with our environment, such as Approve Leave reading our MSS Configuration, Request Leave reading our ESS information and Pay Stubbs app, correctly reading information from SAP Payroll.

Because we could “prove” the apps could work within our environment, a decision was made to kick off the project formally, as Mobile and Simplicity fit neatly into our departmental strategy.

Productive Architecture

We run a standard three tier SAP landscape with Dev-QA-Production instances of Suite, PI, EP,SRM.

After reading a “LOT” of available guides and information, we made the decision to build three gateway front end ABAP 7.40 servers.

This brings its own benefits, problems and solutions.

SAP Gateway is installed and configured on these servers, and they are a natural home for the UI Components of the Fiori applications, which means patching should be easier as the UI5 apps are decoupled from the ERP suite.

So… for our dev system, we now have a brand new shiny ABAP 7.40 Application server acting as a gateway hub taking to our development ERP system, which is replicated in QA and production.

The next trick is setting up trusted communications between the ABAP server and the back end ERP system, setting up users in the ABAP system and making sure these match to the ERP system. And getting the authorisations correct as well.

The trick with the Gateway and Fiori apps architecture is that the user profiles on the gateway system should match the user profiles on the back-end ERP system.  For example if your a employee on ESS you shouldn’t have access to the MSS apps in Fiori.

These are all quite easily configurable in Fiori via the custom “Groups” and “Catalogues” section in Fiori apps

These allow you to restrict what apps users can see, what tiles they have access to on the launchpad etc. Its really nice and tidies everything up for the end user,

Due to our Gateway architecture, this allows us to expose  Fiori URLs via our loadbalancer to the internet, which means our apps are available via mobiles etc without a VPN connection whilst protecting core ERP.

Our Fiori Configuration

When a user first accesses our URL either via the fiori client or Logon this is the 1st page they see.


This is a Shibboleth IDP system that has been hooked into SAP via SAML and  LDAP.

The LDAP function reads users in, and authentication is an “alternative” logon on procedure in SICF with user authentication turned off as its handled by our IDP

The next Screen our users are going to see is a VERY simple three tile screen with our initial apps.


“Leave Request”

“Approve Leave Request”

Our ESS and MSS functionality is branded as myJob and MyTeam

So to replicate this in Fiori we have created custom groups and catalogues called MyJob and MyTeam to tie everything up nicely.

“Paystubbs and “Leave Request” will be part of MyJob and “Approve Leave” being part of MyTeam.

We have decided to go with SAP standard at the moment for simplicity and branding is a bit buggy……..


Clicking on the Tiles obviously brings up the respective applications such as approve Leave


End user reaction

This has been pretty much 100% positive so far from demos with the pressure on to get these apps rolled out ASAP… which has thrown up some quirks in testing.

One example of this is the leave request calender has a UI bug that greyed out Friday and Saturday instead of Saturday and Sunday as non working days.

As the apps are so new there a LOT of SNOTES and UI fixes available, however if you get your architecture right and build an separate gateway landscape,this shouldn’t be an issue, its just time consuming. We have had some requests from our payroll office to remove $ signs from the icons etc. which isn’t a big problem !

Moving Forward

Post go live and depending on how it progresses we have plans to implement further Fiori applications, such as “Approve shopping carts”, “Expenses Approvals”, and generic approvals for systems such as E-Recruitment.

If anyone has any questions etc feel free to comment.

There is a LOT more that i could write, our go live is scheduled for the 15th of December and we are currently QA testing within out IT department, which are always the hardest people to impress, again feed back has been very positive to the Fiori applications.

The apps work, there not that difficult to implement and anyone who is a SAP HCM customer or has any sort of workflow process should seriously start investigating them. IMHO.

Post Script.

The implementation team has consisted of primarily my colleague Andrew Turner, who manfully decided to setup the SAML connections to our IDP , the https connections and the LDAP config, my self and George Credland.

With help from our normal Business teams in testing the applications/

The work so far has all been carried out internally

Post Script -2 Fully live

Dear All

For those interested our Fiori deployment has been launched university wide this week, and the apps are available to 7K end users, after bedding in our trial launch over the last few months as a live pilot.

We have extended the number of apps available from the initial three in the trial, to four applications at launch with two more in the pipeline.

We now have the following SAP standard Fiori apps developed or are due to be launched !

1) Payslips – Available to all staff

2) Request Leave – Available to all staff

3) Approve Leave – Available to line managers with the relevant role.

3) Team Calendar – Due to be launched to all Staff

4) Approve Expenses – Available to line managers with the relevant role, this includes the PDF Trip form functionality though Adobe Document Services.

5) Approve Shopping carts – Our first non HCM app is now available to budget holders and those with the relevant SRM Approve Cart role

6) Approve Job Requisitions – Custom E-Recruitment application, This is going to be based on the SAP generic My-Inbox Application and will allow Jobs to be approved on our website.

potential further applications include MySpend and others.

You must be Logged on to comment or reply to a post.
  • Hi James,

    always interesting to read about experiences in the wild.

    How often are you planning to patch the UI5 libraries?

    Will you test all applications after every update of the libraries?

    • Hi Mark, The plans to test the UI5 / Front systems will be based on feedback i think.

      If there are any major issues brought up such as the UI calender bug, then we will patch.

      Honestly we don't really have a strategy yet......

      The strategy will come post deployment.

  • Hi James,

    Excellent write-up of what seams a perfect Fiori implementation!

    I recognize the fact that there are a lot of notes released for the individual apps. I heard the advice from SAP is to scan the marketplace for new notes on a daily basis. For 3 apps this shouldn't be a big problem, but if you implement more apps than this can turn into a daytime job. It would be good if you could subscribe to notes-updates of a certain fiori app so SAP could push notifications of these fixes to you instead of you having to scan for them yourself.

    Please keep us posted on new experiences. This is valuable stuff!

    Cheers, Roel

    • Roel van den Berge wrote:

      It would be good if you could subscribe to notes-updates of a certain fiori app so SAP could push notifications of these fixes to you instead of you having to scan for them yourself.

      I suggest SAP implements something along the lines of Security Notes in Solution Manager instead. Same with SAPUI5, it is very hard to keep up with all the SAP notes.

    • James has done a great job for us, taking the initiative and seeing it through to what looks like a viable implementation in a few months alongside keeping our existing services up and running. We certainly wouldn't have come so far without that enthusiasm.

      We've seen a fair number of bugs but that's to be expected with technology that's so new. None of them are blocking issues and we're proactively looking at patches and Notes.

      It's pretty clear we'll need to patch more frequently than the core systems, but having the applications on a separate gateway hub limits the impact of patching.

      Since the applications are so new and frequently being updated we're aiming to run as standard as possible. We'll aim to push out the first three apps, then get user feedback on their experience and gauge interest for further scenarios.

      We had hoped to hook in Google Analytics to capture usage data, device/platform information etc., but it looks like that would need a custom version of each application. Ideally this would be an option to hook into the framework as standard as its only a small piece of javascript to embed into the page to get it working. Its a free service and would tighten the business case for further investment, so its going to be a balance between maintenance and enhanced feedback.

  • Thanks for sharing James. It is good learning for me, hope I will come across the Fiori Implementation soon. Please keep posted, post implementation experiences.

    Warm Regards


  • Thanks James - this is really valuable insight into a Fiori implementation! Good to see the positive feedback of Fiori coming from a customer rather than from SAP or a partner...

    George that's a great suggestion for SAP to include the option for Google Analytics!

    Please do update us post-go-live - we wait in anticipation 🙂

  • Hi James,

    Great write up, we are starting to look at Fiori and the SAP Gateway at a client I am working at presently. 

    We have installed the Gateway in a Hub Deployment as you are doing in your POC system above but they have set up a configuration client and a closed client (similar to our development environment 100/120).  This I think has confused the installation massively.

    Is this something that you have done in your configuration landscape for Gateway.  We have only 1 Gateway system set up a the moment (for development of POC) and we wish to develop in our development client ( i.e. 100 to take advantage of the DDIC etc).

    Do you think this second client is necessary as we're having issues when trying to Register our own test services in this format.

    Thanks for the blog, I am definitely interested in hearing how you get on.



    • Hi Ashley,

      For gateway development it needs to point to one client on the ECC system, and you need to replicate the gateway setup across your dev, qa and prod systems other wise it well get REALLY confusing.

      So Lets say you have one shiny new standalone gateway server, and one standard dev - QA-Production landscape.

      Your 1st install of gateway should map across to your dev system only..... you will need three gateway servers to match a dev-qa-prod ECC landscape.......

      For example if you have a 200 Dev client that has users & data, you only need ONE gateway client that points to this 200 ECC client. If there is no data the apps won't have any information to display.

      One client in your gateway system is all thats necessary, and all that we have built.

      • Thanks for that James. 

        Our Basis guy has finished for Christmas now so will get onto him in the new year.

        Good luck with it all and have a great Christmas yourself.


      • Hello James,

        First of all - great job and explanation. When reading it I felt again all the "pain" we already passed during implementation.

        Since some months we are also running a Fiori system. Currently we have only one FES/Gateway which is connected to the test CRM and ERP systems. Our intention is to use the same system and connect it to the productive CRM and ERP as well.

        Actually I am not sure whether and how this could be done. The idea is in the transaction "Activate and maintain services" - /IWFND/MAINT_SERVICE to add a second alias to the Apps service - one to the prod and one to the test environment.

        Do you think this could be done and work properly?

        Please share your opinion.

        Best regards,


        • If you want my honest opinion.... Build a productive FES and gateway system.

          You could do what you describe but then..... users and roles become an issue and linking the FES system to prod I'm assuming that sort of thing ?

          Then groups and roles configurations..... etc etc.

          • Hi Jeremy Apologies for not responding earlier.

            We would have no issues running a cloud based productive server.....

            If we had one to play with and we could hack away at it like a normal ABAP system, for user authentication and roles etc.

          • Hi James,

            Glad to see that you have progressed a lot with Fiori implementations. I noticed you also have ERecruitment in your landscape, have you done any Fiori apps on that?

            Jeremy, I have been playing around with WebIDE in the HCP and it is pretty easy to develop and run the Fiori apps in the cloud. What is even more interesting that you can also transfer the Fiori app developed in the cloud to your on-premise GW and vice versa. The prerequisite is that you have the HANA Cloud Connector installed to provide the connection between the On-Premise GW and your HCP account.

            Best regards,


          • Hi Pekka,

            We're looking at using the My Inbox application to handle eRecruitment approval requests. They're high value and require multiple approvers so this is a priority from the HR side.

            We've no plans for bespoke candidate Fiori content given that eRecruitment isn't the SAP "take forward solution" for recruitment. We need to start looking at SuccessFactors, where they have mobile search and register functionality, plus are working on the application side.


  • James,

    Thanks for sharing. I would go your route as well and implement F apps on 7.40. You do not mention SMP? Also, your SAP Gateway is within SAP NW 7.40, and not separate from NW 7.40?



    • Hi James ? SMP as in SAP Mobile platform ? Not needed at all for the Fiori Apps.

      We don't have it.

      Gateway is within out NW7.40 ABAP server. It come installed as part the core installation.

      By leaving gateway separate, you can then expose the Fiori apps links.

      • James,

        Yes, SAP Mobile Platform. I thought this was required for iPad, iPhone, etc.?

        I do understand that on 7.31 SAP Gateway is separate, and on NW 7.4 it is included as the with NW 7.4 install.



        • Hi,

          Fiori apps are web applications not native applications so you do not need SMP.

          Maybe you thought of SAP Fiori client which is, for the moment only handling cache management for optimization purposes.

          In future releases, SMP can be added into the landscape to support offline OData for Fiori apps.

          Maybe these blogs can be of some help:

          SAP Fiori & SMP

          Update on Fiori & Mobile

          Best regards,


          • I wish the Fiori iOS app worked a little better. The idea is real nice, but it's not iPhone 6 optimized when I last checked, and doesn't work as well as Safari for authentication.

            As much as I like the idea, it's much better just to add the Fiori app as an icon with a link to Safari. Which is frustrating because Safari doesn't do a good job of caching, and Fiori is still quite large.

  • Hi James,

    This is really a great motivation blog for SAP Fiori implementation. We are in the beginning stage of implementing it. There is long way to go and we hope it will start working like you.



  • Hi James,

    a really nice blog. I was really shocked by the first sentence "Over past 6 months ...". Could you comment why it took it so long? I understand that you had to deploy a new system to your landscape but still it looks so long. What would help to speed up this process? A better documentation from SAP?


    • Hi Marin.

      As described in the Article we built four brand new systems.

      One Sandpit one to test the technology, then three gateway ones for our Dev / QA / Prod landscape. We had to test the applications, do all the user config etc, whilst figuring out UI5 and Fiori. It is Brand new you know !

      Take an avage time of about a month to build configure and setup a sap system... Six months easy ! (Never mind actual testing)

      Unfortunately things do take time.

  • Great work done. I liked the idea of My job and My team architecture, its simple and effective, which most users will love to see it. Thanks for sharing this wonderful info.

  • Dear James; great blog and thank you very much for sharing this with the community; very helpful!

    We got a kind request and/or suggestion: would you want to share this same story on the (Higher) Education & Research user group meeting (HERUG) upcoming April in Cambrigde?

    Check out the web page on this SAP user group meeting and let me know if you are able to attend:

    You can directly contact me via [Removed by Moderator, see Rob's profile for contact information]

    Thanks in advance.

    Rob Jonkers

    SAP Solution Management (Higher) Education & Research.

  • Hi James, great blog with lot of key learning. I had a question regarding how did you expose business suite services in oData format ? Was it done through oData integration Add-On on business suite ?

  • Hi James,

    This is very interesting Friori implementation. I would like to ask two things regarding this implementation.

    1. Regarding license. As this project is migrating ESS/MSS Portal to Friori. Do you need additional license for it or the current ESS/MSS Portal license should be sufficient?

    I know Friori itself is free but how about the user license in the backend. Currently ESS/MSS users have been covered by SAP Platfom/Application ESS or MSS User category.

    2. Regarding your H/W solution, your solution is 3 gateway servers.

    Are these three servers, each of them M5000 with 32GB? How many CPU you have install? How many number of users covered by these three servers. The total 6500 users or only 1000 users (pilot). is this sizing based on SAP Quick Sizing result?

    Thanks a lot in advance and very sorry for too many questions.



  • Hi James,

    Thanks for the completed great article,

    Could you describe a bit more on SAML integration and LDAP integration, we have similar architecture - For POC its embedded Gateway/Fiori system and Gateway separately installed for rest of the systems, We are in process of implementing QA currently

    We configured LDAP connectors etc with our LDAP directory servers and trying to figure out how to integrate SAML with IDP, Would appreciate if you could elaborate a bit on that



  • nice Blog!

    A question about: "After reading a “LOT” of available guides and information, we made the decision to build three gateway front end ABAP 7.40 servers."

    Which aspects did influence your decision from building three instead of one frontend server ?