Meticulous Investigation in Backend: Restricting Fiori Launchpad (ABAP) theme selection

We had Blue Crystal, Belize, now we have Quartz. What we haven’t until now, 3 Fiori revisions later, is a way to allow only a few selected themes to user choose from. Customers create their themes but are left with two options to restrict theme selection:

• Disable entirely have only a custom one set as default
• Have multiple custom themes, but they have to be displayed alongside all standard ones.

The third option, displaying only customer ones, was not possible… until now.

Post-Mortem Update: If you are on ABAP Platform 2020 FPS01+ and only need to hide SAP themes, you can use a new Launchpad parameter THEMING_HIDE_SAP_THEMES for that. Kudos to Séverin de BEAULIEU .

Disclaimer: This is a about an enhancement in INTEROP service, the backbone of all data gathered to make Fiori Launchpad work as we know it (tiles, catalogs, and a bunch of other things). Changing  that service blindly can screw really good your system Launchpad. Read carefully the instructions or ask for system backup before starting, one of them will surely help you in this journey.

Note: Those steps were initially done on 7.52 (ABAP Trial) and could be exactly replicated on an older system (7.40). Therefore this standard part is somewhat stable and the procedure should be the same or similar for other stack versions. Steps were done through SAPGUI for Java.

How did I find where to enhance?

The same way as any Fiori/UI5 application that you know nothing (Jon Snow): peek network traffic in browser developer console. All modern web applications communicate with one (or multiple) backend endpoint(s), and UI5 is no exception (OData / REST). You can find its name there.

INTEROP Service selected on Developer Console Network tab

Here we have path /sap/opu/odata/UI2/INTEROP/Themes. Reading a bit more about how developers implement OData services, you’ll find that SEGW projects commonly falls into /opu/odata/sap/ space, so this INTEROP should be a bit special and have a own handler class or, at least, one assigned. You can find it through SICF transaction.

Locating INTEROP path on SICF…

…and then locating its handler class.

To debug or not to debug?

Not to debug, be clever. And then debug (cleverly).

We have a name, we have search tools, we have the premise that all new code are implemented in classes. Do the math. Open SE84 and search for it.

After searching by class name. Naming patterns plus good descriptions simplifies our work.

We have the class: /UI2/CL_EDM_DA_INTEROP_THM_00. You can either read its source code and locate, or help yourself with layer-aware debug.

Activating layer-aware debug to stop only in that class

Enhancement point spotted! Class constructor of class /UI2/CL_EDM_DA_INTEROP_THM_00. Just one implicit enhancement there and job is done.

Theme selection after enhancement, displaying only High Contrast themes

I could happily finish here but I won’t. Let’s do this enhancement wise, a pluggable one to be quick to adapt whenever SAP decides to change standard code. Normal development would be with a new customer class wrapping company rules to restrict themes, but I did by creating a BAdI definition and calling it there, and only then implementing a customer class. Why? To share it with you!

You can download/install from git repo thalesvb/flponprem-themerestriction and all you need to do is implement a BAdI with your rules, the same way you do for standard code. Whenever SAP changes (or relocates) that code, git repo will (probably) be updated. You fetch that update for your system, and that’s it. No need to manually readapt code on your end.

This is not bulletproof, it is still possible to set any theme with URL parameters because that happens on Fiori Launchpad Javascript, before any call to backend. There is margin to disable this behavior, but that’s an excellent start for one horror story and I will not help you with it.

Now if you’ll just look right here…

[Neuralyzer sound]