A noteworthy idea with a challenging path ahead
So, with the July 2017 update dropping in at the beginning of October (I know, nomenclature issues here), among the new features we get, one items got some of us excited. That is Virtual Entities. The sales pitch was something along the lines of a new way to integrate data from external sources. That sounds beneficial, if we can finally reduce our arsenal of 3rd party tools and make our life that much easier in the process. But is it really all that it’s meant to be?
Well, let’s have a look, shall we.
The first and most important touted fact is the ease of use, where this can be simply configured, without the need of a full development cycle. How true is that? Well, if you box your view to Dynamics 365 CE only, yes, that’s true. You configure the connection, and then configure a new entity of type Virtual Entity, and voila, data just flows. More on this later.
But, and there is a but, your data source has to offer an OData v4 endpoint. And here comes the caveat, you do still need the dev cycle to create these custom endpoints that can be leveraged through simple configuration. And, since most applications do not have it, all we’ve done is shifted the focus of the dev team. You could consider though the fact that this could be pushed on to a partner supporting the data source application, if they are willing to do it. Let’s just leave it at that for now.
With a move to microservices I’m seeing lately on some customers, while OData is supported, it’s not always the best approach as it could expose a larger set of inner data structure than you want. If that’s the case, there goes this option.
Next, data is read-only in your Dynamics 365 CE. This might be all you need, and that works out great. You can control where updates are done and have a different master for specific type of data. But if that doesn’t fit your business need, you’re back to the drafting board.
When it comes to field level security, this is a read-only field by default, so not much to say there. All you do is control visibility of that section.
Next, there is no support for business processes around this data. Hence, you can not leverage business process flows, nor you can trigger workflows. This is because data does not in fact reside in your tenant. This could be a big limitation, depending on the business need you have. If you need that to happen, again, like trigger a process of update other fields when data refreshes on the other side, back to the drafting board and revert to some of the older techniques.
Finally, and this is a positive one, as I just mentioned, the data does not reside in your tenant. This could be a beautiful thing for compliance. I can think of PCI compliance right away, but other scenarios apply just as well.
More on the technical side, the data source must have a GUID type primary key. Again, this goes back to the data source creator, and if they are willing to accommodate this need. Then, properties must be mappable to standard Dynamics 365 types. This, in most cases, will not be an issue.
As for the Dynamics 365 CE process to configure this, it’s straight forward, kudos to the team for making it so easy.
How to do it
First off, from the Settings > Administration, hit the Virtual Entities Data Sources and create your new source. As mentioned before, right now you only have a choice of OData v4. As for configuration, all you need is to provide a name for your data source and the target URL. Pagination option provides the standard client or server side.
Next you create your entity just like any other, but you select the Virtual Entity option and the data source as the new data source you created. Make sure you map the External Name and External Collection Name to the data source field names, and add additional data fields as needed.
And voila, you’re done here. Easy as pie!
So, overall, this is a great way for easy scenarios, assuming all the moving parts work together. There are obvious use case scenarios where this is valuable, but there are still scenarios where the amount of work required to make this work is not justified. Make sure you’ve done you due diligence before embarking on this path.
Hopefully when more data source types are supported, this becomes the preferred way to solve a lot more issues. Only time will tell.
Try it, use it, enjoy!