Power Automate проект для Отдела Финансов: задачи и их решения

Наконец закончили проект для отдела финансов, который делали «на общественных началах» вместе с директором по логистике (это она, если что, но я никак не могу принять новомодного окончания -ка для обозначения должностей, занимаемых женщинами).

Проект, в сущности, довольно простой. Реализован с использованием Microsoft Forms, SharePoint Online, Power Automate и, конечно, Teams (куда же сегодня без него).

Бизнес-процесс следующий:

Аккаунт-менеджер оформляет заявку на заключение договора с клиентом в Microsoft Forms. Далее, в Power Automate срабатывает триггер в потоке, реагирующий на заполнение формы. Данные формы передаются на рассмотрение менеджерам разных уровней через механизм Approve, интегрированный с Teams. Одновременно создаётся запись в списке в SharePoint Online, с указанием текущего статуса сделки. В случае, если менеджер одобряет сделку, она передаётся на рассмотрение следующему менеджеру и так далее, пока не одобрят все участники процесса. При всеобщем одобрении инициатор запроса получает уведомление о том, что он может брать запрос в работу и заключать договор с клиентом. Если кто-то из менеджеров отказывает, запрос в целом получает статус «Отказано» и инициатор получает почтой уведомление о том, что ему необходимо связаться с менеджером, не утвердившим запрос, и ответить на комментарии, которые дал данный менеджер.

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

Сначала сделали очень простой поток в корпоративной среде по умолчанию. Проверили логику работы. Всё показалось корректным и можно было бы запускать в эксплуатацию бизнес-пользователями. Но, мы не ищем лёгких путей. Встал вопрос о том, что нужно бы сделать всё «по уму» и реализовать CI/CD для данного процесса с добавлением сред (Development, Test и Production). И вот тут появились интересные задачки, которые нужно было решить.

Как сделать так, чтобы в разных средах триггер срабатывал при заполнении разных форм? Т.е. для каждой среды — своя форма для заполнения. В простом варианте триггер отслеживает форму по ID, автоматом прописываемом в потоке при выборе формы в процессе создания потока. То же и с полями формы, которые Power Platform берет из формы в виде ID и которые для разных форм, соответственно, тоже разные. Для решения этой задачи пришлось создать переменные среды, в которых прописать уникальные ID для формы и для её полей, а в потоке в качестве ID использовать значения этих переменных. Конечно, не очень красиво, но, достаточно прописать эти значения один раз и можно пользоваться ими постоянно.
Когда мы прочитали данные формы, как обращаться к полям, если они, опять же, читаются по ID, а в разных средах эти ID будут разными? Решение — создать новый массив, в котором поля будут иметь читаемые (желательно, понятные для человека), одинаковые для всех сред имена, а значения будут взяты из полей формы.
Как запараллелить процессы утверждения? Количество менеджеров, которые одобряют заявку, может доходить до пяти. Это не проблема, так как процессы будут более-менее одинаковыми, меняется только имя менеджера и его идентификатор. Когда утверждение проходит по цепочке, тоже не проблема. Просто создаём запросы на утверждение последовательно. Но, бывает ситуация, когда одобрения должны делаться параллельно. Как быть в этом случае? Тут нам на помощь приходят бренчи или параллельные ветки. Когда возникает подобная ситуация, просто создаём не новое действие, а новую ветку:

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

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

В данной задаче возник вопрос, на который я пока не нашёл ответа. Сколько времени живёт переменная в потоке? Есть ли какой-то период, после которого отследить значение переменной невозможно? В документации по Power Automate ответа я пока не нашёл. Может кто-то подскажет в комментариях.

Ну и собственно, как реализовать CI/CD в Power Platform «малой кровью», чтобы не использовать Azure DevOps Services или GitHub? Как оказалось, это достаточно просто. Реализацию я описал в статье Добавить DevOps в Power Platform приложение? Легко! — Andrey’s blog (zyqandrey.blog).
Да, ещё один вопрос, который возник, это как быть с переменными среды в Managed средах? Можем ли мы менять их в своём managed решении? Как оказалось, не можем, но если очень хочется, то есть способ. О нём я тоже рассказал в упомянутой статье, но тут повторюсь. Оказывается, в решении Default, которое имеется во всех создаваемых нами средах, независимо от того, является ли среда managed или unmanaged, мы можем изменять значения переменных среды и эти изменения будут «видны» всем решениям, которые имеются в данной среде. В нашем случае мы, например, для managed среды Test или Production меняем переменные для значений ID формы и её полей, и триггер в нашем потоке будет срабатывать при заполнении «правильной» для него формы.

