Closed ThePlenkov closed 1 year ago
I just reviewed the documentation and the human readable texts are correctly only talking about one path, however, you finding is correct, the sample code snippet is wrong, backend
is an object and not an array.
To have a proxy for multiple paths, please use two instances of the middleware e.g.
- name: backend-proxy-middleware
afterMiddleware: compression
configuration:
backend:
- path: /my/path
pathReplace: /my/entry/path
url: https://my.backend.example:1234
- name: backend-proxy-middleware
afterMiddleware: compression
configuration:
backend:
- path: /my/other/path
url: https://my.backend.example:1234
@tobiasqueck well - but that's a point - it was working like this before. The problem is not with documentation. Fiori tools migration command also converts neo-app.json to a wrong format now.
Moreover - this way of definition in real life is problematic. When you lunch locally some real SAP application, for example as a part of extension project - you might need 5-6 extra paths, resolving /resources/sap/fin/some/app to /sap/bc/ui5_ui5/FIN_SOME_APP. Each app may have also libarries dependencies, those libraries depend on another libraries - so the real list may be long. And with this approach ui5.yaml becomes a monster. Supporting array path - you may significantly improve dev expreinece and reduce number of lines in the config file.
@ThePlenkov I think there is a mixup with the middlewares. The Fiori tools migration should migrate to the fiori-tools-proxy
in @sap/ux-ui5-tooling
(which is internally using this one here). You would use something like https://www.npmjs.com/package/@sap/ux-ui5-tooling#connecting-to-multiple-back-end-systems.
Or are you saying that the behavior of the fiori-tools-proxy
is not working as documented and you narrowed the issue down to the @sap-ux/backend-proxy-middleware
module?
The problem you are describing should most likely be solved differently (but it is not yet properly documented but we are working on it). The issue you are seeing is that your local preview FLP does not know where to find your reuse libraries (or other apps) and assumes they are part of ui5 and therefore checks /resources/...
.
To fix that, you need to edit your flpSandbox.html
file. Search for the following
<script id="sap-ui-bootstrap"
src="/resources/sap-ui-core.js"
...
data-sap-ui-resourceroots='<my_libs_as_json>'
...>
</script>
The resource roots are a json string containing lib/app id to path mapping e.g. for one of my local test projects, I have the following
{"my.app": "/","sap.fin.central.lib":"/sap/bc/ui5_ui5/sap/fin_lib/","sap.se.mi.plm.lib.attachmentservice":"/sap/bc/ui5_ui5/sap/plm_ath_cres1/","sap.s4h.cfnd.featuretoggle":"/sap/bc/ui5_ui5/sap/featuretoggles1/","fin.co.lib.utils":"/sap/bc/ui5_ui5/sap/fin_co_lib/"}
With that setting your proxy configured for path /sap
should cover everything.
When you lunch locally some real SAP application, for example as a part of extension project - you might need 5-6 extra paths
Do you have a extension project or an adaptation project?
@tobiasqueck you got it right. Initially it was ui5-ux-tooling and i downcasted it to here because I though the format supposed to be same. Meanwhile indeed - here is the way how I solve it with a appconfig/fioriSandboxConfig.json
{
"modulePaths": {
"booking.ushell.plugin.excelDownloader": "/sap/bc/ui5_ui5/sap/ZFLP_EXCEL",
"fin.ar.lineitems.display": "/sap/bc/ui5_ui5/sap/FIN_CUST_LITS",
"sap.fin.arp.lib.lineitems": "/sap/bc/ui5_ui5/sap/fin_arp_lib_li/sap/fin/arp/lib/lineitems",
"sap.fin.central.lib": "/sap/bc/ui5_ui5/sap/fin_lib/sap/fin/central/lib"
},
"applications": {
"GL-lineItems": {
"title": "Manage Customer Line Items"
}
},
"services": {
"LaunchPage": {
"adapter": {
"config": {
"groups": []
}
}
},
"NavTargetResolution": {
"adapter": {
"config": {
"applications": {
"GL-lineItems": {
"additionalInformation": "SAPUI5.Component=booking.fin.ar.lineitems.display",
"url": "/booking/fin/ar/lineitems/display",
"applicationDependencies": {
"self": {
"name": "booking.fin.ar.lineitems.display"
},
"asyncHints": {
"libs": [
{
"name": "sap.fin.arp.lib.lineitems"
}
]
}
}
}
}
}
}
}
}
}
But in the old version we managed to resolve everything just using neo-app.json
but indeed - to come here - i had to spend quite some time for reverse engeneering =) So piece of documenation would be useful here.
@tobiasqueck before closing this issue- we still have a problem with migration tool. Do you know who owns this? Which project is it?
@tobiasqueck before closing this issue- we still have a problem with migration tool. Do you know who owns this? Which project is it?
That is still internal at SAP but @devinea is the expert. He is on vacation right now, but I will check with him once he is back.
@ThePlenkov Do you there a open query on migration?
@devinea to be honest I don't know where to open - it happened via VS Code migration extension - but I guess that extension is just using some function.
Hi!
I have reviewed the code and it seems that backend-proxy-middleware doesn't support multiple paths as it's documented: https://github.com/SAP/open-ux-tools/tree/main/packages/backend-proxy-middleware#changing-the-path-to-which-a-request-is-proxied
So this kind of definition:
gives this error:
Could you please have a look and advise how to design multiple paths for the same destination?
Actually I came here from another place. VS code extension has migrated my neo-app.json to such a format and fiori-tools-proxy fails now.
Thanks!