Lack of Information in Error Log File UCI Form

Many times, it happens that we get an error or exception message while working on the Dynamics 365 UCI form.

So, to get more information related to the error we download the Log File.

Now at this point of time we struggle to find the information related to error while working on the UCI form.

Below is the comparison between an exception error that will come between UCI form and Classic form.

The reason why I am showing this comparison is because when we download the error Log File on both of the form, we don't find plenty of information in the Log File downloaded on the UCI form.

But in the Classic form we find enough information.

Below is the comparison of generated Log file between UCI form and Classic form.

Above screenshot contains the error related to the external assembly registered i.e. “Newtonsoft.Json”.

Note:  Due to the SANDBOX isolation mode in all MS CRM online versions, registering an external assembly require Merging. Refer: Merger External Assemblies.

Solution

An alternate solution is to enable Trace log and read the error from Plug-in Trace log.

1. Go to Setting -> Administration->System Settings.

2. Go to Customazation and select Exception.

After doing this, whenever we get any Exception, we can go to Plug-in Trace Log and see the error record.

3. Go to Settings -> Plug-in Trace Log.

4. Open the record.

Below is the last Exception Record that was created when we get an Exception error on my screen.

After opening above record we get enough detail as we were getting in Classic forms.

Happy Learning, LET'S SHARE !

Get N: N relationship records in Canvas App using CDS/Dataverse – Power Platform

Note- We have to use Dataverse connector instead of CDS now, steps would be same.

Scenario –

Let us assume there are two entities with N: N Relationship and we need to show the related records on Canvas App.

Lets get started.

1.  Entity Design

Entity 1 – First (Project records are stored in this entity)

Entity 2 – Second (Resource records are stored in this entity)

Relationship – N:N

We associate few Resources to Project in CDS as below-

Now we want to visualize this data in canvas app. Let us see further steps.

2. Enable Entities for Change Tracking

We need to enable change tracking for both the entities to access N:N data.

First Entity- This store Project Records

Second Entity - This store Resource Records

3.  Create canvas app 

Go to https://make.powerapps.com/, click on “Create”, select Canvas app from blank.

We will see a blank screen to which we will add controls from the ribbon

Our screen is ready.

4. Attach data source to canvas app.

Click on Project dropdown and in the Properties window provide entity and column you want to display in the dropdown.

Click on Resources Datatable and data custom data source from the formula bar –

To add columns to the Datatable select the control, go to properties, click “Edit fields” and add required fields.

All done, Let’s run the app.

Output – On selection of Project, only associated records shown in the Datatable.

Happy Learning, LET’S SHARE!

Replicate Data to Azure SQL Database - Part 2

Previous Post - Validate Data Export Profile

In this part we will replicate data to Azure SQL Database using Data Export Service profile that we have validated in Part 1 -  Validate Data Export Profile.

We will also see how Data Export Service makes transactional data (frequently updated data) easily replicates to Azure SQL Database.

1. Assuming Data Export Profile validation is successful in previous part - Validate Data Export Profile(LINK), click Next button and select entities whose data we want to replicate.

Note: if the required entity is not coming in the search list then you need to enable Change Tracking in the Entity properties.

2.    Select the Relationship, if exist.

3.    Select Next and Activate the Data Export Profile.

For Example, we use 2 entities i.e. ics_child and ics_subchild.

4. Refresh the Data Export Profile after some time.

Whooaaaaaa! We have successfully replicated the data of 2 entities i.e. Child and Sub Child to the Azure SQL Database. 

5. Let’s go to the Server Explorer and see our data.

Here we can see our both Entities that we have selected for replication in Step 1.

6. We will see the records (rows) in SQL DB.

So here they are. This is how Data Export Service Works.

We don’t have to be worry about the transactional data (frequently created or modified). The replication of data will occur at the same time when there will be any record modified or new record is created in the Common Data Service.

We can also see the analytical figure of our data in Azure Portal by going to the Database (DataExportServiceDB).

Stay Tuned for more Updates.

For more information, visit-

https://docs.microsoft.com/en-us/power-platform/admin/replicate-data-microsoft-azure-sql-database

CRM SDK Feature – Entity Change Tracking

 The aim of this topic is to make a clear understanding of what is Entity Change Tracking and how Entity Change Tracking works.

Many of us use AzureData Export Service in our daily business scenarios but we don’t know the logic behind Data Export Service.

I’m pretty much sure, we will get a clear understanding of Entity Change Tracking and DataExport Service and how they are related to each other.

Pre-Requisite -

•        Make a Console Application (.Net Framework)
•        Use RetrieveEntityChangesRequest SDK method

Business Scenario-

Let’s say we have a requirement that dictates to retrieve those records that are recently created or modified in CRM Entities.

In such case, where our CRM is the source, we use fetch xml query to retrieve records. But what about the records which are modified recently. In such case we typically compare modified on date which is not a reliable solution and may not perform well when there are too many records in the source system.

Change Tracking is the feature to outplay in these scenarios.

Change Tracking feature offers a reliable and efficient way to track Transactional Data Changes for CRM Entities.

In other words, Change Tracking is used in Dynamics CRM to keep data synchronized in an efficient way by detecting what data has changed since the last data was synchronized.

Detection is done by DataToken. DataToken is the unique string that we get in Response from RetrieveEntityChangesRequest.

Let’s do it practically. We will use only 1 entity for better understanding.

