Dynamic OData URLs in Fiori Elements Apps running in cFLP

[marcel_schork]

Hi,
in one of our projects we are running a Fiori Elements (FE) app inside a Launchpad on SAP BTP CF. The app is exposed via multiple tiles while each of these tiles should connect with a different SAP backend. In freestyle UI5 apps this can be accomplished by dynamically creating and prefixing the path to the OData endpoint and map it to different destinations like shown below.

However this approach doesn't work for FE apps as the datasource url provided via manifest.json determines the destination being used.
We also tried to dynamically provide the manifest object like suggested here, but without success.

Is anybody aware of a solution or knows that is not (yet) possible to accomplish with FE?

Thanks & best regards,
Marcel

[nicolas_lunet]

Hello Marcel,

In my opinion the dynamic manifest definition seems like your best bet as it's the very first point in time where you can do anything with the application (before the models are created).

We use this approach frequently for merging additional content in standard application manifest (changing the odata url being one of our use case)

Do you have more details as to what you tried and couldn't get to work ?

Regards

Nicolas

[marcel_schork]

Hi Nicolas,

This is exactly what we tried. Providing a dynamic manifest object in the Component.js of the FE app:

AppComponent.extend("test.Component", { 
  metadata: {
    "manifest" : {
        ...
        dataSources: {
            "odataService": {
                 ...
                 "uri": `${dynamicPrefix}/sap/opu/odata/sap/SERVICE/`,
            }
        }
    }
  }
});

However this approach is working in freestyle UI5 apps and for Fiori Elements within our local dev environment using a FLP sandbox. But when deploying to BTP Cloud Foundry and running the app inside a Fiori Launchpad the url from the static manifest.json file is used to create the OData model.

Does this approach work for you in Fiori Elements apps and if so are they running standalone or inside a FLP?

Thanks your answer!

Best regards,

Marcel

[nicolas_lunet]

Hi Marcel, I think the main approach is not have a JSON string here but rather do metadata: { manifest: getMyManifest() }

getMyManifest will be called at runtime and you can then return the correct manifest including the static (but correct) odata url you need

This works fine in an FLP environment, you can check https://sapui5.hana.ondemand.com/resources/sap/fe/test/Utils.js where we do this for getManifest

[marcel_schork]

Hi Nicolas,

we will give it a try. Thanks for the hint! But honestly I do not get the difference between calling a method that provides the manifest object or putting it direcly without a function call. In both cases the object will look the same. And the later approach didn't work for us in FE applications.

Best regards,

Marcel

[marcel_schork]

Hi Nicolas,

I tried again the approach you shared. It's working in a Fiori Sandbox locally, but after deployment to BTP and running via Managed AppRouter standalone and also inside FLP we can't manipulate the OData URL. We also created a case, but it seems that they don't understand the problem.

We created a little Fiori Elements app with a CAP backend to reproduce the issue.

https://sapcross-dev.launchpad.cfapps.eu20.hana.ondemand.com/da43fd4f-a68b-459d-9be5-cb632900d631.fe...

In the manifest.json we use a not existing service endpoint (srv2/) and during app start we try to maniplute the manifest using the correct one (srv1/). As said this works fine locally in the sandbox, but after deployment it doesn't. And in the network trace we also see that our manifest.json is loaded before the Component.js of the app.