Использование REST API для расширения функциональности приложений на основе холста

2025-04-30

Microsoft Power Platform позволяет расширить функциональные возможности вашего приложения Power Apps на основе холста с помощью API-интерфейсов REST. При работе со сложными алгоритмами или множеством источников данных перемещение логики из приложения на основе холста в API-интерфейс RESTful может быть хорошим выбором, позволяющим поддерживать простоту формул в рамках приложения Power Apps на основе холста, перенося более сложную функциональность на сторону сервера. Пользовательские соединители Power Platform позволяют приложениям на основе холста использовать REST API так же, как и другой источник данных.

Совет

В статье представлен пример сценария и визуальное представление того, как использовать интерфейсы REST API для расширения функциональности приложений на основе холста. Это решение представляет собой обобщенный пример сценарной архитектуры, которую можно использовать для множества различных сценариев и отраслей.

Схема архитектуры

Рабочий процесс

Приложение на основе холста: приложение Power Apps на основе холста использует пользовательский соединитель для доступа к операциям, предоставляемым функцией Azure. Пользователь аутентифицируется в приложении с помощью Entra ID, и доступ к данным ограничен данными, к которым у пользователя есть доступ.
Пользовательский соединитель: пользовательский соединитель описывает, какие операции приложение может использовать из интерфейса REST API, который в примере реализован функцией Azure. С помощью пользовательского соединителя приложение Power Apps на основе холста может использовать логику, как и любой другой источник данных.
Приложения Microsoft Entra ID: функция Azure защищена с помощью приложения Microsoft Entra ID. В пользовательском соединителе регистрируется и настраивается второе приложение Microsoft Entra ID, чтобы разрешить приложению Power Apps на основе холста доступ к операциям функции Azure.
Функция Azure: функция Azure реализует интерфейс RESTful API, предлагая одну или несколько операций, которые доступны приложению Power Apps на основе холста путем экспорта пользовательского соединителя с портала Azure или путем ручной настройки. Функция Azure защищена регистрацией приложения Entra ID, чтобы гарантировать только авторизованных вызывающих.
Azure Cosmos DB: функция Azure может использовать Azure Cosmos DB или Azure SQL или любое другое облачное хранилище данных, необходимое для управления данными. На самом деле, функция может работать с данными в Microsoft Dataverse при использовании функционального подхода из-за сложности логики.

Компоненты

Среда Power Platform: содержит ресурсы Power Platform, например Power Apps, которые реализуют взаимодействие с пользователем приложения "В магазине". Эти ресурсы перемещаются из одной среды в другую (например, из разработки в тестирование) с помощью решений Dataverse.
Power Apps: Power Apps используется для реализации пользовательского интерфейса решения. Создатели могут создать приложение, используя пользовательский коннектор, созданный разработчиком функции Azure, в качестве источника данных приложения.
Пользовательский соединитель: пользовательские соединители Power Platform описывают операции и структуры данных интерфейса RESTful API. Они позволяют легко использовать API-интерфейс из таких ресурсов, как приложение Power Apps на основе холста. При использовании из Power Apps они позволяют ссылаться на API-интерфейс, как и на любой другой источник данных.

Подробности сценария

Power Apps позволяет организациям создавать пользовательский интерфейс, а с помощью интерфейсов REST API бизнес-логика централизована и доступна приложению с помощью настраиваемого соединителя. Такой подход также позволяет приложению Power Apps выступать в качестве интегратора нескольких серверных служб, предоставляя пользователю единое представление данных и логики из всех источников. Используя подход REST API, вы также можете перенести сложность взаимодействия с несколькими другими системами в компонент, реализующий REST API, и упростить реализацию приложения на основе холста, в то же время обеспечивая тот же пользовательский опыт.

В приведенном выше примере приложение "В магазине" создается с помощью приложения Power Apps на основе холста. Приложение позволяет сотруднику магазина быстро сохранить запрос на уведомление о невыполненном заказе для клиента, когда товар отсутствует на складе. Приложение использует одну операцию RecordBackorder, которая настраивается в пользовательском соединителе, описывающем серверную операцию функции Azure. В этом примере функция Azure является реализацией REST API. Для реализации этого паттерна можно использовать любую технологию, позволяющую создать RESTful-сервис.

