Skip to Content
Technical Articles
Author's profile photo Anton Mavrin

Some useful techniques to troubleshoot Web Assistant configuration

Ok, let’s add some quite advanced technical stuff into the blog post stream 🙂

So far, there are 2 main approaches for Web Assistant implementation for S/4HANA product family:

  1. Using Web Dispatcher and Fiori Catalogs (explained in the SAP Enable Now Web Assistant Integration Guide and SAP Fiori Overview)
  2. With or without Web Dispatcher (since S/4HANA 2020) and without Fiori Catalog, replacing the last one with the plugin in the Fiori Launchpad configuration. (Installation Guide for SAP S/4HANA 2021)

Undisputable benefits for using dedicated Fiori Catalog(s) for the Web Assistant settings is that one can manage i.e. who can view standard context help provided by SAP, and who needs hypercare and “premium” content developed with SAP Enable Now and requiring the dedicated license.

With Web Assistant settings maintained in the Fiori Launchpad Configuration, they are applied for every FLP user, no matter whether custom SAP Enable Now content is required or not.

So, let’s move closer to issues I’ve been witnessing for the last 2 years working on various SAP Enable Now projects globally.

Myth 1: When assigning 2 Fiori catalogs with different Web Assistant settings to the same user, settings from the “specific” catalog will override the “basic” settings.

No, this won’t happen. In this case “random” catalog out of 2 assigned will be applied. Example: you have editor=false in the Catalog 1, and assigned Catalog 2 where the editor parameter is set to true. This won’t work.

Myth 2: When having Web Assistant setup done in the FLP Configuration, assigning Fiori Catalogs will override the default settings.

No, FLP configuration highly likely will prevail, so catalogs will be useless. What you can try to do is to implement only basic parameters in the Fiori Launchpad configuration and put remaining ones that actually specify the Web Assistant behavior in the FLP Catalog. Theoretically, this should work, however, I couldn’t yet test this approach with any customer.


If Web Assistant behavior is different from what you expected and configured, you can check what settings are really applied without having access to FLP configuration or Catalogs.

Just open the browser developer tools (Ctrl+Shift+i or F12), navigate to the Console tab, type the command Help4.getShell()._params and press Enter. You will see the response in the console in a form of an object. Expand the object information. Voila! All real Web Assistant settings applied are in front of you.


Developer console magic

So, you found that parameters’ values in the console are different from what you asked to put or put by yourself while configuring the Web Assistant. Let’s find out!

First, using the transaction /UI2/FLPCM_CUST I would check whether we have any conflicting Fiori Catalogs with Web Assistant settings. This also helps when nobody remembers what Fiori catalog had been created for the Web Assistant or when it wasn’t created at all, but setting were added to the “random” existing catalog that, of course no one has idea about. In the /UI2/FLPCM_CUST select the search option that uses target mappings and look for

Result A:  Only 1 Fiori Catalog was found.

Open it in the Fiori Launchpad Designer (/UI2/FLPD_CUST – Client Specific or /UI2/FLPD_CONF – Cross-Client) and compare setting there with what you could find in the browser developer console. If you don’t see a match, most likely the conflict is with settings made in the Fiori Launchpad Configuration.

Result B: More than 1 Fiori Catalog was found.

Open them in the Fiori Launchpad Designer (/UI2/FLPD_CUST – Client Specific or /UI2/FLPD_CONF – Cross-Client) and compare setting there with what you could find in the browser developer console. Then in the PFCG transaction find out what roles grant access to these catalogs. Check whether you have both roles assigned, because the conflict could be because of that. If with single Fiori Catalog assigned to you, actual Web Assistant settings you observe in the browser developer console are still different, then we have a conflict with settings in the Fiori Launchpad Configuration.

So, time to check whether Web Assistant plugin exists in the Fiori Launchpad Configuration and ruins our life. To get there use transactions: /UI2/FLP_CUS_CONF – Client Specific or /UI2/FLP_SYS_CONF – Cross-Client. Sometimes, I saw Web Assistant plugin configuration done for all clients, other customers had it client-specific. This is the last place where conflicting configuration could hide from us. Once you find it, make decision whether you are going to use “flexible” approach with Catalogs or Web Assistant “carpet bombing” with FLP configuration parameters only.

As I mentioned above, you can try “cocktail mixed approach” by leaving only basic parameters in the FLP configuration and adding the remaining ones (i.e. ServiceLayerVersion, dataUrlSEN2 etc.) in the Fiori Catalog(s). Disclaimer: I haven’t tested it yet, could work theoretically. If you were able to do it in your system, please do not hesitate to let me know, so we could spread this awesome news among other customers 😉

