One of the great new features available in Dynamics 365 v9 is Virtual Entities, which allow you to represent data from external system as entities without copying or synchronizing data, and often times without any custom code. In this series of posts, I’ll dive into this new feature, with a focus on what it means for Dynamics 365 Portals, and how we can leverage them to create no-code integrations between your Dynamics 365 Portal and other systems.
Virtual Entities allow you to represent data from external systems natively in Dynamics 365 without the data actually residing in the database. There are three main components to setting up a Virtual Entity: the data provider, the data source, and the Virtual Entity definition.
The data provider is the code that performs the queries against a specific data source. As part of the first version of Virtual Entities, Microsoft includes an OData v4 data provider. This means that if your data source has an OData v4 endpoint, you can use it with Virtual Entities without writing a line of code! You also have the option to build your own custom data provider if you data source does not have an OData v4 endpoint, however I’ve heard mixed results from people who’ve tried this. It may be a while before all the kinks associated with a custom data provider are worked out.
The data source is used to point your Dynamics 365 instance to where the data is actually located. When configuring a data source, you select a data provider, and enter the configuration data needed to access that data source, such as the URL of the OData feed.
Finally, the Virtual Entity definition allows you to create the entity in Dynamics 365 in almost the exact same way you’d create a normal (i.e. non-virtual) entity. Within your solution, simply create a new entity and check the Virtual Entity checkbox. You’ll then be able to select your data provider and the corresponding entity/table within the external data source that map to the Virtual Entity.
There are a number of great articles already available that step you through the process of setting up a Virtual Entity – instead of repeating those steps I’ll provide the links below for your reference.
https://blogs.technet.microsoft.com/lystavlen/2017/09/08/virtual-entities/
The following limitations of Virtual Entities have been well documented:
However, there is one other limitation I ran into when playing with these, and it has an impact on what we can do with portals: the inability to perform joins across Virtual Entities within a single query (in FetchXML language, if you’re fetching a non-virtual entity, you can’t use a virtual entity in a link-entity node, and if you’re fetching a virtual entity, you can’t include a link-entity at all). Now this limitation makes sense; it is not really feasible to perform joins across data that resides in different locations – it’s a complex thing to do, and performance could be a nightmare. However, it’s something you need to keep in mind if you intend on using Virtual Entities.
It seems like Microsoft has prevented users from creating these bad queries in some places, but there are still a few gaps. For example, if you create a N:1 relationship between Contact and a Virtual Entity, you’ll get a lookup to the Virtual Entity on the Contact record. When editing views for the Contact entity, you can add the Virtual Entity lookup field as a column; this will work fine. This is because underneath the hood, the FetchXML query simply returns the GUID of the related record; the UI is responsible to actually determining the name to display, which it does by making a single query to the OData source for all of the names that appear on that particular page. But, if you instead choose the Virtual Entity from the Record Type drop down when adding a column, and add the Name column (or any other column, for that matter), you’ll be able to successfully save the View, but you’ll get an error when you try to open that View and see the records.
One other thing to note: your OData v4 service may be case sensitive. This means that any searches will also be case sensitive, including Quick Finds. This may be counter-intuitive for users since generally Quick Finds in Dynamics 365 are not case sensitive.
In my next post, I’ll get into a bit more detail on what is, and isn’t, possible when it comes to creating relationships involving virtual entities.
[…] post Virtual Entities and Dynamics 365 Portals – Part 1 appeared first on Engineered […]
[…] my first post in this series I discussed how virtual entities and the link-entity node in FetchXML don’t mix well. In this […]
[…] my first post in this series I discussed how virtual entities and the link-entity node in FetchXML don’t mix well. In this […]
[…] far in this series, I’ve provided an intro on virtual entities and a deeper dive into virtual entities and relationships. In this post, I’m finally going to […]
[…] far in this series, I’ve provided an intro on virtual entities and a deeper dive into virtual entities and relationships. In this post, I’m finally going to […]