Should You Learn CDS vs. Standard public data entities implementation approach First?
Let's look at some stats.
So you want to get into integration between Dynamics 365 CE or Custom Power Apps and Dynamics 365 FO. The question is, which type of Public Data entities are to be used from Dynamics365 FO?
As someone who's working on a list of integration approaches such as
1. Dual-write
2. Data integrator
3. Connector
4. API
Should I use Customers V2, Customers V3, or Sales Quotation Header CDS entity? What is the difference between these entities and tables?
It is always tricky to make decisions about which data entity to be used for the above-mentioned integration approaches, read on and I'll give you my thoughts.
If you deep dive more into available Dynamics 365 FO Data entities whether named with CDS or not under the hood it is connected with business transactions or master tables such as custtable, salesline etc.
As the world becomes increasingly reliant on digital platforms, it is more important than ever to ensure that application integration plays a vital role.
Integration technology is a vital component of Dynamics 365 FO and Dataverse (Dynamics 365 CE & Power Apps) such as Data connector, API, Dual-write and VirtuEntity.
There isn't a right answer, but there is a better one
Let's deep dive into CDS vs Non- CDS data entities artifacts and understand the purpose build business logic and metadata changes
1. SalesQuotationHeaderCDSEntity: The standard function/method "updatePrices" is used to invoke Odata actions via Dual-write
2. smmContactPersonCDSV2Entity: It has additional fields in comparison with standard public Data entities such as AssociatedContactNumber & AssociatedContactType
After learning the CDS data entities, one might say that it is not recommended to use CDS Data entities when there is no Dual-write infrastructure used and a possible reason may be
Use standard public data entities (non-CDS) as it is
Extend standard public data entities (non-CDS)
Build custom public data entities for tailored-made business processes
A CDS entities are lightweight, performance-optimized entity specially designed to integrate with Dataverse - it need not be done through Dual-write but can be done through other methods such as using Data Integrator or custom integration.
In a nutshell, There is no general best practice that recommends you use CDS vs Non-CDS entities, right? Nevertheless, you may choose the following option based on the fit/gap analysis for each interface:
Conclusion
It is important to note that the performance and effort required for each of these options will vary. Therefore, each entity's decision should be made based on business requirements by the project team.
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!
Subscribe to my newsletter
Read articles from Rakesh Darge directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Rakesh Darge
Rakesh Darge
This blog is my contribution to the Dynamics 365 Finance & Supply chain management & Power Platform community. Having worked with Axapta / Dynamics AX / D365 F&O for 18 years out of my 21 years of career in application development and ERP. I'm passionate about Dynamics 365 ERP, Power Platform & Azure integrations 💡. However, I tend to always look forward. So I mostly write about current subjects. My aim is that my deep thought may inspire some of you and provoke some new thoughts in the interest of our community. Please note, that the views expressed in this blog are mine alone and do not necessarily reflect the view of my employer.