This is the first part of the two-part blog post series explaining the virtual entity concept in Common Data Service for Finance and Operations.
Link to the second part: To be updated.
Preface
As many of you may know, some of the Microsoft Dynamics 365 products either have their own data models and application platforms and some of them have shared ones. For example, our current cloud-based ERP products, Finance and Operations and Business Central have their own data models and application platforms. Then we have many different applications, such as Dynamics 365 Sales, Dynamics 365 Field Service and Dynamics 365 Marketing, which are model-driven apps and are built on top of Common Data Service platform, thus sharing the same data model.
Ever since all of these different business applications were put into the Dynamics 365 product family, we have talked about One Dynamics 365. From technology perspective, that would certainly mean new innovations in order to claim that these different applications in the same product family talk the same language and different business processes can be executed beyond application boundaries.
It has been a great journey for the Microsoft’s engineering team to come up with the solutions that would bring the applications and their data closer to each other. From the perspective of Finance and Operations, that has meant integrations between Finance & Operations and Common Data Service. The integration have been done at the platform level, so that every model-driven app can benefit from the integration.
Integration solutions today
First, we got the Finance and Operations Connector in the Power Platform to perform the CRUD operations as well as execute OData actions. The connector is based on communication through OData protocol and Power Platform is always the active party in that integration, where as Finance and Operations responds in reactive manner.
To address the integration workloads between Finance and Operations apps and the model-driven apps, the Data integrator was introduced to Power Platform. Before the Data integrator, it was more or less common to integrate, for example Dynamics 365 Sales and Finance and Operations using a middle-ware service, like Azure Logic Apps or Microsoft BizTalk, to create the the connections and the dataflows between those two applications. Along with the Data integrator, a few pre-defined integration templates for it and the support for custom templates were introduced also. Those pre-defined templates covered the most usual integration scenarios between Finance and Operations and the model-driven apps, such as Prospect-to-Cash process.
In the 2020 release wave 1, an integration infrastructure and a solution, Dual-write, was introduced and it was generally released on April 2020. That’s the feature that brings really the feel of One Dynamics 365 and it surely doesn’t disappoint. The dual-write infrastructure establishes near-real-time, bidirectional and synchronous integration between Common Data Service and Finance and Operations. Effectively, that enables us to create integrations that transfer data between those two platforms in real-time, while respecting the data integrity rules and validation logic of each platform. Really powerful infrastructure and application solution, which is easy to setup, is extensible and today the solution supports already 100 and more data entities from Finance and Operations. Of course, the entity coverage will grow and will target also scenarios, where usually some logic is executed in Finance and Operations in order to produce the data, like on-hand inventory calculation.
Do not forget the larger effort that contributes to these integrations. That is called Common Data Model, which brings different data models of Microsoft’s Business Applications together unifying the data models and sharing the data language for business and analytical applications.
Virtual entities
In July 2020, solution for virtual entities in Common Data Service for Finance and Operations will be released. At the time of writing this post, it’s in public preview, to which any partner can join.
First, we need to understand what are virtual entities in Common Data Service. In Common Data Service, we have native data entities but also virtual entities. As the name of it might give a hint, the virtual entities are virtual and therefore not really native entities in Common Data Service. Virtual entities represent data of external data sources and Common Data Service doesn’t store the data of virtual entities – the data is always read from the external data sources. But for the applications that are consuming virtual entities, those entities appear as any other entities, native or virtual.
So, the Microsoft engineering team came up with the solution that exposes every public data entity from Finance and Operations as virtual entities in Common Data Service. This makes it look like the data entities from Finance and Operations are inside the Common Data Service, even though they technically aren’t. The data resides in the external data source and Common Data Service reads the data from there and doesn’t store the data. So, now you’ve got effectively an access to Finance and Operations data entities from any application or solution by using Common Data Service without having any data integrations first built in place.
The setup is rather easy, when you have both the Finance and Operations and Common Data Service environments already existing. You can follow the guidance to set up the integration from here: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/power-platform/admin-reference
Technical architecture
For virtual entities in Common Data Service for Finance and Operations, the solution does not only support read operations but the all of the CRUD (Create, Read, Update, Delete) operations. To complete the set of operations we have available, we also get the possibility to execute OData actions of the F&O data entities through the virtual entities. From technical perspective, the virtual entity solution for Finance and Operations doesn’t rely on OData protocol to connect with Finance and Operations. Instead, the engineering team came up with a separate Web API solution on Finance and Operations side. The virtual entities plug-in in Common Data Service connects and interacts with the new Web API securely. By using the separate API solution, we’re not stressing the OData API with additional workload. With the separate Web API, the system can better deal with the translations of different languages that the Common Data Service and Finance and Operations talk.
On general release, the virtual entities solution already takes into account application lifecycle management seriously. The packages that form the whole solution are managed solutions. Virtual entities can be added, dropped or updated as the catalog that keeps track of the F&O data entities is also virtual and there’s a solution that is responsible of refreshing the catalog. As the solutions in the Power Platform are managed, anyone can take dependencies on them. Read more about the application lifecycle management from here: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/power-platform/application-lifecycle-management
Virtual entities can also have relationships to both native and virtual entities in Common Data Service. The integration utilizes and respects the metadata (including relationships between entities) that are given to the data entities in Finance and Operations. Labels, enums, company codes, calculated fields – those are all available and supported by the integration. Relationships between entities are generally supported out-of-the-box, but for ‘virtual entity from F&O to native entity in CDS’ -relationship, you need to put some effort to establish the relationship, because it’s something that the solution itself can’t do on your behalf. Other way around, establishing a relationship native entity to virtual entity is like creating native entity to native entity relationship, which is really a basic scenario.
For error handling the virtual entity solution uses the business logic that is in Finance and Operations. Upon saving a record through virtual entity, Finance and Operations executes its business logic like it normally does however we are interacting with it. If the data operations or OData actions result to an exception, the error message from Finance and Operations is caught and sent as a response to the action back to the virtual entity and to the user.
More on the entity modeling of the integration can be read from here: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/power-platform/entity-modeling
The impact
Virtual entities in Common Data Service for Finance and Operations as a solution enables many things that weren’t possible before. First of all, we are able to use virtual entities as data sources for model-driven applications. Say, we’re looking at Accounts in Dynamics 365 Sales. We are able to create a view that shows the account’s transactions in a ‘gridview’ on the account form, the data is read from Finance and Operations through a virtual entity. No data integration whatsoever was needed to be built between Finance and Operations and Common Data Service to achieve this.
We are now also able to create a Power Portal that can display data from Finance and Operations through the virtual entities. That is remarkable given the fact that the users can also perform CRUD operations towards the data and, if updated in the portal, the validated data is updated directly to Finance and Operations. Oh, and Power Portals and virtual entities support anonymous interaction also. Although, that use case scenario needs to be addressed in Finance and Operations to make it work correctly. Read more about it from here: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/power-platform/power-portal-reference
Virtual entities can be also consumed through Power Apps Canvas applications, Power Automate and Power BI, which were already able to connect with Finance and Operations through the other integration capabilities, like through the Finance and Operations connector.
Now it’s also possible to feed Finance and Operations data directly to AI Builder through the virtual entities. Now imagine that. The AI capabilities that we have on Power Platform can be used on Finance and Operations data directly through the virtual entities.
Demo #1
To highlight the power of the virtual entity capability, I’ve built a model-driven application, where I’m going to use Sales Order Headers V2 and Sales Order Lines V2 data entities (both native in Finance and Operations) as virtual entities in Common Data Service to display sales orders for company USMF and the related sales order lines. I’ve enabled both of the data entities in Common Data Service by making them ‘Visible’.
For the main view, I created a customized view to display the sales orders. The records were read from Finance and Operations, when I opened the view.
I’ve customized the main form of the Sales Order Headers V2 entity to include a new tab called Sales order lines. When the tab is opened, using the relations between the two entities, the system fetches sales order lines that belong to the selected sales order.
The system automatically brought also “New Sales order lines …” -button. When I click the button, I can give details for the new sales order line. In this demo I only give the item number for the sales order line to demonstrate some things. Now, for this form, I didn’t put any logic behind that would fetch the next number from a number sequence or fetch the sales order number and the company from the previous context, so I need to fill out the Lot ID, the sales order number and the company as well.
Upon saving, the record is actually saved to Finance and Operations, because we are interacting with a virtual entity. Again, the Common Data Service doesn’t store the data of virtual entities. When saving a new record, or updating an existing one that resides in Finance and Operations database, Finance and Operations performs validation checks and executes other connected business logic also. Besides the usual identification values for the record, like lot, company and sales order number, I also sent item number. Usually, when you create a new sales order line in Finance and Operations and give it an item number, plenty of other values are automatically filled by the underlying business logic, when you save the record. The same logic is executed and the same other values are automatically assigned to the record even if I save the record from a model-driven app using a virtual entity.
Demo #2
To highlight that the virtual entity solution is a Power Platform solution and not bound to just some applications within the platform, I created a canvas app in Power Apps, where I replaced the F&O connector with virtual entity data sources.
As you are able to see, the data sources show as Common Data Service entities like those were native in there. But no. Those are virtual and the data is fetched on each screen update in the Power App from Finance and Operations through the virtual entities.
All of the fields from Finance and Operations related virtual entities have their names constructed so that it begins with mserp_<name of the field>, like mserp_dataareaid.
Besides sharing the application to mobile devices of the users or as a desktop application, this application could very well be embedded to Finance and Operations workspace. So, this, in a way, is another approach of creating customized view for Finance and Operations, where the form and the functionality is created on Power Apps and the data is coming directly from Finance and Operations through the virtual entities. Then, the users can use that same application wherever they like: on mobile phone, tablet, desktop, Finance and Operations workspace, Microsoft Teams, you name it.
Final words
Thanks for reading this far. I felt that it was important to look at what is the history and the tools and services we have available today in order to highlight what really was missing and which are the scenarios the virtual entities functionality is targeting at.
I’ve been referring to the documentation of the feature throughout this blog post. That is, because the level of quality in this documentation is remarkable and if you want to learn more, definitely look at the documentation and try the functionality by yourself: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/power-platform/overview
The virtual entities solution is generally available in July 2020.
Stay tuned for the second part of this blog post series, where we approach this topic from a different angle.
Sami Pappila
Partner Technical Architect for Business Applications
Microsoft Western Europe
Connect: https://www.linkedin.com/in/samipappila/
Dynamics Sharks Blog 
Leave a comment