CAP service (OData V2), Cloud Foundry Mobile Services and Kapsel plugins

[johnmurray]

Hi all,

Unusual problem that I'd be very grateful if someone could answer or has any ideas on. To summarise:

I have a UI5 application which runs in the Cloud Foundry (CF) Fiori Launchpad and uses CAP for the backend. I'm using the OData v2 proxy adapter to provide an OData v2 service and have exposed that through my approuter. The OData v4 service is not mapped and is thus not available. I am also using CF mobile services to have an android version of this same app and it is using the kapsel plugins.

Now for the problem (I apologise it is a bit long):

Essentially my problem is that if I tick the option in Mobile Services offline odata configuration "Batch all defining requests" then when I run the application on android device, it fails to create the offline store. What's interesting though is that the error message (below) is returning HTTP 200 (success) and is actually returning the data from the service, however it is the OData v4 format which presumably is what is causing the crash. If I disable the "batch all defining requests" option then everything works as expected, so for some reason it is the batching that is causing the problem. In the FLP version of the app I am using batching without any issues, so it is not that my service doesn't support batching. My current thoughts are that something somewhere along the line is causing the OData v2 proxy adapter to crash or fail, and it is falling back to just returning the original OData v4 service. That is the only way I can think that the OData v4 service would be coming from the route, because as previously mentioned I have configured it such that it should technically be impossible to access through the app router.

Any thoughts or ideas would be very welcome

The error message is below and as you can see it is OData v4, I have clipped it after the first entity because it is a very long error message and you get the idea:

Retrieve feed https://<hidden>.cfapps.eu10.hana.ondemand.com:443/<hidden>/$batch failed because the OData server returned HTTP code, 200, with message: {"d":{"responses":[{"status":200,"id":"~00","headers":{"odata-version":"4.0","content-type":"application/json;odata.metadata=minimal;charset=utf-8"},"body":{"@odata.context":"$metadata#ExampleTypes","value":[{"ID":1,"name":"Example Data"}]}}
...

[gregorw]

Can you provide which v2 proxy version and CDS version you're using? Also have you tried to record the requests made from the kapsel client using the Mobile Service trace functionality? Can you replicate the result when running this requests with Postman or REST Client?

[johnmurray]

Thanks Gregor, I've pasted the output of `cds -v` below. With regards to capturing the the requests from MS trace, if I'm honest I haven't done that yet but I will definitely give that a go.

@sap/cds: 4.1.9
@sap/cds-compiler: 1.39.0
@sap/cds-dk: 3.0.0
@sap/cds-foss: 2.0.0
@sap/cds-odata-v2-adapter-proxy: 1.4.44
@sap/cds-reflect: 2.13.0
@sap/cds-runtime: 2.3.0
@sap/hana-client: 2.5.109
@sap/xsenv: 3.0.0
@sap/xssec: 3.0.9
Node.js: v12.16.1

[christoffer_fuss]

I am facing the same error and batch requests are not working with the offline store....have you reported this issue to SAP? I I will try to debug this tomorrow....

[johnmurray]

Hi christoffer.fuss did you get anywhere with your debugging? Due to having too many things I didn't report this to SAP because I had a work around in disabling batch requests for defining entities. However I'm kicking myself for that now because I've just discovered this is the cause of many other issues in my application. Please can you let me know how you got on and if I'll report it to SAP if you haven't yet.

Thanks

John

[christoffer_fuss]

Hi jmurray91, yes I had a very long journey with oliver.klemenz to fix the batch requests and we were finally able to solve this problem :). The main problem was that the V2 proxy was giving a status code of 200 in case of success and not a 202, which is standard for Odata V2.
This fix is not yet released but I guess it is coming this week, hopefully tomorrow 😉

Best regards and many thanks to oliver.klemenz ,
Chris

[johnmurray]

Hi christoffer.fuss Thanks for the quick response! That is absolutely brilliant news you managed to find the problem and that a fix is coming too. I'll keep my fingers crossed that it lands tomorrow!

Thanks again and also to oliver.klemenz !

John

[christoffer_fuss]

and here it is 🙂

https://www.npmjs.com/package/@sap/cds-odata-v2-adapter-proxy/v/1.4.50

[christoffer_fuss · Accepted solution]

Like mentioned above the problem was the status code of 200 and not 202. Mobile Services needs to get a 202 response to accept the batch. This version of the V2 proxy fixes this issue:
https://www.npmjs.com/package/@sap/cds-odata-v2-adapter-proxy/v/1.4.50

Many Thanks to oliver.klemenz !

[OliverKlemenz · Accepted solution]

That I would call, a just in time fix... Thank you too, for tackling this together...

[johnmurray · Accepted solution]

Hi again both, I've installed the latest patch version and I can see now in the web version of my app that batch response is being rewritten to 202 as expected. However in my APK I can see that it still appears to be trying to use OData V4 and the subsequent 200 return code. Are there any custom headers or anything else that I need to do to force it into V2 mode? Or should it "just work"?

[christoffer_fuss · Accepted solution]

Hi John,

I am using these customHeaders:

 "customHeaders": {
     "Content-Type" : "application/json",
      "accept": "application/json"
}

For me batch requests are working fine, also the option "Batch all defining requests".
My offline config:

Best regards,
Chris

[johnmurray · Accepted solution]

