Автоматизация отчетов: интеграция Битрикс24 с MySQL по расписанию

1. Интеллектуальная аналитика задач из Битрикс24 с помощью MySQL

Разберем пример нашего заказчика-производителя инструментов, сотрудники которого ведут управление операционной деятельностью в Битрикс24 (коробочная версия).

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

Из-за большого объема задач мы разработали удобное и надежное решение — интеграцию Битрикс24 с базой данных MySQL на платформе Пинкит.

Благодаря этой связке все обновления по задачам — от статуса и сроков до результатов — автоматически выгружаются в отдельные строки таблицы.

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

Вызовы на пути к идеальной интеграции

Разрабатывая интеграцию, мы столкнулись с несколькими моментами, устранение которых помогло сделать решение ещё лучше.

1.1. Частая выгрузка данных — излишняя нагрузка

Поскольку задач было очень много, и каждая обновлялась по нескольку раз в день, выгрузка происходила каждые 5 минут и создавала огромное количество API-запросов.

Несмотря на то, что и MySQL, и платформа Пинкит отлично справлялись с нагрузкой технически, для заказчика это не приносило реальной бизнес-ценности.

Ведь данные нужны были в основном к концу месяца для формирования отчетов — а система постоянно обновляла одни и те же данные, создавая избыточную нагрузку.

Как связан объем API-вызовов в интеграциях по обмену данными и бизнес-польза для пользователей CRM? Читайте в статье.

1.2. Рассинхронизация данных при больших объемах

При работе с большим количеством задач иногда появлялись небольшие расхождения в данных.

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

Оптимальное решение для эффективной аналитики

Наше предложение было следующее: перейти от частой выгрузки к запуску интеграции один раз в месяц — непосредственно перед подготовкой отчетов.

Это простое, но эффективное изменение позволило достичь сразу нескольких важных целей:

• Сократить количество запросов к серверу на 95% — меньше лишней нагрузки, больше ресурсов для ключевых задач.


• Полностью устранить рассинхронизацию данных — теперь данные всегда точные и синхронизированы.


• Упростить процесс аналитики — вся информация в MySQL актуальна именно на момент формирования отчета, что облегчает принятие решений.

Для удобства мы подготовили готовый шаблон интеграции, который можно использовать уже сейчас.

Далее мы покажем, как настроить обе интеграции: обновление задач и запуск по расписанию, чтобы вы могли быстро внедрить это решение в своем бизнесе.

2. Запуск интеграции в начале каждого месяца. Задача обновлена => MySQL_task

Шаг первый: Откуда

Забираем данные из Битрикс24 при событии обновления задачи. Добавляем два дополнительных запроса:

Тип: Запрос

Название: order[CHANGED_DATE]

Значение: ASC

Тип: Запрос

Название: filter[>CHANGED_DATE]