P.S. Also using the /UI2/FLP_CUS_CONF or /UI2/FLP_SYS_CONF transactions you can add very useful parameters in the FLP configuration: NAVIGATION_GUI_INPLACE and NAVIGATION_WDA_INPLACE with assigned value of true, so that GUI for HTML and Webdynpro applications will be opened in the same browser tab. This is required for Web Assistant and also fixes ugly UX when user has millions of browser tabs opened when working with such apps.

Warmest Regards, Anton

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Marna Parodi
      Marna Parodi

      hi Anton,

      great post with really useful hints!

      Our settings are maintained primarily via FLP Configuration. Primarily meaning that this is the place where all of the settings are maintained, included optional ones, such as "enableClassiIntent". I confirm that FLP config settings seem to override Fiori Catalogue. Generally speaking, I admit I don't like very much the idea of a maintenance that is not unique. Anyhow, I always try to avoid conflicts (= I enter same values in both places).

      On the other hand, I have a conflict that I could not yet solve. The value I've entered in parameter "version" in both FLP configuration and the catalogue is not applied in S/4. I have found this out using the "show context" information command in Web Assistant and now, thanks to your how-to, I could also verify with Help4.getShell()._params. Unfortunately, parameter "version" returns 2020;000, whereas I would expect it to be 2021.000 as per my (double) configuration (system Product Version is ABAP PLATFORM 2021).

      Can you think of anything I should further investigate?

      thank you,



      Author's profile photo Anton Mavrin
      Anton Mavrin
      Blog Post Author

      Hi Marna,

      I would start with FLP_CUS_CONF and FLP_SYS_CONF, as well as searching again for target mappings presence in the FLP catalogs. In the S/4HANA Implementation Guide a transaction HELP_CONFIG is mentioned. It's responsible for Web Assistant conffiguration, and adds all required parameters in the FLP. Check what's there as well.


      Author's profile photo Marna Parodi
      Marna Parodi

      hi Anton,

      thanks again. Please find below my results (unsuccessful, I'm afraid).

      FLP_CUS_CONF - this is indeed where I maintain parameters for WEB_ASSISTANT_HELP_PLUGIN and my "version" = 2021.000.

      FLP_SYS_CONF - I had never used it before and the web assistant plugin entry is missing. I suppose the reason is that it was decided not to maintain cross-client.

      target mapping presence in FLP catalogs - I didn't mention in my previous reply, but I had searched for it. Target mapping is in 2 catalogs. One is the help catalog, where the target mapping was originally created (Original, TM only). In the other catalog, the target mapping exists only as a reference (Reference, TM only). I have the required role granting access to the catalog containing the referenced target mapping.

      HELP_CONFIG - I didn't know that either, thank you for pointing to that. I did not run the report, but I've compared the settings to my settings in FLP_CUS_CONF. There are basically two differences:

      1. Learning App Back-End URL and Learning App Workspace in our settings are configured for an Extended Workarea scenario. But I don't think this should create any problem with the version.
      2. Version is defaulted literally as "2021.latest". I've read note 2954479 that recommends to display a dynamic documentation. So I've changed "version" from <2021.000> to <2021.latest> but the issue remains, because both "Requested" and "Available" version is 2020.000 (see attached image).



      Best regards,



      Author's profile photo Anton Mavrin
      Anton Mavrin
      Blog Post Author

      Hi Marna Parodi,

      HOORAY!!!! We fixed it together with you this morning!!!

      Issue summary (for those, who are still interested ;))

      For unknown reasons Web Dispatcher was forwarding user to the FLP Client 200, even when user put another client number in the FLP authentication dialog window, or maybe the Web Dispatcher port number we were provided was specific to the client 200.

      We were able to find out what client FLP is using by following the SAP Note 2418379.


      Real SAP client number could be found in FLP cookies.

      Correct Web Assistant configuration was maintanined in the Client 100, but not in 200. Incorrect product version "2020.latest" was coming exactly from Client 200.

      Fix (temporary)

      We added additional parameters in the Web Assistant plugin in FLP Configuration to bypass the Web Dispatcher and were able to enjoy correct Web Assistant config when opening FLP directly, without the Web Dispatcher.

      Fix (permanent)

      1. Find out why Web Dispatcher always forwards to Client 200. (or find the correct port for each client)

      2. Make decision about using Web Dispatcher for Web Assistant or not, because this is supported since S/4HANA 2020

      3.  Make sure that correct Web Assistant configuration is applied to all systems/clients.

      Author's profile photo Marna Parodi
      Marna Parodi

      hi Anton,

      thank you one more time for helping me determine the cause of the problem. I'm happy because I've understood how it can be fixed and I became aware - even more than before - of the delicate role of Web Dispatcher in a Web Assistant implementation. It's been a very constructive way of ending the working week 🙂  Best regards - Marna