Question/Bug: Not Addressable Entities and Path generation

[sterlp]

Hello Guys,

we discovered an interesting use case where the XSLT generator behaves a bit odd, at least in our currently even wrong:

1. we have to entities Head and Address
2. the second entity is a dependent one, from Head, means not access-able (is-a-relation)
3. the root entity is access-able

As soon we add a create option for the sub entity, we also get two POST operation for SubEntity AddressSet. One on the parent, which is fine and one on the root.
But it requires the link to the head and of course it's ID should not be "create able".
As a workaround we can of course set it as create able, but we end up still with two "POST" end-points, where in one the parent ID is in the body and path and in the second, only because we set it as create-able, in the body.

Overall our expectation was, that no endpoint methods are generated on top level, if we set the entity as not address able.
Hope this description is somehow understandable.

With e.g. DELETE (or update/PATH) it works fine:

OpenAPI has only the DELETE endpoint on the sub-path:

Not sure if it is a bug, or intended behavior, because of a use case I can't think of right now. I testet most combinations but this particular one somehow let us wondering.

Thanks in advance

Paul

SAP HeadSet ist adressierbar und beides anlegbar.xml.txt

[ralfhandl]

@sterlp Hi Paul,

Thanks for reporting this!

Seems like I only considered the read case for non-addressable entity sets 🙄

Please confirm if this is the desired behaviour:

• if AddressSet is not addressable, no paths starting with /AddressSet will be generated
• if in addition AddressSet is creatable, a post operation for path /HeadSet(...)/to_Address will be generated
• if AddressSet is updatable / deletable, a patch / delete operation for path /HeadSet(...)/to_Address(...) will be generated

Thanks in advance

[sterlp]

@ralfhandl Hello Ralf,

many thanks for the fast response. To your questions:

• if AddressSet is not addressable, no paths starting with /AddressSet will be generated
  => YES

• if in addition AddressSet is creatable, a post operation for path /HeadSet(...)/to_Address will be generated
  => YES

• if AddressSet is updatable / deletable, a patch / delete operation for path /HeadSet(...)/to_Address(...) will be generated
  => YES (no patch / delete on the root /AddressSet )

Thanks

Paul

[ralfhandl]

@sterlp Pull request #312 fixes the first two bullet points, using a test case based on your example.

Regarding the third bullet point: I am not sure whether Gateway supports PATCH and DELETE for two-level paths with key segments such as /HeadSet(...)/to_Address(...).

Could you please check with your service whether that works?

Thanks in advance!

[sterlp]

I will check on Wednesday, sorry for the delay. I think we have to add some ABAB coding to ensure the call is received or not.

[sterlp]

Hello @ralfhandl,

you are right, at least on OData v2 this won't work. Means only this works:

Good:

GET/DELETE/PATCH: /sap/opu/odata/sap/ZE_API_DEMO_SRV/AddressSet(BusinessPartner='1',AddressId='1')
POST: /sap/opu/odata/sap/ZE_API_DEMO_SRV/HeadSet('1')/to_Address

Bad:

GET/DELETE/PATCH: /sap/opu/odata/sap/ZE_API_DEMO_SRV/HeadSet('1')/to_Address('1')

at least in out tests.

---

Long story short: Only the POST on the root has to be removed as soon as the entity is not address able but create able; as otherwise we have two POST endpoints.

Thanks

Paul

[ralfhandl]

@sterlp Please review

• XSLT, OData V2: no direct create for non-addressable entity sets #312