Solutions for supporting dynamic OData/annotation URL for Fiori Elements App

[patton_li]

Hi UI5 Fiori Elements team colleagues,

Problem description:

We are from BTP xx team, we need to build a Fiori Elements app and the app is hosted on our server (CF), when user is visiting the app, the Fiori Elements app can get OData format entity data and the entity annotations dynamically (means the service url and annotation URL is not specified in the "datasources" part of the Fiori Element app "manifest.json" file).

If you have supported this case like: passing the "datasources" part during the Fiori Elements app visiting, please help to show us the sample case and docs, thanks~

The reason of why we need this:

We provide sample OData services, each user can play our OData entity API and annotation uploading API with his isolated space. We expecting: the built up Fiori Elements app can connect to the sample services with dynamically URL and render an UI to user, and use it to check the data and manage it.

[maheshpalavalli]

You can create the manifest.json content on the fly and send it the component as shown below: (But i believe this will be executed once, so you might have to refresh internally or re-instantiate again when the manifest.json content is changed.

AppComponent.extend("test.Component", {
 metadata: {
 "manifest" : getManifest() // write your code to generate manifest.json inside
   }
});

Note: This is not a best practise and I suggest anyone who is looking for this approach to check thorsten.hochreuter comment for more information.

[patton_li]

Hi Mahesh,

Thank you for your idea, I'm trying this to resolve it.

--

Thanks and regards,

Patton.

[thorsten_hochreuter]

Hello,

I'm aware that this is an old comment, but I'll try to make a case against this pattern regardless:

The UI5 Core team highly discourages the manipulation of the manifest at runtime.

The manifest of a Component is considered a static resource, which should be provided as-is to, e.g. by a backend service or via the app-index etc.

So the best practice approach is to load the manifest first (e.g. by calling the Component.create() factory).
This way a bunch of optimizations can be performed.
You get access to early parallel preloading of library dependencies, as well as automatic model creation.
Any future optimization will be part of the manifest first approach too.

Sadly we've seen a number of cases where one tries to load the manifest synchronously (very bad) in the Component.js module (or in this case a getManifest()-helper). These synchronous requests are obviously very bad for performance, but will also not be supported in UI5 2.0.

So please make sure your application isn't relying on such behavior, so that you are ready for a potential upgrade in the future.

Now concerning the static provisioning:

There is a way to do this correctly.
You can provide the static manifest content via the factory function itself, this will look something like this:

// load manifest asynchronously
const oManifestResponse = await fetch("path/to/manifest.json")
const oManifestParsed = await oManifest.json();

// ... manipulate the oManifestParsed object ...

// pass it to the component factory
const oComponent = await Component.create({
    manifest: oManifestParsed
});