cancel
Showing results for 
Search instead for 
Did you mean: 

CAP entity key recommendations vs. fiori elements

nlaenger
Explorer
0 Kudos

Hi,

I really don't know where to put this question.

As in the CAP documentations it is recommended to us a "generic" key for all entities (aspect cuid):
Domain Modeling | CAPire (cloud.sap)

This eases the implementation of generic functions that can apply the same ways of addressing instances across different types of entities.

So I started my CAP journey with this recommendation in mind.
So much time later and more knowledge with fiori elements I'm stating to user more and more concepts...

Know I'm trying me luck with Deep linking and ODATA v4.
Navigation to an App (Inbound Navigation) - Documentation - Demo Kit - SAPUI5 SDK

And there quick hidden on the documentations is says (thanks to the UI5 support for pointing this out):

Applications must ensure that the semantic keys across the different entity sets of the subobject pages are named uniquely to ensure the correct deep linking behavior.

So now I have to change all entity key to have a different names.

But now the question for me:

  1. Is the recommendation in the CAP is "wrong" (if you want to use fiori elements)
  2. Where is the right address to put this discussion

regards

Norbert

Accepted Solutions (1)

Accepted Solutions (1)

MioYasutake
Active Contributor

You can use the following annotation to represent a semantic key:

Common.SemanticKey: [ SalesOrder ]

Therefore, you can use cuid for the primary key and specify one or more different fields for the semantic key.

 

nlaenger
Explorer
0 Kudos
That was also my idea.ut at the moment a SemanticKey that is not the same as the technical key will crash the fiori elements site.
nlaenger
Explorer
0 Kudos
ok, strange new site.... At the moment my pages will always crahs if my Semantic key does not match the technical key. Therefore I did raise an Support Ticket and this leads to this discuson.
nlaenger
Explorer
0 Kudos
I still don't like it to add more "key fields" that the FE UI will use but having another key on the DB side the UI will use sometimes. But it is what it is for now 😕 Impact on Draft etc. I will see when refactor everything.

Answers (0)