Налаштування інтеграції Бітрікс24 з Redmine

Як працює синхронізація Бітрікс24 з Redmine

Частина команди працює в Redmine — звикли, налаштували workflow, не хочуть переїжджати. Інша частина — в Бітрікс24, бо там CRM, телефонія та чати. Результат: задачі дублюються вручну, статуси розходяться, а при спробі зібрати звіт по проєкту потрібно відкрити обидві системи та звести дані в таблиці. Наші інженери — сертифіковані спеціалісти з 10+ роками досвіду — пропонують готове рішення під ключ: middleware для двонаправленої синхронізації. Ви перестаєте витрачати час на ручне перенесення та отримуєте єдину картину проєкту. Оцініть проєкт: напишіть нам, і ми за 1 день підготуємо план робіт.

Архітектура інтеграції

Зв'язка працює через Redmine REST API та Б24 REST API. Redmine надає JSON/XML API для роботи з issues, проєктами, користувачами та записами часу. У Redmine немає вбудованих webhooks — middleware використовує polling для відстеження змін.

Б24 (подія задачі) → Webhook → Middleware → Redmine REST API → Issue Redmine (polling) → Middleware → Б24 REST API → Задача 

Polling працює так: middleware кожні 30–60 секунд запитує GET /issues.json?updated_on=>=<last_check_time>&status_id=* — отримує всі issues, оновлені після останньої перевірки. Для Б24 використовуються стандартні вебхуки через event.bind.

Мапінг полів

Redmine використовує Textile (за замовчуванням) або Markdown для описів. Middleware конвертує HTML з Б24 у потрібний формат: заголовки, списки, посилання, виділення.

Чому важливий мапінг статусів?

Redmine дозволяє створювати довільні статуси та переходи (workflow). Middleware підтримує гнучкий мапінг:

Важливий нюанс: Redmine перевіряє допустимі переходи статусів через workflow. Middleware перед оновленням запитує доступні переходи та виконує проміжні кроки, якщо прямий перехід неможливий.

Кастомні поля

Redmine активно використовує кастомні поля (Custom Fields). Middleware підтримує мапінг довільних полів:

• Текстові (string/text) ↔ UF_CRM_* строкові поля Б24.
• Списки (list) ↔ select-поля Б24. Middleware мапить значення за ID або назвою.
• Числові (int/float) ↔ числові поля Б24.
• Дата ↔ поля дати Б24.
• Логічні (bool) ↔ чекбокси Б24.

Конфігурація мапінгу зберігається в middleware та редагується через панель адміністрування.

Синхронізація проєктів

Redmine-проєкти мапляться на проєкти (групи) Б24:

Трекер Redmine (Bug, Feature, Support) визначає тип задачі. Middleware може мапити трекер на тег або кастомне поле в Б24.

Прив'язка тикетів до задач

Middleware зберігає таблицю мапінгу b24_task_id ↔ redmine_issue_id. При створенні задачі в одній системі автоматично створюється парна в іншій. Критерій синхронізації — належність до маппованого проєкту.

Коментарі (journals у Redmine) синхронізуються в обидва боки:

• З Redmine: middleware парсить journals з notes при polling та створює коментарі в задачі Б24.
• З Б24: за подією ONTASKCOMMENTADD middleware викликає PUT /issues/{id}.json з полем notes.

Первинна міграція

Перед увімкненням синхронізації middleware переносить існуючі дані:

1. Вивантаження issues з Redmine через GET /issues.json?project_id={id}&limit=100&offset={n}.
2. Створення задач у Б24 через tasks.task.add з мапінгом усіх полів.
3. Зворотне вивантаження задач Б24, яких немає в Redmine.
4. Заповнення таблиці мапінгу ID.

Що входить у роботу

• Готова middleware з конфігурацією під ваші проєкти
• Мапінг статусів, полів, трекерів та кастомних атрибутів
• Перенесення історії задач та коментарів
• Тестування та налагодження синхронізації
• Документація з експлуатації та навчання команди
• Гарантійна підтримка 1 місяць

На відміну від самописних скриптів, наше рішення обробляє конфлікти статусів та дублювання даних автоматично. Понад 50 успішних інтеграцій з Бітрікс24 підтверджують надійність підходу. Зв'яжіться з нами, щоб отримати консультацію та точну оцінку вашого проєкту.

Як middleware обробляє конфлікти синхронізації?

Конфлікти виникають, коли одну й ту саму задачу змінюють одночасно в обох системах. Middleware використовує правило "остання зміна перемагає" (last-write-wins) з відміткою часу. Для кожного оновлення middleware порівнює updated_on з Redmine та CHANGED_DATE з Б24. Якщо різниця менше 5 секунд, задача позначається для ручного вирішення — адміністратор отримує сповіщення. Це знижує ризик втрати даних до мінімуму. У нашій практиці за рік роботи — менше 0.5% конфліктів, і всі були вирішені автоматично.