Модернизация приложений с помощью Power Platform

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

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

Совет

Вы можете сохранить или распечатать этот технический документ, выбрав в браузере элемент Печать, затем выбрав Сохранить как PDF.

Введение

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

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

Почему Power Platform?

Комплексные инструменты и технологии, входящие в состав Power Platform, значительно снижают продолжительность, стоимость и требования к разработке проектов модернизации и цифровой трансформации. Его низкокодовый подход снижает — и даже может устранить — потребность в дорогостоящих специалистах по программированию, науке о данных и инженерной разработке ИИ. От этого выигрывают как разработчики-любители, так и профессиональные разработчики. Разработчики-любители могут принимать активное участие в процессе модернизации, создавая приложения непосредственно на основе своего опыта в предметной области и снижая свою зависимость от ИТ-команд. Профессиональные разработчики могут создавать даже сложные решения за гораздо меньшее время, что позволяет им быстрее перейти к следующему проекту.

Продукты и концепции Power Platform

Каждый продукт в семействе Power Platform имеет уникальную специализацию. Организации могут внедрять продукты по отдельности или в комбинации для удовлетворения своих конкретных требований. Продукты взаимосвязаны, образуя единое целое, вне зависимости от их комбинации.

В следующей таблице представлен общий обзор каждого продукта Power Platform.

Product	Description
Power Apps	Создавайте пользовательские приложения на интуитивно понятном холсте с помощью перетаскивания. Благодаря наличию более тысячи соединителей внутренние и внешние источники данных и сервисы находятся всего в нескольких щелчках мыши. Ваши приложения могут выполняться в веб-браузере, на компьютере или на мобильных устройствах.
Power Automate	Создавайте рабочие процессы для автоматизации даже сложных процессов. Интегрируйте внутренние и внешние источники данных и службы с помощью встроенных и настраиваемых соединителей. Используйте цифровую автоматизацию процессов (DPA), если в приложениях есть интерфейс прикладного программирования (API). Используйте роботизированную автоматизацию процессов (RPA) для автоматизации повторяющихся задач, выполняемых в браузере или классическом приложении. Запускайте рабочие потоки для выполнения при возникновении событий в других системах и службах или по расписанию для выполнения в определенное время.
Copilot Studio	Создание разговорных агентов с использованием графического интерфейса без кода. Агенты можно развертывать в нескольких каналах, включая веб-сайты, мобильные приложения и платформы обмена сообщениями, такие как Microsoft Teams. Разработка с помощью ИИ может ускорить создание тем. Генеративные ответы могут находить и представлять информацию из нескольких источников, не требуя создания тем.
Power BI	Перетаскивайте диаграммы, таблицы и другие визуальные элементы на холст, чтобы легко создавать сложные отчеты, раскрывающие аналитические сведения, скрытые в ваших данных. Включайте автоматизированное машинное обучение для прогнозного моделирования и визуализации ИИ с деревьями декомпозиции для подробного анализа первопричин. Изучайте свои данные, задавая вопросы на естественном языке в простом формате вопросов и ответов.
Power Pages	Быстро создавайте привлекательные веб-сайты на основе данных на безопасной платформе корпоративного уровня с минимальным написанием кода (SaaS). Благодаря богатым настраиваемым шаблонам и гибкому визуальному интерфейсу создавать, размещать и администрировать современные бизнес-сайты, доступные за пределами организации, стало проще.

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

Понятие	Description
Power Fx	Power Fx — это малокодовый язык с открытым исходным кодом, вдохновленный формулами Excel. Строго типизированный, декларативный и функциональный, с императивной логикой и управлением состояниями, весь выражаемый в понятном для человеке тексте, язык Power Fx упрощают обычные задачи программирования как для непрофессиональных, так и для профессиональных разработчиков. Он поддерживает полный спектр разработки, от "без кода" для тех, кто никогда раньше не программировал, до "профессионального кода" для опытных профессионалов, позволяя разным рабочим группам сотрудничать и экономить время и деньги.
Соединители	Соединители жизненно важны для совместной работы малокодового и традиционного программирования для создания современных приложений. Соединители — это оболочка вокруг API-интерфейса, которая позволяет Power Apps и Power Automate использовать внутренние и внешние источники данных и службы. Доступно более тысячи готовых соединителей, и вы можете создать свой собственный для любого RESTful API. Определение соединителя включает метаданные, необходимые для упрощения использования API малокодовыми приложениями.
Dataverse	Dataverse — это облачное гибридное хранилище данных, построенное на сервисах управления данными Azure, — но это больше, чем просто база данных. Это базовая платформа данных как для Dynamics 365, так и для Power Platform, с серверной логикой в виде рабочих процессов и подключаемых модулей, бизнес-правил и потоков процессов, очень развитой моделью безопасности и расширяемой платформой разработки со встроенной поддержкой многоязычных и мультивалютных приложений. Приложения можно быстро создавать на основе модели данных, что делает ее одним из самых быстрых способов развертывания решения для работы с формами и данными.
AI Builder	AI Builder позволяет легко использовать искусственный интеллект в Power Apps и Power Automate, чтобы производить анализ на основе ваших данных, автоматизировать процессы и сделать приложения более продуктивными. С AI Builder вам не нужны навыки программирования или обработки и анализа данных, чтобы получить доступ к возможностям ИИ. Предварительно созданные настраиваемые модели готовы к использованию во многих распространенных бизнес-сценариях, и вы можете создавать собственные модели в соответствии с конкретными бизнес-потребностями.
Copilot	Помощь ИИ Copilot делает пользователей и разработчиков Power Platform, как непрофессиональных, так и профессионалов, более продуктивными, позволяя им тратить больше времени на лучшие части своей работы и меньше времени на рутинные задачи. Опишите свой бизнес-сценарий Copilot в Power Automate, и он превратит ваше описание в автоматизированный рабочий процесс. Расскажите Copilot в Power Apps, что вы хотите сделать или какую информацию вы хотите видеть, и он сможет создать приложение для этого. Copilot настраивает подключения, создает и заполняет таблицы, генерирует экраны и даже предлагает предложения по улучшению вашего потока или приложения. В ваши приложения с первого экрана будут встроены интерфейсы на основе Copilot, чтобы пользователи могли получать ценную информацию в ходе разговора.
Среды и решения	Среды — это границы, которые содержат ресурсы Power Platform и упрощают управление ими и их защиту. Они также используются в управлении жизненным циклом приложений (ALM), когда решения разрабатываются и тестируются в отдельных средах перед развертыванием в рабочей среде. Решения представляют собой упакованные настройки и расширения Power Platform. Решение может включать приложения, потоки, таблицы, диаграммы, панели мониторинга, соединители и другие компоненты, необходимые для настройки или расширения. Решения можно разрабатывать, тестировать и развертывать для работы в отдельных средах в рамках политики ALM организации. Вы можете экспортировать решения, чтобы поделиться ими с другими пользователями или организациями, а также импортировать решения от других пользователей. Решения бывают управляемыми или неуправляемыми. Для разработки и тестирования используются неуправляемые решения. Управляемые решения используются для рабочего развертывания и распространения.

Основные преимущества Power Platform для модернизации приложений

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

• Снижение затрат. Организации могут сэкономить деньги на разработке и обслуживании приложений. Исследование, проведенное по заказу Forrester Consulting, показало, что организации, использующие Power Platform, могут снизить затраты на разработку приложений на 45% и получить 140% окупаемости своих инвестиций.

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

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

• Сокращение технического долга. Затраты — как в финансовом отношении, так и в виде упущенных возможностей — на обновление «быстрых и грязных» программных решений и поддержание устаревшей инфраструктуры высоки. Power Platform сокращает этот технический долг, упрощая и удешевляя создание решений с первого раза, упрощая интеграцию данных и управление ими с помощью общей модели данных и соединителей, предоставляя централизованную платформу для управления решениями и поддерживая непрерывное совершенствование с помощью аналитики и искусственного интеллекта.