Значение: {{now|date('Y-m-d\TH:i:s','Europe/Moscow','-1 month)}}

Шаг второй: Инструменты

• Проверка. Задача выгружалась ранее в БД?

Используем Поиск ID соответствующий сущности. Название поля - source.id.

• Если задача ранее не выгружалась в базу данных, тогда пропустить обработку данной задачи

Используем проверку в поле step13. Условие - (Логическое) Истина, Действие - Продолжить, если проверка пройдена.

• Получить постановщика

Используем API-запрос методом GET с указанием URL /user.get.json?ID={{source.createdBy}}.

• Информация о исполнителе

Используем API-запрос методом GET с указанием URL /user.get.json?ID={{source.responsibleId}}.

• Дата создания задачи

Используем Форматирование даты/времени в поле source.createdDate. Формат даты/времени - Y-m-d H:i:s.

• Крайний срок задачи

Используем Форматирование даты/времени в поле source.deadline.

• Дата последнего изменения

Используем Форматирование даты/времени в поле source.changedDate. Формат даты/времени - Y-m-d H:i:s.

• Дата закрытия

Используем Форматирование даты/времени в поле source.closedDate. Формат даты/времени - Y-m-d H:i:s.

• Получить теги у задачи

Используем API-запрос методом GET с указанием URL /task.item.gettags?TASK_ID={{source.id}}.

• Преобразовать массив тегов в строку

Преобразуем массив в JSON в поле step7.result. Условие выполнения - step7.result.

• Статус задачи

Используем сопоставление данных в поле source.status. Сопоставляем статус задачи и столбец в таблице БД.

• Получить департамент постановщика

Используем API-запрос методом GET с указанием URL /department.get.json?ID={{step1.result.0.UF_DEPARTMENT.0}}.

• Получить департамент Исполнителя

Используем API-запрос методом GET с указанием URL /department.get.json?ID={{step2.result.0.UF_DEPARTMENT.0}}.

Условие выполнения - step2.result.0.UF_DEPARTMENT.

• Приоритет задачи

Используем Сопоставление данных для сопоставления приоритета задачи и соответствующий столбец таблицы.

• Получить результат задачи

Используем API-запрос методом GET с указанием URL /tasks.task.result.list?taskId={{source.id}}.

• Проверяем наличие результата по задаче

Используем инструмент Если-Иначе в поле step15.result. Условие - Не пустое значение. Результат при успешной проверке = 1, Результат при неуспешной проверке = 0.

• Убрать теги из комментария

Используем замену по регулярному выражению в поле step15.result.0.text. Условие выполнения - step16. Регулярное выражение = /\[.*?\]/.

Шаг третий: Куда

Обновляем строку в БД MySQL.

Шаг четвертый: Сопоставление данных

Добавляем пользовательские сопоставления.

ID задачи

Тип: Столбец SQL

Название параметра: id_task

Значение параметра: {{Идентификатор задачи}}

Название

Тип: Столбец SQL

Название параметра: Nazvanie

Значение параметра: {{Название задачи}}

Ссылка

Тип: Столбец SQL

Название параметра: Ssylka

Значение параметра: https: //**/ company/ personal/user/{{Исполнитель (id)}}/tasks/task/view/{{Идентификатор задачи}}/

ID родительской задачи

Тип: Тело

Название параметра: ID_roditelskoj_zadachi

Значение параметра: {{Идентификатор родительской задачи}}

Описание

Тип: Столбец SQL

Название параметра: Opisanie

Значение параметра: {{Описание}}

Постановщик

Тип: Столбец SQL

Название параметра: Postanovshchik

Значение параметра: {{step1.result.0.LAST_NAME|default()}} {{step1.result.0.NAME|default()}}

Ответственный

Тип: Столбец SQL

Название параметра: Otvetstvennyj

Значение параметра: {{step2.result.0.LAST_NAME|default()}} {{step2.result.0.NAME|default()}}

Дата создания задачи

Тип: Столбец SQL

Название параметра: Data_sozdaniya

Значение параметра: {{step3|default(1970-01-01 00:00:00)}}

Крайний срок задачи

Тип: Столбец SQL

Название параметра: Krajnij_srok

Значение параметра: {{step4|default(1970-01-01 00:00:00)}}

Дата последнего изменения задачи

Тип: Столбец SQL

Название параметра: Data_poslednego_izmeneniya

Значение параметра: {{step5|default(1970-01-01 00:00:00)}}

Дата закрытия задачи

Тип: Столбец SQL

Название параметра: Data_zakrytiya

Значение параметра: {{step6|default(1970-01-01 00:00:00)}}

Теги

Тип: Столбец SQL

Название параметра: Tegi

Значение параметра: {{step8|default()}}

Статус задачи

Тип: Столбец SQL

Название параметра: Status

Значение параметра: {{step9}}

Отдел постановщика

Тип: Столбец SQL

Название параметра: Otdel_postanovshchika

Значение параметра: {{step10.result.0.NAME|default(Не указан)}}

Отдел ответственного

Тип: Столбец SQL

Название параметра: Otdel_otvetstvennogo

Значение параметра: {{step11.result.0.NAME|default(Не указан)}}

Проект/Группа

Тип: Столбец SQL

Название параметра: Proekt

Значение параметра: {{source.group.name|default(Не указан)}}

Приоритет

Тип: Столбец SQL

Название параметра: PRIORITY

Значение параметра: {{step12}}

Результат задачи

Тип: Столбец SQL

Название параметра: rezult_zadachi

Значение параметра: {{step17|default()}}

Шаг пятый: Запуск

Запускаем.

3. Интеграция запускает другую интеграцию по расписанию

Шаг первый: Откуда

Указываем событие срабатывания вебхука.

Шаг второй: Инструменты

Пропускаем.

Шаг третий: Куда

Запускаем интеграцию Пинкит с доступом через Login-Pass.

Шаг четвертый: Сопоставление данных

Сопоставляем строки БД и поля задач.

Шаг пятый: Запуск

Запускаем.

4. Итог

Благодаря настройке интеграции для синхронизации данных из Битрикс24 в MySQL наш заказчик получил сразу несколько значимых преимуществ:

• Сократил количество запросов к серверу на 95%, что позволило значительно снизить затраты на инфраструктуру.


• Полностью устранил ошибки в аналитике, обеспечив точность и надежность данных.


• Ускорил подготовку отчетов с 2 дней до всего 2 часов, значительно повышая оперативность принятия решений.

Такой результат — это не просто цифры, а реальное улучшение бизнес-процессов и удобство для всей команды.

Если у вас есть вопросы, пишите нам в Телеграм или WhatsApp, расскажите о вашем бизнес-сценарии, и наши инженеры помогут настроить интеграцию без ручного труда и разработки.

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

Подберите свой шаблон интеграции без регистрации здесь.

Алексей Окара,
продакт-менеджер Пинкит