Implementing SAP Fiori in a Productive Environment.

Introduction

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.

Architecture

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.

“Paystubbs”

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