• Повысьте безопасность и обеспечьте соответствие нормативным требованиям. Все продукты Power Platform включают в себя полностью интегрированные средства безопасности корпоративного уровня, соответствия требованиям и управления «из коробки», начиная со сред, в которых они работают. Управляемые среды — это набор инструментов, которые позволяют администраторам управлять Power Platform в большом масштабе с большим контролем и меньшими усилиями. Помимо прочих возможностей, вы можете ограничить круг лиц, которые могут предоставлять общий доступ к тем или иным потокам и приложениям, ограничить круг лиц, с которыми можно делиться теми или иными потоками и приложениями, а также использовать политики для ограничения соединителей, которые могут использовать создатели. Нативные, гибкие модели безопасности данных означают, что каждому приложению не нужно создавать свои собственные.

• Модернизируйте по мере использования. Чем более важны приложения, которые вы хотите модернизировать, тем меньше вероятность того, что вы захотите заменить их все сразу. Малокодовый подход хорошо подходит для создания решений в управляемых шагах.

• Интегрируйте старые приложения. Старые приложения часто не имеют API-интерфейсов. Возможности RPA Power Platform позволяют автоматизировать классические приложения и включить их в новые современные бизнес-процессы. RPA также может быть полезна для постепенной модернизации больших и сложных приложений.

• Внедряйте инновации, не тратя больше. Возможности Power Platform продолжают совершенствоваться. Приложения, созданные на платформе, выигрывают от инноваций Microsoft без дополнительных затрат для вас.

• Повысьте производительность труда на современном рабочем месте. Power Platform является частью современной рабочей области Microsoft. Приложения, модернизированные на платформе, могут использовать такие возможности Microsoft 365, как привлекательный мобильный интерфейс и простая, интуитивно понятная совместная работа. Передовые технологии искусственного интеллекта, такие как Copilot, AI Builder и функции, о которых скоро будет объявлено, делают пользователей и разработчиков более продуктивными с меньшим разочарованием и более простыми схемами обучения.

Инновация для работника передней линии

Сотрудникам первой линии нужны современные приложения, которые можно использовать на любом устройстве и где бы они ни работали. Им нужен доступ к аналитике в режиме реального времени, чтобы быстрее принимать лучшие решения. Они должны сотрудничать с коллегами и руководством, чтобы все работало без сбоев. Когда American Airlines решила модернизировать некоторые аспекты своей деятельности, они получили все это и даже больше.

В партнерстве с Microsoft компания American Airlines создала ConnectMe, — приложение Microsoft Teams, построенное на Power Apps и Azure. Используя приложение на любом мобильном устройстве, команды первой линии имеют под рукой ключевую информацию о прибытии, посадке, багаже и выходе на посадку в режиме реального времени, оптимизируя наземные операции, ускоряя время разворота воздушных судов и делая путешествия более приятными для клиентов. Узнайте больше о трансформации авиакомпании.

Расширение возможностей ИИ для работников умственного труда

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

Постепенный переход к модернизации устаревших приложений

Если ваша организация похожа на большинство, у вас есть растущий список устаревших приложений, которые выиграют от модернизации. Устаревшие приложения, как правило, используют устаревшие технологии и построены на инфраструктуре (аппаратном и программном обеспечении), которая больше не поддерживается. Часто лишь немногие сотрудники, как правило, те, кто приближается к пенсии, знают, как они работают. Новые сотрудники не хотят иметь с ними ничего общего, потому что они не могут использовать современные инструменты, к которым они привыкли или с которыми хотят работать. Их обслуживание, не говоря уже об их обновлении, требует преодоления горы технического долга, который становится все выше по мере того, как вы поднимаетесь. Годы, а возможно, и десятилетия лоскутного обслуживания приводят к созданию кодовой базы, к которой никто не осмеливается прикоснуться, особенно когда на нее полагается большая часть бизнеса.

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

Варианты модернизации приложений

Модернизация не всегда означает пересоздание устаревшего приложения с нуля. Другими вариантами являются вывод его из эксплуатации, замена, повторное размещение, рефакторинг и изменение архитектуры.

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

Окончание срока жизни

Перенос

Модернизация

Списать

Replace

Рехостинг

Рефакторинг

Перепроектирование архитектуры

Перестройка

Описание:

Удаление приложения

Замена приложения на SaaS или другое приложение

Повторное развертывание "как есть" в облаке

Оптимизация существующего кода

Перенос кода на новую архитектуру приложения или разбиение его на микросервисы

Переписывание приложения с нуля с исходной областью действия и спецификациями

Драйверы

Больше не нужен

Сокращение расходов

Сокращение капитальных затрат

Воспользуйтесь преимуществами новых технологий

Сокращение капитальных затрат

Восстановление хранилища данных

Быстрая окупаемость инвестиций в облако

Более быстрые и короткие обновления

Более переносимый код

Повышение эффективности использования ресурсов, скорости и затрат в облаке

Повышение производительности

Сокращение технического долга

Повышение масштабируемости, надежности и удобства обслуживания

Упрощение внедрения новых облачных возможностей

Смешанные стеки технологий

Ускорение инновации

Ускорение разработки

Снижение эксплуатационных расходов

Технологии Microsoft

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Контейнеры

Azure PaaS

Power Platform

Azure PaaS

Бессерверные микросервисы

Power Platform

Azure PaaS

Бессерверные микросервисы

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

Вариант	Description
Рехостинг	Рехостинг перемещает приложение без изменений из старой среды в новую. Малокодовый подход не применяется напрямую, но рехостинг может быть первым шагом перед применением других стратегий, которые будут включать малокодовые решения.
Рефакторинг или изменение архитектуры	Рефакторинг настраивает код таким образом, чтобы приложения могли получить максимальную выгоду от облачной среды. Изменение архитектуры значительно модифицирует код. Это может включать в себя инкапсуляцию существующей логики путем ее перемещения в API-интерфейс, который может быть предоставлен малокодовым решениям через соединитель.
Замена или перестроение	При замене приложение заменяется другим. При перестроении приложение воссоздается с нуля. Этот вариант обычно используется в тех случаях, когда подход с минимумом кода позволяет достичь наилучших бизнес-результатов. Начало работы с приложением из Dynamics 365 или Microsoft AppSource может помочь быстро начать модернизацию, если сценарий использования соответствует предварительно созданной возможности. Затем организации могут использовать компоненты Power Platform для настройки приложения в соответствии со своими уникальными потребностями.

Малокодовый подход Power Platform потенциально может предложить гораздо больше, чем просто еще один инструмент разработки. Включение малокодового подхода в стратегию современного приложения также может заложить основу для участия в модернизации сотрудников, не являющихся разработчиками, таких как эксперты в предметной области. Организации обнаружили, что создание Центра передового опыта (CoE) в Power Platform и использование таких инструментов, как начальный набор CoE, для создания рекомендаций и управления помогает пользователям успешно создавать малокодовые приложения и средства автоматизации, а также обеспечивает повторное использование таких ресурсов, как API-интерфейсы и компоненты. Малокодовый подход может ускорить разработку приложений и помочь организациям быстрее извлекать пользу из своих данных, независимо от того, где они находятся. На самом деле, многие организации решают интегрировать малокодовое мышление в свою культуру.

Руководство по модернизации

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

1. Планирование. Тщательно продумайте цели модернизации устаревшего приложения и определите стратегию их достижения. Четко сформулируйте проблему, которую вы хотите решить с помощью модернизации. Сейчас самое время оценить свои приложения и среды с точки зрения того, что не работает, что работает, но может быть улучшено, и, — что самое важное, — какую ценность для бизнеса или пользователей представляют любые изменения. Оцените каждую возможность модернизации на предмет ее потенциала для использования преимуществ малокодового подхода. Отдавайте приоритет возможностям, включающим решения с минимумом программирования. Используйте Средство оценки стратегии внедрения облака, чтобы создать экономическое обоснование модернизации приложений.

