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

Проект, в сущности, довольно простой. Реализован с использованием 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 формы и её полей, и триггер в нашем потоке будет срабатывать при заполнении «правильной» для него формы.

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