Engineered Code is proud to announce the availability of ecLearn - the Learning Management System built on top of Microsoft Dataverse


Virtual Entities and Dynamics 365 Portals – Part 4 – Fake OData v4 Service

In order to confirm that much of the functionality in Dynamics 365 Portals works with virtual entities, I needed to have data sources with some pretty specific fields. Rather than hunting for an existing service to meet all of my requirements, I was able to quickly setup a fake OData service hosted in Azure Web Apps that I could use as my Dynamics 365 Virtual Entity Data Source.

Existing Public OData v4 Endpoints

When I first started playing with virtual entities, there were two publically available OData v4 endpoints that I was using:

Both of these services were great for testing. If you want to see how virtual entities perform with larger data sets, the Purdue Classes entity has over 250k records in it. EDIT: The Classes entity does not have a string field to map to the Name field, so you can’t use it for Virtual Entities – thanks Jan for the comment! The Courses entity, which I used for my testing, has over 32k entries.

However, there were a few features where I needed very specific types of data, or specific values, and these two services didn’t quite fit. Specifically, to test the mapping functionality on Entity List and Entity Forms, I required records with Latitude and Longitude coordinates. To test out 1 non-virtual entity to N virtual entities relationships, I required fields that contained the IDs of records that existed in my Dynamics 365 instance. Obviously, public endpoints wouldn’t satisfy that condition so I decided to create my own.

Avoiding the Reinvention of the Wheel

I didn’t want the service to be too complicated; for example, I didn’t want to have to setup a database. Thankfully, I found this tutorial that did exactly what I needed: it stepped me through the process of creating an OData v4 service where all of the data was defined right in the code.

Within minutes I had a project setup and was able to query my new OData service. I pushed the code up to an Azure Web Apps, and I figured I was off to the races. I created a new Virtual Entity Data Source pointing at my Azure Web App, created the virtual entity and the fields, and attempted a simple advanced find – but instead of seeing a list of my data, I got an error.

The Small But Important Missing Piece

After a bit of digging, I came across a comment on a Microsoft how-to article. It turns out I needed to explicitly add support for a few OData options that Dynamics 365 requires, including $select, $count and $orderby.

To do that, I simply added to the following line to WebApiConfig.Register, right before the call to EnsureInitialized:


With that in place, my Fake OData v4 service was up and running, and successfully feeding virtual entities to Dynamics 365!

Poor Man’s Logging

I was curious to find out how often Dynamics 365 actually calls the Virtual Entity Data Source. Unsurprisingly, it’s a lot. There doesn’t seem to be any caching of virtual entity information, so every time you request information about virtual entities, it hits the data source (including for things like populating suggested options in lookup fields). Caching is always a challenge, so I completely understand why this first version of virtual entities doesn’t include it.

To see what was happening, instead of implementing a proper logging mechanism, I used the code found here to send myself an email with the Office 365 SMTP server each time a request was made. The body of the email included the requested URL.

Even though the code isn’t complicated, it nice that someone else had already figured out the server name, port and other configuration parameters for me. A lazy but effective approach!

4 responses to “Virtual Entities and Dynamics 365 Portals – Part 4 – Fake OData v4 Service”

  1. […] post Virtual Entities and Dynamics 365 Portals – Part 4 – Fake OData v4 Service appeared first on Engineered […]

  2. Jan Verwaest says:

    Dear Nicolas,

    You mentioned in your blog that you have been able to test with The Purdue OData v4 Service. Did you actually manage to map the Classes entity with Dynamics 365?

    This entity does not contain a field of the Type=Edm.String. So how would you map this with a virtual entity that automaticly creates a Primary Key with a Data Type=Single Line of Text. This can not be altered. Therefor it can not be mapped with a corresponding field from the external datasourc.

    Did you manage to get around this issue or am I overlooking something?

    Jan Verwaest

  3. Nicholas Hayduk says:

    Hi Jan,

    No, I don’t think you’re missing anything – it’s my mistake.

    I didn’t use Classes in my testing – I used Courses and Subjects. I looked for an entity with a large quantity to mention in my post, without actually testing it.

    I’ve updated the post. Thanks for the comment, and for reading!


  4. AB says:

    Thanks for taking the time to write this up! I also went down the route of building a little OData service, but was stuck at the point where Dynamics was giving me inscrutable errors when querying it. I suspect I need to add those OData options in the service initialisation…

Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.