Эта архитектура предлагает гибкость, но также означает, что для разработки и поддержки службы и уровня данных RESTful требуется больше усилий разработчиков кода. В общем, по мере увеличения сложности форму приложения на основе холста вам следует рассмотреть этот тип архитектуры. Например, когда для создания единого представления требуется несколько источников данных, использование слоя API-интерфейса может помочь в обеспечении высокой производительности, поскольку данные ответа могут быть сформированы на стороне сервера и доставлены клиенту более эффективно. Использование этого слоя промежуточного уровня означает, что вы можете добавить уровень кэширования на стороне сервера и реализовать более обширную телеметрию для приложения.

Рекомендации

Эти соображения реализуют основы Power Platform Well-Architected — набора руководящих принципов, повышающих качество рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Power Platform Well-Architected.

Надежность

Спроектируйте рабочую нагрузку, чтобы избежать ненужной сложности — использование подхода REST API из приложения Power Apps через пользовательский соединитель позволяет избежать ненужной сложности, а также централизовать логику там, где она может использоваться другими приложениями в организации. Пользовательский соединитель позволяет Power Apps Maker использовать операции из RESTFul API так же, как и любые другие операции с источниками данных.

Тестирование отказоустойчивости и доступности — переместив логику из приложения на основе холста в REST API, вы сможете независимо тестировать API-интерфейс отдельно от приложения, которое его использует.

Измерение и публикация индикаторов работоспособности — данные телеметрии должны быть получены из компонента REST API для отслеживания его работоспособности. Например, использование ведения журнала Azure Monitor — Application Insights обеспечит адекватное отслеживание компонента.

Группа безопасности

Создание преднамеренной сегментации и периметров — обеспечение того, чтобы приложение использовало отдельные среды Power Platform для поддержки этапов жизненного цикла приложения, и обеспечения того, чтобы только правильные пользователи имели доступ к каждому этапу, может поддерживать политики сегментации. Также важно, чтобы зарегистрированные приложения Entra ID были разделены между средами, чтобы обеспечить защиту каждого этапа данных и не смешиваться между средами.

Операционная эффективность

Внедрение методов безопасного развертывания — стандартизация развертывания любых изменений в приложении Power Apps с помощью автоматизированных процессов развертывания, таких как конвейеры. Продвигайте приложение в рабочую среду только после тестирования изменений.

Реализуйте стратегию устранения сбоев развертывания — учитывая зависимость между приложением и REST API, вы должны убедиться, что у вас есть проверенная стратегия для устранения сбоев развертывания любого из них, при котором возникают ошибки после обновления одного из компонентов.

Эффективные процессы

Проектирование в соответствии с требованиями к производительности — оцените производительность решения и объем требований, предъявляемых к данным. Оценка должна включать в себя способ доступа к данным и оценку того, как приложения Power Apps, непосредственно использующие различные источники данных, могут быть чрезмерно активными в общении с источниками данных. Это может привести к снижению производительности из-за задержки отдельного запроса, отправляемого в каждое хранилище данных. Например, если в приложении есть логика, которая работает с большим количеством строк в источнике данных, вы можете перенаправить весь этот сетевой трафик в серверную функцию Azure. Сведение к одному взаимодействию с REST API, который, в свою очередь, будет управлять взаимодействием с несколькими другими источниками данных, где это может быть сделано более эффективно.

Оптимизация логики — по мере усложнения логики в приложении на основе холста, функции Azure или аналогичные реализации RESTful API могут разгрузить эту логику в централизованную службу многократного использования. Использование возможности пользовательского соединителя для описания этих интерфейсов RESTful API позволяет приложениям на основе холста использовать настроенные операции так же, как и любой другой источник данных.

Тестирование производительности — наряду с тестированием функциональности и сбоев важно протестировать и разработать базовый уровень производительности и оценить его в рамках цикла выпуска, если API-интерфейс чувствителен к изменениям во время завершения работы.

Оптимизация взаимодействия

Проектирование с учетом эффективности — приложения, которые позволяют пользователям получать доступ к нескольким источникам данных из одного приложения Power Apps, не требуя от них взаимодействия с несколькими отдельными приложениями, делают пользователя более эффективным и представляют собой хорошее использование более настраиваемого визуального интерфейса.

Соавторы

Microsoft поддерживает эту статью. Эту статью написали следующие участники.

Основные авторы:

Мехди Слауи Андалусси (Mehdi Slaoui Andaloussi), Главный инженер-менеджер