Utilizarea API-ului web pentru verificatorul Power Apps

API-ul web al verificatorului Power Apps oferă un mecanism de efectuare a unei verificări de analiză statică în raport cu particularizările și extensiile platformei Microsoft Dataverse. Este disponibil pentru creatori și dezvoltatori în vederea efectuării unor verificări complexe ale analizei statice a soluțiilor lor în raport cu un set de reguli de bune practici în scopul identificării rapide a modelelor problematice. Serviciul oferă logica pentru caracteristica verificator de soluții în producător Power Apps portal și este inclus ca parte a automatizării pentru cereri depuse la AppSource. Interacționarea directă cu serviciul în acest mod permite analiza soluțiilor care sunt incluse ca parte a mediilor on-premises (toate versiunile acceptate) și online.

Pentru informații despre utilizarea serviciului de verificare din codul PowerShell, consultați Lucrul cu soluții folosind PowerShell.

Abordări alternative

Înainte de a citi detaliile despre cum să interacționați la cel mai de jos nivel cu API-urile web, luați în considerare utilizarea modulului nostru PowerShell, Microsoft.PowerApps.Checker.PowerShell. Este un instrument complet acceptat, disponibil în Galeria PowerShell. Restricția actuală este aceea că necesită Windows PowerShell. Dacă nu puteți îndeplini această cerință, atunci interacțiunea directă cu API-urile este cea mai bună abordare.

Introducere

Este important de reținut că o analiză a soluției poate duce la un proces de lungă durată. De obicei, poate dura șaizeci (60) de secunde până la cinci (5) minute, în funcție de diferiți factori, cum ar fi numărul, dimensiunea și complexitatea personalizărilor și a codului. Fluxul de analiză are mai mulți pași și este asincron începând cu inițierea unei lucrări de analiză cu API-ul de stare fiind folosit pentru a interoga pentru finalizarea operațiunii. Un flux de exemplu pentru o analiză este următorul:

1. Obțineți un OAuth token
2. Încărcare de apeluri (pentru fiecare fișier în paralel)
3. Analiza apelurilor (inițiază operațiunea de analiză)
4. Starea apelului până la terminare (bucla cu o pauză între apeluri până la încheierea semnalului sau până la atingerea pragurilor)
5. Descărcați rezultatele din URI-ul SAS furnizat

Câteva variațiuni sunt:

• Includeți o căutare a setului de reguli sau a regulilor ca pas preliminar. Cu toate acestea, ar fi puțin mai rapid să treceți într-un cod de set de reguli configurat sau codat. Este recomandat să utilizați un set de reguli care să răspundă nevoilor dvs.
• Puteți opta pentru a nu utiliza mecanismul de încărcare (consultați încărcarea pentru limitări).

Trebuie să determinați următoarele cerințe:

• Care geografie?
• Care versiune?
• Ce reguli și reguli?
• Care este ID-ul dvs. de chiriaș?

Consultați următoarele articole pentru documentația despre API-urile individuale:

Preluați lista de seturi de reguli
Preluați lista de reguli
Încărcați un fișier
Invocă analiza
Verificați starea analizei

Determinați o geografie

Când interacționați cu serviciul de verificare Power Apps , fișierele sunt stocate temporar în Azure împreună cu rapoartele care sunt generate. Utilizând o API specifică geografiei, puteți controla unde sunt stocate datele. Solicitările către un punct final geografic sunt direcționate către o instanță regională pe baza celor mai bune performanțe (latență către solicitant). Odată ce o cerere intră într-o instanță de serviciu regional, toate procesarea și datele persistente rămân în acea regiune anume. Anumite răspunsuri API returnează adrese URL ale instanțelor regionale pentru solicitările ulterioare odată ce o lucrare de analiză este direcționată către o anumită regiune. Fiecare zonă geografică poate avea o versiune diferită a serviciului implementată la un moment dat. Utilizarea diferitelor versiuni de servicii se datorează procesului de implementare sigură în mai multe etape, care asigură compatibilitatea completă a versiunilor. Astfel, aceeași geografie ar trebui utilizată pentru fiecare apel API în ciclul de viață al analizei și poate reduce timpul de execuție global, deoarece este posibil ca datele să nu trebuiască să călătorească la fel de mult peste fir. Geografiile disponibile sunt următoarele:

Gestionarea versiunii

Deși nu este necesar, se recomandă să includeți parametrul șirului de interogări versiunea API cu versiunea API dorită. Versiunea actuală API este 2.0 pentru seturi de reguli și reguli și 1.0 pentru toate celelalte solicitări. De exemplu, următorul set de reguli este o solicitare HTTP care specifică utilizarea versiunii API 2.0:

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

Dacă nu este furnizată, cea mai recentă versiune API este utilizată în mod implicit. Se recomandă utilizarea unui număr de versiune explicit, deoarece versiunea este incrementată dacă sunt introduse modificări de ruptură. Dacă numărul de versiune este specificat într-o solicitare, se va menține suportul de compatibilitate în versiuni ulterioare (numeric mai mare).

