External Entities: Not all OData retrieves are optimized

Question: Does Mendix fully leverage the OData features when retrieving External Entity data?

Answer: No. While Mendix does use the OData query parameters like $filter, $top and $skip, it leaves some performance gains on the table.

In Mendix, external entities are published as a standard OData service which exposes its data as entities. On the consuming end, Mendix abstracts it by importing the service contract into the app allowing developers to work with remote entities as if it were local entities without managing the underlying REST calls themselves.

A published external entity will provide the following endpoints:

• POST /$count
• GET /$query
• GET List
• GET (‘id’)

All retrieves on external entities in a consuming Mendix application will be routed through the POST /$query endpoint and it ignores the dedicated endpoints for GET by ID, GET list and GET count. This is not inherently an issue, as the /$query endpoint is not limited by too long URLs and can therefore handle more query parameters. It does raise the question —if Mendix doesn’t fully leverage the OData features— are we unknowingly introducing hidden performance bottlenecks? Unfortunately, yes.

The (hidden) performance issues I found so far:

1. Retrieve + Count, where the count action is not in the same microflow as the retrieve: Mendix fetches the full dataset and counts it on the consuming side (if the count is in the same microflow it only fetches the count via the $query endpoint). It could make this more efficient by getting only the count when there is no other usage of the retrieved external entity list.
2. Retrieve associated objects: Mendix does two separate calls (in retrieve from association) to get both objects. Instead it could fetch both using the $expand feature in a single request. When working with lists it introduces a lot of extra calls (for each item in a list, fetch a related external entity).
3. Retrieve of child ids: the exposed ‘id’ is available in the response, but Mendix assigns an internal id to the retrieved object and the external-id of the associated objects is not available to the developer.

Since OData supports these features, a workaround is obvious; when efficient processing is required a REST call to the OData service endpoint is a good alternative.

Checked in Mendix 10.24.16 on an OData v4 service.