The Low-Code revolution is currently being overshadowed by the latest developments in AI. This is somewhat understandable, since Low-Code is not nearly as revolutionary as the latest neural networks... or is it?
Online, it's often read that Low-Code and No-Code solutions can reduce development costs tenfold. I personally find this assessment a bit too optimistic. In my experience, however, one is often up to five times faster in development. While this does not reach the revolutionary impact of AI technologies, the value of such time savings should not be underestimated. Time is money, as they say.
One of the biggest hurdles in the area of Low-Code is limited adaptability. It is often claimed that with Low-Code solutions like the Microsoft Power Platform, only simple problems can be solved. This may have been the case in the past, but the platform has now reached a very good level of maturity and, thanks to the extension possibilities with Pro-Code components, almost anything can be implemented.
It is finally possible to digitize processes that until now had no "affordable" solution.
In this blog, I want to highlight the potential of the Power Platform in combination with Dataverse plugins. If you are a developer yourself and want to explore the advanced features of the Power Platform, you will find instructions for a modern developer workflow for Dataverse plugins at the end of this article.
Advanced Business Logic with Plugins
The development of PowerApps, which are based on Dataverse, opens up the possibility to use Dataverse plugins at specific points. These plugins are activated when interacting with Dataverse. Within these plugins, various operations can be carried out: connections to external APIs, data validations, or specific business logic can be implemented.
This elegantly connects the Low-Code and No-Code world with the Pro-Code world. Many limitations are thus overcome, and the best of both worlds can be used.
For example, for all standard components in a business app, such as authentication, security, the entire frontend, and all CRUD operations, the ready-made components of the Power Platform can be used. At the same time, more complex business logic can be extended using .NET and C# in the Dataverse plugins.
What about the frontend? Sometimes classic forms are not enough and the user-friendliness could be significantly improved thanks to specific UX/UI designs. There is also a solution for this: those who develop a Model-Driven-App can use so-called web resources and PCF components to develop their own components in the graphical user interface with JavaScript or TypeScript. This allows almost limitless expansion of the frontend where necessary.
Plugin Development
Dataverse plugins seem to be less widespread and known than the JS/TS web resources for extending the frontend. There are also fewer current resources on this topic. Most articles date from the time before Dataverse, as the plugins have their roots in the Common Data Service and in the Dynamics CRM platform.
Microsoft itself does not make it easy for developers to get started. If you follow the official MS Docs for plugin development, you are pushed towards the Visual Studio Extension. The user experience with this extension is quite poor, the tooling is faulty and often crashes Visual Studio. The user reviews of the extension are also not the best...
The other option presented in the documentation is the manual way, which requires too many clicks and manual steps in the development and debugging cycle. Ain’t nobody got time for hat.
There is a much better approach that is unfortunately not yet often represented in the docs, namely the use of the Power Platform CLI. There, a modern toolset is available that simplifies the development of such plugins and enables a modern workflow. Here is a small step-by-step guide for developing a Dataverse plugin in VS-Code with the Power Platform CLI.
Development Workflow
Requirements
First, the .NET Framework and the Power Platform CLI are needed. Note here that besides the latest .NET version, the .NET Framework 4.6.2 must be installed. After installing .NET, the Power Platform CLI can be installed with the following command:
dotnet tool install --global Microsoft.PowerApps.CLI.ToolPreparation
Let's start by creating a new solution in the portal, which we then download. For this step, we need the name of the solution and the environment ID. In this case, we take "DemoSolution" as an example.
pac auth create --environment ****.dynamics.com
pac solution clone --name DemoSolution
cd DemoSolution
dotnet build"dotnet build" automatically creates an unmanaged solution under bin/Debug/DemoSolution.zip.
Plugin Hinzufügen
Within the solution, we create a folder for the source files and simultaneously initialize a new plugin.
mkdir plugin-src
cd plugin-src
mkdir demoplugins
cd demoplugins
pac plugin init
code .This creates the framework for the plugin by adding the first empty plugin (Plugin1) and opens our solution with VS Code. It is important to note here that "pac plugin init" creates a solution that contains the first of potentially many different plugins. According to Microsoft, one should always bind a plugin to an action (Step) in Dataverse. However, many different plugins can be contained in this single assembly.
Now the class `Plugin1.cs` can be edited. As an example here, the given name on the Account Entity will always be overwritten with "Gotcha!".
It's best to rename the project, the namespace, and the solution as well, so that later sensible assembly names are created. Ideally, one should follow the following convention: Provider.Solution.Plugins.
Now we can compile our plugin with dotnet build.
We now need to add a reference to the plugin in the solution. From the solution folder:
pac solution add-reference --path .\plugin-src\demoplugins\For the plugin to be cleanly integrated with the solution, additional metadata is needed. Unfortunately, this is not added with add-reference. The easiest way to do this is via the portal during the first deployment.
Deployment
Open the appropriate solution with the Plugin Registration Tool (PRT) and register the plugin assembly in the solution:
pac tool prt
In the next step, select "Load Assembly" and choose the previously compiled DLL. Then select "Register Selected Plugins".
Store the the assembly ID here. We will need it later. You can find it in the properties tab at the bottom.
Now right-click on the plugin and add a step.
Now in the Maker Portal, within our Demo Solution, add the plugin and the step. Then don't forget to "Publish all customizations":
Finally we can download the necessary metadata from the Online Solution with a sync. After that, we can also export the entire solution locally.
pac solution sync
dotnet build DemoSolution.cdsproj"dotnet build" from the solution folder will now also compile the plugins. If we have done everything correctly, we should see the assemblies in the exported Solution.Zip.
Updates
Now we come to the interesting part, namely how to make changes to the plugin and transfer them conveniently to the environment.
The whole thing can be done very easily with a CLI command. However, since some information is required each time, I recommend creating a simple PowerShell script so that updates can really be uploaded with one click.
In the plugin folder, we create a Deploy.ps1 script with the following content.
$assemblyId= "ASSEMBLY_ID"
$pluginFile = ".\bin\Debug\net462\WorkframeDemoSolution.GotchaPlugins.dll"
Write-Host "Building..." -ForegroundColor Yellow
dotnet build .
Write-Host "Pushing..." -ForegroundColor Yellow
pac plugin push --pluginFile $pluginFile --pluginId $assemblyId
Write-Host "Done!" -ForegroundColor GreenSimply replace ASSEMBLY_ID with the previously copied ID. Then execute the script and the updates will be uploaded. The Plugin Registration Tool is no longer needed for this step, and you don't have to leave your beloved editor.
Comments