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

Статья
09/04/2023

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

Авторы: Рави Чада (Microsoft), Руи Сантос (Microsoft)

Заметка

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

Среда по умолчанию

Для каждого клиента создается одна среда по умолчанию, которая доступна для всех пользователей в этом клиенте. Среда по умолчанию создается в регионе, ближайшем к региону по умолчанию клиента Microsoft Entra, и называется так: [Имя клиента Microsoft Entra] (по умолчанию). Всякий раз, когда новый пользователь регистрируется для Power Apps или Power Automate, он автоматически добавляется для роли создателя среды по умолчанию. Никакие пользователи не добавляются автоматически в роль администратора среды по умолчанию.

Вы не можете удалить среду по умолчанию и не можете вручную создать резервную копию среды по умолчанию. Системное резервное копирование выполняется постоянно. Объем среды по умолчанию ограничен 1 ТБ. Среда по умолчанию имеет следующие возможности:

3 ГБ емкость баз данных Dataverse
3 ГБ емкость файлов Dataverse
1 ГБ емкость журнала Dataverse

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

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

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

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

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

Рабочие группы Центра передовых технологий (CoE), которые отслеживают Power Platform , вынуждены реагировать после достижения ограничений, что отрицательно влияет на приложения, работающие в среде по умолчанию. Это ограничение также может приводить к необходимости регулярного выполнения администратором или рабочей группой центра передовых технологий. Существует три больших этапа:

Идентификация объектов Power Platform
Перемещение объектов Power Platform
Очистка объектов Power Platform

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

Со временем объекты Power Platform эволюционировали и стали учитывать решения. Теперь приложения и потоки могут быть осведомлены о решениях по умолчанию, хотя для этого требуется активация вручную. Создатели по-прежнему могут создавать приложения и потоки из make.powerapps.com и make.powerautomate.com, которые можно классифицировать как не поддерживающие решения, и их можно экспортировать по отдельности или добавлять в решение. Добавляя решение, создатель может использовать переменные среды и ссылки на подключения для настройки и развертывания конечных точек в разных средах.

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

Идентификация объектов Power Platform

Первый шаг — определить приложения, потоки и активы, которые необходимо переместить или очистить. Начальный комплект CoE обеспечивает инвентаризацию всех приложений и потоков, а отчеты Power BI помогают определить их использование. Этот шаг поможет вам оценить использование приложений и маркировать их. Выполняя это упражнение, обязательно отмечайте приложения и потоки, которые следует перенести в другую среду. Тег может основываться на используемых соединителях, местоположении пользователя, отделе пользователя и т. д. В этой статье также описывается метод распознавания элементов, которые следует очистить или переместить, на основе методов защиты от потери данных (DLP).

Перемещение объектов Power Platform

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

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

В другом случае предположим, что имеется приложение на основе холста, использующее подключение Office 365. В этом случае разработчику просто нужно добавить в решение только приложение на основе холста.

Очистка объектов Power Platform

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

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

Поддержание коммуникационной стратегии играет ключевую роль. Администраторы должны планировать общение:

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

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

Стратегии

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

Стратегия DPL

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

Идентификация объектов с помощью DLP

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

Чтобы предотвратить простой потенциально важных объектов из-за политики DLP, входящей в стартовый комплект CoE, вы можете найти Редактор DLP (анализ воздействия). Цель редактора DLP — позволить администраторам увидеть влияние существующих политик или потенциальное влияние изменений политик. Он предоставляет администраторам представление о затронутых приложениях и потоках, а также ресурсах, которые были бы отключены в случае применения новых или обновленных политик. Приложение можно использовать для просмотра существующих политик, изменения существующих политик и снижения рисков, связываясь с создателями и информируя их о наилучшем образе действий для их приложения или потока.

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

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

Используя редактор DLP версии 2.0, в области Анализ воздействия выберите Экспортировать затронутые приложения и потоки в CSV.

Используйте редактор DLP версии 2.0.

Каждый созданный файл CSV (flow.csv и apps.csv) содержит информацию о:

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

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

Пример реализации для идентификации подключения:

Создайте поток Power Automate.
Используйте соединитель Получить политику DLP клиента, указав требуемую политику DLP.
В результате получаются два массива: бизнес-данные и некоммерческие данные. В качестве примера соединитель Twitter показывает следующий код:
```
[
  {
    "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
    "name": "Twitter",
    "type": "Microsoft.PowerApps/apis"
  }
……
]
```
Из этого списка у вас есть доступ к имени соединителя, которое соответствует списку имен колонки CSV Подключение приложения или потока.
Преобразовав CSV в формат Excel и поместив его в свой OneDrive, вы можете прочитать все затронутые приложения и потоки из Power Automate. Проверьте, какое подключение затронуто, на основе логики, сравнивающей подключения с именами соединителей.
После того как вы определите, какое подключение оказывает влияние, создайте новый список с идентификатором приложения или потока и соединителем, затронутым политикой DLP.
Используйте предыдущую информацию, чтобы уведомить создателя о будущих последствиях. Вы можете использовать Power Cards для сбора отзывов от создателя, если приложение или поток можно удалить или его необходимо перенести в другую среду.

Если на основе анализа вы определите, что затронутые потоки не используются, вы можете поместить их в карантин и отправить создателю электронное письмо с инструкциями о том, как переместить их в другую среду. Это поощряет культуру «сделай сам» (DIY) и устраняет теневые ИТ. В некоторых ситуациях может потребоваться исключить некоторые объекты из политики DLP. Например, вы можете применить конкретную политику защиты от потери данных только для новых ресурсов, которые были созданы, и исключить текущие ресурсы. Дополнительные сведения об исключении ресурсов из политики DLP см. в разделе Исключение ресурсов из политики DLP.

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

Стратегия среды

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

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

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

Стратегия общения

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

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

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

Вещи, которые следует учитывать:

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

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

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

Аудитории

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

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

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

Алгоритм

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

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

Выделение ресурсов

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

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

Индивидуальная миграция объектов

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

Экспорт и импорт приложения на основе холста (устаревший способ)

Подробные шаги описаны в разделах Экспорт пакета приложения на основе холста и Импорт пакета приложения на основе холста.

Этот метод экспорта приложений является устаревшим. Хотя он поддерживается, мы рекомендуем вам использовать решения. Решения позволяют перенести несколько компонентов вместо всего одного ресурса.

Экспорт и импорт потока (устаревший способ)

Следующие шаги описывают, как экспортировать поток.

Выберите меню «…», выберите Экспорт, затем выберите Пакет (.zip).
Введите имя и описание для вашего пакета. Затем вы можете настроить параметры по умолчанию и добавить комментарии, доступные на этапе импорта.
Выберите кнопку Экспорт в правом нижнем углу, чтобы загрузить пакет. Если загрузка не начинается автоматически, вы можете выбрать кнопку Загрузить.

Следующие шаги описывают, как импортировать поток.

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

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

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

Экспорт и импорт приложения на основе модели

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

Подробные пошаговые процессы описаны в разделах Экспорт решения и Импорт решения.

Экспорт и импорт бота Microsoft Copilot Studio

Вы можете экспортировать и импортировать боты с использованием решений. Подробный список шагов описан в разделе Экспорт и импорт ботов с помощью решений.

Экспорт и импорт сайта Power Pages

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

Приложение формы SharePoint — особый случай для среды по умолчанию

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

Создание резервной копии объектов Microsoft Power Platform

Большинство объектов Microsoft Power Platform экспортируются в виде zip-файлов. Если нет, то у них есть хотя бы один формат файла. Эти файлы в своем исходном формате, в виде zip-файла или любого другого расширения, можно добавить в любое место хранения файлов или репозиторий по вашему выбору. Несколько вариантов, которые следует упомянуть, это Azure DevOps, GitHub, SharePoint, One Drive или любое другое решение, поддерживающее все форматы файлов.

Варианты массовой миграции

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

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

Любые комментарии о совместной работе, сделанные в приложении или потоке, также не включаются.

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

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

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

Поддерживается: Dataverse, приложения Dynamics
Не полностью поддерживается: приложение Canvas, библиотека компонентов, пользовательские страницы, Power Automate, Microsoft Copilot Studio

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

Миграция метаданных, а затем данных

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

На высоком уровне шаги следующие:

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

Проверка зависимостей решения

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

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

Добавление компонента в решение (вручную)

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

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

Корректировка ссылок на подключения

Приложения на основе холста и потоки обрабатывают подключения по-разному. Потоки используют ссылки на соединения для всех коннекторов, в то время как приложения Canvas используют их только для неявно общих (не OAuth) соединений, таких как аутентификация сервера SQL.

Обновление приложения для использования ссылок на подключения вместо подключений

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

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

Обновление потока для использования ссылок на подключения вместо подключений

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

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

