CAP Hybrid testing ignores cf target

[matteoprinetti]

I have 2 Subaccounts - lets say DEV and QAS. Both have the destination "backend", which is SAP On-premise Server:

On Subaccount DEV "backend" points to our ABAP Dev server (lets say DE1)

On Subaccount QAS "backend" points to our ABAP Quality server (lets say QA1).

Now when I logon to my BAS running on the DEV subaccount I cf login to the DEV Subaccount:

cf login --sso ... etc etc.

If now I do something like curl "backend.dest/sap/opu/odata/sap/MYSERVICE_SRV/$metadata" I correctly get the metadata from service on DE1.

If I now change the target and login to the foundry QAS Subaccount

cf login --sso ... etc etc.

and issue the same curl request, the data still come from the DEV Server !

So it looks the destination proxy ignores the cf target but just used the one where the BAS is running (if I start a BAS on the QAS Subaccount, curl returns alwas data from QA1 does not matter which cf Im targeting.

Is this "bug or feature" ? It would be very handy to have the hybrid testing run against other subaccounts - for example to debug why a certain query is failing which is always impossible to reproduce on DEV.

[Dinu]

The destinations in proxy in BAS are from the subaccount BAS belongs to. It has no relationship to the target of cf CLI.

If you want to connect to multiple environments, you may create different profiles for these environments with `cds bind --for <profile>` where `<profile>` is like `hybrd-dev`, hybrid-qa` etc. When using a profile you need to use login to the specific DC (with `cf api` and later `cf login`) for the cf environment. If the profiles use the same DC, you don't have to switch. You should not use BAS proxy, but instead use destination service directly for this. Bind to destination service in the hybrid profiles to achieve this.

[gregorw]

But I would think that this will not work when you want to use an on Premise Destination via the Connectivity Service. So maybe another use-case for https://github.com/jowavp/sap-cf-proxy

[junwu]

that is probably the expected behavior

[gregorw]

Have you tried if executing:

curl localhost:8887/reload

after switching the subaccount helps?

[matteoprinetti]

Yes it makes no difference, I think its expected behaviour.