Utilitza l'API web de verificador de Power Apps

L'API web de Power Apps Checker proporciona un mecanisme per executar comprovacions d'anàlisi estàtica contra personalitzacions i extensions de la plataforma Microsoft Dataverse. Està disponible per a creadors i desenvolupadors per realitzar verificacions d'anàlisi estàtica rica a les solucions amb un conjunt de regles de pràctiques recomanades i identificar ràpidament patrons problemàtics. El servei proporciona la lògica per a la funció de verificador solució al creador de Power Apps portal i s'inclou com a part de l'automatització per a sol·licituds enviades al Marketplace. Interactuar directament amb el servei d'aquesta manera permet analitzar les solucions que s'inclouen com a part dels entorns locals (totes les versions compatibles) i en línia.

Per obtenir informació sobre l'ús del servei de verificació des del codi del PowerShell, consulteu Treballar amb solucions mitjançant el PowerShell.

Nota

L'ús de Power Apps Checker no garanteix que la importació de la solució tingui èxit. Les comprovacions d'anàlisi estàtiques realitzades a la solució no coneixen l'estat configurat de l'entorn de destinació i l'execució correcta de la importació pot dependre d'altres solucions o configuracions de l'entorn.

Enfocaments alternatius

Abans de llegir els detalls de com interactuar al nivell més baix amb les API web, considereu utilitzar el nostre mòdul PowerShell, Microsoft.PowerApps Checker.PowerShell, en canvi. És una eina totalment suportada que està disponible a la PowerShell Gallery. La restricció actual és que sí que requereix PowerShell de Windows. Si no es pot complir aquest requisit, interactuar directament amb les API és el millor enfocament.

Com començar

És important tenir en compte que una anàlisi de solucions pot donar lloc a un procés de llarga durada. Normalment pot trigar seixanta (60) segons a més de cinc (5) minuts, depenent de diversos factors, com ara el nombre, la mida i la complexitat de les personalitzacions i el codi. El flux d'anàlisi és de diversos passos i asíncron, i comença iniciant una feina d'anàlisi amb l'API d'estat que s'utilitza per fer la consulta de l'acabament de la feina. Un flux d'exemple per a una anàlisi és el següent:

Obtenir un OAuth token
Càrrega de trucades (per a cada fitxer en paral·lel)
Anàlisi de trucades (inicia la feina d'anàlisi)
Estat de les trucades fins a la finalització (bucle amb una pausa entre trucades fins que s'indiqui el final o es compleixin els llindars)
Baixar els resultats de l'URI de SAS proporcionat

Algunes variacions són:

Incloeu una cerca del conjunt de normes o normes com un pas previ. No obstant, seria una mica més ràpid passar un identificador de conjunt de normes configurat o codificat de manera permanent. Es recomana utilitzar un conjunt de normes que s'ajusti a les vostres necessitats.
Podeu optar per no utilitzar el mecanisme de càrrega (vegeu la càrrega per conèixer les limitacions).

Heu de determinar els requisits següents:

Quina geografia?
Quina versió?
Quins conjunts de regles i regles?
Quin és el vostre identificador d'inquilí?

Consulteu els articles següents per obtenir documentació sobre les API individuals:

Recuperar la llista de conjunts de regles
Recuperar la llista de regles
Penjar un fitxer
Invocar l'anàlisi
Comprovar l'estat de l'anàlisi

Determinar una zona geogràfica

Quan interactues amb el servei de verificació de Power Apps, els fitxers s'emmagatzemen temporalment a Azure juntament amb els informes generats. Mitjançant l'ús d'una API específica de la zona geogràfica, podeu controlar on s'emmagatzemen les dades. Les sol·licituds a un extrem geogràfic s'envien a una instància regional en funció del millor rendiment (latència fins al sol·licitant). Quan una sol·licitud entra en una instància de servei regional, tot el processament i les dades persistents romanen dins d'aquesta regió en particular. Algunes respostes de l'API retornen URL d'instància regional per a sol·licituds posteriors un cop s'encamina una feina d'anàlisi a una regió específica. Cada geografia pot tenir una versió diferent del servei implementada en un moment donat. L'ús de diferents versions del servei es deu al procés de desplegament segur de diverses etapes, que garanteix la compatibilitat total de la versió. Per tant, la mateixa zona geogràfica s'hauria d'utilitzar per a cada trucada a l'API en el cicle de vida de l'anàlisi i pot reduir el temps d'execució global, ja que les dades no hauran de viatjar tan lluny. Estan disponibles les zones geogràfiques següents:

Azure datacenter	Nom	Zona geogràfica	URI base
Públic	Visualització prèvia	Estats Units	unitedstatesfirstrelease.api.advisor.powerapps.com
Públic	Producció	Estats Units	unitedstates.api.advisor.powerapps.com
Públic	Producció	Europa	europe.api.advisor.powerapps.com
Públic	Producció	Àsia	asia.api.advisor.powerapps.com
Públic	Producció	Austràlia	australia.api.advisor.powerapps.com
Públic	Producció	Japó	japan.api.advisor.powerapps.com
Públic	Producció	Índia	india.api.advisor.powerapps.com
Públic	Producció	Canadà	canada.api.advisor.powerapps.com
Públic	Producció	Amèrica del Sud	southamerica.api.advisor.powerapps.com
Públic	Producció	Regne Unit	unitedkingdom.api.advisor.powerapps.com
Públic	Producció	França	france.api.advisor.powerapps.com
Públic	Producció	Alemanya	germany.api.advisor.powerapps.com
Públic	Producció	Emirats Àrabs Units	unitedarabemirates.api.advisor.powerapps.com
Públic	Producció	Suïssa	switzerland.api.advisor.powerapps.com
Públic	Producció	República de Sud-àfrica	southafrica.api.advisor.powerapps.com
Públic	Producció	Corea del Sud	korea.api.advisor.powerapps.com
Públic	Producció	Noruega	norway.api.advisor.powerapps.com
Públic	Producció	Singapur	singapore.api.advisor.powerapps.com
Públic	Producció	Suècia	sweden.api.advisor.powerapps.com
Públic	Producció	Polònia	poland.api.advisor.powerapps.com
Públic	Producció	Itàlia	italy.api.advisor.powerapps.com
Públic	Producció	Govern dels Estats Units	gov.api.advisor.powerapps.us
Públic	Producció	Govern dels EUA L4	high.api.advisor.powerapps.us
Públic	Producció	Govern dels EUA L5 (DOD)	mil.api.advisor.appsplatform.us
Públic	Producció	Xina operat per 21Vianet	china.api.advisor.powerapps.cn

Nota

Podeu utilitzar la zona geogràfica de visualització prèvia per incorporar les característiques més recents i els canvis anteriors. Tanmateix, tingues en compte que la previsualització utilitza només United States Azure regions.

Versions

Tot i que no és obligatori, es recomana incloure el paràmetre de cadena de consulta api-version amb la versió de l'API desitjada. La versió actual de l'API és 2.0 per a conjunts de regles i regles i 1.0 per a totes les altres sol·licituds. Per exemple, el següent conjunt de regles és una sol·licitud HTTP que especifica utilitzar la versió 2.0 de l'API:

https://unitedstatesfirstrelease.api.advisor.powerapps.com/api/ruleset?api-version=2.0

Si no es proporciona, s'utilitza la versió més recent de l'API per defecte. Es recomana utilitzar un número de versió explícit, ja que la versió s'incrementa si s'introdueixen canvis importants. Si el número de versió s'especifica a una sol·licitud, es mantindrà la retrocompatibilitat en versions posteriors (numèricament superiors).

Conjunts de normes i normes

Power Apps Checker requereix una llista de regles quan s'executa. Aquestes normes es poden proporcionar en forma de normes individuals o d'un agrupament de normes, anomenats conjunts de normes. Un conjunt de normes és una manera pràctica d'especificar un grup de normes en comptes d'haver d'especificar cada norma individualment. Per exemple, la característica de comprovació de la solució utilitza un conjunt de normes anomenat Comprovador de la solució. A mesura que s'afegeixen o eliminen noves regles, el servei inclou aquests canvis automàticament sense requerir cap canvi per part de l'aplicació consumidora. Si necessiteu que la llista de normes no canviï automàticament com s'ha descrit anteriorment, les normes es poden especificar individualment. Els conjunts de normes poden tenir una o diverses normes sense límit. Una norma pot ser en cap o diversos conjunts de normes. Podeu obtenir una llista de tots els conjunts de normes trucant a l'API de la següent manera: [Geographical URL]/api/ruleset. Aquest punt final ara requereix autenticació.

Conjunt de normes del comprovador de solucions

El conjunt de normes del comprovador de solucions conté un conjunt de normes impactants amb poques oportunitats de falsos positius. Si executeu l'anàlisi amb una solució existent, us recomanem que comenceu amb aquest conjunt de regles. Aquest conjunt de regles és utilitzat per la funció de verificació desolucions.

Conjunt de normes de certificació del mercat

Quan publiques sol·licituds al Marketplace, has d'obtenir la certificació de la teva sol·licitud. Les sol·licituds publicades al Marketplace han de complir un alt estàndard de qualitat. El conjunt de regles de certificació del Marketplace conté les regles que formen part del sistema de verificadors de solucions, a més d'altres normes per garantir que només es publiquen aplicacions d'alta qualitat a la botiga. Algunes de les normes de certificació del Marketplace són més propenses a falsos positius i poden requerir més atenció per resoldre's.

Cercar l'identificador de l'inquilí

L'identificador del vostre inquilí és necessari per interactuar amb les API que necessiten un testimoni. Consulteu aquest article per obtenir més informació sobre com s'obté l'identificador d'inquilí. També podeu utilitzar ordres del PowerShell per recuperar l'identificador d'inquilí. L'exemple següent aplica els cmdlets al mòdul AzureAD.

# Login to Microsoft Entra ID as your user
Connect-AzureAD

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

L'identificador d'inquilí és el valor de la propietat ObjectId que es torna de Get-AzureADTenantDetail. També podeu veure'l després d'iniciar la sessió amb el cmdlet Connect-AzureAD a la sortida del cmdlet. En aquest cas, s'anomenarà TenantId.

Autenticació i autorització

Les consultes de regles i conjunts de regles no requereixen un OAuth testimoni, però totes les altres API sí que requereixen el testimoni. Les API admeten el descobriment de l'autorització trucant a qualsevol de les API que requereixin un testimoni. La resposta és un codi d'estat HTTP no autoritzat de 401 amb una capçalera WWW-Authenticate, l'URI d'autorització i l'identificador de recurs. També heu d'indicar a la capçalera x-ms-tenant-id l'identificador d'inquilí. Consulteu Power Apps Checker authentication and authorization per a més informació. A continuació es mostra un exemple de la capçalera de resposta retornada d'una sol·licitud d'API:

WWW-Authenticate →Bearer authorization_uri="https://login.microsoftonline.com/0082fff7-33c5-44c9-920c-c2009943fd1e", resource_id="https://api.advisor.powerapps.com/"

Un cop tinguis aquesta informació, pots triar utilitzar la Microsoft Authentication Library (MSAL) o algun altre mecanisme per adquirir el token. El següent és un exemple de com es pot fer això utilitzant C# i la biblioteca MSAL .NET:

// Substitute your own environment URL here.
string resource = "https://<env-name>.api.<region>.dynamics.com";

// Example Microsoft Entra app registration.
// For your custom apps, you will need to register them with Microsoft Entra ID yourself.
// See https://docs.microsoft.com/powerapps/developer/data-platform/walkthrough-register-app-azure-active-directory
var clientId = "51f81489-12ee-4a9e-aaae-a2591f45987d";
var redirectUri = "http://localhost"; // Loopback required for the interactive login.

var authBuilder = PublicClientApplicationBuilder.Create(clientId)
    .WithAuthority(AadAuthorityAudience.AzureAdMultipleOrgs)
    .WithRedirectUri(redirectUri)
    .Build();
var scope = resource + "/.default";
string[] scopes = { scope };

AuthenticationResult tokenResult =
     await authBuilder.AcquireTokenInteractive(scopes).ExecuteAsync();

Per obtenir el codi de treball complet, vegeu l'exemple d'inici ràpid de l'APIweb.

Un cop hàgiu adquirit el testimoni, s'aconsella que proporcioneu el mateix testimoni a les trucades posteriors en el cicle de vida de la sol·licitud. Tanmateix, més sol·licituds poden justificar l'adquisició d'un nou testimoni per motius de seguretat.

Seguretat del transport

Per obtenir el millor xifratge de la seva classe, el servei de verificació només admet comunicacions que utilitzen Transport Layer Security (TLS) 1.2 i superiors. Per a orientació sobre .NET millors pràctiques al voltant de TLS, consulteu les millors pràctiques Transport Layer Security (TLS) amb el .NET Framework.

Format de l'informe

El resultat de l'anàlisi de la solució és un fitxer zip que conté un o diversos informes en un format JSON estandarditzat. El format de l'informe es basa en els resultats de l'anàlisi estàtica anomenats com a format d'intercanvi de resultats d'anàlisi estàtics (SARIF). Hi ha eines disponibles per visualitzar i interactuar amb els documents SARIF. Consulteu aquest lloc web per obtenir més informació. El servei utilitza la segona versió de l'estàndard OASIS.

Consulteu també