odata-v2: entityBuilder().fromJson() does not recognize sub-sub entities

Describe the bug I am on my way to create PurchaseOrders using SAP Cloud SDK and available oData EDMX file. This EDMX is coming from a custom made oData API of an R/3 ERP.

I used @sap-cloud-sdk/generator in version 2.5.0 to generate a Virtual-Data-Model first.

Within I am trying to create a PO by using the ability to create the entity by using the purchaseOrderSetApi.entityBuilder().fromJson() functionality.

Unfortunately, this is only working for direct navigation properties of the entity purchaseOrderHeaderSet, so it’s available for toPurchaseOrderItem of the PO, but not for sub-sub entities like toPurchaseOrderItmAccountAssignment of toPurchaseOrderItem.

To Reproduce myVdm.service()purchaseOrderHeaderSetApi.requestBuilder().create( myVdm.service().purchaseOrderHeaderSetApi.entityBuilder().fromJson( (entityToSendToErp as myVdm.PurchaseOrderHeaderSet) ) )

entityToSendToErp looks like something like that: {“documentNumber”:“4100000333”, “toPurchaseOrderItem”: [ {“itemNumber”:“1”,“quantity”:“90”,“toPurchaseOrderItmAccountAssignment”: [ {“glAccountNumber”:“80000000”,“costCenter”:“321110”} ] } ], “isCreate”:true}

Expected behavior I did guess, the complete json is getting used and recognized, not only properties and navigations related to the main-entity (available as SCHEMA of the entity). As “toPurchaseOrderItmAccountAssignment” is not identified as part of the SCHEMA of “purchaseOrderHeaderSet” (what’s true indeed, because it’s part of the item), it get’s added as “customField” instead.

Maybe there is another approach to deal with deep-structured json object and getting an entity created from it and I just do not know it 😉? Hint.

Analysis I debugged the scenario and discovered file “@sap-cloud-sdk/odata-common/entity-builder”, containing method “fromJson()”. Here it does check only against the schema of the main-entity, but not of related sub-entities.

Impact / Priority This is blocking our architecture, where we’re using json objects to send to the ERP within the SDK. Affected development phase: 2 weeks before SIT Impact: Blocked Timeline: e.g. Go-Live is in 7 weeks.

[FrankEssenberger]

I would not call this a mistake because it is not clear from the fromJson() that you have to initialize something. If we keep this method in newer higher versions we either need to make this clear from the API or make it capable of initializing the object. However, we had issues with cycle references along the way.

[drvup]

Hi @FrankEssenberger , thanks for coming back to me about this issue. Yes, you’re right. I identified the lazy init stuff and I made the same mistake here again 😉

Anyhow, of course with this approach the all-time generic approach is lost. But that’s a perfect way to mitigate the issue while you and the team is checking abilities to solve the fromJson() part. Maybe it’s worth to highlight that at the documentation on the related part 😉 Lazy developers like me can identify this issue easier and maybe check out available approaches like we did discuss now 😄

However, thanks for pointing this out and thanks for the great support. This is really appreciated 😃

Best, Cedric