Hi Everyone,
Today i am going to share views on the Virtual Entity which is added to Dynamics 365 in October 2017 release.
When the Virtual Entity might be useful?
Scenario's:
1) You have data in another system that only needs to be viewed in Dynamics 365.
2) Highly sensitive data in an external system that you don't want to be stored in Dynamics 365.
Virtual entities are made up of three main components, a data provider, a data source record, and a virtual entity.
Virtual Entities are an alternative to client-side and server-side approaches for connecting external data with Dynamics 365 with a solution that is significantly easier to configure and manage.
As the name itself states the "Virtual", which is not physically exists.
The Virtual entity is quite useful in integrations scenario's like Microsoft Dynamics 365 Integration with a third party system.
Where the data from third party system will not be stored physically on Dynamics 365 database to avoid data replication.
The data will be "read only" with the first release of this new feature.
User can not update the data on the virtual entity but can be used in dashboard, viewed in advanced finds, views, query purposes only.
Can not run the workflows or business process flows on the virtual entity. Hopefully in next releases more functionality will be added to virtual entity.
Today i am going to share views on the Virtual Entity which is added to Dynamics 365 in October 2017 release.
When the Virtual Entity might be useful?
Scenario's:
1) You have data in another system that only needs to be viewed in Dynamics 365.
2) Highly sensitive data in an external system that you don't want to be stored in Dynamics 365.
Virtual entities are made up of three main components, a data provider, a data source record, and a virtual entity.
Virtual Entities are an alternative to client-side and server-side approaches for connecting external data with Dynamics 365 with a solution that is significantly easier to configure and manage.
As the name itself states the "Virtual", which is not physically exists.
The Virtual entity is quite useful in integrations scenario's like Microsoft Dynamics 365 Integration with a third party system.
Where the data from third party system will not be stored physically on Dynamics 365 database to avoid data replication.
The data will be "read only" with the first release of this new feature.
User can not update the data on the virtual entity but can be used in dashboard, viewed in advanced finds, views, query purposes only.
Can not run the workflows or business process flows on the virtual entity. Hopefully in next releases more functionality will be added to virtual entity.
Image from Microsoft
Virtual entity creation and mapping
Initially, defining a virtual entity is the same as defining a custom entity: you specify the entity, attributes, and relationships for the new virtual entity type. However, additionally, you then connect the virtual entity to a data provider to manage data retrieval.
The custom entity type and its fields must be mapped to the corresponding data in the external data source. For example, a virtual entity might be represented as a row in an external relational database, and each of its fields might correspond to a column in that row.
(Note that these external data names are often different than their corresponding virtual entity names.)
A specific, required mapping occurs for the entity ID field: the data provider must be able to provide this GUID and associate it to the external record that represents this entity instance.
The most direct way to achieve this is to actually use GUIDs as primary keys in the external data source.
Limitations of Virtual Entities
There are some limitations to virtual entities that you need to be aware of when evaluating whether you can use virtual entities with your external data.
Data is read-only. The virtual entity feature doesn’t support pushing changes made in Dynamics 365 back to the external system.
Only organization-owned entities are supported. The security filtering applied to user-owned entities is not supported. Access to the virtual entity data can be turned on or off for individual users based on their security role. Field-level security is not supported.
It must be possible to model the external data as a Dynamics 365 entity. This means:
> All entities in the external data source must have an associated GUID primary key.
> All entity properties must be represented as Dynamics 365 attributes. You can use simple types representing text, numbers, optionsets, dates, images, and lookups.
> You must be able to model any entity relationships in Dynamics 365.
> An attribute on a virtual entity cannot be calculated or rollup. Any desired calculations must be done on the external side, possibly within or directed by the data provider.
> Auditing and change tracking is not supported. These may be implemented within the external data store.
Virtual entities cannot be enabled for queues.
Offline caching of values is not supported for virtual entities.
A virtual entity cannot represent an activity and do not support business process flows.
Once created, a virtual entity cannot be changed to be a standard (non-virtual) entity. The reverse is also true: a standard entity cannot be converted into a virtual entity.
Virtual Entity and OData 4
If you need Azure Cosmos DB (formerly Microsoft Document DB), a virtual entity provider is available from AppSource. And for everything else you have two options:
Using the Dynamics 365 Data SDK, .NET Developers have the option of creating custom virtual entity data providers to help integrate external data source types that are not supported by an existing data provider.
You can see on the custom virtual entity data providers page, is to create an OData v4 interface to your external data source, so that you can directly access it with the supplied standard OData v4 Data Provider.
I hope this helps.
For consultation/Training Visit www.gmritsolutions.co.uk or reach out to us at admin@gmritsolutions.co.uk