Fiorifying your ERP System – Ingredients of a successful Fiori Implementation – Part 2

[former_member184598]

In part 1 of this blog series (you can read it here - http://scn.sap.com/community/mobile/blog/2015/02/05/fiorifying-your-erp-system-ingredients-of-a-succ...), I have tried to outline what all things you need to think about when planning your Fiori implementation. In this blog we will discuss the actual implementation itself. Scenario we are using as a topic of discussion here is Leave Management with some extensions.

Get, Set, Go! Starting the Implementation

Once you have a plan in place, you are ready to work on the pre-requisites for your implementation.

Step 1: Test core functions well in ERP!!

This is probably the most ignored step but the biggest time saver. Fiori uses same good old ERP core functionalities. So you need to make sure that you can perform these core functions in your backend sandbox/development system.

For Example, in Leave Management scenario, you may ask yourself following questions:

Are you able to create a leave from transaction PTARQ? Does it trigger the right workflow?

Are basic workflow configs in place for Leave Approval workflow? (Workflow customizing configs, Event Linkages, workflow definitions are active, human tasks are made as General Tasks, Org Structure and Agent Assignment as per Org Structure etc.)

Have you activated ESS Business Function? (Surprise! Yes you need it!)

Have you made your leave quotas available for use in ESS (Along with basic quota configuration)?

Are Team Calendar configs available in MSS for Leave Approval Apps?

And so on…

Take another example.

If you are interested in purchasing related apps (Like Order from Requisitions, Track Purchase Order or Approve Purchase Order), in the backend system, you should be able to create POs, Create PRs, have a release strategy setup, tested standard workflows and so on.

If you don’t know this bit, your partner or architect/functional consultant should be able to help you explaining which app uses what in the backend.

If your backend is not in place, you are destined to face horrible problems when you put Fiori in.

Step 2: Set up systems and perform the installation and initial configs

Once you have done your landscaping its time for basis team to step in and start the install.

Then, once right components are in and services have been activated, your architect can help basis team perform Gateway configuration (different Types of RFC Destinations, System Alias for various services and Task Gateway etc.) and do a connectivity check between systems.

Now you are ready to put the Fiori Components in. For each app, there is a relevant UI Component and a corresponding OData/Backend components. In case of Central Hub generally, UI components go on Gateway Hub and OData components go on your backend.

For Example: In case of Leave Creation App, UI Component is UIX01HCM 100 and Backend component is GBHCM002 600. 

UI Components can also be common across many apps. Once components are in place you need to activate and register the services on Gateway.

For a basis consultant reading this blog, you have to be careful as to which activities here are transportable and which ones are manual. It will help you prepare the right cutover plan before go-live. Also, apart from this you should have a close eye on what notes are available for the apps in your scenario. Keep an eye on what patches/notes are coming up in this area.

In short, this is a work of close coordination between your architect and your basis team. Having seen a few setups now, I can safely say that its very hard to do these things in isolation.

Step 3: Perform App specific configurations if needed

For Approval Apps, you will need a specific configuration telling Fiori what workflow tasks to use for which app. These configs are explained in the configuration section for approval apps in sap help.

The documentation also talks about relevant details about the Launchpad configuration for each app (Semantic Objects, Role for LPD_CUST etc.).  Personally, I prefer to do this as a separate activity later along with Launchpad Designer configurations.

Tip: If you get an unending spinning wheel when you open an approval app, you have missed this scenario configuration or you have done it wrong.

Step 4: Test the standard App via SICF transaction on your Gateway system

Now you can test your app via sicf transaction or may be wait for next step and configure Launchpad before testing. Full SICF service paths are available in the Fiori documentation.

Step 5: Launchpad config for your Apps

In order to enable tiles for your apps on Fiori Launchpad, you need to perform Launchpad Configurations.

For custom apps, majorly there are 4 steps involved for this set of configs.

    a) Creating/Enabling Roles in LPD_CUST transaction in your backend system

    b) Create Semantic Objects in a defined IMG for each app

    c) Launchpad Designer Configuration (Creating catalogues, adding them to group, creating tiles)

    d) Creating/Enabling Roles with appropriate Catalog for each app

Tip: Some of these configs have to be added manually to a Transport!

There are some good blogs/How-to guides on SCN for this. Below are a couple of links explaining how to add custom app to Launchpad.

http://scn.sap.com/docs/DOC-56166

http://scn.sap.com/docs/DOC-55106

For standard apps, you only need to to step d) above with right Catalogs and Groups.

This is a fairly quick activity even if you do not understand Launchpad Object Relationships but its recommended to understand it before you play around with Launchpad Designer.

Step 6: Perform Extensions

Once you have tested the standard app via Launchpad, you are ready to perform modifications.

This is where your UI5 and ABAP developers come into picture. The extensibility documentation of each app helps you identify all the views and associated enhancement points and dictionary objects to modify.

The approach, I personally prefer here is top-down approach. You determine what you want to see on UI, do some mock-ups and once you are happy, have a look at how can you support this new field or screen from the backend (Dictionary Enhancement->API Enhancement->OData Wrapper Enhancement).

Note: Approval Apps are always related to a workflow task. These apps pull data from the task containers.

So, even if you have a custom task, you should be fine unless you have done major changes like change the activity type from standard activity to user decision.

As for ABAP developers in particular, skills needed are Enhancement Framework, OO ABAP and Gateway development skills.

Step 7: Final Tests and Transport Planning

When you have tested the application in dev., its time now to transport the extended solution to QA where you can get multiple business users to test the apps with the help of your HCM consultant. Generally you would perform the installations and system specific Gateway/Fiori configs (like RFCs/Alias) on each landscape but things like Launchpad roles and your extensions can go via usual transports in both Gateway and Backend Systems.   

And finally, as usual, if business users are happy in QA, you can perform the cutover and request a downtime for a technical or full-fledged go-live.

To summarize, implementing and extending Fiori Apps is not difficult if done with right tools, technologies and people. Along with UX renewal these apps can provide a significant business value in a very short span of time. Happy learning and please share you feedbacks!

Next blog/blogs in the series would be for Analytical and Factsheet Apps.