2. Внедрение. Модернизируйте свои приложения не только постепенно, но и итеративно. Итеративный подход дает организациям возможность гибко изменять объем проекта или стратегию по мере необходимости. Малокодовые решения Power Platform можно разрабатывать и тестировать быстрее, чем приложения традиционной разработки, а для развертывания в управляемых средах требуется всего несколько шагов. Несмотря на то, что малокодовый подход требует меньше повышения квалификации, чем традиционное кодирование, убедитесь, что ваши сотрудники должным образом обучены тому, как работать в смешанных командах, которые сочетают малокодовые и традиционные ресурсы.

3. Операции. Модернизация приложения не ограничивается внедрением. Благодаря малокодовому подходу, ориентированному на облако, вы можете использовать службы и инструменты облачной платформы для обеспечения безопасности, управления и оптимизации приложений.

Оценка возможностей для малокодовых решений

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

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

Например, если вы определили, что приложение не подходит из-за того, что в Power Apps отсутствует обязательный элемент управления, вы можете использовать Power Apps component framework (PCF) и традиционный код для создания пользовательского элемента управления. Другой пример — приложение со сложной логикой. Логику можно централизовать в API-интерфейсе, доступ к которому из Power Apps осуществляется с помощью пользовательского соединителя. В обоих этих примерах расширяемость Power Platform позволила создать большую часть приложения с использованием малокодовых компонентов, заполнив пробелы с помощью традиционно разработанного кода.

NSure.com, собственная онлайн-платформа для покупки страховых полисов, предлагает реальный пример. Первоначальный запуск компании опирался на традиционно разработанные сервисы Angular, Xamarin и Azure. Добавив Power Platform и Dynamics 365, NSure.com создали решение следующего поколения, используя как малокодовые, так и традиционные методы программирования, как показано на следующей схеме. Узнайте больше о пути развития компании.

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

Сценарии клиентской части, которые не подходят для подхода с минимумом кода

Сценарий	Задача
Пользовательское устройство несовместимо	Power Platform распознает мобильные устройства и специализированные устройства, такие как сканеры штрих-кодов. Устройства, зависящие от определенных API-интерфейсов или драйверов, могут не поддерживаться и требовать более традиционного подхода.
Большой объем данных на стороне клиента	Пользовательский интерфейс в некоторых приложениях требует больших объемов данных, что является проблемой для любой технологии, а не только для малокодового подхода. Загрузка и обработка такого большого количества данных может привести к нагрузке на серверные системы и снижению производительности как приложения, так и устройства, на котором оно работает. Пользователи не так продуктивны, когда им приходится ориентироваться в море данных. Прежде чем переходить к традиционным методам программирования для обработки нагрузки, изучите, могут ли правильная фильтрация и навигация обеспечить лучшее взаимодействие с пользователем.
Сложные автономные требования	Приложения, которые должны работать в местах с плохим подключением или его отсутствием, могут быть сложными в реализации и поддержке, независимо от того, используют ли они малокодовый подход или традиционный код. Power Apps предлагает базовые возможности для простых автономных сценариев. Например, приложение, которое собирает интересы во время события и загружает их в маркетинговую базу данных после события, будет работать нормально. Для приложений, в которых требуются файлы и изображения, соединители, не относящиеся к Dataverse, или сложное разрешение конфликтов, следует обратиться к традиционным методам программирования.

Сценарии серверной части, которые не подходят для подхода с минимумом кода

Сценарий	Задача
Высокоскоростные данные	Обычно поддерживается импорт миллионов строк данных в рамках миграций и аналогичных событий. Однако рабочие нагрузки, включающие ежечасную или ежедневную обработку миллионов строк данных, должны подвергаться более тщательной оценке. Например, сбор больших объемов телеметрии Интернета вещей (IoT) в Dataverse не имеет смысла. Вместо этого облачные сервисы Azure можно использовать для сбора и анализа данных и соответствующих сигналов, добавленных в Dataverse, для запуска действий в приложении. Приложениям, которые регулярно обновляют данные большого объема в Dataverse, может потребоваться помощь традиционного программирования для масштабирования обновлений.
Фоновые рабочие нагрузки со сложной логикой	Фоновые рабочие нагрузки, связанные со сложной логикой или большим объемом вызовов API, могут не подойти для решения с минимумом кода. Вместо этого логика может быть централизована в API, который может быть вызван малокодовым решением.
API-интерфейсы, использующие протоколы, отличные от RESTful	Соединители Power Platform поддерживают только API-интерфейсы REST. Если вам нужно подключиться к API другого стиля, например SOAP или gRPC, предоставьте свой собственный REST API, который взаимодействует с несовместимым.

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

Приоритет малокодовых возможностей

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

При расстановке приоритетов следует учитывать следующие факторы:

• Зрелость вашей организации в использовании малокодовых платформ
• Сложность возможности
• Окупаемость инвестиций для организации, пользователей и ИТ-отдела
• Время ввода в эксплуатацию

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

Приложения со сложной интеграцией с другими системами часто не являются лучшим местом для старта. Попытка справиться со слишком большими или слишком сложными приложениями может привести к разочарованию и сбою. Избегайте любых сомнительных малокодовых кандидатов. Сохраните их после того, как ваша команда завершит несколько успешных модернизаций.

При модернизации большого монолитного приложения подумайте, можно ли модернизировать небольшие его части постепенно. Раньше монолитные приложения были обычным явлением. Сейчас более распространены небольшие приложения, ориентированные на роли или задачи. Они позволяют поэтапно разрабатывать, улучшать и масштабировать команды, которые их создают.

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

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

Организуйте и повышайте квалификацию своих команд

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

Команда, состоящая из малокодовых ресурсов, работающих наряду с традиционными ресурсами кода, называется смешанной командой. Смешанные команды предназначены для поощрения совместной работы путем обучения обоих типов ресурсов интеграции малокодовых решений с традиционным кодом. Архитектор решений определяет, как будет построено решение между малокодовым и традиционным кодом.

Несмотря на то, что по умолчанию легко поручить всю работу традиционным разработчикам, малокодовая модернизация — это хорошая возможность расширить проектную команду. Многие бизнес-пользователи создают отличные ресурсы с минимумом программирования. Они могут ускорить работу команды, потому что уже понимают бизнес-задачу. Им просто нужно научиться выполнять малокодовую работу, которую берет на себя команда, и быть знакомыми с процедурами тестирования и управления жизненным циклом. Это может означать изучение того, как создавать приложения в Power Apps или рабочие процессы в Power Automate. Они также должны понимать, что могут разработать традиционные программисты, чтобы упростить их работу с минимумом кода. Это не значит, что они должны знать, как писать традиционный код.

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

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

Сбор требований

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

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

Не работайте с нарушением малокодовых подходов

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

Команды, которые привыкли работать с традиционным кодом, могут попытаться свести к минимуму использование малокодового подхода. Например, вместо того, чтобы использовать элементы управления Power Apps, команда может создать приложение из элементов управления Power Apps component framework, чтобы по возможности избежать использования малокодового подхода. Командам лучше всего зайти как можно дальше с помощью малокодового подхода, пока они не столкнутся с препятствиями, которые невозможно обойти. Команды, которые учатся использовать возможности платформы, более успешны в достижении максимальных преимуществ малокодового подхода. Малокодовый подход становится все более способным взять на себя то, что раньше было возможно только с традиционным кодом. Распространенной проблемой в прошлом было застревание из-за того, что малокодовый подход не мог воспроизвести некоторые необходимые функции. Эта проблема решается Power Platform с помощью параметров расширяемости, которые позволяют в основном малокодовым приложениям включать специализированные компоненты, написанные в традиционном коде, когда это необходимо.

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

