on 02-26-2021 8:30 AM
Hello CAP Experts,
I think in CAP stimple things should be kept simple and so I'm try to avoid any additional coding when I just want to proxy an external service. This works fine for normal OData requests including $filter, $select, $top and $skip. But i.e. Fiori elements adds also $count=true to show the number of total results. If in return the value of "@odata.count" is 0, nothing will be displayed. This behaviour was described also by gadirov in Fiori Preview of external OData (Northwind) Product Instances not shown. I've provided him a workaround. But as I mentioned that doesn't really solve the isse.
So I now have setup an example where this issue can be reproduced. In my bookshop-demo I've included the external service ZPDCDS_SRV which is provided from the SAP ES5 Gateway System and doesn't require any authentication. The custom handler to call the external service is implemented in srv/admin-service.js#L40:
let result = await externalTransaction.run(req.query)
So you see that I simply forward the query that I get from the local request to the external service.
To reproduce the issue you only need to follow the setup instructions in the readme. Especially make sure that you maintain the destinations in default-env.json.
Please set the environment variable:
DEBUG=follow-redirects
To get an output of the request sent to the backend.
Then start the project with
cds run
and call the URL http://localhost:4004/admin/SEPMRA_I_Product_E?$format=json&$top=1&$select=Product - you will be asked for a username and password. Just enter admin for the username. The result will be:
{
"@odata.context": "$metadata#SEPMRA_I_Product_E(Product)",
"value": [
{
"Product": "HT-1000"
}
]
}
When you now request http://localhost:4004/admin/SEPMRA_I_Product_E?$count=true&$select=Product&$skip=0&$top=30 which is exactly how the Fiori Elements preview app constructs the request, you will get:
{
"@odata.context": "$metadata#SEPMRA_I_Product_E(Product)",
"@odata.count": 0,
"value": [
{
"Product": "HT-1000"
},
...
As you can see the value for @odata.count is 0. When you check the log output you will see a line:
path: '/sap/opu/odata/sap/ZPDCDS_SRV/SEPMRA_I_Product_E?$select=Product&$top=30&$orderby=Product%20asc',
That represents the path requested from the backend. And here the $inlinecount=allpages is missing. I would expect that the count=true is transalted into $inlinecount=allpages.
Hope that this issue can be fixed in the CDS runtime or in the SAP Cloud SDK used by CAP.
Best regards
Gregor
Hi Gregor,
Currently we do not know the version of the external OData service (v2/v4). Our plan is to make this configurable and then provide specific translations, e.g. `$count=true` -> `$inlinecount=allpages`.
Best regards,
David
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi David,
thank your for the update. Maybe you can assign someone to the Incident 145735 / 2021. The last information I've got there was "We are still looking for the most suitable processor.".
Best regards
Gregor
Hi Gregor,
I'm happy to inform you that this feature will be released with the next release!
Best regards,
David
Hi david.kunz2,
I've updated bookshop-demo to the latest CAP Release (5.4.3) and gave it another try. You find the coding in srv/admin-service.js#L101. Unfortunately the count is not returned for the called OData V2 service as the parameter is passed as $count=ture and not as $inlinecount=allpages. Should the correction be already included in this release?
Best regards
Gregor
Hi gregorw ,
The functionality to distinguish between OData v2 and v4 is not yet released. It will come with the next release.
Best regards,
David
Hi David,
can you confirm that this is solved with the Consuming Services General Available in the October 2021 Release and documented in Consuming OData V2 Services in Node.js?
Best Regards
Gregor
Hi gregor.wolf ,
Do you have any idea if this has been solved with one of the latest releases?
I did not find anything in the CAP documentation nor the releases.
Currently I'm using your workaround which is really helpful, but it seems it does not cover a $batch request scenario, could that be?
Thank you in advance!
Best regards,
Dries
The current workaround for this issue is:
const count = await externalTransaction.get(`${req._.req.path}/$count`)
result['$count'] = count
Check out here in context: srv/admin-service.js#L42
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
11 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.