How to use Azure Functions to extend Power Platform - Part 3

As already described in my previous articles on Azure Functions, I am currently studying for the Azure Developer certificate (AZ-204) from Microsoft. To consolidate the knowledge I have learnt, I am writing blog articles on relevant topics. In my day-to-day work, I mainly deal with business applications that are implemented using the Microsoft Power Platform or Microsoft Dynamics 365 CE. As a result, I always try to bring the Azure technologies that can be used for the development of applications into the context of the Power Platform or Dynamics 365 CE.,

One relevant reason why I work with Microsoft technologies in the first place is the possibility of closely interlinking a wide variety of tools in order to implement an innovative business application that creates added value. Microsoft Azure is the basis for Microsoft Dynamics 365 and the Power Platform. All low-code tools and first-party apps are hosted on Microsoft Azure and utilise Microsoft Azure functionalities in one way or another.,

In the following, I will describe scenarios where the use of Azure Functions in the context of Microsoft Power Platform or Dynamics 365 CE applications can be worthwhile. Many of the possibilities described are also possible with low-code tools such as Power Automate or Azure Logic Apps. This article makes no judgement as to whether the use of ‘real’ programming or low-code is better or worse for the scenarios. As always, the following applies to me: use the technology that makes the most sense for your application scenarios and resource availability.,

Quick refresher on Azure Functions

Integration with third-party systems

In a productive operation, a business application is usually not a monolith acting on its own. In most cases, the systems are integrated into an existing IT landscape with existing applications. These different applications are often responsible for sub-steps in a business process, which means that data must at least be synchronised between the systems or functions from one system are called up by another system. Azure Functions are a tried and tested tool when it comes to integrating applications that run on the Microsoft Power Platform with other systems. In theory, a distinction is made between inbound integration and outbound integration. With inbound integration, a message is sent from a third-party system to our Power Platform or Dynamics 365 application for processing in order to update data or call a function. With outbound integration, we tell a third-party system that it needs to do something. Azure Functions can be used to map both scenarios.

Let's assume we have developed a fundraising system for a non-profit organisation in which, among other things, donations are to be recorded that can be received via different donation channels, for example a bank or online payment service provider. In this scenario, our system must be able to process the transactions from both the bank and the online payment service provider. Here it is possible to use an Azure Function to implement integration with the online payment provider by sending a message when a new online donation is received in a dedicated queue (Azure Service Bus). This message is received by an Azure Function and the information it contains is transferred to the target data model of our application and finally a data record is created in Dataverse. The Service Bus does not necessarily have to be connected between the third-party system and the Azure Function.

In the above scenario, where the Azure Function is used to create and book an incoming donation from a third-party system in our fundraising system (inbound integration), another Azure Function can be used to inform the third-party system that the donation has been booked. In this scenario, a WebHook is registered on the relevant system event in the Power Platform environment. This WebHook then calls a second Azure Function that performs all the relevant transformation steps to record the booking in the payment system. In the best case scenario, the payment system provides an API that can then be called from the Azure Function.

Outsourcing of resource-intensive or time-controlled tasks

As Power Platform developers, we are all familiar with the limitations we are subject to when writing a plugin or custom workflow activity. All operations must be performed within the two minute limit. Furthermore, Microsoft advises against using parallelization within the code extensions, as this can lead to unwanted behavior. If you are implementing a requirement that is likely to require a lot of resources or has the requirement to perform tasks in parallel, it is advisable to use Azure Functions. Depending on the use case, the Azure Function can then be started either by a ribbon button via an http call or by executing a plugin/webhook. An Azure Function hosted on a consumption plan can run for up to 10 minutes. In addition, the option of parallelization can be used within an Azure Function instance.

In the context of the fundraising system, for example, the calculation of target groups for donors is a good use case for the use of Azure Functions. Donors are usually divided into target groups (mid-level donors/major donors/...) by non-profit organizations based on their donation behavior in the last X years. When defining and calculating the target group, relevant donation items and direct debits must be queried and then a complex logic must be carried out to calculate the current target group. Doing this within the fundraising system creates unnecessary load on the system.

Regularly starting a background activity that runs every X hours is also not possible with the standard tools of the Power Platform and Microsoft Dynamics 365 CE. Azure Functions are also suitable for this, as they can be started automatically based on a schedule.

Executing complex workflows

Developers who are still familiar with older versions of Microsoft Dynamics CRM know how time-consuming it can be to implement complex workflows that execute several steps in a sequence. The classic workflows within the Power Platform are not intuitive to create and reach their limits at a certain level of complexity. Of course, it is possible to extend the classic workflows with the help of custom workflow activities, but Microsoft itself now advises against using them. With the help of Power Automate, users are also able to implement complex workflows and Power Automate has a variety of options that make almost any scenario possible. Above a certain size and complexity, Power Automate also becomes difficult to maintain and confusing. Azure Durable Functions is an extension of Azure Functions that can be used to implement state-dependent workflows. There are different application patterns for Azure Durable Functions. Today we are focusing on function chaining. In function chaining, there is an orchestrator function that calls subordinate Azure Functions one after the other. The Azure Functions can exchange information with each other, for example by working on a shared function context.

To remain in the context of our fundraising application, a potential application scenario here is the processing of entries from CAMT files (standardized format for transferring bank transactions). An entry in the CAMT file contains, among other things, information about the donor and the intended use. In a Durable Azure function for transaction processing, the orchestrator function can first call a sub-function “Identify donor”. This function saves the donor in the shared function context. Another function “Identify donation purpose”, which is called after the first function, attempts to extract a donation purpose from the purpose of the bank transaction and, if successful, also saves this in the shared function context. Further functions can be called according to this principle.

Summary

In this blog article, I described various application scenarios in which I think it makes sense to use Azure Functions. I discussed the following three cases:

• Integration with third-party systems: Azure Functions can be used to build interfaces between third-party systems and apps that run on the Power Platform.
• Outsourcing of resource-intensive or time-controlled tasks: The Power Platform has limitations that restrict the runtime of code components. If it is foreseeable that a requirement is very time-consuming, it is advisable not to implement it in the Power Platform itself. Furthermore, there are no mechanisms that start time-controlled tasks
• Executing complex workflows: With the help of Azure Durable Functions, we have a modern tool alongside Power Automate or Azure Logic Apps that can be used to map workflows.