В последние годы малокодовые платформы быстро развиваются. Несмотря на то, что они всегда хорошо справлялись с поддержкой сценариев повышения индивидуальной производительности, в последнее время основное внимание уделяется корпоративным возможностям. Организации создают малокодовые приложения, которые поддерживают современное рабочее место, включая гибридную работу (удаленную и очную) и сопутствующую потребность в способах поощрения совместной работы. Малокодовые платформы, такие как Power Platform, могут масштабироваться для работы с приложениями, на которые могут полагаться все пользователи в организации и которые могут быть интегрированы в корпоративные модели безопасности. Подключая возможности малокодового подхода к корпоративной инфраструктуре, вы можете использовать малокодовые методы параллельно с традиционными методами. Малокодовый подход абстрагирует большую часть сложностей и позволяет более широкому кругу людей участвовать в создании решений.

Понимание структуры затрат при малокодовом подходе

Распространенный вопрос, который задают организации, когда они рассматривают возможность модернизации, заключается в том, сколько это будет стоить? Несмотря на то, что полное обсуждение лицензирования и анализа затрат выходит за рамки данной статьи, мы можем рассмотреть эти темы на высоком уровне.

Продукты Power Platform являются лицензируемыми продуктами. Вы можете лицензировать их по отдельности в соответствии с вашими требованиями. Вы можете настроить выставление счетов Azure для оплаты по мере использования, что позволяет использовать продукты без предварительных лицензионных обязательств или покупки и включает в себя некоторый объем использования в приложении Power Automate. Кроме того, для Power Automate имеется лицензирование по числу пользователей и по числу потоков для изолированной работы. Лицензирование по потокам хорошо работает, если у вас есть автоматизация, которая приносит пользу всей организации. Лицензии Power Apps могут быть на пользователя или на приложение. Сайты Power Pages лицензируются на пользователя, сайт или месяц. Для сайтов, прошедших проверку подлинности, требуется дополнительная лицензия. Все лицензии включают в себя использование соединителей и Dataverse, с возможностью лицензировать дополнительное хранилище и запросы API для сценариев с большими объемами данных.

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

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

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

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

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

Взгляд внутрь Power Platform

Компоненты Power Platform построены на тех же облачных сервисах Microsoft Azure, которые доступны при использовании традиционных методов программирования. Интеграция этих компонентов друг с другом, а также с функциями безопасности, масштабируемости и аварийного восстановления была выполнена за вас.

Внутри Dataverse

Dataverse работает на базе более чем 25 полностью управляемых служб Azure, таких как Functions, Load Balancer, Cognitive Services, Synapse, DevOps, Active Directory и Microsoft Purview. Встроенные возможности включают комплексную безопасность, мощную аналитику, искусственный интеллект, расширенную бизнес-логику и обработку событий, моделирование данных, интеграцию с Dynamics 365, Microsoft 365, Azure и многое другое. Все эти возможности построены на многоязычном уровне хранилища Dataverse, который основан на Azure SQL DB (для реляционных данных), Azure Cosmos DB (для NoSQL), Azure Blob Storage (для файлов) и Azure Data Lake Storage Gen 2 (для крупномасштабной аналитики и долгосрочного хранения данных). Они доступны для прозрачного использования в малокодовых компонентах Power Platform и через REST API Dataverse.

Высокая доступность, непрерывность бизнес-процессов и аварийное восстановление (BCDR) важны для критически важных бизнес-приложений. Dataverse максимизирует доступность с помощью служб обеспечения надежности Azure. Репликация первичного и вторичного серверов выполняется синхронно, с структурой под ними, которая может обнаруживать сбои и выбирать новый первичный сервер в соответствии с протоколами корректности. Отработка отказов с высоким уровнем доступности, которая происходит в регионе Azure, происходит легко и редко замечается пользователями, обычно за считанные секунды. Им гарантирована нулевая потеря данных независимо от того, является ли сбой плановым или незапланированным.

Отработка отказов с аварийным восстановлением происходит в двух регионах Azure. Чтобы обеспечить более быструю отработку отказа с минимальной потерей данных, непрерывная копия аварийного восстановления поддерживается с помощью асинхронной репликации. Плановая отработка отказа не влечет за собой потери данных и в производственных средах обычно может быть завершена за секунды или несколько минут.

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

Внутри Power Automate

Облачные потоки Power Automate построены на основе Azure Logic Apps. Power Automate предоставляет абстракции и интеграцию с другими малокодовыми компонентами, такими как Power Apps, и использует механизм среды выполнения Logic Apps. Разработчики, знакомые с Logic Apps, обнаружат, что Power Automate использует похожие концепции, включая язык выражений.

Внутри Power Apps

Механизм времени выполнения Power Apps построен на фреймворке React. Приложения создаются в конструкторе Power Apps, который использует интерфейс перетаскивания для создания экранов. Формулы Power Fx реализуют логику. Соединители расширяют доступ приложений к другим службам, логике и компонентам, которые позволяют повторно использовать визуальные расширения. Разработчики могут использовать инфраструктуру Power Apps component framework (PCF) для создания пользовательских элементов управления. В то время как многие фреймворки пользовательского интерфейса могут использоваться вместе с PCF, Power Apps имеет встроенную поддержку React.

Внутри соединителей

Соединители используют управление Azure API для управления учетными данными и подключениями каждого пользователя.

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

Исключение составляет соединитель Dataverse. Он отображается в списке соединителей для приложений и потоков, но реализован по-другому. Когда приложение или поток использует данные или действия Dataverse, взаимодействие происходит напрямую через API OData Dataverse.

Параметры расширяемости Power Platform

Расширяемость — это ключевая функция, которая отличает Microsoft Power Platform от других малокодовых платформ. Руководящим принципом платформы является «никаких обрывов» — вам не должно мешать делать что-то с помощью малокодового подхода, даже если для этого требуется традиционный код. При необходимости вы можете создать всю рабочую нагрузку как часть более крупного приложения, используя традиционный код. Тем не менее, платформа предлагает множество вариантов расширяемости, которые позволяют использовать малокодовый и традиционный код вместе в одной рабочей нагрузке.

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

Вариант	Description
API-интерфейсы и настраиваемые соединители	Настраиваемые соединители для REST API централизуют логику приложения и позволяют предоставлять его компонентам с минимумом кода безопасным и управляемым способом. Этот подход можно использовать в стратегии модернизации приложений с приоритетом API. Пользовательский соединитель использует документ OpenAPI для определения того, как малокодовый компонент может взаимодействовать с API-интерфейсом REST. Например, можно создать API с помощью Функций Azure и опубликовать его в Управление API Azure. Управление Azure API может экспортировать определение OpenAPI для автоматического создания пользовательского соединителя для использования в малокодовом решении. Такой подход отделяет клиентские приложения от API-интерфейсов, позволяя им развиваться независимо друг от друга. API-интерфейсы управляются централизованно, что добавляет уровень безопасности, не предоставляя API напрямую и используя методы проверки подлинности, такие как ключи подписки, маркеры, сертификаты клиента и пользовательские заголовки.
Power Apps component framework	Power Apps Component framework — это инфраструктура расширяемости для создания пользовательских визуальных элементов для Power Apps и Power Pages. Компоненты кода создаются с помощью HTML, JavaScript или TypeScript. Компоненты кода следует рассматривать как стандартные блоки пользовательского интерфейса, которые можно повторно использовать для создания одного или нескольких приложений. Компоненты включают манифест, который определяет, как компонент с минимумом кода может взаимодействовать с компонентом кода. Интерфейс компонента позволяет механизму среды выполнения размещения передавать события жизненного цикла контейнера размещения. Это позволяет компоненту кода отображать свои визуальные элементы, используя контекстную информацию, предоставляемую контейнером размещения. Для поиска идей можно просмотреть галерею сообщества по адресу https://pcf.gallery.
Виртуальные таблицы	Виртуальные таблицы упрощают интеграцию данных, хранящихся во внешних системах. Они бесшовно представляют внешние данные в виде таблиц Microsoft Dataverse, без репликации данных и часто без необходимости пользовательского программирования. Dataverse поставляется с поставщиками данных для OData v4 и Azure Cosmos DB. Поставщик виртуальных соединителей, в настоящее время доступный в предварительной версии, расширяет список доступных поставщиков данных, включая подмножество соединителей Power Platform, в том числе SharePoint и SQL Server. Для более сложных сценариев разработчики могут создавать пользовательские поставщики данных. Создание пользовательских поставщиков данных требует глубоких знаний как внешних данных, так и Dataverse. Возможность создавать подключаемые модули Dataverse с помощью Power Fx для логики доступна в предварительной версии.
Подключаемые модули Dataverse	Подключаемый модуль Dataverse — это пользовательский обработчик событий, который выполняется в ответ на определенное событие. Подключаемые модули можно сравнить с хранимыми процедурами в ядре СУБД, но написанными на .NET. Например, события создаются во время обработки операции с данными Microsoft Dataverse или по запросу для пользовательских событий API-интерфейса. Подключаемый модуль реализован в виде пользовательского класса, скомпилированного в сборку .NET Framework, которую можно отправить и зарегистрировать в Dataverse. Используя определенный интерфейс, подключаемый модуль может получить контекстную информацию об обрабатываемом событии. Подключаемые модули могут выполняться как часть транзакции Dataverse и могут выполнять другие операции с данными, которые являются частью текущей транзакции. Подключаемые модули предназначены для небольших единиц работы. Их производительность должна быть оптимизирована, чтобы они не оказывали негативного влияния на общую производительность. Подключаемые модули выполняются всегда, независимо от операций из пользовательского интерфейса или API, что делает их мощным способом согласованного применения бизнес-логики.

