Today we continue with the blog series D365 V9.0 – A Feature a Day, and I am enjoying the self-discovery process of all the new improvements that have been made to the V9.0 platform. Today’s feature will be focusing on the newly introduced Virtual Entities.
Today’s Feature – Virtual Entities
Previously the options for integrating external data sources into your Dynamics solution were limited usually involving persisting external data within your organisation database or developing client side script to pull on demand.
Today, Microsoft Dynamics 365 V9.0 offers a new way of integrating external data in a friendly manner – introducing Virtual Entities.
Virtual Entities behave similarly to regular entities but instead sources its data from external sources.
So how does this work?
Virtual entities consist of three main components – a data provider, a data source and a virtual entity. The following diagram from the Microsoft Documentation describes the relationship best:
- Organisation DB stores meta data, the data source and actual data.
- In the case of Virtual Entities, the data remains hosted within the External Data Source. Hence when you create a Virtual Entity it will remain Read Only as essentially it is a reference to the data source.
- D365 V9.0 comes with a OData Data Provider that you can use to connect with an OData V4 Web Service (more on this later).
What are the limitations?
The following limitations should be considered when implementing Virtual Entities such as:
-
- Auditing is not supported.
- It cannot be used in a Roll Up and Calculated Field calculation.
- It cannot be an activity type (for reasons that might be obvious, it is read only).
- Knowledge management, SLAs, Change Tracking Mobile Offline, Field Security, MS Web Portals are not supported.
- Your Data Source must use a GUID as an ID.
What are some other cool things you can do with Virtual Entities?
During testing I thought i’d try out some of the existing operations that you could still perform with Virtual Entities. Here’s a few examples of what you can do with Virtual Entities:
- You can Export your rows to Excel (but you cannot import them again, as it is read only).
- You can package your Virtual Entities, Virtual Entity Data Providers and Virtual Entity Data Sources into a solution.
- You can quickly switch between data sources through the Customisations window.
So how do I create one?
I’ll start by modelling a public data source. You can see a full explanation of how to set up your first data set by reading Jesper Osgaard’s post on Virtual Entities on his blog. I use his steps as the basis of this section, as he has kindly found us a public data source that uses a GUID as the primary identifying key (see limitations – requiring a GUID in your data source).
I won’t go into as much detail as Jesper (you can do so in the above link at your own time), but at a high level these are the steps:
- Pick your Data Source. In this case it will be from the Products OData V4 Service located at http://services.odata.org/V4/OData/OData.svc/ and the collection will be “Advertisement”
- Define your Virtual Entity Data Source (Settings > Administration > Virtual Entity Data Sources)
2) Create a New Data Source (Select OData v4 Data Provider)
4) Create your Virtual Entity and associated fields
5) Map your Fields to the Field Names within your Data Source (using External Name)
6) Finally preview your data by navigating to your newly created Virtual Entity.
Final thoughts
I’ve been asked many times in the past if it was truly necessary to persist data within the Dynamics Data Model, and prior to V9.0 there were very few options for us to architect a neat solution. This new feature attempts to address the integration situation with Dynamics 365, and I am looking forward to seeing further enhancements to Virtual Entities in future releases.
As this is a first release, i’m sure it will continue to evolve and get better. My only suggestions would be:
- More detailed logs, so we can debug easier.
- The ability to use the native OData Data Connector on data sources that do not use a GUID but rather an Integer as the identifier.
But other than that, it’s a fantastic addition to the Dynamics platform and I’m sure will be greatly appreciated by Developers and Architects alike.
Stay tuned for my next blog in the V9.0 series! Until then, thanks for reading.
If you’re keen on trying this new feature out yourself, head on down to https://trials.dynamics.com/Dynamics365/Signup