Използвайте Power Apps checker web API

Уеб API за проверка на Power Apps предоставя механизъм за извършване на статични проверки на персонализации и разширения към платформата Microsoft Dataverse. Налично е за създатели и разработчици за изпълнение на проверка с богат статичен анализ на решенията си срещу набор от правила за най-добри практики и бързо да разпознаете тези проблематични модели. Услугата предоставя логиката за функцията solution checker в Power Apps maker portal и е включена като част от автоматизацията за приложения, подадени в Marketplace. Директното взаимодействие с услугата по този начин позволява анализ на решения, които са включени като част от локална (всички поддържани версии) и онлайн среда.

За информация относно използването на услугата за проверка от кода на PowerShell вижте Работа с решения с помощта на PowerShell.

Бележка

  • Използването на Power Apps checker не гарантира, че импортирането на решение ще бъде успешно. Проверките на статичния анализ, извършени спрямо решението, не знаят конфигурираното състояние на средата на местоназначението и успехът на импортирането може да зависи от други решения или конфигурации в средата.

Алтернативни подходи

Преди да прочетете подробностите за това как да взаимодействате на най-ниско ниво с уеб API, помислете за използването на нашия модул PowerShell, Microsoft.PowerApps Вместо това Checker.PowerShell. Това е напълно поддържан инструмент, който е наличен в PowerShell Gallery. Настоящото ограничение е, че изисква Windows PowerShell. Ако не можете да отговорите на това изискване, тогава директното взаимодействие с API е най-добрият подход.

Начало

Важно е да се отбележи, че анализът на решението може да доведе до дълъг процес. Обикновено може да отнеме шестдесет (60) секунди до над пет (5) минути в зависимост от различни фактори, като брой, размер и сложност на персонализациите и кода. Потокът на анализа е многостъпален и асинхронен, започващ с иницииране на задача за анализ с API на състоянието, използван за заявка за завършване на заданието. Примерен поток за анализ е следният:

  1. Получаване на OAuth токен
  2. Качване на обаждане (за всеки файл паралелно)
  3. Анализ на повиквания (инициира задачата за анализ)
  4. Състояние на обаждането до завършване (циклично с пауза между разговорите, докато не се сигнализира края или се спазват праговете)
  5. Изтеглете резултатите от предоставения SAS URI

Няколко варианта са:

  • Включете търсене на набор от правила или правила като предварителна стъпка. Въпреки това, ще бъде малко по-бързо да се премине в конфигуриран или твърдо кодиран набор от правила за правила. Препоръчва се да използвате набор от правила, който отговаря на вашите нужди.
  • Можете да изберете да не използвате механизма за качване (вижте качването за ограничения).

Трябва да определите следните изисквания:

Вижте следните статии за документация относно отделните API:

Извличане на списъка с набори от правила
Извличане на списъка с правила
Качване на файл
Анализ на извикване
Проверка за състояние на анализа

Определете география

Когато взаимодействате с услугата Power Apps checker, файловете временно се съхраняват в Azure заедно с генерираните отчети. Използвайки специфичен API за география, можете да контролирате къде се съхраняват данните. Заявките до географска крайна точка се насочват към регионален екземпляр въз основа на най-добрата производителност (латентност към заявителя). След като заявката влезе в регионален екземпляр на услугата, цялата обработка и постоянните данни остават в конкретния регион. Някои отговори на API връщат URL адреси на регионални екземпляри за последващи заявки, след като заданието за анализ бъде насочено към конкретен регион. Всяко географско местоположение може да има различна версия на услугата, разгърната във всеки един момент. Използването на различни версии на услугата се дължи на многоетапния процес на безопасно внедряване, който гарантира пълна съвместимост на версиите. По този начин, една и съща география трябва да се използва за всяко API извикване в жизнения цикъл на анализа и може да намали общото време за изпълнение, тъй като данните може да не трябва да се движат толкова далеч над проводника. По-долу са посочени наличните географии:

Azure datacenter Име География Основен URI
Публични Предварителен преглед САЩ unitedstatesfirstrelease.api.advisor.powerapps.com
Публични Производствен САЩ unitedstates.api.advisor.powerapps.com
Публични Производствен Европа europe.api.advisor.powerapps.com
Публични Производствен Азия asia.api.advisor.powerapps.com
Публични Производствен Австралия australia.api.advisor.powerapps.com
Публични Производствен Япония japan.api.advisor.powerapps.com
Публични Производствен Индия india.api.advisor.powerapps.com
Публични Производствен Канада canada.api.advisor.powerapps.com
Публични Производствен Южна Америка southamerica.api.advisor.powerapps.com
Публични Производствен Обединеното кралство unitedkingdom.api.advisor.powerapps.com
Публични Производствен Франция france.api.advisor.powerapps.com
Публични Производствен Германия germany.api.advisor.powerapps.com
Публични Производствен Обединени арабски емирства unitedarabemirates.api.advisor.powerapps.com
Публични Производствен Швейцария switzerland.api.advisor.powerapps.com
Публични Производствен Южна Африка southafrica.api.advisor.powerapps.com
Публични Производствен Южна Корея korea.api.advisor.powerapps.com
Публични Производствен Норвегия norway.api.advisor.powerapps.com
Публични Производствен Сингапур singapore.api.advisor.powerapps.com
Публични Производствен Швеция sweden.api.advisor.powerapps.com
Публични Производствен Полша poland.api.advisor.powerapps.com
Публични Производствен Италия italy.api.advisor.powerapps.com
Публични Производствен US Government gov.api.advisor.powerapps.us
Публични Производствен L4 на правителството на САЩ high.api.advisor.powerapps.us
Публични Производствен Правителство на САЩ L5 (DOD) mil.api.advisor.appsplatform.us
Публични Производствен Управлявано в Китай от 21Vianet china.api.advisor.powerapps.cn

