Azure Function integration with Dataverse

In the world of Power Platform and Dynamics 365, knowledge of Azure has become an almost fundamental resource to achieve a seamless integration and unlock the full potential of the ecosystem that Microsoft offers. As many of you know, Dynamics Plugins have a two-minute runtime limit, which is adequate in most cases, but may be insufficient in more complex and demanding scenarios. In this article, we will explore in detail the process of creating an Azure Function from scratch, opening a world of possibilities to extend the capabilities of Dynamics and Power Platform. In addition, we will show how to associate this Azure Function to a Dataverse Webhook so that it is automatically executed when an event of interest occurs.

For the creation of our Azure Function, it will be necessary to have Visual Studio installed, since the well-known Microsoft SDK will be used to interact with Dynamics (we must make sure we have the Azure development workload installed) and an Azure subscription. In my case, I am going to use the subscription that includes the Visual Studio Enterprise license. Once we have that subscription, we will go to the Azure portal and create or choose the resource group where we will create our Azure Function. Once located in the resource group, we will search in the Marketplace “Azure function” and select the option shown in the following image.

Next, it will be necessary to configure a series of mandatory parameters for the creation of our Azure Function such as those shown in the image and which will be explained below.

• Resource Group: Container in which several Azure resources are hosted.
• Function Application Name: Name of our Azure Function, this name must be unique.
• Runtime environment stack: Language in which the Azure Function will be implemented. I recommend using .NET Core because it is an enhanced version of the .NET Framework.
• Version: Version of the environment stack. In my case I have chosen version 6 of .NET Core as it guarantees long term support.
• Region: Location where our Azure Function will be hosted. Choose the closest possible location to the server to ensure shorter waiting times.
• Operating System: In my case I have chosen Windows as it integrates seamlessly with .NET as it is a language developed by Microsoft.

In addition, it will be necessary to configure at least one storage account associated with our Azure Function. It is also advisable to create an Insights application to have records of calls to our Azure Function and monitor if any error occurs or any other information that is considered relevant. Once this process is completed, we will proceed to create our Azure Function.

Now it’s time for the implementation and publication of our code. Let’s create a new project in Visual Studio and select “Azure Functions” as project type.

We will choose the location of the project and configure it with the parameters as shown below.

• Function Worker: This parameter refers to the execution environment where our Azure Function will run.
• Function: Defines the trigger or event that will activate our Azure Function.
• Authorization level: This parameter sets how requests to our function will be authenticated. It can be set to “Function” (where a function key is required to access) or “Anonymous” (where no authentication is required).

By clicking on the “Create” button, Visual Studio will generate the project and a default function called “Function1” with an example code in the previously chosen language.

Next, we will proceed to install the Nuget Microsoft.PowerPlatform.Dataverse.Client in the project, which will allow us to connect and interact in a simple way with our Dataverse environment.

Once this Nuget is installed, we will proceed to the implementation of the code. On this occasion, a simple example functionality will be developed. Although there are other better ways to approach this task, this option is ideal for demonstration. The idea is that, when creating a new account in Dataverse, our Azure Function will be invoked and will get the data of that account from the execution context just as it would happen with a Plugin. The function, in turn, will be responsible for creating a new contact with the name “Contact of {account name}”.

Below are images with the code that performs this functionality:

Once all the code is implemented, we will proceed to publish our function in Azure. To do this, we will select the “Publish” option in our project and choose from the Azure subscription our Azure Function created in previous steps.

A series of configurations will be loaded and when everything is correct, we will choose the “Publish” option as shown in the following image.

With our Azure Function already published, we will return to our Azure Function in the Azure portal. We will enter the implemented function (in my case Function1) and in the “Code & Test” tab we will get the url of the function.

By copying this url, we will get a link consisting of the “endpoint” of the Azure Function, the name of the function we want to invoke and a section called “code”. The latter will act as a necessary authentication method, otherwise any system could access this function as it is public.

Example:

https://azurefunctionaxazureblog.azurewebsites.net/api/Function1?code=yK3b0LupPZYxrISdTDyaBITs3Zkk6RZGaP0hMBWJ0k-YAzFuhu4iB==

Finally, it only remains to associate our Azure Function to the event we want Dataverse. In this case, the creation of accounts. To do this we will go to the Plugin Registration Tool and register a new Web Hook.

We will add the name we want, the endpoint of our Azure Function and the configuration parameters. In this case we will use WebhookKey and the code previously generated in Azure.

Once created, the only thing left to do is to add the desired Step as if it were a Plugin.

Finally, we only need to test our Azure function and verify that it works correctly. To do this, we will go to our Dataverse environment and create an account.

It is possible that the creation of the contact may take a little while since it is an asynchronous procedure, but since it is a simple and inexpensive implementation it will not take long. Finally, we will return to our application to verify that the contact has indeed been created correctly.

As a conclusion, it is relevant to highlight that in this instance an approach focused on a Dataverse event has been adopted. However, this same approach can be applied to a variety of different situations, thus evidencing the unlimited potential offered by Azure Functions.

I hope this information will be useful to many, serving as an introduction to the fascinating world of Azure with a focus on Dynamics/Power Platform and unlocking endless possibilities