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:

• http://api.purdue.io/odata/$metadata
• http://services.odata.org/V4/OData/OData.svc/$metadata

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:

config.Count().Filter().OrderBy().Expand().Select().MaxTop(null);

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!