Step 1 – Make a Console Application (.Net Framework).

Step 2 – Make CRM service as below-

Step 3 – Add a function “ChangeTrackPull()” as below.

Step 4 – We will call it in our CRM service.

Step 5 – Now go to the Entity property and Enable Change Tracking. Save and Publish.

Step 6 – We will go back to the Console Application and start debugging.

Step 7 – Below is the DataToken.

Step 8 – Now again debug the Console Application and stay on “response” to see the record counts.

The record count is 0 during the 2^nd pull. This means none of the record is newly created, updated or deleted. Let’s update any existing record.

Step 9 – Go the Entity and update any record. Again, debug the application.

We get 1 record count and that’s because we updated 1 record after previous pull.

The DataToken is also updated in the response that will be used in next pull of data. So, save it somewhere.

Now here is 1 more important point to learn. We get the following type of record after an initial pull.

•         Newly created or Updated record
•          Deleted record

Step 10 – Update a code to know the type of record we will get.

Step 11 – Again go back to the Entity and Create a New Record, then debug an application.

We get 1 record count. Let’s check the record type whether it is newly created/updated record or deleted record.

Step 12 – Jump to line 83 in Console Application.

It is the NewOrUpdated record. Let’s delete some records from the same entity and debug it again.

Before that copy the updated DataToken. We will use it in next pull i.e. after deleting some records.

Step 13 – Delete some records and debug.

Here we get 4 record counts.

Now we know, in above case we get change Type as RemoveorDeleted.

 For better understanding let’s check one by one whether they are updated or deleted records. We will check in the same way as we have checked in Step 12.

Note: The response will be EntityReference in case of deleted record.

Now I hope we get a clear understanding of Change Tracking. This same concept works while Replicating Data using Data Export Service in Azure.

Let's jump to Part – Azure Data Export Service

Validate Data Export Profile - Part 1

Previous Post - Introduction to Azure Data Export Service

Pre-Requisite -

• Install Data Export Service Solution in Microsoft Dynamics 365 (online) instance.

o   It is the bridge between Common Data Service Data and Destination (ex. Azure SQL Database)

• Only users with System Administrator in the Microsoft D365 instance can setup Data Export        Service Solution
• Azure Subscription (trial will also work).
• Need to get Dynamics 365 Organization ID and Tenant ID.

1. Go to AppSource and install Data Export Service Solution in the D365 organization.

2.  Select an Environment and click on Install.

3. It will be installed in few seconds.

4. After installation, go to the Dynamics 365 environment. We will find Data Export Sub Area in Advanced Settings.

We will use this after setup of all the components in Azure.

5. Login to Azure Portal - https://portal.azure.com/ and create new Resource group.

6. Click on Add button and search SQL Database.

7. Select and Create SQL Database.

8. Enter Database Name and Create a new Server.

Remember the UserName and Password.

9. Select the Pricing tier. Pricing Tier is based on the amount of Data needs to be replicated to the Destination Target sytem.

We will take as Basic for example.

10. Click on Create Button and wait until it gets deployed.

We can see the deployment progress in the notification on the top right corner. 

11. Now we can see our SQL Database and SQL Server in the Resource Group are deployed successfully.

12. Now we will test the connection of the Server “dataexportservertest” by connecting it with Visual Studio.

For this, we will open “dataexportservertest” server and setup fire wall setting.

13. Add Client IP. This will allow firewall to access this server on our system. Click on Save button.

Note: If we will try to access this server on some another system then we need to add IP address of that System. Otherwise we won’t able to access it.

The IP address of that system will be automatically added to it on which we have Azure Portal opened in that system.

14. Open Server Explorer in Visual Studio and add the add connection to the Server “dataexportservertest”.

Note: We can also create the server connection in SQL Server Management Studio.

15. Enter following details, Test the connection and click OK button.

Server Name: Copy from the server profile.

Authentication: SQL Server Authentication

User name and Password: Copied at the time of making new server.

Database: After entering correct information, Azure Database will automatically be mapped.

Successful connection will be made.

16. Now it’s time to make Azure Key Vault.

Before creating it, we need Connection String that need to be added while making Azure Key Vault.

Right Click the Azure Database and click Properties in Visual Studio.

Copy the Connection String. We will use this connection string when making Secret in Azure Key Vault. Make sure not to paste the password as ******.

17. We will go the Resource Group "DataExportService" and add Azure Key Vault.

18. Enter the Key Vault name, name everything else as default and then click on the Access policy.

19. Add on Add Access Policy button, select Secret permission as Get and add Principal as Data Export Service.

20. Click Review+Create > Create.

21. Now open the Azure Key Vault from the Resource Group Data Export Service and add Secret.

Value: Connection string that we have copied earlier. (Step 16)

22. Add Tag such that Name as Organization ID and Value as Tenant ID. Go to Secrets > Name > Current Version > Tags. Save Azure Key Vault.

23. Now we will copy the Secret Identifier. To copy it, go to the Secrets > Name > Current Version > Secret Identifier.

This Secret Identifier will be used while Data Export Service Profile setup in the Dynamics 365 environment.

24. Open Data Export Profile on Dynamics CRM environment and enter the Secret Identifier in Key Vault URL to validate.

Whooo! We did it. Now we can easily replicate the data to the Azure SQL DB.

Let’s jump to next part to Replicate Data to Azure SQL DB – Replicate data to Azure SQL Database – Part 2