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:
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.
Troubleshooting
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.
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 sap.dfa.help.utils.adapters.fiori
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
So far, there are 2 main approaches for Web Assistant implementation for S/4HANA product family:
- Using Web Dispatcher and Fiori Catalogs (explained in the SAP Enable Now Web Assistant Integration Guide and SAP Fiori Overview)
- 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.
Troubleshooting
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 sap.dfa.help.utils.adapters.fiori
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 "
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
- SAP Managed Tags:
5 Comments
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