Изучение сценариев малокодовой архитектуры модернизации

Как и в случае с большинством платформ, вы можете создавать бесконечное количество архитектурных сценариев, используя компоненты Power Platform и другие облачные службы Microsoft. В этом разделе документа мы рассмотрим некоторые из наиболее распространенных сценариев и обсудим некоторые соображения, которые следует иметь в виду при их использовании.

Взаимодействие с приложениями

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

Power Apps

Рабочие нагрузки должны быть спроектированы таким образом, чтобы пользователи могли выполнять большую часть своей работы, не переключаясь между приложениями. При модернизации большого монолитного приложения можно разделить его функциональность на несколько приложений. И наоборот, если пользователям необходимо работать с несколькими приложениями, их можно объединить в одно приложение, которое предоставляет единое представление нескольких источников данных.

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

Тип приложения	Description
Приложения на основе холста	Приложения на основе холста обладают широкими возможностями настройки. Они состоят из одного или нескольких экранов, с которыми взаимодействуют пользователи. Вы управляете макетом каждого экрана и навигацией по экранам. Приложения на основе холста работают с данными с использованием соединителей. Одно приложение может работать с несколькими соединителями, что делает его удобным для интеграции с несколькими источниками данных в качестве составного приложения.
Приложения на основе модели	Приложения на основе модели используют Dataverse в качестве основного источника данных. Они состоят из одной или нескольких страниц, которые могут быть таблицами Dataverse или пользовательскими страницами. Страница таблицы Dataverse может быть детализирована до страницы сведений для просмотра и редактирования. Пользовательские страницы могут включать экран приложения на основе холста и данные из соединителей. Приложения на основе модели имеют настраиваемую встроенную структуру навигации. Она согласована во всех приложениях на основе модели, что помогает пользователям адаптироваться.

На следующей схеме показана базовая архитектура приложения на основе холста или приложения на основе модели, в которой приложение подключается непосредственно к источникам данных.

Чтобы свести к минимуму прямые подключения к источнику данных, можно настроить приложение на использование пользовательского соединителя с API, который выполняет всю необходимую работу в источнике данных. Такой подход позволяет контролировать, какие операции доступны компонентам с минимумом кода, и абстрагироваться от сложности базовой логики. На следующей схеме показан этот подход с приоритетом API.

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

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

Power Pages

Основным источником данных для Power Pages является Dataverse. Когда вы добавляете страницы на веб-сайт, вы сохраняете определения страниц в Dataverse. Страницы могут как представлять данные Dataverse, так и собирать данные от пользователей для хранения в таблице Dataverse.

Страницы можно настроить для анонимного доступа или для доступа с проверкой подлинности с помощью Microsoft Entra ID для внутренних пользователей или поставщиков удостоверений для внешних пользователей. Когда аутентифицированные пользователи получают доступ к данным, доступны только те данные, на доступ к которым у них есть разрешение.

Распространенным применением сайта Power Pages является предоставление внешним пользователям самостоятельного доступа к бизнес-процессам организации. Внутренние пользователи могут пользоваться приложением Power Apps. Такая архитектура показана на следующей схеме.

Управление данными

Модернизация приложения требует оценки данных, используемых в решении в целом. Модернизированные приложения имеют множество вариантов обработки данных. Во многих случаях несколько приложений используют один и тот же репозиторий данных. Перенос данных в новый репозиторий в рамках модернизации одного из приложений становится затруднительным. Основной принцип Power Platform заключается в том, что данные можно использовать там, где они есть, или переносить на платформу в Dataverse или озеро данных.

У вас есть следующие варианты архитектуры данных модернизированного приложения:

• Оставьте данные на месте: используйте соединители или API-интерфейсы с пользовательскими соединителями для доступа к данным там, где они находятся. Если данные находятся в локальной среде, шлюз данных может обеспечить безопасное подключение. Используйте виртуальные таблицы для интеграции совместимых внешних данных в виде таблицы Dataverse.

• Миграция в Dataverse: Dataverse является хорошим вариантом для транзакционных данных и для консолидации нескольких источников в единую систему записей. Данные можно сопоставлять и переносить из многих источников с помощью Power Query и автоматизированных потоков. Dataverse также поддерживает эластичные таблицы, предназначенные для приема больших объемов данных, хранящихся в неструктурированных или частично структурированных форматах.

• Миграция в озеро данных: для исторических, аналитических данных или данных телеметрии используйте озеро данных. Данные в озере можно использовать для создания аналитики Power BI или обрабатывать для получения аналитических сведений на основе искусственного интеллекта.

При оценке вариантов архитектуры данных модернизированного приложения учитывайте следующие моменты:

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

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

• Консолидация данных: в рамках модернизации приложений часто выявляются данные, которые не имеют четкого владельца или ответственности за обеспечение их надлежащего использования. Консолидируя свои данные в Dataverse, организации могут улучшить управление ими и обеспечить их надлежащее использование.

• Конфиденциальность и безопасность данных: вы должны оценивать конфиденциальность и безопасность на основе текущих потребностей и целевой архитектуры модернизации, а не только на основе того, как устаревшее приложение обрабатывали их. Облачные решения имеют больше возможностей для реализации элементов управления конфиденциальностью и безопасностью. Часто их можно упростить с помощью одного хранилища данных. Кроме того, необходимо подумать о том, как реализовать единую безопасность данных в гибридных приложениях, которые разделяют данные между несколькими репозиториями.

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

Для каждого модернизируемого приложения следует определить архитектуру данных. Первым шагом является формирование общего видения того, как ваши архитектуры данных интегрируются с Dataverse. Если цель состоит в том, чтобы максимизировать ценность малокодового решения, то вы должны использовать Dataverse везде, где это возможно. Наличие видения на начальном этапе поможет вам избежать распространения большего количества изолированных хранилищ данных.

Внешние данные и Dataverse

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

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

На следующей схеме показано использование виртуального соединителя.

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

Следующие соображения помогут вам оценить использование виртуальных таблиц в проектах модернизации.

• Все внешние источники данных должны иметь первичный ключ, и поставщик данных должен представлять его Dataverse в виде идентификатора GUID. Ключи, отличные от GUID, можно использовать с заполнением, если значение дополнения является стабильным и уникальным.
• Безопасность данных настраивается на уровне виртуальной таблицы. Безопасность на уровне строк и столбцов недоступна.
• Производительность виртуальных таблиц зависит от поставщика данных, API внешнего источника данных и подключения к источнику данных. В большинстве случаев доступ к виртуальным таблицам происходит медленнее, чем к локальным таблицам Dataverse.
• Некоторые функции Dataverse, такие как поиск, аудит, диаграммы и панели мониторинга, а также автономный доступ, недоступны для виртуальных таблиц.
• Использование виртуальных таблиц для справочных данных может привести к снижению синхронизации.

