Skip to Content
avatar image
Former Member

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

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Oct 23, 2017 at 05:28 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Florian Pfeffer

      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