Добавление объекта в решение (автоматизация)

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

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

Для приложения на основе холста:

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

Для потока:

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

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

Экспорт и импорт решения

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

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

Интерфейс командной строки (CLI) Power Platform также предоставляет возможности экспорта и импорта решений. Все команды, связанные с решением, можно использовать для создания, экспорта и импорта решений. Вы также можете использовать CLI для передачи данных внутрь и наружу.

Удобный для создателей вариант — использовать конвейеры, предназначенные для демократизации ALM для Power Platform. Объединение возможностей автоматизации ALM и непрерывной интеграции/непрерывного развертывания (CI/CD) в единый сервис функций становится более доступным для всех создателей, администраторов и разработчиков.

Создание подключений (вручную)

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

Перенос данных

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

Экспортируйте и импортируйте данные вручную с помощью книг Excel.
Облачный поток Power Automate может быть разработан для извлечения данных из исходных таблиц и записи непосредственно в пункт назначения. Однако для этого создателю необходимо использовать соединитель Dynamics 365 Connector или соединитель Dataverse (устаревший). В настоящее время соединитель Dataverse не поддерживает подключение между средами. Эта функция запланирована на будущее, и после ее выпуска ее можно будет использовать для перемещения данных из одной среды в другую.
Инструмент миграции конфигурации (CMT) — это инструмент, который используется для миграции портала, но его также можно использовать для обычной миграции данных. Инструмент CMT также может использоваться с PowerShell. Инструмент командной строки PAC дает возможность вызвать CMT.
Потоки данных можно использовать для создания сопоставлений между средами и для перемещения данных. Веб-соединитель HTTP можно использовать в качестве альтернативы Dataverse.
Фабрику данных Azure можно использовать с соединителем Dataverse для извлечения данных из источника и вставки их в место назначения.

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

Моменты, которые следует учитывать при очистке

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

Определите порядок импорта данных. Наименее зависимые таблицы идут первыми, а наиболее зависимые — в конце.
Не все поля необходимо сопоставлять. Такие поля, как Версия, Дата изменения, Дата создания и некоторые другие системные поля не требуют сопоставления.
Если вы хотите сохранить исходное значение поля Дата создания, затем используйте сопоставление поля источника Дата создания полю OverRiddenCreatedOn в целевой таблице.
Данные аудита невозможно перенести.
Не включайте никакие рабочие процессы или потоки, которые запускаются при вставке данных, если это не предусмотрено. Это увеличивает время миграции данных.

Параметры расстановки тегов

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

Создайте таблицу под названием Теги и настройте связь «многие ко многим» (N:N) с приложением, потоками и другими таблицами инвентаризации. Затем вы можете создать тег и связать эти записи с соответствующими пунктами запасов. Для удобства пользователя вы можете встроить сетку в форму Основная приложений, потоков и других таблиц инвентаризации. Этот вариант рекомендуется, поскольку он обеспечивает согласованность ссылок.

Создайте текстовое поле в каждой таблице инвентаризации и используйте его для ввода текста (тега), который можно будет использовать позже.

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

Карантинный вариант

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

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

В обоих случаях важно иметь правильное общение с владельцем.

Вариант "Только удалить"

Если действительно нет потери производительности и повторного использования объектов, этот вариант — лучший. Большинство тестовых потоков и приложений попадают в эту категорию.

В этом случае, как только список объектов будет определен, можно будет разработать пакет PowerShell и передать в него список CSV, который затем удалит все эти активы.

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

Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

Вариант резервного копирования и удаления объектов

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

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

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

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

Заключение

Power Platform — это инструмент как для непрофессиональных, так и для профессиональных разработчиков. Использование среды по умолчанию должно быть в первую очередь ориентировано на личную производительность с использованием продуктов Microsoft 365. Разработка всех остальных приложений и потоков должна происходить в определенных общих средах, индивидуальных средах или средах разработки. Настоятельная рекомендация — разработать независимую стратегию среды, основанную на политике DLP, что может помочь создателям разрабатывать свои приложения и потоки в правильной среде. Создание коммуникационной стратегии и предоставление пользователям моделей самообслуживания для изучения стратегии, реализации решений и передовых методов разработки приложений и потоков также дает большую выгоду. Хорошим дополнением будет размещение некоторых историй успеха на информационном сайте. Истории успеха, публикуемые внутри компании, помогают создателям знакомиться с идеями и открывают для них возможности, которые можно реализовать с помощью Power Platform.

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

Поделиться через