Файлы и изображения

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

Использование Dataverse для файлов и изображений уместно, когда они имеют прямую связь с данными и нескольким пользователям не нужно совместно работать над ними, например, фотография продукта или местоположения или окончательный вариант юридического контракта. Однако, если нескольким пользователям необходимо изменить юридический контракт одновременно, использование SharePoint обеспечит более широкие возможности для совместной работы. Рассмотрите возможность использования хранилища BLOB-объектов Azure напрямую, если вам нужно управлять безопасностью отдельно от Dataverse или если вам нужно использовать определенные функции, относящиеся к файлам.

Интеграции

Модернизация приложений часто включает в себя интеграцию с внутренними или внешними системами. Интеграции можно разделить на данные, приложения или процессы.

• Интеграция данных объединяет данные из разных источников, чтобы предоставить пользователю единое представление. Она предлагает независимый подход, но не позволяет строить логику или процессы в режиме реального времени. Производительность может быть выше, так как все данные являются локальными.

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

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

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

Следующие соображения помогут вам оценить, как реализовать существующие интеграции:

• Нужна ли еще интеграция? Нередки случаи, когда результаты интеграции уже никто не используют, и ее можно упразднить.

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

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

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

• Microsoft Teams: приложения Power Apps на основе холста и агенты Copilot Studio можно внедрять в каналы Teams. С помощью соединителя Teams приложения и потоки могут легко публиковать и использовать сообщения Teams. Карточки Power Apps можно использовать как микроприложения для обмена полезной информацией в канале Teams.

• SharePoint: приложения Power Apps на основе модели можно настроить для подключения к документам, хранящимся в библиотеке SharePoint, чтобы сделать их доступными в строке Dataverse. С помощью Microsoft Списки или списка SharePoint пользователи могут запускать потоки Power Automate в контексте элемента списка.

• Power BI: аналитика Power BI может отображаться в контексте приложения Power Apps на основе холста. Вы можете внедрить приложение на основе модели в отчет Power BI, чтобы пользователи могли выполнять действия на основе аналитических сведений, не покидая Power BI.

Использование Dataverse в качестве основного репозитория данных для модернизированного приложения предоставляет несколько встроенных возможностей, которые могут быть полезны для интеграции.

• Пользовательские API-интерфейсы Dataverse можно использовать для входящей интеграции на уровне приложений. Пользовательские API предоставляют уникальную операцию, связанную с небольшим объемом пользовательской логики кода. Например, отправляющая система может использовать пользовательский API-интерфейс RequestNewProject, и связанная с ним логика будет знать, как поместить полученные данные в соответствующие таблицы Dataverse. Отправляющая система будет абстрагирована от структуры таблицы Dataverse.

• Исходящая интеграция может быть выполнена с помощью предусмотренных в Dataverse возможностей публикации событий. Dataverse можно настроить для публикации в служебной шине Azure, центрах событий Azure или любом приемнике веб-перехватчика. Например, при создании новой строки таблицы Dataverse проекта она может быть опубликована в очереди служебной шины Azure. Кроме того, можно опубликовать дополнительные концептуальные события, соответствующие событию бизнес-процесса. Например, можно определить и опубликовать события завершения проекта.

На следующей схеме показан пример входящих и исходящих событий в среде Dataverse.

Организациям также следует рассмотреть готовые варианты интеграции, доступные у сторонних поставщиков в Microsoft AppSource. Например, у Microsoft есть готовое решение для организаций, которым необходимо интегрировать SAP с Power Platform. Это готовое решение включает в себя приложения и потоки, а также добавляет новые функции, которые упрощают взаимодействие между системой SAP вашей организации и Power Platform.

Например, компания Ernst & Young использовала готовую интеграцию с SAP для быстрой разработки решения для оптимизации высокочастотного глобального финансового процесса. На следующей схеме решения PowerPost организации показано, как финансовые пользователи разносят документы в главной книги системы SAP ERP с помощью Power Platform.

Варианты подключения интеграции

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

• Шлюзы данных позволяют малокодовым компонентам из Power Apps, Power Automate и Power BI обращаться обратно к локальным ресурсам для поддержки гибридных сценариев интеграции. Шлюзы позволяют модернизированным малокодовым приложениям быстро получать доступ к источникам данных, которые по-прежнему находятся в локальной среде. С помощью шлюза можно подключаться к локальным данным из таких источников, как локальная файловая система, DB2, Oracle, SAP ERP, SQL Server и SharePoint. Один шлюз может поддерживать несколько пользователей и доступ к нескольким источникам. Вы также можете настроить шлюзы данных в виде кластеров для обеспечения высокой доступности.

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

  

• Шлюзы данных виртуальной сети позволяют потокам данных Power BI и Power Platform подключаться к службам данных в виртуальной сети Azure без необходимости использования локального шлюза данных на виртуальном компьютере внутри виртуальной сети.

• Приватный канал Azure и частные конечные точки сети Azure позволяют приложениям и потокам безопасно получать доступ к Power BI. Частные конечные точки используются для отправки трафика данных в частном порядке с использованием магистральной сетевой инфраструктуры Microsoft, а не через Интернет. Частные конечные точки гарантируют, что трафик, поступающий в ресурсы Power BI организации, такие как отчеты или рабочие области, всегда следует по настроенному в организации пути к сети приватного канала.

• Azure ExpressRoute предоставляет расширенный способ подключить вашу локальный сеть к облачным службам Microsoft с помощью частного подключения. Одно подключение ExpressRoute может получить доступ к нескольким онлайн-службам, таким как Power Platform, Dynamics 365, Microsoft 365 и облачные службы Azure, не проходя через общедоступный Интернет. ExpressRoute требует тщательного планирования и настройки, а также требует больших затрат для службы ExpressRoute и поставщика услуг подключения.

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

Бизнес-логика

При создании современных приложений вы можете выбирать, с помощью чего реализовывать бизнес-логику и где ее внедрять в архитектуру приложения. Без руководства большинство организаций в конечном итоге столкнутся с хаосом бизнес-логики. Наличие многократно используемой логики, обеспечивающей согласованность в реализации, может помочь ускорить усилия по модернизации.

Для наших целей мы определяем бизнес-логику как отличную от логики взаимодействия с пользователем. Например, логика перехода от экрана к экрану на основе значений данных инспекции — это логика взаимодействия с пользователем. Логика, реализуемая для определения завершения проверки, может включать несколько оценок условий и считаться бизнес-логикой.

При проектировании решения, включающего малокодовое решение, следующие соображения помогут вам решить, где можно разместить бизнес-логику.

• В приложении Power Apps: размещение бизнес-логики в малокодовом приложении является самым простым подходом, но он предоставляет ограниченные возможности для повторного использования или обеспечения согласованности между приложениями и автоматизациями. Как правило, этот подход следует ограничивать некритически важной простой логикой, которую не нужно использовать другим приложениям или автоматизациям. Инструменты с минимумом программирования не обеспечивают построчную отладку. Если логика занимает более одного экрана или ее трудно читать, следует рассмотреть другие подходы, которые будут более удобными в обслуживании. Нередки случаи, когда некоторая бизнес-логика дублируется локально в приложении и в облаке. Например, если пользователь вводит резервирование гостиницы, бизнес-правило заключается в том, что дата выезда не может быть раньше дата заезда. Если приложение не проверяет это, пользователь дошел бы до конца и отправил бы резервирование только для того, чтобы обнаружить, что пользовательский соединитель отклонил его. Обработка валидации локально в приложении и в облаке обеспечивает гораздо лучший пользовательский опыт.

