О ЗАКАЗЧИКЕ
REST API для Битрикс24 позволяет решать нетиповые задачи на портале заказчика. Один из наших заказчиков с помощью скриптов на REST обрабатывал события портала, но столкнулся с проблемой.
ЗАДАЧА ПРОЕКТА
Стандартная библиотека стала выдавать ошибку о превышении лимита запросов, но ничего не могла сделать для исправления ситуации.
С этой проблемой клиент обратился к нам.
РЕАЛИЗАЦИЯ
Первым делом мы провели анализ скрипта и сразу предложили схему его оптимизации. Некоторые вызовы можно было объединить в группу, а некоторые вообще исключить.
Изначально при добавлении счета было 5 запросов. Всегда отрабатывали 3 из них. 1 запрос выполнялся по условию заполненности данных, а еще 1 запрос никогда не выполнялся из-за ошибки в скрипте.
Запрос который выполнялся по условию, и тот который не выполнялся, дублировались в следующем скрипте на изменение счета. А скрипт на изменение запускался сразу после скрипта на создание. Поэтому 2 запрос можно было отбросить.
Скрипт на изменение также делал 5 вызовов REST. 2 вызова обязательно надо сделать отдельно, а вот 3 оставшихся, можно объединить в группу. Итог: тоже 3 запроса.
Оптимизация количества запросов немного облегчила проблему переполнения очереди, но не решила ее полностью. Так как счета приходят из внешней системы и приходят массово, при добавлении более 20 одновременно мы опять столкнемся с переполнением очереди.
Вот схема оптимизации, которую мы проделали:
После этого заказчик рассказал о еще одном скрипте, который дополнительно обрабатывает еще одно событие — изменение статуса счета. В итоге мы решили объединить оба скрипта в один. После этого начали решать проблему с переполнением очереди.
У нас уже был опыт обработки ошибки переполнения очереди. Мы решали эту проблему в наших библиотеках, созданных для тиражных приложений и простейших приложениях на вебхуках.
Заказчик же в работе использовал стандартную библиотеку для REST от Битрикс24. Ему мы предложили доработать стандартную библиотеку CRest для корректной отработки ошибки переполнения очереди. Решение простое. Если возникает ошибка переполнения, то делаем паузу и пробуем повторить отправку запроса. Если опять ошибка переполнения очереди, то увеличиваем паузу и опять пробуем повторить отправку запроса.
Этот алгоритм уже отработанный, поэтому было достаточно использовать его в рамках дополнения стандартной библиотеки. Для проверки работы этого метода, мы написали расширение библиотеки для отработки массовых операций.
Мы смогли решить задачу заказчика. Скрипты оптимизированы. Ошибки переполнения очереди запросов в Б24, успешно обрабатываются.