Hi All,
This blog is my journey towards solving an issue and learning how the launchpad plugins are loaded from the backend to the launchpad.
->>>Note<<<- This blog won’t explain how to create the plugins in Fiori Launchpad.
For actual help and blogs on how to do it:
https://help.sap.com/viewer/a7b390faab1140c087b8926571e942b7/7.51.3/en-US/a90ed59d22bb46898a2ec7a7da...
https://blogs.sap.com/2017/10/12/create-a-welcome-popup-for-portal-fiori-launchpad-and-freestyle-sit...
https://blogs.sap.com/2017/05/24/allow-users-to-switch-language-in-the-fiori-launchpad-using-ui-plug...
Overview:
Fiori Launchpad plugins are used to extend the launchpad functionality like adding buttons and doing some task when the launchpad is opened etc.,
This usually will be done by create a custom ui5 app based launchpad plugin and deploying it to the ABAP server. Then creating the target mapping and assign the role to that catalog and the same to the user.
So recently there was a question in answers.sap.com on how to show the outage message for the Fiori Launchpad. I never tried it, so I thought to try it once as it will be a good learning for me.
Now when I did all the coding and configuration, it didn’t work!!. I couldn’t find the plugin loaded in the launchpad. So I thought let’s debug in the old fashioned way(thinking it will be a very easy task :D)
So I did f12 on the Fiori Launchpad and started looking at the Launchpad related libraries in the sources and found the below ui2/ushell folder:
So the plugins will be instantiated(see above)
/sap/bc/ui5_ui5/ui2/ushell/resources/~20180316143600~/sap/ushell/services/PluginManager-dbg.js
The above code basically creates the component for the custom plugins(as they are obviously an UI5 app) which is mentioned in the target mappings.
I found here that my plugin component is not called at all.
I checked if any service call might be there to fetch all the custom plugin details but to my surprise no call went to the backend (it makes sense as unnecessary calls will slow down the the Launchpad)
So I debugged a bit and found the code where it is reading the plugins
It is reading from the window parameter "sap-ushell-config" where the plugin details are stored.
So again I started to search where the window parameter is set and found the place, it is nothing but the main flp file where the Launchpad is loaded:
But where is that oServerSideConfig coming from? same file, little bit above, we cannot see it in the debugging as it is a dynamic parameter, so opened it in the backend code directly(below);
So the serversideconfig is set via the placeholder( ${SERVER-SIDE-CONFIG} ) which is again set from http_hanlder class.
Now I went to the HTTP handler class from FLP’s SICF node.
So at last I found the code where it is fetching the plugins.
and they are setting it at below in the response(which is the Fiori launchpad page).
But little did I know, it is fetching the plugins from SHMA(Shared memory access) and so no actually reading the db and trying to fetch the plugins based on a condition, the plugins are already set to SHMA instance before in some other code.
I guess, this is to increase the performance of the Fiori Launchpad so no addition logic will be performed to fetch the plugins or other information when we launch the FLP.
Here the table mt_plugin doesn’t have my plugin but it has other plugins.
Again, now I debugged where the shared memory is set. But still I don't know which service or backgroundjob or program will save the plugins to SHMA
So I assumed that it might be set from the Launchpad catalog configuration service when we save the target mapping. Luckily yes and the breakpoint got triggered.
I found the issue now.. Instead of ‘Shell’ I’ve mentioned in the target mappings Semantic object as ‘shell’. Even I didn't get any error while saving(no idea why). A silly mistake 😄
So after all this debugging, the issue is a very simple one and from this I understood how the plugins are loaded in Launchpad.
1. First they will be set to SHMA on the save of the target mappings to increase the performance of FLP loading
2. The plugins information along with someother launchpad stuff is converted to string and set to launchpad.
3. These data will be read by the plugin manager.js and the plugins components will be asynchronously loaded.
This is a kind of reverse engineering but if you go from the bottom to top, you get an idea of the process of loading plugins to the launchpad.
The architecture and coding is an awesome piece of art written by SAP team and It’s a very good learning for me 🙂
Thanks to all who took their time to read this till the end 😄
Best Regards
Mahesh
This blog is my journey towards solving an issue and learning how the launchpad plugins are loaded from the backend to the launchpad.
->>>Note<<<- This blog won’t explain how to create the plugins in Fiori Launchpad.
For actual help and blogs on how to do it:
https://help.sap.com/viewer/a7b390faab1140c087b8926571e942b7/7.51.3/en-US/a90ed59d22bb46898a2ec7a7da...
https://blogs.sap.com/2017/10/12/create-a-welcome-popup-for-portal-fiori-launchpad-and-freestyle-sit...
https://blogs.sap.com/2017/05/24/allow-users-to-switch-language-in-the-fiori-launchpad-using-ui-plug...
Overview:
Fiori Launchpad plugins are used to extend the launchpad functionality like adding buttons and doing some task when the launchpad is opened etc.,
This usually will be done by create a custom ui5 app based launchpad plugin and deploying it to the ABAP server. Then creating the target mapping and assign the role to that catalog and the same to the user.
So recently there was a question in answers.sap.com on how to show the outage message for the Fiori Launchpad. I never tried it, so I thought to try it once as it will be a good learning for me.
Now when I did all the coding and configuration, it didn’t work!!. I couldn’t find the plugin loaded in the launchpad. So I thought let’s debug in the old fashioned way(thinking it will be a very easy task :D)
So I did f12 on the Fiori Launchpad and started looking at the Launchpad related libraries in the sources and found the below ui2/ushell folder:
So the plugins will be instantiated(see above)
/sap/bc/ui5_ui5/ui2/ushell/resources/~20180316143600~/sap/ushell/services/PluginManager-dbg.js
sap.ushell.Container.getService("Ui5ComponentLoader").createComponent(oApplicationProperties)
.done(function(oLoadedComponent) {
if (oPluginDeferred) {
oPluginDeferred.resolve();
}
oDeferred.resolve.apply(this, arguments);
})
.fail(getRejectHandler());The above code basically creates the component for the custom plugins(as they are obviously an UI5 app) which is mentioned in the target mappings.
I found here that my plugin component is not called at all.
I checked if any service call might be there to fetch all the custom plugin details but to my surprise no call went to the backend (it makes sense as unnecessary calls will slow down the the Launchpad)
So I debugged a bit and found the code where it is reading the plugins
It is reading from the window parameter "sap-ushell-config" where the plugin details are stored.
So again I started to search where the window parameter is set and found the place, it is nothing but the main flp file where the Launchpad is loaded:
But where is that oServerSideConfig coming from? same file, little bit above, we cannot see it in the debugging as it is a dynamic parameter, so opened it in the backend code directly(below);
So the serversideconfig is set via the placeholder( ${SERVER-SIDE-CONFIG} ) which is again set from http_hanlder class.
Now I went to the HTTP handler class from FLP’s SICF node.
So at last I found the code where it is fetching the plugins.
and they are setting it at below in the response(which is the Fiori launchpad page).
But little did I know, it is fetching the plugins from SHMA(Shared memory access) and so no actually reading the db and trying to fetch the plugins based on a condition, the plugins are already set to SHMA instance before in some other code.
I guess, this is to increase the performance of the Fiori Launchpad so no addition logic will be performed to fetch the plugins or other information when we launch the FLP.
Here the table mt_plugin doesn’t have my plugin but it has other plugins.
Again, now I debugged where the shared memory is set. But still I don't know which service or backgroundjob or program will save the plugins to SHMA
So I assumed that it might be set from the Launchpad catalog configuration service when we save the target mapping. Luckily yes and the breakpoint got triggered.
I found the issue now.. Instead of ‘Shell’ I’ve mentioned in the target mappings Semantic object as ‘shell’. Even I didn't get any error while saving(no idea why). A silly mistake 😄
So after all this debugging, the issue is a very simple one and from this I understood how the plugins are loaded in Launchpad.
1. First they will be set to SHMA on the save of the target mappings to increase the performance of FLP loading
2. The plugins information along with someother launchpad stuff is converted to string and set to launchpad.
3. These data will be read by the plugin manager.js and the plugins components will be asynchronously loaded.
This is a kind of reverse engineering but if you go from the bottom to top, you get an idea of the process of loading plugins to the launchpad.
The architecture and coding is an awesome piece of art written by SAP team and It’s a very good learning for me 🙂
Thanks to all who took their time to read this till the end 😄
Best Regards
Mahesh
- SAP Managed Tags:
21 Comments