Вот, собственно, и весь проект. Как я сказал в начале, он довольно простой в смысле логики бизнес-процесса (если не считать, что в заявке имеется пять разных критериев, по которым запускается пять веток в каждой из которых одобрения должны делать менеджеры из десяти разных стран, двух вертикалей, и пяти департаментов). Но мы надеемся, что проект упростит жизнь АМов и сделает процесс утверждения заявок более прозрачным и простым.

Добавить DevOps в Power Platform приложение? Легко!

Когда я создавал свои первые приложения в Power Apps, такого понятия, как DevOps в Power Platform ещё не существовало. Но, прошло время, и сегодня Microsoft предлагает простые и эффективные способы организации жизненного цикла приложений в Power Platform.

В этом посте я опишу простой вариант, в котором мы не будем делать интеграцию с Azure DevOps Services или c GitHub, а просто создадим несколько сред, в которых и будет жить наше приложение.

Для примера возьмём поток в Power Automate.

Итак, для начала необходимо решить, какие среды или Environments вы будете использовать. На мой взгляд, как минимум, вам понадобится три среды:

Development — среда, где будет происходить собственно разработка, изменение вашего потока. Решение будет unmanaged, то есть с возможностью редактирования. Если вы создаёте среду «с нуля», можете выбрать тип среды «Разработка»
Test — среда для тестирования приложения в managed варианте. При создании подойдёт тип среды «Песочница»
Production — производственная среда, в которой будут работать ваши конечные пользователи. При создании выбираем тип «Рабочая версия». Здесь приложение тоже будет managed и, как следствие, изменений в нём мы делать не будем.

Создание трёх сред позволит нам обезопасить себя от случайного изменения, удаления или иных нежелательных действий с приложением или потоком, которые повлияют на бизнес-пользователей и сделают их работу либо невозможной, либо затруднительной. Также, имея несколько разных по свойствам сред, мы можем быть уверены, что наше приложение будет вести себя одинаково в различных условиях и для различных пользователей. Ещё одним плюсом будет возможность ограничения доступа к приложению в разных средах. Логично, что в Dev это будут только разработчики, в Test — соответственно, тестировщики (или пользователи, которым вы дадите такие полномочия), а в Production — только ваши бизнес-пользователи.

Для создания сред используем Центр Администрования (Admin Center), вкладку «Среды»:

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

При создании разных сред может возникнуть сложность с реакцией на триггеры, по которым срабатывает ваш поток. Например, вашим триггером может быть заполнение пользователем формы в Microsoft Forms. Если во всех средах триггеры будут реагировать на заполнение одной и той же формы, вы будете получать ложные срабатывания, например в Test и Prod, когда будете проводить тестирование в Dev. Вопрос, как этого избежать? Я думаю, что есть много различных вариантов. В одном из проектов я выбрал такой: для каждой среды создал по одной форме, и настроил триггер на срабатывание именно заданной формы. Но, как это сделать, если идентификатор формы задаётся на этапе дизайна, т.е. хардкодится? Тут на помощь могут прийти Переменные Среды (Environment Variables), которые вы можете задавать как для конкретного приложения (Solution), так и для среды в целом (если пропишете значения переменных в решении Default).

Тут мы подходим к теме решений или Solutions, с помощью которых реализуется DevOps в Power Platform. Как пишет Misrosoft в свой документации, Решения — это механизм реализации ALM в Power Apps и Power Automate. В решение вы можете включить свои приложения, потоки, коннекторы, добавить в них переменные среды, модели и всё, что понадобится для работы вашего приложения при переносе его в другую среду. Пример — приложение Default, которое создаётся в каждой среде при создании:

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

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

Дело в том, что если среда имеет статус managed, вы не сможете изменить значение переменной среды в вашем решении. Но, открыв решение Default, вы увидите, что и значение по умолчанию и текущее значение доступны для редактирования. Это открывает лазейку для управления нашим приложение или потоком. В нашем случае с формой Microsoft Forms мы можем использовать переменную среды в потоке для задания ID формы, и менять его значение в каждой среде.

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

На этом вводная часть закончена и мы можем переходить непосредственно к созданию конвейеров (или Pipelines). Инструкцию от Майкрософт по созданию конвейеров можно прочитать здесь.

Поскольку мы уже создали три среды (Development, Test и Production), нам потребуется одна дополнительная среда, которая будет использоваться только для хранения информации о нашем конвейере (или конвейерах, если вы создадите их несколько).
Эта среда называется Средой размещения.

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

Так определяет её Microsoft. При создании этой среды не забудьте, что все среды, используемые в конвейерах, должны иметь базу данных Microsoft Dataverse. Создаём её также в Центре Администрирования.