Бележка

Можете да изберете да използвате географията на визуализацията, за да включите най-новите функции и промени по-рано. Въпреки това, имайте предвид, че предварителният преглед използва само United States Azure региони.

Създаване на версии

Въпреки че не е задължително, препоръчително е да включите параметъра низ на заявката за версия на api с желаната версия на API. Текущата версия на API е 2.0 за набори от правила и правила и 1.0 за всички останали заявки. Например следният набор от правила е HTTP заявка, уточняваща използването на версията на API 2.0:

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

Ако не е предоставена, по подразбиране се използва най-новата версия на API. Препоръчва се използването на изричен номер на версията, тъй като версията се увеличава, ако се въведат извънредни промени. Ако номерът на версията е посочен в заявка, ще се поддържа поддръжка за съвместимост с по-късна (по-голяма) версия.

Набори от правила и правила

Power Apps checker изисква списък с правила, когато се изпълнява. Тези правила могат да бъдат предоставени под формата на индивидуални правила или групи от правила, посочени като набор от правила. Набор от правила е удобен начин да се определи група от правила, вместо да се налага да се определят всяко правило поотделно. Например функцията за проверка на решения използва набор от правила с име Инструмент за проверка на решения. Когато се добавят или премахват нови правила, услугата включва тези промени автоматично, без да изисква промяна от приложението-потребител. Ако искате списъкът с правила да не се променя автоматично, както е описано по-горе, тогава правилата могат да бъдат определени индивидуално. Наборите от правила могат да имат едно или повече правила без ограничение. Правилото може да бъде в никой или в множество набори от правила. Можете да получите списък с всички набори от правила, като се обадите на API както следва: [Geographical URL]/api/ruleset. Тази крайна точка сега изисква удостоверяване.

Набор от правила за инструмента за проверка на решение

Наборът от правила за проверка на решения съдържа набор от въздействащи правила, които имат ограничени шансове за фалшиви положителни резултати. Ако изпълнявате анализ спрямо съществуващо решение, препоръчително е да започнете с този набор от правила. Този набор от правила се използва от функцията запроверка на решения.

Набор от правила за сертификация на пазара

Когато публикувате заявления в Marketplace, трябва да получите сертификация на кандидатурата си. Приложенията, публикувани в Marketplace , трябва да отговарят на висок стандарт за качество. Наборът от правила за сертифициране на Marketplace съдържа правилата, които са част от набора за проверка на решения, плюс други правила, които гарантират, че в магазина се публикуват само висококачествени приложения. Някои от правилата за сертификация на Marketplace са по-податливи на фалшиви положителни резултати и може да изискват повече внимание за разрешаване.

Намерете идентификационния си номер на клиента

Идентификационният номер на вашия клиент е необходим за взаимодействие с API-тата, които изискват означение. Вижте тази статия за подробности как да получите идентификационния номер на клиента. Можете също да използвате командите PowerShell за извличане на идентификатора на клиента. Следващият пример прилага кратките команди в модула AzureAD.

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

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

Идентификационният номер на клиента е стойността на свойството ObjectId, която е върната от Get-AzureADTenantDetail. Можете да го видите и след като влезете с помощта на командлета Connect-AzureAD в изхода на командлета. В този случай той ще бъде назован TenantId.

Удостоверяване и упълномощаване

Заявките за правила и набори от правила не изискват маркер, OAuth но всички останали API изискват маркера. API-ите поддържат откриване на авторизация, като се обаждат на някой от API, които изискват означение. Отговорът е неупълномощен код на състоянието на HTTP 401 със заглавка WWW-Authenticate, URI адрес за упълномощаване и ИД на ресурса. Трябва също да предоставите идентификационния си номер на клиента в заглавката x-ms-tenant-id. Вижте Power Apps Checker authentication and authorization за повече информация. Следва пример за заглавката на отговора, върната от заявка за API:

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

След като получите тази информация, можете да изберете да използвате Microsoft Authentication Library (MSAL) или друг механизъм за придобиване на токена. Следва пример как това може да се направи с помощта на C# и библиотеката 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();

За пълния работен код вижте примера за бърз старт на уеб API.

След като придобиете маркера, се препоръчва да предоставите същия маркер на последващи извиквания в жизнения цикъл на заявката. Въпреки това, повече заявки може да гарантират придобиването на нов токен от съображения за сигурност.

Транспортна сигурност

За най-доброто в класа си криптиране услугата за проверка поддържа само комуникации с помощта на Transport Layer Security (TLS) 1.2 и по-нови версии. За насоки относно .NET добри практики около TLS, вижте най-добрите практики на Transport Layer Security (TLS) с рамката .NET.

Формат на отчет

Резултатът от анализа на решението е zip файл, съдържащ един или повече доклади в стандартизиран JSON формат. Форматът на отчета се основава на резултатите от статичния анализ, наричани формат за обмен на резултати от статичен анализ (SARIF). Има инструменти за преглед и взаимодействие с документи на SARIF. Вижте този уеб сайт за подробности. Услугата използва втора версия на стандарта OASIS.

Вижте също

Извличане на списъка с набори от правила
Извличане на списъка с правила
Качване на файл
Анализ на извикване
Проверка за състояние на анализа

  • Last updated on