Testing The Waters Is Better Than Drowning in the Pool! isn't it so? 🏊♀️
Long story short, there are two sets of Data entities in Dynamics 365 FO.
- Standard data entities
- Dual-write specific data entities (Postfix as CDSEntity)
The core purpose of having these categorizations is to manage, simplify & better control ALM, CE & ERP-related business scenarios, External party integration, or some processes that required some additional logic to be called to handshake with other downstream processes.
How Does It Work Under The Hood?
This is more about how data entities are designed in Dynamics 365 FO.
Dynamics 365 FO data entities are more complex since they encompass a wide range of data sources.
Furthermore, each data source could result in multiple tables. During a transaction, most processes should be performed within the context of the table, not within individual data entities.
A dual-write identifies whether a certain table is affected by a change on a certain form, for example, the customer form. When changing the customer form, changes are made to the customer table, addresses, and retail account tables.
As a matter of fact, it does not use the data entity, but rather it changes the table. Due to dual-write, this process recognizes that these two or three tables that have changed during the process relate to the CustCustomerV3Entity entity, and that they have all been modified to correspond to records in the CustTable entity.
In order to do this, it tries to find out table relations and determine what all final entities' records have been affected. In other words, the more maps or cross-data sources you have, such as DirPartyBaseEntity etc. In other words, databases are hitting the same type of record multiple times for different types of data.
Therefore, editing one global address book record could result in editing more than one entity, causing more than one entity on the Dataverse to be affected.
Thus, it is always recommended to create data entities as thin as possible from a Dual-write perspective.
It is worthwhile to use newly released light weight Data entities in the context of above scenario i.e., CustCustomerBaseEntity (Customer definitions), CustCustomerDetailV2Entity (Customer details V2)
What To Consider While Designing Dual-write Data Entities?
- Create a custom data entity with only the required data sources (tables) and enabled the required fields
- Remodel the Data entity in Dynamics 365 FO to remove unused data sources and tables or implement getEntityRecordIdsImpactedByTableChange to optimize the runtime queries
- Avoid using the same table which is being tracked by multiple data entities because any change to the table will trigger a Dual-write evaluation for the linked Data Entities
- In the event that point no. 3 is unavoidable due to business processes, you should consider simplifying the entity or evaluating query optimizations for data entities
- Read-only and outer join data sources should be removed since they cannot be tracked
- Data sources without any fields mapped should be removed, as these will not be tracked
- Data sources (tables) that are mapped must be registered with business events
Additional tips: 💪
Dynamics 365 FO will trigger the changes only if the fields mapped to the records were modified. However, Dynamics 365 CE and Power Apps trigger all field modifications in Dual-write.
I hope this article was a good read for you. Do share it with your friends and other peers.
Thank you for Reading - Let's Connect!
Enjoy my blog? For more such awesome blog articles - follow, subscribe and let's connect on LinkedIn, Twitter, YouTube
Stay tuned!