Далее переходим во вновь созданную среду и делаем следующее:

Установите в своей хост-среде приложение Конвейеры Power Platform, выбрав хост-среду, а затем выбрав Ресурсы>Приложения Dynamics 365.
Выберите Установить приложение и прокрутите вниз на правой панели, пока не найдете Конвейеры Power Platform.
Выберите Далее; если вы согласны, примите условия и выберите Установить.

После указанных действий приложение Power Platform Pipelines должно иметь статус «Установлено».

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

По завершении установки пакета Конвейер развертывания перейдите на портал Power Apps и выберите хост-среду (где вы установили приложение Конвейер Power Platform). Перейдите в «Приложения» и запустите приложение Конфигурация конвейеров развертывания.

Выберите Среды на левой панели, затем выберите Создать, чтобы создать записи сред в Dataverse:

Заполните поля Имя (зависит от названия вашей среды), Тип среды (может быть Development Environment или Target Environment), ID среды (мы сохранили его ранее), необязательное поле Описание. Если ID среды указан правильно, статус валидации должен измениться на Success. Не забудьте нажать на кнопку «Сохранить».

Таким образом создаём три среды — Development (тип Development), Test (тип Target) и Production (тип Target).

Далее переходим во вкладку Конвейеры (Pipelines). Здесь снова нажимаем кнопку New.

После сохранения, вы сможете добавить среду разработки, выбрав её из ранее созданных на предыдущем шаге:

После этого можно переходить к созданию Стадий Развертывания. В сетке Стадии Развёртывания нажимаем кнопку «New Deployment Stage» и в открывшемся окне заполняем поля:

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

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

Развёртывание из среды разработки в среду тестирования (из Development в Test)
Развёртывание из среды тестирования с продуктивную среду (из Test в Production)

Должно получиться что-то типа такого:

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

При установке приложения «Конвейеры Power Platform» добавляются две роли безопасности:

Пользователь конвейеров развертывания: имеет привилегии на запуск конвейеров, к которым ему предоставлен доступ.
Администратор конвейеров развертывания: имеет полный контроль над всей конфигурацией конвейеров, не будучи участником роли безопасности «Системный администратор».

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

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

Напомню, что все действия по развертыванию производятся из среды разработки Development. Перейдём в Решения, выберем своё решение, которое мы создали ранее (или создадим новое, если мы ещё не сделали этого) и выберем раздел Контейнеры (Pipelines).

Здесь выбираем нужный конвейер (если их более одного). Как видно на картинке, первый доступный вариант развертывания — это из Dev в Test. Нажимаем кнопку Deploy here.

Если есть зависимости, которые не включены в решение и которых ещё нет в целевой среде развертывания, визард сообщит вам об этом и предложит включить их в решение. Если развертывание прошло успешно, вы увидите информацию о новой версии решения в среде развертывания, дату и время последнего развертывания. Также станет доступна кнопка Deploy here в следующей целевой среде развертывания (Production).

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

Microsoft Power Platform — no code, low code или всё же нет?

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

Но, что интересно, хотя Майкрософт декларирует, что это no code или low code платформа, т.е. что она позволяет создавать приложения или реализовывать сценарии без необходимости писать какой-либо код, компании публикуют вакансии для разработчиков (или инженеров) Power Platform. Если мы изучим требования к соискателям, то заметим, что несмотря на отсутствие требований к знанию языков программирования (хотя нет, всё же знание С# и .NET присутствует), сред разработки и прочей программистской тематики, подобный специалист явно не является рядовым пользователем O365, а знание Azure, методологии и практики DevOps, баз данных, SharePoint, ERP и BI систем будет большим плюсом, как и наличие диплома в Computer Science и/или Information Systems.

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

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

С другой стороны, подобный подход (отсутствие необходимости писать код, знать синтаксис языков программирования и прочие милые сердцу разработчика вещи) позволяет отдельным представителям отряда офисных работников, которые по ошибке или по глупости не пошли в своё время учиться на специальность «Compiter Science» в университете, сделать мечту реальностью и начать создавать мобильные и веб-приложения, бизнес-потоки и прочее своими руками. Да, поначалу это будет что-то простенькое, но со временем эти энтузиасты смогут стать реальными power users, а кого-то ждёт карьера Power Platform Engineer. Реальные примеры уже есть.

Нам же, крутым программерам, создающим свои решения с нуля, остаётся лишь свысока поглядывать на эти «детские шалости». Или уделить этому немного своего времени и сделать для коллег пару-тройку действительно крутых решений с использованием Power Apps, Power Automate, возможно, Azure ну и чего-нибудь ещё и показать, какую мощь даёт Power Platform на самом деле 😉