Sub Title

Tuesday, February 14, 2023

Brief Idea for Navigate To Enhancement in Microsoft Dynamics 365Dataverse

 Microsoft Dynamics 365/Dataverse has been a popular platform for businesses to manage their operations, customer relationship management, and financials. The platform provides various tools and features to help businesses streamline their processes, improve efficiency, and make data-driven decisions. One of the key features in Dynamics 365/Dataverse is the NavigateTo() method, which allows users to easily navigate to different areas of the platform, including records, forms, and pages.

Recently, Microsoft has made some enhancements to the NavigateTo() method in Dynamics 365/Dataverse, making it even more powerful and user-friendly. Here is some of the new enhancements to the NavigateTo() method in Dynamics 365/Dataverse:

Improved Navigation: The NavigateTo() method now provides a more streamlined navigation experience for users, making it easier to access the areas of the platform they need. The new navigation options allow users to jump to specific records, forms, or pages with just a few clicks.

Better Performance: The NavigateTo() method has been optimized to improve its performance, making it faster and more responsive. This will make it easier for users to access the information they need, reducing the time it takes to complete tasks and making the platform more efficient.

Enhanced Customization: The NavigateTo() method now supports customization options, allowing developers to tailor the navigation experience to meet the specific needs of their organization. This will allow businesses to create a more personalized experience for their users, making it easier for them to access the information they need.

Improved Security: The NavigateTo() method has been enhanced to include improved security features, making it even more secure. This will ensure that sensitive information is protected and users can access only the information they need to complete their tasks.

Use Case:

I want to determine which Business Process Flow should be accessible by default when I open an entity record, and I also want to enlarge the currently active stage.

In this example, I'm utilizing the Lead entity, which has two Business Process Flows enabled for it, with Lead to Opportunity Sales BPF as the default BPF.

When you create a business process flow in CRM, a new entity with the name of the business process flow is created in the background. All data pertaining to the business process flow is kept in this entity. In this case, we would need the BPF Process Id, BPF instance Id, and Active Stage Id values from the Business Process Flow entity fields to open the BPF records. I am now utilizing the Dynamics 365 endpoint API to obtain the required value.

Below is the sample code that you can use to achieve this

function openRecordBPFUsingNavigateTo(){
  let pageInput = {};
  let navigationOptions = {};
  try {
   pageInput = {
    pageType:"entityrecord",
    entityName:"lead",
    entityId:"Lead Record Id",
    processId:"BPF Id",
    processInstanceId:"BPF Instance Id",
    isCrossEntityNavigate:true,
    selectedStageId:"Stage Id"
   }
   navigationOptions= {
    target:2,
    height:{ value: 70, unit: "%" },
    width:{ value: 60, unit: "%" },
    position:1
   };
   Xrm.Navigation.navigateTo(pageInput,navigationOptions).then((success)=> { 
    //Code which you want to execute on success
   },(error) => {
    //Code which you want to execute error to handle on exception
   });
  } catch(error) {
   //Code which you want to execute error to handle on exception
  }
}




To know more about the attributes used, please follow this link.

In conclusion, the enhancements to the NavigateTo() method in Dynamics 365/Dataverse will provide a better user experience, improve performance and make it easier for businesses to access the information they need to drive their operations. These enhancements will help businesses take advantage of the power of Dynamics 365/Dataverse and make data-driven decisions to improve their business outcomes

Wednesday, February 1, 2023

Performance Improvement in FetchXml Request

Overview:

We will discuss the common issue that we usually face in our projects. We have slowness of the application, and most of the time, it's identified that we had a FetchXml request that we are using to sync with the Microsoft Dataverse.

Introduction:

When working on dynamic projects, we usually use an easy way to query and execute the FetchXml to get the results. For the construction of the FetchXml, we mostly used Advance Find, and also we can use the Xrm Toolbox for building a FetchXml.

The most common issue we faced was the slowness of the FetchXml query as we moved toward the complexity. There is a way that we can use to resolve this issue.

How to improve the slowness:

The traditional fetch will pull all the columns for the top table records given in the filter criteria. For example, we query to pull 500 records from the table containing 100 columns and 100000 approx. Rows that meet the filter criteria. This case will give us the following issues.

·         To return the result set of 500 records, it pulls almost 99500 rows with all columns and then returns 500 rows.

·         Optimizer for the query can generate an arbitrary order when using the child columns for the retravel but result in a data order we don't want to use.

We can use the LateMaterialize option in the FetchXml request to resolve the slowness issue. It will break the request into smaller, usable segments, improving the performance of long-executing FetchXml requests. The improvement mostly depends on the data distribution for each table and link table used.

After using the LateMaterialize, the created fetch will.

·         Only pulling the primary ID of the top number of records given in the query also fulfilling the filter criteria.

·         Retrieved on the needed data column based on the primary IDs given on the filter criteria. Like if six columns are needed in the given query. It will on retrieving them.

Example for using LateMaterialize in FetchXml:

<fetch version="1.0" output-format="xml-platform" latematerialize="true" mapping="logical" distinct="true">

                <entity name="[entity]">

                                <attribute name="[attribute]" />

                                <link-entity name="[entity]" from="[linked entity]" to="[linked entityid]" link-type="outer" alias="[alias]">

                                                <attribute name="[name of linked entity column]" />

                                </link-entity>

                                <filter type=[filter type]>

                                                <condition attribute="[column]" operator="[operator]" value="[value]"/>

                                </filter>

                </entity>

</fetch>

 

Above is the sample we can use to modify our FetchXml query to resolve the optimization issue.

<fetch version="1.0" output-format="xml-platform" latematerialize="true" mapping="logical" distinct="true">

                <entity name="account">​

                                <attribute name="accountnumber" />​

                                <attribute name="createdby" />​

                                <attribute name="ownerid" />​

                                <link-entity name="account" from="accountid" to="parentaccountid" link-type="outer" alias="oaccount">​

                                                <attribute name="createdby" />

                                                <link-entity name="account" from="accountid" to="accountid" link-type="outer" alias="oaccount1">​

                                                                <attribute name="createdby" />​

                                                                <attribute name="accountid" />​

                                                                <attribute name="name" />​

                                                </link-entity>​

                                </link-entity>​

                                <link-entity name="account" from="accountid" to="accountid" link-type="outer" alias="oaccount2"/>

                                <filter type='and'>​

                                                <condition attribute="statecode" operator="eq" value="2"/> ​

                                </filter>​

                </entity>​

</fetch>

 

So, with the above FetchXml, we are almost retrieving the account hierarchy. As a developer, we know that if we use the self-referential relationship, it will affect the performance of the project badly. Still, by using LateMaterialize, we can resolve that issue.

LateMaterialize is the most beneficial.

·         Query where there are one or more linked conditions to other tables, and their columns are used for the data.

·         Query where there are tables that have many columns and logical columns.

I hope this will be helpful.

Thanks.

Conclusion

So, in this blog, we give you an option that can be utilized to resolve the performance-related issue faced while using FetchXml in the project.