Hi christoffer.fuss and oliver.klemenz , unfortunately it's still not working for me - however after a bit more investigation this morning I've discovered the following:
1. If I set the customHeaders for the hybrid app to both be application/json then my v2 OData Cap service URL comes back as OData V4 and therefore causes errors

2. If I set the customHeaders for the hybrid app to both be multipart/mixed then my v2 OData Cap service URL does come back as OData V2, which is some success, however I then get an error in Mobile Services "The incoming path /mobileservices/management/versions is not mapped to a Destination"

3. If I remove the "content-type" header completely from customHeaders, and set "accept" to be "multipart/mixed", then my V2 Cap service does continue coming back as OData V2, but then mobile services gives me an error that "Error parsing a batch response. Incorrect value for HTTP Header "Content-Transfer-Encoding:\"\" ". I've checked and my service is not sending that header, which would explain that error. I've had a look through the CAP code and I can see several references to that HTTP header, but it does not appear to be being sent. I see in the code comments that it's been deprecated as of v1.30? Which maybe explains why it is no longer being sent. Is there an option or flag to reenable the sending of that header?

So from the above and some other tests I've done, CAP appears to only return OData V2 for a batch request for me if I specify the "accept" header to be "multipart/mixed". If I set it to be application/json or do not include it, then the service will return OData V4.

It seems that whatever I try I can get either CAP to be happy, or Mobile Services to be happy, but never both at the same time.

[OliverKlemenz · Accepted solution]

Hi John,

I'm not in the topic of Mobile Services processing so much, and the batch settings you mentioned I cannot help with (maybe christoffer.fuss can share his experience with batch requests with Mobile Services and CDS OData V2 Adapter Proxy, as it works on his side).

What I really find strange, is that you get an OData V4 non-batch response for a OData V2 batch request (as mentioned in you issue description in the error message)... If you pass a multipart/mixed $batch request by calling /$batch URL, you shall also get a multipart/mixed $batch response from OData V4.

One this you can do for better analysis, is to enable tracing in the CDS OData V2 Adapter Proxy, by setting ENV variable:

XS_APP_LOG_LEVEL=debug

Then you see all logs of the logging layer starting with "cov2ap/" in the console.

You get detailed logging (url, status code, body, headers) of the V2 client request (cov2ap/Request), V4 proxy request (cov2ap/ProxyRequest), V4 proxy response (cov2ap/ProxyResponse), V2 client response (cov2ap/Request).

In addition please watch out for any other errors/warnings starting with "cov2ap/". Those can indicate, what went wrong on the way.

Best regards,

Oliver

[christoffer_fuss · Accepted solution]

We are already in contact via slack. I can provide source code, logs, traces, configs, whatever is needed 😉

[johnmurray · Accepted solution]

Thanks oliver.klemenz for the tip on the App Log Level. I've now set that however there is not a single warning or error being logged unfortunately. When I set the two headers to application/json I can see that:

1. cov2ap/request comes in as OData V2
2. cov2ap/ProxyRequest then is ODataV4
3. cov2ap/proxyResponse comes back as OData V4
4. cov2ap/response continues to be OData V4

I don't suppose you have any more ideas do you? I have a call with a SAP tomorrow AM to look at my Mobile Services configuration but assuming all is correct there then it does point to cov2ap and/or CAP being at fault somehow.

christoffer.fuss can I just check which versions of the plugins you're using with cds -v please? Mine are:

@sap/audit-logging: 3.2.0
@sap/cds: 4.2.4
@sap/cds-compiler: 1.43.0
@sap/cds-dk: 3.1.2
@sap/cds-foss: 2.1.0
@sap/cds-odata-v2-adapter-proxy: 1.4.50
@sap/cds-reflect: 2.13.1
@sap/cds-runtime: 2.5.3
@sap/hana-client: 2.6.58
@sap/xsenv: 3.0.0
@sap/xssec: 3.0.10
Node.js: v12.16.1
audit-apps: 1.0.0

[christoffer_fuss · Accepted solution]

@sap/cds: 4.2.7
@sap/cds-compiler: 1.43.0
@sap/cds-dk: 3.1.4   
@sap/cds-foss: 2.1.0   
@sap/cds-reflect: 2.13.1 
@sap/cds-runtime: 2.5.6  
Node.js: v12.19.0

You are using Node.js? We are using CAP Java....

Best regards,
Chris

[OliverKlemenz · Accepted solution]

That behavior is very strange. I currently could not image a situation, where for "application/json" the OData v4 response is not converted to an Odata v2 response.

Would you mind sharing the log of the following four requests incl. url, status code, headers, body.

1. cov2ap/request comes in as OData V2
2. cov2ap/ProxyRequest then is ODataV4
3. cov2ap/proxyResponse comes back as OData V4
4. cov2ap/response continues to be OData V4

That would help me in the analysis.

Furthermore is it possible that you debug the CDS OData V2 Adapter Proxy? We could have a call on that together, to have a look on what's happening, if the logs do not point me to the root cause..

But definitely there is something wrong in how the OData proxy works...

[johnmurray · Accepted solution]

Thanks for sharing that christoffer.fuss , good to see we're using broadly the same versions. Interesting you're using CAP Java though!

oliver.klemenz I'm more than happy to share anything you need, do you have an email address I can use to contact you? It would be great to have a call as well to ensure I'm getting you the right logs. Thanks

[OliverKlemenz]

New patch version available, filling content-transfer-encoding:

https://www.npmjs.com/package/@sap/cds-odata-v2-adapter-proxy/v/1.4.53