Seturi de reguli și reguli

Verificatorul Power Apps necesită o listă de reguli atunci când este executat. Aceste reguli pot fi furnizate sub forma unor reguli individuale sau a unui grup de reguli, denumit drept set de reguli. Un set de reguli este un mod convenabil de a specifica un grup de reguli în loc de a specifica fiecare regulă individual. De exemplu, caracteristica de verificare a soluțiilor utilizează un set de reguli numit Verificator de soluții. Pe măsură ce noi reguli sunt adăugate sau eliminate, serviciul include aceste modificări în mod automat, fără a necesita nicio modificare din partea aplicației consumatoare. Dacă doriți ca lista de reguli să nu se modifice automat așa cum este descris mai sus, atunci regulile pot fi specificate individual. Seturile de reguli pot avea una sau mai multe reguli fără limită. O regulă nu poate fi în niciunul sau mai multe seturi de reguli. Puteți obține o listă a tuturor seturilor de reguli apelând la API după cum urmează: [Geographical URL]/api/ruleset. Acest punct final necesită acum autentificare.

Set de reguli pentru verificator de soluție

Setul de reguli pentru verificatorul de soluții conține un set de reguli de impact care au șanse limitate de fals pozitiv. Dacă rulați analiza pe o soluție existentă, este recomandat să începeți cu acest set de reguli. Acest set de reguli este utilizat de funcția de verificare a soluțiilor.

Set de reguli certificare AppSource

La publicarea aplicațiilor pe AppSource, trebuie să vă certificați aplicația. Aplicațiile publicate pe AppSource trebuie să respecte un standard de calitate ridicat. AppSource Setul de reguli de certificare conține regulile care fac parte din setul de reguli de verificare a soluțiilor, plus alte reguli pentru a se asigura că numai aplicațiile de înaltă calitate sunt publicate în magazin. Unele dintre AppSource regulile de certificare sunt mai predispuse la rezultate false pozitive și pot necesita mai multă atenție pentru rezolvare.

Găsiți ID-ul entității dvs. găzduite

ID-ul entității dvs. găzduite este necesar pentru a interacționa cu API-urile care necesită un token. Faceți referire la acest articol pentru detalii despre cum se obține ID-ul entității găzduite. Puteți utiliza, de asemenea, comenzile PowerShell pentru a prelua ID-ul entității găzduite. Următorul exemplu aplică cmdleturile din modulul AzureAD.

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

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

ID-ul entității găzduite este valoarea proprietății ObjectId care este returnată din Get-AzureADTenantDetail. Puteți vedea, de asemenea, după logare folosind cmdlet-ul Connect-AzureAD din ieșirea cmdlet. În acest caz, va fi numit TenantId.

Autentificare și autorizare

Interogarea pentru reguli și seturi de reguli nu necesită un OAuth token, dar toate celelalte API-uri necesită tokenul. API-urile acceptă descoperirea autorizației apelând oricare dintre API-urile care necesită un token. Răspunsul este un cod de stare HTTP neautorizat de 401 cu un antet WWW-Authenticate, URI de autorizare și ID-ul resursei. De asemenea, ar trebui să furnizați ID-ul entității găzduite în antetul x-ms-tenant-id. Consultați Power Apps Autentificare și autorizare Checker pentru mai multe informații. Următorul este un exemplu de antet de răspuns returnat de la o solicitare API:

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

Odată ce aveți aceste informații, puteți alege să utilizați Microsoft Authentication Library (MSAL) sau un alt mecanism pentru a obține simbolul. Următorul este un exemplu despre cum se poate face acest lucru folosind C# și 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();

Pentru codul de lucru complet, consultați API-ul web eșantionul QuickStart.

Odată ce ați achiziționat indicativul, este recomandat să furnizați același simbol pentru apelurile ulterioare din ciclul de viață al solicitării. Cu toate acestea, mai multe solicitări pot justifica obținerea unui nou token din motive de securitate.

Securitatea transporturilor

Pentru cea mai bună criptare din clasă, serviciul de verificare acceptă numai comunicații care utilizează Transport Layer Security (TLS) 1.2 și o versiune ulterioară. Pentru instrucțiuni privind cele mai bune practici .NET în jurul TLS, consultați Cele mai bune practici de Transport Layer Security (TLS) cu .NET Framework.

Format raport

Rezultatul analizei soluției este un fișier zip care conține unul sau mai multe rapoarte într-un format JSON standardizat. Formatul raportului se bazează pe rezultatele analizei statice, denumite Format de schimb de rezultate ale analizei statice (SARIF). Există instrumente disponibile pentru a vizualiza și interacționa cu documentele SARIF. Consultați acest site pentru detalii. Serviciul folosește versiunea a doua a standardul OASIS.

Consultați și

Preluați lista de seturi de reguli
Preluați lista de reguli
Încărcați un fișier
Invocă analiza
Verificați starea analizei