• В облачном потоке Power Automate: вы можете выражать бизнес-логику в действиях в потоке, и поток может запускаться в ответ на событие или запрос на выполнение по требованию от других приложений и потоков. Поток может обеспечить малокодовый подход к централизации логики. Шаги в потоке независимы и не являются частью транзакции. Однако в потоках может быть реализована компенсация для обработки отката при возникновении ошибок. Потоки могут выполнять шаги, используя подключения, которые имеют разрешения, выходящие за рамки того, что может делать пользователь приложения, предоставляя способ повышения разрешений. Такой подход также позволяет свести к минимуму разрешения, которые могут потребоваться пользователю приложения.

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

• В пользовательских API-интерфейсах Dataverse: пользовательские API-интерфейсы Dataverse позволяют реализовать собственное пользовательское сообщение API-интерфейса, которое может выполнять логику. Например, можно создать пользовательский API Close Inspection, который будет использоваться для выполнения всей работы по проверке и закрытию инспекции. Он не будет управляться событиями, а будет использоваться по требованию приложениями и потоками, которым это необходимо. Как и в подключаемых модулях, управляемых событиями, изменения данных, вносимые в пользовательском подключаемом модуле API, являются транзакционными. Пользовательский API-интерфейс лучше всего использовать, когда единственной службой, которую он использует, является API-интерфейс Dataverse для работы с другими данными. Подключаемые модули для пользовательских API-интерфейсов можно развертывать в решении Dataverse вместе с приложениями и потоками.

Реализация кода API-интерфейса

Вы можете реализовать API-интерфейсы в своей любимой среде выполнения размещения API, например Функции Azure, Контейнеры приложений Azure или любой службе, которая может размещать REST API. Эти пользовательские API-интерфейсы могут реализовывать любую логику, и их могут использовать как малокодовые приложения, так и приложения с традиционным кодом. Пользовательские API не предоставляют никакой поддержки транзакций, кроме той, которую может обеспечить API, который они используют. Например, пользовательский API может использовать конструкции транзакций SQL Server, если он использует SQL Server. Развертывание API кода не зависит от ресурсов с низким кодом, которые могут его использовать. Вы можете использовать Управление API Azure, чтобы управлять использованием этих API и сделать их более заметными.

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

Безопасность, включая аутентификацию и авторизацию, является неотъемлемой частью архитектуры модернизированного приложения. Современные приложения зачастую сложнее защитить, чем устаревшие. Они включают в себя несколько облачных служб, и пользователи работают с ними из более разных мест. Концептуально безопасность в платформе предназначена для того, чтобы пользователи могли выполнять необходимую работу с наименьшими трудностями, сохраняя при этом защиту данных и служб.

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

Давайте бросим общий взгляд на несколько уровней безопасности, которые составляют модель безопасности Power Platform.

• Пользователи аутентифицируются с помощью Microsoft Entra ID, а использование можно ограничить с помощью политик условного доступа.
• Лицензирование является первым контрольным шлюзом для предоставления доступа к компонентам Power Platform.
• Возможность создания приложений и рабочих потоков контролируется ролями безопасности в контексте сред.
• Способность пользователей видеть и использовать ресурсы Power Platform контролируются путем совместного использования приложения с пользователями. Доступ к ресурсам предоставляется непосредственно пользователю или группе Entra ID.
• Среды действуют как границы безопасности, позволяя реализовать различные требования безопасности в каждой среде.
• Потоки Power Automate и приложения на основе холста используют соединители. Учетные данные для конкретных подключений и связанные с ними права на службы определяют разрешения, когда приложения используют соединители.
• Среды с экземпляром Dataverse поддерживают более продвинутые модели безопасности, предназначенные для управления доступом к данным и службам в этом экземпляре Dataverse.
• Использование соединителя можно дополнительно ограничить с помощью политик защиты от потери данных (DLP). К соединителям также могут применяться входящие и исходящие ограничения между клиентами.

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

При использовании Dataverse в составе решения он включает модель безопасности на основе ролей, которую можно адаптировать ко многим бизнес-сценариям. Данные могут быть защищены вплоть до отдельного столбца в строке данных. Пользователям назначается одна или несколько ролей безопасности, которые вместе определяют их общие привилегии. Dataverse предоставляет стандартные блоки моделирования безопасности, такие как бизнес-подразделения и рабочие группы. Например, бизнес-единицы можно использовать для определения границ безопасности, чтобы изолировать данные между двумя разными группами пользователей организации. Команды можно использовать для группировки пользователей, которым требуется одинаковый доступ к данным. Вы даже можете назначить групповое владение строками данных. На следующей схеме показано использование бизнес-единиц для изоляции данных по подразделениям организации.

Разработка модели безопасности

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

• Удостоверение пользователя: как пользователи проходят проверку подлинности и было ли это уже сопоставлено с Microsoft Entra ID в сценариях, поступающих из локальной среды? Это включает в себя сопоставление групп, необходимых для поддержки назначения групп приложений или рабочих групп в облачных хранилищах данных, таких как Dataverse.

• Идентификатор подключения соединителя: когда приложения используют один или несколько соединителей, какой тип проверки подлинности выполняется для подключения и обеспечивает ли он уровень контроля, необходимый для реализации требуемых элементов управления безопасностью? Например, приложениям, использующим субъект-службу для подключения, не требуется, чтобы пользователь приложения имел прямой доступ к соединителю, что может быть полезно в некоторых сценариях. Индивидуальные пользовательские подключения могут быть удобны для приложений, которым необходимо знать, какой пользователь выполнил операцию, или ограничить круг ответов конкретными пользователями.

• Переносимость конструкций безопасности: по мере того как ваши приложения используют больше соединителей и репозиториев данных, важно помнить, что не все конструкции безопасности одного соединителя сопоставляют непосредственно с другим. Например, в Dataverse существует несколько способов, с помощью которых пользователь может получить доступ к строке данных, включая предоставление общего доступа к этой строке пользователю. Если приложение связывает библиотеку документов SharePoint со строкой, система безопасности, предоставляющая доступ к библиотеке документов, отличается от системы безопасности, управляющей доступом Dataverse. Они не сопоставляются напрямую. Модернизированные приложения должны учитывать эти типы несоответствий в используемых соединителях и репозиториях данных.

Искусственный интеллект

За последние несколько лет искусственный интеллект нашел свое применение в усилиях по модернизации приложений. При модернизации приложений организациям следует рассмотреть возможность использования искусственного интеллекта, чтобы сделать пользователей более продуктивными и способными принимать обоснованные решения. Результаты внедрения ИИ также могут привести к повышению качества обслуживания клиентов, что положительно скажется на бизнес-результатах.

В том числе ИИ, который раньше был связан с интеграцией логики приложений и созданием специально обученных моделей. Благодаря доступности и мощи больших языковых моделей приложения теперь могут внедрять новые способы использования ИИ, чтобы помочь пользователям получать ответы и выполнять задачи. Пользователи могут использовать подсказки на естественном языке для взаимодействия с возможностями ИИ в широком спектре вспомогательных бизнес-сценариев.

Компания Microsoft внедрила Copilot в основные продукты и услуги, чтобы упростить доступ к передовым технологиям искусственного интеллекта. Copilot использует современные методы искусственного интеллекта и большие языковые модели, и пользователи могут взаимодействовать с ним в приложениях, которые они используют каждый день, таких как Microsoft 365, Windows, Dynamics 365 и Power Platform.

Подключаемые модули для расширения возможностей

Пользователи приложений на базе Copilot могут обратиться к Copilot за помощью по общим задачам в приложении. Вы можете расширить возможности помощников, включив в них данные и задачи, с которыми они еще не знакомы, и которые выходят за рамки приложения, с которым работает пользователь. Microsoft 365 Copilot может включать в себя данные Power Platform, хранящиеся в Dataverse, чтобы пользователям не приходилось постоянно переключаться между приложениями. Например, в Outlook пользователь может попросить Copilot создать обновление состояния для всех проваленных проверок, завершенных сегодня. Microsoft 365 Copilot автоматически наследует родную систему безопасности и управления Dataverse и применяет безопасность пользователей и разрешения во время выполнения.

