2
When creating a new API page with a table relation, you can expand (OData $expand) the table relation if the related record type has a page of type API.
For example, if you create an API page for Sales Header, and another API page for Customer, then you can expand the Sell-to Customer No. using $expand=customer.

This does not work when there are multiple table relations to the same table - it doesn't work for Bill-to Customer on the same page as there is only one NavigationProperty added per related table type.





















It would be good if we could define the NavigationProperty Name on fields that have a table relation. This would allow us to have multiple NavigationProperty elements for the same record type.

Something like this:

Category: Development
STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future.

Best regards,
Business Central Team

Comments

D

From my point of view this is an error report rather than a feature request.

Reasons:
- Today it seems to depend on the field sequence: the first field with a table relation wins. The API client will never know if the billto or sellto customer (createdby or modifiedby user...) is returned, and it will never be able to request the other one.
- By default the fields seem to be bound to systemIds if no target field is explicitely declared within the TableRelation (e.g. Currency instead of Currency.Code). This is definitely wrong because a currency code will never match a systemId.
- The client gets an error message if it tries to expand an entity name (e.g. currency) which is also used as a field name (e.g. currency). The client will never be able to expand this entity in such a page.

Suggestion to solve all these issues:
- If $expand contains a name that can be found in the field list, then the field's TableRelation will be evaluated in a BC compatible manner (BC primary key field instead of API primary key field). The result (expanded JSON object) will be returned instead of the simple field value. If there is no match, then still the field value is returned (instead of null).
- If $expand contains an entity name (which cannot be found in the field list), then the NavigationProperty is being created like it is today (just for legacy reasons).

So in case of a sales header with a selltoCustomer and a billtoCustomer the compiler should just create three NavigationProperties:
- "selltoCustomer"
- "billtoCustomer"
- "customer"

Seems to be low effort and big win.

Category: Development

D

NavigationProperty Name="selltoCustomer" Type="Microsoft.NAV.customer" ContainsTarget="true"
NavigationProperty Name="billtoCustomer" Type="Microsoft.NAV.customer" ContainsTarget="true"

Category: Development