adventures inside the Power Platform

Power Pages and Cloud Flow - deployment fun?

eugene van staden — Wed, 11 Dec 2024 10:38:43 GMT

I wont go into how to create a flow or even how to add it to a Power Pages site, there are enough posts online about this.

Seems that I am not the first or the only person facing this issue, https://community.powerplatform.com/forums/thread/details/?threadid=fde43469-a96f-4696-a176-2957b5e13591

Lots of blog posts about this feature but not much on how and what to do when you ready to move this new shiny portal to the next level.

So where do I start....

I deployed my site and site components via a solution. I do enjoy this feature and approach to deploying power pages sites. Once you are ready, export the solution as Managed and then import into the Target environment via your preferred deployment approach.

Once deployed, spin up the portal and trigger this new Cloud Flow. In my case its just a button on a page.

And this is where it gets fun. On running the flow from the Site you get this lovely response.

{"ErrorCode":"0000000A","Message":"FlowAccessDenied"}

But how, everything seems legit. The trigger url is good and it should just work as the label promised! The flow is switched on and triggers manually via the maker portal.

So what the hell is going on! Why FlowAccessDenied error. I double check the Web Roles and yes they are all good.

Ok, so now I cant sleep and start poking around for an anwser.

I start off by checking Site Component that was added to my solution (powerpagescomponent) and then details of the Flow via the API.

~/api/data/v9.2/powerpagecomponents(2c81fa59-bbb6-ef11-b8e8-000d3ad22a58)

~/api/data/v9.2/workflows(4e82f6bd-4712-4640-b6b9-1858ae46ee06)

You can check the details of the PowerPagesComponent if you export the solution and compare the values in the workflow record.

From this I started comparing the values in Dev and Test and lo and behold the values in Test reflects what is in Dev. Oh dear lord, hmmm.

Lets have a look at this powerpagescomponent item. It has a Content property with a JSON object with properties that identify the Flow, the Trigger and few other items as below:

adx_flowapiurl : /_api/cloudflow/v1.0/trigger/4e82f6bd-4712-4640-b6b9-1858ae46ee06
adx_flowtriggerurl : "https://6f7bcc3d-ce82-4203-bb92-f416b2c4889c.13.common.australia.azure-apihub.net:443/apim/logicflows/38A92E4CCA254600BCA504FA39254321-42BEF8BD24FE7E2F/triggers/manual/run?api-version=2016-06-01
adx_metadata : 38a92e4c-ca25-4600-bca5-04fa39254321
_adx_processid_value :4e82f6bd-4712-4640-b6b9-1858ae46ee06

What you will notice from these values:

The Guid in the adx_flowapiurl value is the workflowid
The Guid at the start of the adx_flowtriggerurl is the Environment Id.
The Guid in the adx_metadata value is the resourceid and is the same value stripped from "-" highlighted in the adx_flowtriggerurl

To get the Flow trigger URL you can get it from running the Flow Test and grabbing the X-MS-APIM-Referrer value from the Header content.

So now I reckon thats it, Eureka, I found the missing link, and lets just go ahead and update the JSON Contet of the relevant Site Component record

adx_flowapiurl : Keep the same
adx_flowtriggerurl : Replace with the trigger URL
adx_metadata : resourceId
_adx_processid_value : workflowid (but this should be the same as the Guid in as above item 1)

After updating the Site Component an Unmanaged layer is added, guess that is expected.

So lets go ahead, refresh the cache and test. No, doest work, same error. Now let me restart the Site and test, no same result. Major dissapointment.

Guess Cloud Flows are not deployable, or maybe they are and I am doing something stupid but there is NO WAY I am going to recreate them manually in Test and Prod environments.

So what is the solution, do we update this PowerPagesComponent once the Solution gets exported and unpacked - is this wise? Do we update the Content property after our Solution deploys - which I tried but with not much luck. Is it specific to my environment, could it be the Managed solution, I have so many questions.

Back to the drawing board.

So the FlowAccesDenied error makes sense now, we are triggering the flow in Dev via Test portal.

I am not sure what the solution is. Raised a support request with Microsoft and lets see what comes from that and will update this post once I have a proper solution.

What is missing from an "ALM" perspective would be to allow the maintenance for the Cloud Flow via the Power Pages designer, but even this is giving me an error when trying to add a new flow to the Test environment.

ErrorCode : "F002"
Message : 
"Grant Access returned error response: {\"error\":{\"code\":\"0x80040217\",\"message\":\"Entity 'systemuser' With Id = 38ce6d41-0d48-ef11-a316-00000000000 Does Not Exist\"}}"

