Understanding the concept and having theoretical knowledge of any technology is one thing and working hands on and solving real time issues is another story. You cannot assume to be a Formula 1 champion just because you are good at the racing games. Similarly, troubleshooting technical issues while configuring Fiori Apps can be little tricky and is often time-consuming if you have not worked hands on in real projects.
I will try to help application developers (ABAP-ers and Frontend-ers) to understand and utilise some troubleshooting tools and the steps to expedite their analysis while working on complex real project Fiori Applications.
We will check the most commonly encountered error while configuring any Fiori App.
Error – ‘Could not start the app due to a configuration problem’
SAP Fiori App users often encounter the error “Could not start the app due to a configuration problem” while accessing standard or custom Fiori apps.
Business Scenario
Refer to the below scenario where you invoke Create Material Master App in Fiori launchpad. You can access the Fiori launchpad using transaction “/n/UI2/FLP”.
If you do not know how to expose SAPGUI Standard/Custom t-code to Fiori App.
Click on the configured Tile of the App and unfortunately it might lead to following error.
For newbies, troubleshooting such issues can be tricky, frustrating and time consuming as SAP Fiori development includes various infrastructure components such as Back-end, Front-end (Gateway), Web dispatched, UI application, etc. On top of this, issues can be in any of these components.
So, the big question is, from where do we start troubleshooting Fiori issues?
1. Often as a first step, developers can leverage the Famous Function Key F12 (or right click and select INSPECT in the browser where Fiori App is running) to invoke front end debugging and identify if issues exist in the front-end or back-end components. In our example, no errors are reported in the console.
2. The next step is to validate if any error exists in SAP Gateway. It can be your front-end or back-end system, depending on your gateway deployment strategy (Hub or Embedded).
Leverage transaction “/IWFND/ERROR_LOG” to validate if any error log is reported in Gateway Services.
Fortunately, in this case, we do not see any errors reported.
3. The next step is to use transaction “/UI2/FLIA” to check the assignment of a given INTENT (semantic object – action pair) to a USER in the context of SAP Fiori launchpad.
This report provides an overview of all intents for a user. It allows you to check to which authorisation role the intent is assigned and if a given user is assigned to this role.
- You can filter the results from the report by device (such as desktop, mobile, etc)
- The default layer is the personalisation layer.
- The check is system-dependent. Start the report in the system for which you want to verify the content.
Verify if “Configuration error” exists for semantic “ZMat” and Action “Create”. In this case no errors were reported.
Next, verify if “Customisation error” exists for semantic “ZMat” and Action “Create”. In this case customisation error is reported as shown below.
Select the error and click on display to further analyse the error message.
Detailed Error Message: “Launchpad ZMM / transaction / ZMM01 does not exist in client 800”.
As part of the complete root cause analysis step, verify if “Personalisation error” exists for semantic “ZMat” and Action “Create”. In this case personalisation error is reported as shown below, however this is similar to one reported in the prior evaluation step.
4. Additionally, developers can also check Fiori Launchpad content using transaction “/UI2/FLP_CONTCHECK”.
Here developers can filter Apps by packages. Let us check it in detail.
No error reported under Configuration for Custom App ZMM.
Validate the same for Customisation. Error reported as shown below for the Catalog ZMM which is used for our custom App.
Select the error and click on Display, to see the detailed error message.
In this case, it is the same error that was encountered in Step 3.
Now, more-or-less, we know the issue. It’s time to resolve it and become the hero of the hour!
Let’s understand what Launchpad Role “ZMM” and Launchpad Instance “transaction” alias “ZMM01” point to. It’s the same Launchpad role and Instance you configure in transaction “LPD_CUST“
We can see in LPD_CUST that both Role and Instance are maintained. If the Role and Instance are configured, then what’s wrong?
Note that launchpad role and instance are defined in Target Mapping, which can be invoked using transaction /n/UI2/FLPD_CUST ( Fiori launchpad designer ).
Select the Target Mapping and click on “Configure”.
We can see that Role and Instance is Maintained in Target Mapping.
THEN WHAT IS THE ISSUE?
Where are we going wrong with the configuration?
If you compare semantic mapping and launchpad configuration closely, you will notice that the Instance is maintained in Target Mapping in Lower case (check the above screenshot). We need to maintain it in the same case exactly as per the LPD_CUST setting.
Let’s change it to Upper case.
Save and reload the App. Bingo! It worked!
When you get the error, you might feel that it is a monster. But when you know the root cause you might feel it is much ado about nothing. This is true for most of the common issues. The issue always seem pretty simple once we know the solution.
As we always say, programming and coding the fix is easy. Finding the reason and root cause takes most of the effort and time.
