Skip to Content

Component Reuse – The move to Manifest.json

First of all sorry that it took me so long to write this last blog. But life happened.

This last blog will be about how we can make a consistent app that will work both on SAP Cloud Platform as well as on premise.

This scenario will happen if you use the webide to develop, but deploy to on premise gateway.

Here are the links to my other blogs in this series

  1. Demystifying the art of component reuse in SAPUI5
  2. Component Reuse – 4 ways of sharing data between the apps
  3. Simplifying the component reuse to work both on premise and in cloud and using the manifest.json

In the first blog i showed you how to use Jquery to register the module path as well as the component. While it works I am really not a fan of having it in the component.js file. So i figured out a way to move this to the manifest.json file.

The benefits of this is also it gives you more control of your resources on when you want to load the component container.

So back to it, it’s quite simple actually.

First we register the component as a dependency under the sapui5 –> dependencies

"components": {
	"bourneMyChildApp": {
		"lazy": true
	}
}

The lazy here makes sure our component isn’t loaded until needed, saving precious bandwith on initial load.

Secondly in the root of sapui5 add the resourceroot to your app

"resourceRoots": {
	"bourneMyChildApp": "../sap/bc/ui5_ui5/sap/mychildapp/"
},

Now you might say, hang on! that only works on prem. And yes you are quite correct, but the actual cloud magic happens in the neo-app.json file. Remember my first blog? We added the following to the neo-app.json file

 {
      "path": "/mychildapp/",
      "target": {
        "type": "application",
        "name": "mychildapp"
      },
      "description": "My Child App"
    }

This tells the SCP that when we run something with path /mychildapp/ it should point to our application. The only thing we need to do to make our app work both on prem and also cloud is to change that path to path we added as a resourceroot

 

 {
      "path": "/sap/bc/ui5_ui5/sap/mychildapp/",
      "target": {
        "type": "application",
        "name": "mychildapp"
      },
      "description": "My Child App"
    },

That’s it! Now when you test in SAP WebIde you are running the cloud version of your app, but when you deploy it, your resourceroots are still fine and picks up your child app from there.

10 Comments
You must be Logged on to comment or reply to a post.
  • Hi Jakob,

     

    I did something similar but then with a library. Did you tried running it in the Fiori Launchpad? The resourceRoots will not always work the same, or at least that was the problem in my case.

    “../” in fiori launchpad, generated a wrong url. I had to use the register module function in the component.js like here: https://blogs.sap.com/2017/04/05/sapui5-how-to-reuse-parts-of-a-sapui5-application-in-othermultiple-sapui5-applications/

    But overall, great blog series! Thank you for sharing!

    Kr, Wouter

    • I must admit I’ve only tested this from Webide and on prem as the client i work with doesn’t use the SAP Fiori Launchpad in the cloud. Another way you be to use jquery and just have a switch statement to register the different module paths.

  • Hi

    I have deployed to an on-premise system and wondering how do I reference “mysharedlibrary”

    I have tried this

    and this

     

    But it’s not working.

     

    Thanks and kind regards

  • Your on premise system doesn’t use the neo-app.Json file. That’s only for the cloud. So your path to your resources needs to be correct and then have your library mentioned in the libs area of your manifest.

  • Very informational series, Jakob. Thanks for your sharing your insights.

    Question – Would this setup using neo-app.json work in CloudFoundry?

    Thanks.

  • Hi Jakob,

    I’ve made it work on Cloudfoundry using destination. Thank you! The apps which have these UI5 modules are currently unsecured i.e. ‘authenticationMethod’ in xs-app.json (approuter) is set to ‘none’. The destination’s authentication is also set to ‘NoAuthentication’.

    Now, when security is enabled in these apps by setting ‘authenticationMethod’ to ‘route’, the setup doesn’t work anymore. The destination correctly makes a request for the child/dependent Component.js from the published app but the content received looks like a SAML authentication step which requires/tries to initiate the authentication process. Previously, when the apps were unsecure, the same call received proper JavaScript content for Component.js file. I would think this is right as the security mechanism is trying to validate the request for Component’s resource files.

    The question is what changes would I need to do in order to make this work when apps are secure? The changes could be needed in the destination service or the parent app which is calling the dependent Component. Any ideas or direction on this would be very helpful and appreciated.

    Thanks!