Как исчисляются вызовы через Power Automate Flow API

Джерри Вайнсток

В предыдущем посте я объяснил, как вызовы через Power Automate flow API «проходят вне основного соединения», и как они могут быть распределены среди других пользователей, кроме владельца потока.

Существует три правила, чтобы понять, где, как и сколько API-вызовов осуществляется в созданном вами потоке. Как только вы поймете эти правила, вы сможете использовать полученные знания при проектировании потока:

1. Одно действие потока или триггер потребляет один вызов API.

2. Чаще всего смотрите Правило №1.

3. Иногда действие потока может потреблять более одного вызова API.

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

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

1. Карточка потока, являющаяся вызовом Dataverse CRUD, не считается двумя вызовами API, а только одним.

2. Независимо от того, насколько сложным является выражение и сколько выражений находится в карточке, карточка считается только одним вызовом API.

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

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

5. Карты действий, которые не были «пройдены» во время выполнения потока, не используют API-вызов.

6. Если вы установите для параллелизма значение >1, то каждая карта, пройденная при выполнении своего «параллельного» действия, будет использовать один API-вызов.

Теперь Правило №2. Начать стоит с того, что большинство из нас, чаще всего, пользуется Правилом №1. Но есть несколько ситуаций, когда карта действия может сгенерировать более одного вызова API. Это подводит нас к Правилу №3, а оно гласит, что иногда карта может сама генерировать или в результате своего действия создать множество API-вызовов.

Итак, основные постулаты Правила №3:

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

2. «Повторные попытки» – если вы установите политику повторных попыток для обработки периодических сбоев, то каждая повторная попытка будет потреблять вызов API.

3. «Применить к каждому» – это как бы описано выше, но вы не только должны учитывать, что каждая карта в цикле генерирует API-вызов, данная команда также использует API-вызов один раз для каждого цикла.

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

Иллюстрации.

Правило №1-1 – Здесь у нас есть карточка действия потока, которая также является действием Microsoft Dataverse CRUD – «Создать». Два действия обнуляются, и только один API-вызов считывается с учетной записи.

Правило №1-2 – Предоставлено коллегой-MVP Антти Паюненом, это пример действия Microsoft Dataverse CRUD — Обновление с несколькими сложными выражениями. Хотя в наличии есть несколько API-вызовов, карта использует только один из них.

Правило №1-4. На иллюстрации ниже поток берет все потоки в клиенте, а затем для каждого найденного потока создает строку в Dataverse с информацией об этом потоке. Таким образом, если он обнаружит 50 потоков, будет взиматься плата за 100 API-вызовов, по одному на каждый. Для каждого найденного потока, проходящего через цикл, и по одному для каждой созданной строки, поэтому 2 действия на 50 циклов равно 100 API-вызовам.

Правило № 1-5. На этом рисунке, поскольку условие можно расценивать, как «нет», API-вызовы используются только при бездействии других процессов.

Правило №1-6. Установка параметра concurrency приведет к тому, что это действие будет выполняться параллельно, по 20 пакетов за раз. Поэтому эта карта будет потреблять в 20 раз больше параллельных API-вызовов, вместо определенной последовательности.

 

Правило № 3-1 и 2. На этой иллюстрации разбивка на страницы включена (хотя порог не указан) и определяется политика повтора. Обе эти настройки приведут к тому, что этой картой будет создано несколько API-вызовов.

Правило № 3-4. Это иллюстрация, демонстрирующая, что карточка «До тех пор, пока» не вычисляется, как «Применить к каждому» для вызовов API. На этом логическом шаге процесс будет проходить в цикле и выполнять обновление записи до тех пор, пока не будет выполнено условие или не будет достигнуто значение 60. Таким образом, для каждого действия Do до будет один вызов API для карточки записи обновления и один вызов API для выполнения до. В результате будет 120 вызовов API.