HANA xsodata on calculation view using keys generate local returns "resource not found"

[shady_shen]

Dear experts,

with HANA XSC, I created an odata services on top of a calculation view using "keys generate local"

service {

"PROJ.model::CV_PROJDETAIL" as "CV_ProjectDetail" keys generate local "GENERATED_ID" aggregates always;

} annotations { enable OData4SAP; }

where there are three dimensions "p_name", "c_name", "proj_phase"

and one measure "cr_number" defined in the calculation view

and by accessing

GET /odata/odata.xsodata/CV_ProjectDetail/?$select=c_name,cr_number&$format=json

I get something like

{"d":{"results":[

  {"__metadata": {"type":"odata.CV_ProjectDetailType"

    ,"uri":"/odata/odata.xsodata/CV_ProjectDetail('543859892167869371')"}

    ,"C_NAME":"SAP","CR_NUMBER":7},

  {"__metadata": {"type":"odata.CV_ProjectDetailType"

    ,"uri":"odata.xsodata/CV_ProjectDetail('543859892167869372')"}

    ,"C_NAME":"SVW","CR_NUMBER":2}

]}}

,which is fine.

However, when I follow the metadata and try to

GET /odata/odata.xsodata/CV_ProjectDetail('543859892167869371')

I got a "RESOURCE NOT FOUND" error.

Is it normal? I would expect it to return the same result similar to

{"d":{"results":[{"C_NAME":"SAP","CR_NUMBER":7}]}}

Best Regards

Shady

[shady_shen]

Hi Tanveer,

I'm afraid one should avoid using the generated ID option and specify the real techincal ID in the xsodata. As to the Fiori application, I guess one will need to find way to put all the key fields in the odata request, say, requesting all the technical fields but hide used ones in the UI.

Just some thoughts, but haven't really put it into real practice.

Best Regards

Shady

[pfefferf]

Yes, the behavior is normal, because the key is only valid for a single session (one OData call). The generated key is only there to fulfill the requirement that the OData result sets contain key. But no navigation etc. is possible with that keys. Check the documentation here.

Regards,
Florian

[shady_shen]

HI Florian,

Thanks for the answer.

But it is strange that how session is defined here, one call per session ( although of course odata access is stateless in this regard).

The reason behind this question is the requirement of Fiori Element application which work properly with the odata services generated by the SAP NW gateway since the generated ID works throughout the entire logon session and can be used to reference the entity.

Do you know whether there is any plan to fill this function gap?

Best Regards

Shady

[pfefferf]

As I am no SAP employee and have no "direct" wire to that specific development area, I do not know if there is a plan to change something here.

Do you have the option to reuse an existing field or a combination of existing fields as key or to generate a constant key in a kind of "consumption calculation view"?

[shady_shen]

Hi Florian,

To provide some further background of the issue. In fact, I do have technical keys in the model. But due to the analytical nature of the fiori element application, this key field is not necessarily in the "select" option of the odata access. And in that case, no "ID" is returned from the odata service, which leads to endless access to the odata service from the Fiori element application. Use "keys generate local" is a workaround that guarantees an "ID" output, but due to the issue I mentioned in the question itself, it now seems not to be a working workaround, either.

Best Regards

Shady