Соединители в качестве подключаемых модулей

Соединители Power Platform также важны для взаимодействия с Copilot. Соединители могут подключаться как подключаемые модули для расширения возможностей Copilot. Например, Microsoft 365 Copilot с соединителем Power Platform для Jira Software может позволить руководителю проекта запрашивать статус запроса в службу поддержки Jira и действовать на основе ответа, например направлять его для получения дополнительного утверждения или создавать заказ на покупку нового оборудования. С помощью подключаемых модулей вы можете интегрировать свои бизнес-процессы и данные с Copilot, чтобы дать пользователям возможность взаимодействовать из любых приложений, которые они используют.

Создание собственного помощника

По мере того как пользователи все больше привыкают к тому, что в их приложениях есть помощь от ИИ-помощника, они ожидают ее во всех приложениях. Вы можете сделать свои современные приложения более привлекательными, включив в них помощников, созданных с помощью стека Copilot — платформы разработки ИИ.

Вы можете использовать готовый элемент управления Copilot в Power Apps для добавления помощников в приложения на основе холста и приложения на основе модели. Настроив представление источника данных и некоторые основные сведения о запросах, вы можете быстро предоставить собственный интерфейс помощника в приложении.

Управление жизненным циклом приложений

Важной частью любой модернизации является создание соответствующего процесса управления жизненным циклом приложений. Организации часто хотят, чтобы их малокодовые усилия соответствовали тому, как они работают с традиционным ALM кода. Power Platform предоставляет средства управления жизненным циклом приложений (ALM), позволяющие включать малокодовые артефакты в процессы, которые вы обычно используете, или вместе с ними.

ALM в Power Platform начинается с того, как вы создаете малокодовые ресурсы. Создаваемые ресурсы находятся в контексте среды Power Platform. Среда может иметь хранилище данных Dataverse. Вы можете использовать несколько сред, — обычно это среда разработки, среда тестирования и рабочая среда, — для реализации целевых зон в процессе управления жизненным циклом приложений, включающем малокодовое программирование. Количество и назначение сред могут быть гибкими, и организации могут настраивать их в соответствии с индивидуальными потребностями проекта. Решение Dataverse — это контейнер для связанных малокодовых ресурсов, облегчающий управление версиями и перенос из одной среды в другую.

Конвейеры Power Platform обеспечивают малокодовый подход к автоматизации развертываний и реализации непрерывной интеграции и непрерывной поставки (CI/CD). Power Platform управляет процессом при настройке конвейеров. Администраторы могут централизованно управлять конвейерами.

Организации также могут использовать инструменты CI/CD по своему выбору. Power Platform CLI — это инструмент командной строки, который можно использовать с большинством средств автоматизации CI/CD. Power Platform Build Tools предоставляют действия для GitHub и задачи для Azure DevOps, которые предоставляют все распространенные действия, необходимые для создания автоматизаций CI/CD, включая малокодовые артефакты.

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

При экспорте решения из Dataverse оно экспортируется в виде одного сжатого файла. Чтобы сохранить малокодовые ресурсы в системе управления версиями, можно использовать средства сборки для распаковки файла решения на отдельные файлы компонентов. Во время автоматизации сборки средства сборки объединяют отдельные файлы из системы управления версиями в один сжатый файл.

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

Если модернизированное приложение включает в себя ресурсы с минимумом кода и традиционным кодом, вы можете объединить их в один процесс CI/CD или управлять ими по отдельности. Благодаря независимому управлению ресурсы можно развертывать по отдельности, а проектные группы могут достичь большей гибкости. Например, API, используемый малокодовым приложением, может быть развернут независимо, если команда не вносит критические изменения.

Мониторинг и аналитика

Модернизированные приложения должны интегрироваться в операционные среды, обеспечивающие возможность диагностики проблем в различных средах, от разработки до производства. Расширение Application Insights, an Azure Monitor собирает данные телеметрии из Power Apps и Dataverse. Эти сведения не только помогают выявлять и устранять проблемы, но и дают представление о том, что пользователи делают в приложении. Эти аналитические сведения можно использовать для улучшения приложений и процессов в модернизированном приложении.

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

Администраторы также могут настраивать среды Dataverse для экспорта данных телеметрии в Application Insights. Регистрируемые данные могут включать вызовы API-интерфейса Dataverse, выполнение подключаемых модулей, операции с пакетами SDK и исключения. Разработчики, создающие логику настраиваемых подключаемых модулей, могут записывать дополнительные данные телеметрии непосредственно в Application Insights.

Использование Application Insights в разных приложениях может упростить сопоставление проблем с несколькими ресурсами. Операционный персонал может создавать оповещения в Azure Monitor, которые будут срабатывать при обнаружении большого количества исключений. Регулярный анализ модернизированных приложений позволяет выявить тенденции, требующие дополнительного изучения.

Заключение

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

Устаревшие приложения создают множество проблем для организаций. Чтобы преодолеть их, организации должны начать инициативы по модернизации приложений, чтобы оживить свою инфраструктуру и воспользоваться преимуществами современных технологий. В этом техническом документе вы узнали, как использовать малокодовый подход к модернизации, в частности, как возможности малокодовой разработки в Microsoft Power Platform позволяют быстро создавать и развертывать современные приложения.

Малокодовый подход открывает двери для более широкого круга людей, чем традиционные программисты. Ключевым фактором организаций, которые добиваются успеха с помощью малокодового подхода, является обеспечение того, чтобы люди, участвующие в модернизации приложений, прошли обучение по разработке с минимумом кода, независимо от того, являются ли они профессиональными разработчиками или бизнес-пользователями. Бизнес-пользователи находятся ближе к решаемой бизнес-задаче и могут применить свои экспертные навыки для экономии времени. Разработчики традиционного кода могут применять методы и навыки, которые у них уже есть, для создания расширений, чтобы заполнить любые пробелы в малокодовом подходе. Организации могут быть наиболее эффективными, объединяя деловые и технические ресурсы в то, что мы называем «смешанными командами».

Этот технический документ закладывает основу для вас. Следующие шаги за вами. Вот некоторые предложения:

• Потратьте несколько минут, чтобы узнать, что ваша организация уже делает с малокодовым подходом. Возможно, вас это удивит!
• Оцените возможности модернизации приложения.
• Определите и расставьте приоритеты для хорошего первого кандидата.
• Укомплектуйте команду, которая модернизирует приложение. Для достижения наилучших результатов убедитесь, что это смешанная команда.
• Убедитесь, что команда прошла необходимую подготовку, чтобы добиться успеха.
• Разрешите команде модернизировать приложение.
• Подумайте об усилиях по модернизации. Доработайте и масштабируйте его для других устаревших приложений.

Путь каждой организации к модернизации приложения уникален. Ваша рабочая группа учетной записи Microsoft или партнер Power Platform может помочь вам спланировать ход работы и удержать вас на правильном пути.

Ресурсы

• Общее экономическое влияние™ возможностей Microsoft Power Platform Premium
• Приложение ConnectMe авиакомпании American Airlines обеспечивает более комфортные путешествия для клиентов и лучшие технологические инструменты для членов команды
• Репозиторий Power Fx с открытым исходным кодом на GitHub
• Начальный набор центра передовых технологий (CoE)
• Оценка принятия Power Platform
• Цифровое страховое агентство автоматизирует сложный процесс покупки с помощью Power Platform
• Коллекция PCF
• Компания EY помогает обеспечить начальный ввод данных в глобальный финансовый процесс с помощью Power Platform, сокращая время выполнения заказов на 95%
• Приватный канал Azure
• Microsoft Azure ExpressRoute
• Планировщик выпусков Power Platform
• Руководство по лицензированию Microsoft Power Platform
• Microsoft описывает фреймворк для создания приложений ИИ и помощников; расширяет экосистему подключаемых модулей ИИ