Closed geert-janklaps closed 11 months ago
Thanks for reporting this issue. Yes, this seems to be a limitation currently. It's only working when cds.xt.ModelProviderService
is running locally.
So your scenario is not supported out-of-the-box currently.
I check, how this can be supported in near future. Stay tuned...
Great, to see this is going to be added in the near future! Do you by any chance have an idea of an availability date that you're aiming for?
To give some context, we're in the process of going live with this partner solution we're creating and the OData V2 adapter is one of the crucial parts for one of the apps. (using a hierarchy tree in SAPUI5, which currently only supports OData V2) Just to keep this in mind for our go-live plan (maybe postpone the delivery of the impacted app).
Thanks for letting me know. I have an alignment meeting with MTX colleagues for this topic today. Depending on that I can give more information. But I hope, that I can provide a solution within the next weeks. Stay tuned.
We discuss the problem, and need further information about your configuration of CDS requires in package.json
. Is there an explicit configuration of ModelProviderService
? Because in your effective env we see this:
"cds.xt.ModelProviderService":{
"impl":"@sap/cds/libx/_runtime/remote/Service.js",
"external":true,
"kind":"rest",
"model":"@sap/cds-mtxs/srv/model-provider"
}
In general the following configuration should be enough in package.json cds section
:
"cds": {
"profile": "with-mtx-sidecar"
"requires": {
"multitenancy": true
}
}
Especially cds.xt.ModelProviderService: "from-sidecar"
is not required.
"from-sidecar" is deprecated anyways and should not be used anymore.
In any case, I will fix, that mps
is checked before access, so that the request will not crash...
I think the from-side car part is the reason why there is an explicit configuration for the cds.xt.ModelProviderService. When removing it, there's no explicit configuration anymore.
The good news seems to be that removing the 'from-sidecar' preset seems to fix the OData V2 adapter issue. I'm now perfectly able to get a metadata document without the previous error.
I must have missed the deprecation of 'from-sidecar' or is not communicated yet? Looking at the CAP documentation, it's still mentioned in the CAP documentation without any deprecation warning so it seems. (https://cap.cloud.sap/docs/guides/extensibility/feature-toggles#add-remote-service-link-to-sidecar)
Good to hear that it works for you now. You're right, it's officially documented. I talked to the colleagues, and they said the usage is discouraged and that from-sidecar
is planned to be deprecated in future. I was mistaken here. But in principle the same result: "from-sidecar" should not be used. Thanks.
Hi,
We've added the OData V2 adapter to our multitenant application, which is using the out-of-the box setup for multitenancy using a side-car.
We're using the default profile with-mtx-sidecar and the cds.xt.ModelProviderService is configured as "from-sidecar". (full standard setup)
When deploying the application to Cloud Foundry, accessing any metadata document fails. This is because the cds.xt.ModelProviderService is not running in the local project, but is configured as a remote service.
It looks like the current framework is expecting the MPS service to be running locally, since this is not the case, the request fails. (mps = undefined)
We're using the latest versions of the libraries involved:
Result of "cds env get requires --profile production":
Is this a bug or am I missing some configuration? Looking into the documentation I didn't seem to find any specifics for a side-car setup for the streamlined mtx library. (only for a remote setup for the old MTX library)
Best regards, Geert-Jan