Partager via

Get started using the Power Apps checker module

  • Article

The Power Apps checker (Microsoft.PowerApps.Checker.PowerShell) PowerShell module interacts with the Power Apps checker service providing the ability to run static analysis jobs and download the results. This module is for solution developers to perform rich static analysis checks on their solutions against a set of best practice rules to quickly identify problematic patterns. The same service also provides the logic for the solution checker feature in Power Apps and ISV studio and is included as part of the automation for AppSource certifications. Interacting with the service using this module allows for analysis of solutions used for both on premise (all supported versions) and online environments.

This module works with Dataverse.

You can install this module directly from the PowerShell Gallery.

  1. Start a PowerShell session.

  2. Enter the following cmdlet.

    install-module Microsoft.PowerApps.Checker.PowerShell

You will then need to ensure that you have an Azure Active Directory application setup as defined below. Once you have that, then you are ready to start using the module. Refer to the online cmdlet documentation or PowerShell documentation for details on how to run a Power Apps checker job.

Power Apps checker authentication and authorization

Interactions with the Power Apps checker analyze API or the Invoke-PowerAppsChecker cmdlet requires an Azure Active Directory (AAD) application. This application should be registered in a tenant with Power Apps or Dynamics 365 licensing. Customers and partners who have licensing for the platform, regardless of having an on-premises or online environment, should have an AAD tenant that has the necessary licensing. For more about on how to create an application in AAD, see Use the portal to create an Azure AD application and service principal that can access resources.

The following are required for the application's registration in AAD for all interactions:

  • Redirect URI
    • Type: Public client (mobile & desktop)
    • Redirect URI: urn:ietf:wg:oauth:2.0:oob
  • API level permissions to the PowerApps-Advisor first party Microsoft AAD application
    • Application permissions to Analysis.All

The following are required for interactions using a user-based token:

  • API level permissions to the PowerApps-Advisor first party Microsoft AAD application
    • Delegated user permissions to Analysis.All
    • Consent will be needed by the user during the fist authentication or by an AAD administrator, depending on the settings for the tenant

The following are required for interactions using an application-based token:

For more details on permissions and consent refer to the Permissions and consent in the Microsoft identity platform endpoint topic.

Sample script to create an AAD application

The following is an example of creating the required AAD application using the AzureAD PowerShell module.

function New-PowerAppsCheckerAzureADApplication
{
    [CmdletBinding()]
    param(
        [Parameter(Mandatory = $true)]
        [Guid]
        $TenantId,
        [Parameter(Mandatory = $true)]
        [ValidateNotNullOrEmpty()]
        [string]
        $ApplicationDisplayName
    )

    # Using AzureAD as the RM modules, AzureRm.Resource and AzureRm.Profile, do not allow for setting RequiredResourceAccess
    Import-Module AzureAD | Out-Null
    try
    {
        Connect-AzureAD -TenantId $TenantId | Out-Null
    }
    catch [Microsoft.Open.Azure.AD.CommonLibrary.AadAuthenticationFailedException]
    {
        Write-Error "Received a failure result from the connecting to AzureAD, $($_.Exception.Message). Stopping."
        return
    }
    $graphSignInAndReadProfileRequirement = New-Object -TypeName "Microsoft.Open.AzureAD.Model.RequiredResourceAccess"
    $acc1 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList "e1fe6dd8-ba31-4d61-89e7-88639da4683d","Scope"
    $graphSignInAndReadProfileRequirement.ResourceAccess = $acc1
    $graphSignInAndReadProfileRequirement.ResourceAppId = "00000003-0000-0000-c000-000000000000"

    $powerAppsCheckerApiRequirement = New-Object -TypeName "Microsoft.Open.AzureAD.Model.RequiredResourceAccess"
    $acc1 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList "d533b86d-8f67-45f0-b8bb-c0cee8da0356","Scope"
    $acc2 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList "640bd519-35de-4a25-994f-ae29551cc6d2","Scope"
    $powerAppsCheckerApiRequirement.ResourceAccess = $acc1,$acc2
    $powerAppsCheckerApiRequirement.ResourceAppId = "c9299480-c13a-49db-a7ae-cdfe54fe0313"

    $application = New-AzureADApplication -DisplayName $ApplicationDisplayName -PublicClient $true -ReplyUrls "urn:ietf:wg:oauth:2.0:oob" -RequiredResourceAccess $graphSignInAndReadProfileRequirement, $powerAppsCheckerApiRequirement
    if ($application -eq $null -or $application.AppId -eq $null)
    {
        Write-Error "Unable to create the application as requested."
    }
    else
    {
        Write-Host "The application $($application.AppId):$ApplicationDisplayName was created in the tenant, $TenantId. You may need to have an administrator grant consent. If running in a userless process, you will need to add a secret or certificate in which to authenticate." 
    }
    return $application
}

# Login to AAD as your user
Connect-AzureAD

# Establish your tenant ID
$tenantId = (Get-AzureADTenantDetail).ObjectId

# Create the AAD application registration using the AzureAD module and the sample script
$newApp = New-PowerAppsCheckerAzureADApplication -ApplicationDisplayName "PowerApps Checker Client" -TenantId $tenantId

# Next step => create a secret via the Admin portal, CLI, or PowerShell module.

Rulesets and rules

Power Apps checker requires a list of rules in which to run. This can be provided in the form of individual rules or a grouping of rules, referred to as a ruleset. A ruleset is a convenient way to specify a group of rules instead of specifying each rule. For example, the solution checker feature uses a ruleset named Solution checker and the AppSource certification uses a ruleset called AppSource. As new rules are added or removed, the feature will include these changes automatically without requiring any change by the consuming application. If you require that the list of rules not change automatically as described above, then the rules can be specified individually.

Report format

The result of the solution analysis is a zip file containing one or more reports in a standardized JSON format. The report format is based on static analysis results referred to as Static Analysis Results Interchange Format (SARIF). There are tools available to view and interact with SARIF documents. Refer to the SARIF project's web site for details. The service leverages version two of the OASIS standard.

See also

Microsoft.PowerApps.Checker.PowerShell Module Reference
Overview