SAP RAP Custom entity referential constraint error...

altafmohammedaftab · 3 weeks ago

Hi Community,

I'm currently working on an SAP RAP unmanaged scenario using Custom Entities in ABAP Cloud, and I’ve run into an issue when trying to expose metadata.

Scenario:

I have two custom entities defined as follows:

Root Entity:

@EndUserText.label: 'Custom Root entity for Parent'
define root custom entity ZParent {
  @OData.property.name: 'SessionId'
  key SESSION_ID : abap.int1;

  _Child : composition [1..1] of ZChild;
}

Child Entity:

@EndUserText.label: 'Custom entity for Child'
define custom entity ZChild {
  @OData.property.name: 'SessionId'
  key SESSION_ID : abap.int1;

  _Parent : association to parent ZParent on _Parent.SESSION_ID = $projection.SESSION_ID;
}

Issue:

When I try to access the $metadata of the service, I receive the following error:

Code: SY/530  
Message: Association assoc_0FCF7701A629F6O035FFE9E6E21380F1: referential constraint property not found in entity ZChildType.

Interestingly, the error does not occur when the @odata.property.name annotation is removed.

Question:

Does the RAP framework not automatically handle property name mapping when using @odata.property.name?

Is there an annotation or recommended approach to handle referential constraints in this case?

Any insights or guidance would be greatly appreciated!

Thanks & Regards,
Aftab

suzanne_alivand

From what I'm seeing, it feels like the RAP framework gets a bit tangled up when you try to rename key fields using @odata.property.name and have associations linking those keys between custom entities. It seems pretty good at renaming the property SESSION_ID to SessionId when just defining the entity itself in the metadata. But when it comes to automatically figuring out the ReferentialConstraint for the association I suspect it gets tripped up, maybe it's looking for the new name SessionId in the child based on the parent's key, but the actual link defined back in the CDS is still using the original ABAP field name.

Honestly, in my opinion the path of least resistance here is probably just to ditch the @odata.property.name. Since taking it off makes the error go away, it seems like the simplest fix to let the framework correctly wire up those constraints without getting confused by the renaming!