Как считаются API-вызовы в интеграциях на примере выгрузки дела из одного Битрикс24 в другой
В этом кейсе разбираем, как связано количество API-вызовов и производительность, откуда берутся API-запросы и в каком случае запрос есть, а в каком его нет, и что вообще такое API. Для ответа на эти вопросы, мы посчитали, сколько API-вызовов совершает интеграция при выгрузке одного дела из одного портала Битрикс24 в другой портал Битрикс24. Статья будет полезна компаниям, которые хотят не только уменьшить ручной труд и автоматизировать процессы, но и сделать это максимально эффективно
1. Почему нужно обращать внимание на число API-вызовов в интеграции? Проблема высокой нагрузки и ее решение
Для сравнения разберем две ситуации.
1.1. Компания решила переехать из облака в коробку Битрикс24. Перед ней стоит задача выгрузить сделки, задачи, контакты, дела и другие сущности. Нанимать разработчика в такой ситуации дорого, и предпочитаете использовать интеграционную шину, которая перебросит данные с портала А на портал Б.
Как связан объем API-вызовов в интеграциях по обмену данными и бизнес-польза для пользователей CRM? Рекомендуем прочитать статью здесь.
1.2. Или другой пример: перед компанией стоит задача выгрузки одних только дел. Будет ли отличаться нагрузка в первом и втором случае?
Да, конечно, в первом случае (п. 1.1) нагрузка будет намного больше, чем во втором (п. 1.2). Если производственные мощности платформы, которая будет передавать данные посредством API, невелики, миграция не будет работать. Придется выбирать, какие данные в приоритете, и выгружать их в первую очередь. Либо же задействовать более производительные, а значит, и более дорогие решения.
О чем не расскажет ваш сотрудник: почему нельзя просто взять и передать данные из сервиса А в Битрикс24? Читайте по ссылке.
Но, не всегда производительность зависит ТОЛЬКО от объема данных. Нагрузка в частности зависит от количества API-вызовов, которые делает интеграция. Логично предположить, что чем больше сделок нужно выгрузить, тем больше нужно запросов. Но при этом выгрузка одной сделки не равняется одному API-запросу. К примеру, нужно добавить фильтрацию, и это уже увеличивает количество запросов. Таким образом, даже при обмене небольшим количеством данных число вызовов может быть больше, чем предполагалось изначально.
Что такое нагрузка и ограничение API-вызовов: как понять функционал интеграции с Битрикс24? Подробности в статье.
Чтобы разобраться, давайте рассмотрим, в каких случаях генерируется API-вызов при работе интеграции.
2. Пример подсчета API-запросов интеграции по выгрузке дел из одного Битрикс24 в другой
2.1. Шаг 1 - Откуда
Запрашивается дело на шаге 1, поскольку в фильтрации указаны строчные поля, то здесь дополнительно запросов нет, только 1 API-запрос на само получение списка дел.
2.2. Шаг 2 - Инструменты
Используем GET-запрос для получения контактов по делу с указанным URL /crm.contact.list?filter[CREATED_BY_ID]=639:
2.3. Шаг 3 - Куда
Создаем дело в портале Б - это еще один API-запрос.
2.4. Шаг 4 - Сопоставление данных
Здесь идет сопоставление и заполнение полей, API-запросов здесь нет.
2.5. Шаг 5 - Запуск
Также запросов не создается.
Итого, на выгрузку 1 дела типа "Звонок" из портала А в портал Б необходимо три API-запроса.
3. Когда API-вызов есть, а когда его нет? Разбор инструментов в интеграции
3.1. Шаг 1 - Откуда
3.1.1. Первый API-запрос запускает интеграцию. На этот запрос интеграция отдает какой-то ответ.
Есть несколько событий, которые будут создавать больше запросов, чем один. Например, получение откликов по всем вакансиям на НН.ru - там один запрос получает набор элементов, потом по каждому элементу еще один запрос на набор элементов и по каждому из них снова запрос.
Также в зависимости от способа авторизации сервиса раз в какой-то промежуток времени может уходить запрос на обновление токена доступа.
3.1.2. Если в ответе запроса приходит более 50 сущностей, например, если за 5 минут (указанный интервал работы интеграции на шаге 5) обновилось более 50 сделок на портале Битрикс24, то интеграция выполняет по одному дополнительному запросу на каждые 50 последующих сущностей (в зависимости от сервиса и его API цифра 50 может меняться в меньшую сторону, например, как у платформы GitLab).
3.1.3. Для мгновенных запросов иногда требуются дополнительные запросы для получения полной информации.
3.1.4. Каждый фильтр, выставленный в интеграции, будь то пользовательский, т.е. добавленный вручную, или предопределенный платформой, т.е. тот, который мы указываем в выпадающем списке в настройках, это так же дополнительный запрос.
Запросом считается фильтр, где элементы для выбора берутся из сервиса-источника. Но, если в фильтре вводится, например, строка, то тут нет запроса.
Итого, только на первом шаге мы можем получить в зависимости от настроек три и более запроса.
Например, рассмотрим первый шаг интеграции по выгрузке смарт-процесса Битрикс24.
На данном шаге запрашивается обновление смарт-процесса в Битрикс24, считаем по одному запросу на каждые 50 сущностей, затем с двух фильтров (один предопределенный и один пользовательский) по еще одному запросу. Итого, только шаг 1 уже содержит три API-вызова.
3.2. Шаг 2 - Инструменты
API-вызовы создают следующие инструменты:
3.2.1. Распознавание речи (Yandex)
Это инструмент, использующий искусственный интеллект Yandex SpeechKit, например, для перевода звонка в текст.
3.2.2. Запрос в YandexGPT
Запросы к искусственному интеллекту YandexGPT могут выполнить, например, поиск ключевых слов в расшифрованной записи звонка.
3.2.3. Собственно API-запрос
Запрос можно настроить в зависимости от ваших задач. GET-запрос получает данные, POST-запрос отправляет данные на сервер.
Соответственно, от количества этих инструментов может сильно отличаться количество запросов в одной и той же интеграции.
Также на шаг 2 попадают сущности с шага 1 по отдельности. Это значит, что если на шаге 2 у нас три инструмента с API-запросом, а на шаге 1 мы получили 10 сущностей, то итоговое количество вызовов на шаге 2 для всех 10 сущностей рассчитывается как 10*3=30. Есть нюанс для GET-запросов, полностью одинаковые GET-запросы кэшируются на 10 минут, и если за 10 минут был точно такой же GET-запрос, то он не считается.
3.3. Шаг 3 - Куда
По каждой сущности с шага 1 делается API-запрос в итоговый сервис, а значит, получив 10 сущностей на первом шаге, на шаге 3 создается 10 API-запросов.
3.4. Шаг 4 - Сопоставление данных
На данном этапе запросы не создаются, также как и на шаге 5.
4. Итог
Таким образом, мы показали, что для выгрузки одной сущности из одного сервиса в другой с минимальным количеством фильтров необходимо три API-запроса.
Количество запросов за сутки и за все время конкретной интеграции можно увидеть в списке интеграций:
Общее количество вызовов по конкретному порталу или сервису можно увидеть здесь:
А сумма вызовов в учетной записи - здесь:
Если у вас есть необходимость добавить больше фильтров, вы используете искусственный интеллект или добавляете дополнительные запросы на шаге 2, количество API-запросов, а следовательно, и нагрузка, увеличивается.
Не всегда высокая нагрузка равна бизнес-пользе. Часто слишком большое количество API-запросов связано с тем, что интервал запуска интеграции слишком короткий и его нужно скорректировать.
Регистрируйтесь в личном кабинете Пинкит по ссылке: https://lk.pinkit.io/register и приходите на бесплатную встречу, где мы проанализируем вашу задачу и подберем оптимальные условия, чтобы производительность была высокой.