Hi,
Background:
we use OData for client side extensions within our managed solution.
For some OData requests navigation property names are required.
Example:
data/v8.0/pt_examples$expand=owninguser(...)
So what we did is to determine the needed navigation propery names at development time and hardcoded our OData requests.
After years one of our customers reported an error.
Turns out that some navigation property names in the customer's organization have changed after importing the last version of our managed solution.
In the customer's org the navigation property is named owninguser_system now, so the request should look like:
data/v8.0/pt_examples$expand=owninguser_systemuser(...)
In order to fix that, we would need to determine the navigation property names at runtime, e.g. with:
data/v8.0/EntityDefinitions(LogicalName='pt_example')/ManyToOneRelationships?$select=SchemaName,ReferencingEntityNavigationPropertyName,ReferencingAttribute
This works, but it considerably complicates the client side code and also has a hit on performance (even if we cache the metadata).
Questions:
- Is this really the way to go?
- Are navigation property names really not stable accross organizations?
- Or is there something special at our customer's organization?
- How do you craft your OData requests with regard to navigation property names?
Additional information:
- The custom entities in our managed solution cannot be customized. So there are no unknown, conflicting lookup fields, which could cause a naming clash.
- Our customer migrated from on premise to online some years ago, and there was a another problem related to entity metadata, which was fixed by Microsoft support. Maybe it is a problem with the entity metadata in the customer's organization after all.
Thanks!
Johannes.
10
Share
Report
All responses (
Answers (
