Should You Learn CDS vs. Standard public data entities implementation approach First?

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

  1. Use standard public data entities (non-CDS) as it is

  2. Extend standard public data entities (non-CDS)

  3. 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!