Exam PL-400 topic 1 question 15 discussion

It has to be the opposite. 1. Custom Connector (Virtual Entities have to have GUIDs or you won't create relationships in CRM) 2. Custom Connector (Virtual Entites are still readonly in CRM) 3. Virtual Entity (Will appear anywhere, it is another CRM entity just different data source)

As of July 2023. Based on testing results by myself. 1. Virtual Table - I was able to create a custom table using SQL Server with primary key as Integer. 2. Virtual Table - Virtual Table was able to handle both read and update out-of-box. We don't need to implement any plugin as get the external system updated. 3. Virtual Table - Virtual Table can be accessible accross all the Dataverse clients. This might be because MS is continously improving the capabilities of Virtual Table.

Analysis: 1. Support records that use integer as primary key Virtual Tables require GUID (uniqueidentifier) as primary key, since Dataverse natively uses GUIDs as primary keys. GUID IS NOT AN INTEGER!!!! Custom Connector can support any data schema because it directly connects to external APIs and can map data accordingly. Answer: Custom Connector 2. Ensure data can be read and updated Virtual Tables can be read and updated if the provider supports it, but many virtual table providers are read-only or have limited write support. Depending on the external system's API, Custom Connectors can be built to read and write data. Answer: Custom Connector (better support for read and write) 3. Ensure data is available to all Microsoft Dataverse clients Virtual Tables appear as native tables in Dataverse, so they are accessible in model-driven apps, canvas apps (via Dataverse connector), Power Automate, etc. Custom Connectors require explicit use and don’t expose data as native Dataverse tables, so integration with all clients is limited. Answer: Virtual Table

1-Support records that use an integer as a primary key: Custom connector Custom connectors are used when integrating with external systems that might use integer-based primary keys. Virtual entities usually rely on Dataverse’s own primary key structure (GUID), making a custom connector more suitable for this requirement. 2-Ensure that data can be read and updated: Custom connector Custom connectors allow for bidirectional data communication, meaning they support both read and write operations on external systems. Virtual entities are typically read-only unless customized or extended, so the Custom connector is the best choice here. 3-Ensure that data is available to all Microsoft Dataverse clients: Virtual entity Virtual entities allow external data to be accessed just like native Dataverse records. They are visible across all Dataverse clients but do not physically store data in Dataverse itself, ensuring easy access from Dataverse applications.

It has to be the opposite. 1. Custom Connector (Virtual Entities have to have GUIDs or you won't create relationships in CRM) 2. Custom Connector (Virtual Entites are still readonly in CRM) 3. Virtual Entity (Will appear anywhere, it is another CRM entity just different data source)

1. Custom Connector 2. Virtual entity 3. Custom Connector

Correct

VE, CC, VE

Well, looks like the correct answer is correct: 1 - VE. Here you can take a look - integer can be used as a PK for VE.(https://learn.microsoft.com/en-us/power-apps/maker/data-platform/limits-tshoot-virtual-tables?tabs=sql#for-each-data-source) 2 - VE. Looks like now VE can support CRUD. This is not a limitation now. (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/virtual-entities/get-started-ve#limitations-of-virtual-tables) 3 - CC (but I'm not sure). Because you need to use it in every client.

GUID is integer…???

C is definatly CC a canvass app can connect to DV so is classed as a DV client, but you cannot connect to a vitual DV entity, so you would need the CC to go between

VE VE CC

1. custom connector - you can create custom connectors in Power Apps and Power Automate that support records with integer primary keys. 2. custom connector - you can create a custom connector in Power Apps and Power Automate that allows data to be both read and updated. 3. virtual entity - Yes, virtual entities in Microsoft Dataverse (formerly known as Common Data Service) are designed to ensure that data is available to all Microsoft Dataverse clients.

Source: https://learn.microsoft.com/en-us/power-apps/developer/data-platform/virtual-entities/get-started-ve 1. Custom Connector - All tables in the external data source must have an associated GUID primary key. 2. Virtual Entity - Full CRUD operation is now supported for custom virtual table data provider. Full CRUD operation is now supported for custom virtual table data provider. Developers can implement plug-ins and register them using the Plug-in Registration tool for each of the CRUD operation supporting the virtual table. 3. Virtual Table

Item 1 can not be virtual table "All tables in the external data source must have an associated GUID primary key."

1. Is Virtual Entities, SQL can either use a guid or an integer. https://learn.microsoft.com/en-us/power-apps/maker/data-platform/limits-tshoot-virtual-tables?tabs=sql

The answers are correct. 1 and 2 you can use virtual entities See this link https://learn.microsoft.com/en-us/power-apps/developer/data-platform/virtual-entities/sample-ve-provider-crud-operations In fact you can not use the custom connector, The 3 item is custom connector, because you can not avaible on all dataverse with virtual entity.