I do think the Cloud Flow feature in Power Pages is great but if it is not deployable then I do not see the value in using it.

The multi choice has arrived in Powerapps Portal - just in time!

eugene van staden — Tue, 14 Dec 2021 19:53:33 GMT

We have seen a good number of improvements with Powerapps Portals in the last year but very few of those have catered around improving the user experience that gets delivered out of the box.

With the announcement that multi choice options are now supported in the Portal I can finally have this feature in a portal without having to introduce a bit too much customization.

So lets see how this is done. I have a form with a few multi choice controls but all I get is this warning.

That makes sense seeing that we got Powerapps Control Framework support in the portal not so long ago and one of the steps in getting this up and running is to enable Read access to the Web Resource table.

I go ahead and add this Table Permission, assign a web role, reset my cache and... It just works. I can select and I can type ahead.

Inspecting the Sources tab in my developer tools I can see a nice bundle of PCF goodies.

This is perfect and its just in time for my next Portal project and here are the detailed instructions.

So if it works for Multi choice, does it work for other choice controls?

Add a Choice field, one that has 2 or more options. For this you need to use the good old Classic interface to edit the Control options, set as default Control then Save and Publish.

Your choice controls on your form would look as below.

Now, add Form metadata for these controls with Code Component as the Control Style

You should see as below. With a bit of styling we should be able to have sweet looking toggle switches!

Deploy your Powerapps Portal with ease

eugene van staden — Sat, 20 Jun 2020 23:19:53 GMT

Developing a Powerapps Portal is one thing, managing it across multiple environments is another - but it should not be!

In September 2019 I had the privilege to discuss this topic with Nick Doelman and Colin Vermander on their Refresh the Cache podcast and been promising them a write up of my Portal ALM process, so here goes (I intend to break down each topic into a seperate write up).

Over the last few months I have noticed a lot of interest in Powerapps Portals ALM and I feel that with the tools available it does not have to be made out to be as complicated.

In fact deploying a Powerapps Portal should be no different from deploying a Powerapps/Dynamics 365 CE Solution in that it has the same components ie. customization, configuration and possibly a few bits of code all packaged up as Solution.

The main difference with Portals is that it has a lot more configuration (data) that needs to be moved from your development environment to a target.

I do not split my portal configuration from my portal solution. Its unpacked and exported, versioned, packed and imported all together. This approach also allows me to deploy my project solutions in layers and keep the Portal seperate from the rest of my project.

This is important as Portal development usually trail your core features in your project and you might not deploy a portal solution to all your target environments. For example you might deploy portal solution to Staging, Test, QA and Production but not to Training.

Configuration data is the heart of a Powerapps Portal and traditionally we would use the Configuration Migration tool to lift and shift this data across instances. But until recently you could not filter in the tool which made exporting the annotations related to your Web Files tricky.

Yes, you can use the Configuration Migration tool for Portal deployment but why do this manually each time you need to update your Portal?

How then do you automate this process and how can you manipulate environment specific configuration such as Site Settings?

With the Export-CrmDataFile and Import-CrmDataFile Cmdlets available in the Microsoft.Xrm.Tooling.ConfigurationMigration powershell package you can easily export and import your Portal configuration, either as a standalone process or part of your deployment strategy. All you need is a configuration schema that you can generate with Configuration Migration Tool or use the samples provided by Microsoft here , or even beter the ones Colin Vermander published over here

The CmdLet usage is fairly straight forward and you can run them on their own or as part of your build process.

Export-CrmDataFile -SchemaFile "D:\Configuration\schema.xml" -DataFile "D:\Configuration\export.zip" -CrmConnection $conn -Verbose

But my preferred option is to use the Microsoft.Xrm.DevOps.Data Powershell package maintained by Andrew Vogel

This package allows you to generate filtered data that is compatible with the Configuration Migration Tool. It is a much cleaner approach than working with the configration schema and eliminates the need to manually import and export data.

$packages = Get-CrmDataPackage -Conn $conn -Fetches @("<fetch><entity name='adx_contentsnippet'>
<attribute name='adx_contentsnippetid' />
<attribute name='adx_contentsnippetlanguageid' />
<attribute name='adx_display_name' />
<attribute name='adx_name' />
<attribute name='statecode' />
<attribute name='statuscode' />
<attribute name='adx_type' />
<attribute name='adx_value' />
<attribute name='adx_websiteid' />
    <filter type='and'>
      <condition attribute='statecode' operator='eq' value='0' />
    </filter>
</entity></fetch>") -DisablePluginsGlobally $true 


$packages.Data.InnerXml | Out-File -FilePath  (Join-Path $PSScriptRoot "..\ReferenceData\data.xml")
$packages.Schema.InnerXml | Out-File -FilePath (Join-Path $PSScriptRoot "..\ReferenceData\data_schema.xml")

You can easily add this script as part of your Solution Export process and store the results in source - I dont like exporting solutions or configuration data as part of my Build or Release steps in Azure DevOps. I execute this from Visual Studio, commit and push my changes from where the build trigger and takes care of the rest.

My approach is to not only unpack the Solution but also the configuration data required, both Portal configuration and standard reference data that is required across all environments.

My portal solution is now versioned per export and can easily be configured for a new environment and deploy with specific settings only for that environment. Sample of unpacked Solution.xml with updated Version number.

<ImportExportXml version="9.1.0.18341" SolutionPackageVersion="9.1" languagecode="1033" generatedBy="CrmLive" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SolutionManifest>
    <UniqueName>PortalConfiguration</UniqueName>
    <LocalizedNames>
      <LocalizedName description="Portal Configuration" languagecode="1033" />
    </LocalizedNames>
    <Descriptions>
      <Description description="Upgrade of Portal Configuration" languagecode="1033" />
    </Descriptions>
    <Version>3.20156.0.1848</Version>
    <Managed>2</Managed>
    <Publisher>

and corresponding deployed Portal Configuration Solution deployed as managed solution in the target environment.

With the data and solution unpacked it can easily be bundled up with the Package deployer tool. Once the changes are commited and pushed to the repository my build and release processes does the rest. This is all wired up in Visual Studio and packaged from the ImportConfig.xml used in the PackageDeployer project template for Visual Studio.

<?xml version="1.0" encoding="utf-16"?>
<configdatastorage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                   installsampledata="false"
                   agentdesktopzipfile=""
		               agentdesktopexename=""
                   crmmigdataimportfile="ImportFiles/data.zip">
  
  <solutions>
    <configsolutionfile solutionpackagefilename="ImportFiles/PortalConfiguration_managed.zip" overwriteunmanagedcustomizations="true"/>
  </solutions>
  </configdatastorage>

You can import the configuration with powershell or either of the Powerapps DevOps build tasks available in Azure DevOps to import the solution or just the data configuration.

Import-CrmPackage -CrmConnection $CRMConn -PackageDirectory $PackageDirectory -PackageName $PackageName -LogWriteDirectory $LogsDirectory -EnabledAsyncForSolutionImport -SolutionBlockedRetryDelay 120 -SolutionBlockedRetryCount 10 -Timeout "00:15:00" -RuntimePackageSettings $RuntimeSettings -Verbose

Sample of a release stage into a new environment.

  - stage: Staging01
    
    displayName: Staging01
    dependsOn: Build
    condition: and(succeeded(), notIn(variables['Build.Reason'], 'Schedule'))
    jobs:
    - deployment: DeployJob      
      displayName: Staging01 
      environment: Staging01
      timeoutInMinutes: 120
      variables:
        - group: D365.D365CDEnvironment
        - group: Secrets-Staging01-AUE
      strategy:
        runOnce:
          deploy:
            steps:
            - task: PowerShell@2
              displayName: Deploy Solution
              inputs:
                targetType: filePath
                filePath: $(Pipeline.Workspace)/drop/Solutions/bin/Release/Scripts/SolutionDeploy.ps1
                arguments: -DeployServerUrl $(d365url) -UserName $(d365username) -Password $(d365password) -PipelinePath $(Pipeline.Workspace)

The next question is how do you manipulate settings specific to each target environment, for example your Dev portal use Local authentication where your Test and Production portal use Azure AD B2C, how do you update these Site Settings?

You could manipulate the exported XML data before packaging it up with the Package Deployer tool or after importing it into your target environment with a post deployment step. For example I usually remove the Administrator Webrole in my production portal and then also update Site Settings and Web Files per environment via a Post deployment action or by extending the PackageTemplate.cs class from the PackageDeployer project template for Visual Studio.

    [Export(typeof(IImportExtensions))]
    public class PackageTemplate : ImportExtension
    {
        public static string EnvironmentAttributeName;

        public override void InitializeCustomExtension()
        {
            // Do nothing. 
        }

        public override bool AfterPrimaryImport()
        {
            UpdateSiteSettings();
            return true;
        }

I prefer to deploy first and then update settings as part of my release process thus keeping my configuration in source as close to the state of the portal in development. This has come in handy a few times when I had to rebuild my development portal when accidentally deleted a component.

The tools that are available allow you to automate the deployment of your Powerapps Portal. No need for manual data export and import nor having to manipulate configuration by hand between your deployments. From a single Visual Studio project template I have all the scripts and processes available to achieve full automated Powerapps Portals ALM.

References:

https://github.com/dylanhaskins/PowerPlatformCICD

https://github.com/abvogel/Microsoft.Xrm.DevOps.Data

https://docs.microsoft.com/en-us/power-platform/alm/package-deployer-tool

https://docs.microsoft.com/en-us/power-platform/admin/manage-configuration-data

https://docs.microsoft.com/en-us/powerapps/maker/portals/admin/migrate-portal-configuration

https://www.powershellgallery.com/packages/Microsoft.Xrm.Tooling.ConfigurationMigration/1.0.0.44

Configure Azure Functions as Webhooks as part of your Dynamics 365 Deployment process

eugene van staden — Mon, 27 Apr 2020 02:04:09 GMT

I tend to use Azure Functions to create external webhooks for Dynamics 365 server side events. Although this post is not about setting up your webhooks, at the end of this post is a series of links that you can use as reference.

This post follows up on a series of articles written by my colleague Dylan Haskins and myself where we take you through our ALM approach, with complete source code for our Framework and Provisioning tool available here on Github.

When setting up the webhook you need to provide a Name, endpoint URL and option for authentication. The webhook key is a perfect option to authenticate with an Azure Function because of the authentication query string is expected to have a key name of code.



https://webhook-dev.azurewebsites.net/api/WebhookFunctionName?code=gqqIX1a2b05vHVjPeGQoiOjkXIwGpr2qENVqFVSQFzR/cdl7QGNqKw==

You can query your webhook registrations as they are stored in the ServiceEndpoint entity:

GET [organization URI]/api/data/v9.0/serviceendpoints?$filter=contract eq 8&$select= serviceendpointid,name,authtype,url

Note: The actual AuthValue property cannot be retrieved.

Once that is all set up how do you then automate setting the unique Endpoint URL and AuthValue per instance that you deploy, for example I usually have a Dev, Test and Prod instance of Dynamics 365 as a bare minimum on a project and ideally you want a unique instance of the webhook deployed for each environment. Yes, you can manually register a unique ServiceEndpoint per instance, or you can automate it as set it up as part of your deployment.

So instead of manually repeating and updating the ServiceEndpoint per environment you can do it via the release proces.

Here is a quick guide that I usually employ:

Step1: Ensure your ServiceEndpoint is added to the Dynamics 365 Solution that you will be deploying.

This will ensure your webhook maintains the same record identifier across all your environments. If you unpack your solution into source control it will be available under the PluginAssemblies directory and will contain all that you need.

<?xml version="1.0" encoding="utf-8"?>
<ServiceEndpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ServiceEndpoint ServiceEndpointId="{00000000-YOUR-GUID-HERE-000000000000}" Name="AccountWebhook">
    <ConnectionMode>1</ConnectionMode>
    <Contract>8</Contract>
    <Path></Path>
    <SolutionNamespace></SolutionNamespace>
    <UserClaim>1</UserClaim>
    <IsCustomizable>1</IsCustomizable>
    <AuthType>4</AuthType>
    <MessageFormat>2</MessageFormat>
    <NamespaceFormat>1</NamespaceFormat>
    <Url>https://mywebhook-dev.azurewebsites.net/api/AccountWebhook</Url>
  </ServiceEndpoint>
</ServiceEndpoints>

Step 2: Update the Webhook parameters during deployment

For this we need to do the following:

Return ResourceId and DefaultHostName from the ARM template deployment, as below

"outputs": {
"FunctionAppResourceId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Web/sites', parameters('functionAppName'))]"
    },
    "FunctionAppHostname": {
      "type": "string",
      "value": "[reference(resourceId('Microsoft.Web/sites', parameters('functionAppName')), '2018-02-01').defaultHostName]"
    }
}

note: you will have to caputre the ARM output to be able to use it in other tasks further down the track

"##vso[task.setvariable variable=foo;isOutput=true]bar"

Deploy the Azure Function

Stock standard App Service deploy task.

Retrieve the Default host key

Retrieve the Default Function key from the recently deployed Azure Function using the Azure CLI task with following script:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/
Microsoft.Web/sites/{name}/functions/{functionName}/listkeys?api-version=2019-08-01

FOR /F "tokens=* USEBACKQ" %%F IN (`CALL az rest --method post --uri "https://management.azure.com$(functionAppResourceId)/functions/$(functionName)/listkeys ?api-version=2018-02-01" --output tsv`) DO (
SET apikey=%%F
)
echo ##vso[task.setvariable variable=functionKey;]%apikey%

note: $(functionAppResourceId) is the output value from the ARM template deployment step.

This will add the value of the apikey to the functionKey pipeline variable, to be used by the following task

Update Webhook details in Dynamic 365

Passing in the new webhook Endpoint and new Host key as parameters the task updates the ServiceEndpoint record in the target Dynamics 365 environment.

note: $(functionAppHostname) is the output value from the ARM template deployment step: https://mywebhook-dev.azurewebsites.net
and $(endpoint) is the actual endpoint of your Azure Function: /api/WebhookFunctionName
```
-webhook $(functionAppHostname)$(endpoint) 

-authvalue $(functionKey)
```
This step can also be used for various actions that you want to execute as part of your deployment such as disable or remove unused items.

Reference:

https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/use-webhooks

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch

https://docs.microsoft.com/en-us/rest/api/appservice/webapps/listfunctionkeys

Integrate your Dynamics 365 with Azure resources using Managed Identity

eugene van staden — Sun, 26 Apr 2020 22:00:00 GMT

Managing credentials is always a challenge but Managed Identity with Azure Active Directory is a great way to solve this problem. Not only is it a free service with Azure AD, its really easy to set up.

At the end of this post is a series of links that you can use as reference.

The preferred method of authenticating external applications with your Dynamics 365 instance would be through Server to Server authentication by:

register your application in Azure AD
assign the required permissions
generate the client secret
and then setting up the corresponding Dynamics 365 Application User
```
 
```

Once you have this all set up you can then connect to your instance using the above credentials created, passing in your Client Id, Client Secret and AD Tenant Id as shown below:

var clientCred = new ClientCredential(_clientId, _secret);
var authContext = new AuthenticationContext("https://login.microsoftonline.com/" + _tenantId);

return authContext.AcquireToken(_resource, clientCred).AccessToken;

Easy yes, but there is an even easier way and that is where Managed identity comes in and why not get Azure AD do all the work for you as below?

To set this up, you can do it as manually shown here or when you deploy your resources with ARM or CLI.

Step 1: Enable System Assigned Identity for your Azure Resource such as an Azure Function

This would create a related Service Principal in the Enterprise Application blade.

note: the Application ID value

Step 2: Create the Dynamics 365 Application User and Assign a security role

Step 3: Update your code

Reference the Microsoft.Azure.Services.AppAuthentication Nuget pacakge in your project

Once this is done change your code to use the AzureServiceTokenProvider.

// Configure the token provider.
builder.Services.AddSingleton(new AzureServiceTokenProvider());

And replace the code that use the Client Id and Secret with below.

//_resource would be your Dynamics 365 instance eg. https://MyDevOrg.api.crm6.dynamics.com

return await _azureServiceTokenProvider.GetAccessTokenAsync(_resource, _tenantId);

and then consume the bearer token

using (var webProxyClient = new OrganizationWebProxyClient(GetServiceUri(), true))
{
   webProxyClient.HeaderToken = await GetD365AccessTokenAsync();
   using (var serviceContext = new XrmServiceContext(webProxyClient))
   {
....

You can run and test locally in Visual Studio by updating your relevant credentials.

I hope this is of help. You can also automate the above sequence of steps as part of your deployment, which I will document in a follow up post.

For more details and thoughts, strategies and tools for ALM for the Power Platform and PowerApps Portals visit Dylan Haskins blog for more indepth details.

All of this and more is available in our PowerPlatform CICD template on Github.

Reference
https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/build-web-applications-server-server-s2s-authentication

https://docs.microsoft.com/en-us/power-platform/admin/create-users-assign-online-security-roles#create-an-application-user

about myself and this blog

eugene van staden — Sun, 09 Feb 2020 22:22:55 GMT

I aim to share some of my thoughts and experiences in developing and delivering business solutions with the Microsoft Dynamics 365 and the Power Platform.

Hopefully you find these helpful and amusing!

You can find more of me here

Eugene van Staden

Github