Розробка проміжного сервісу обміну 1С та Бітрікс

Прямий зв'язок 1С та Бітрікс простий, доки систем дві. Додайте склади, CRM та маркетплейси — кожен новий зв'язок подвоює складність. На одному проєкті клієнт з'єднав три сайти на Бітрікс з єдиною 1С напряму. Щотижня синхронізація злітала, дублювалися замовлення, розходилися залишки. Середній час на виправлення — чотири години. Ми спроектували проміжний сервіс (middleware), який став єдиним шлюзом для всіх систем. Результат: помилки пішли, час синхронізації скоротився вдвічі.

Middleware під ключ потрібен, коли кілька сайтів на Бітрікс підключені до однієї 1С, коли потрібна синхронізація з CRM або маркетплейсами, коли конфігурація 1С нестандартна, а вимоги до трансформації даних виходять за межі CommerceML-маппінгу. Він ізолює бізнес-логіку обміну та робить її тестованою окремо. Замовте аудит — ми оцінимо ваш проєкт.

Коли необхідний middleware?

• Кілька сайтів на Бітрікс підключені до однієї 1С
• 1С + Бітрікс + CRM (AmoCRM, Bitrix24) — дані потрібно синхронізувати між усіма
• Нестандартна конфігурація 1С без HTTP-сервісів — потрібен адаптер
• Вимоги до трансформації даних складніші, ніж можна реалізувати в CommerceML-маппінгу
• Бізнес-логіка обміну повинна бути ізольована та тестована окремо від 1С та Бітрікс

Чому middleware ефективніший за прямі інтеграції?

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

Обробка помилок у middleware

Черга завдань з механізмом backoff: якщо завдання впало, воно автоматично повторюється через 5 хвилин. Максимум 3 спроби, після чого помилка фіксується у SyncLog. Інші завдання не блокуються — кожен елемент синхронізується незалежно. Це дозволяє локалізувати проблему та не втрачати дані.

Як працює черга завдань?

Черга будується на Redis та Horizon (Laravel) або аналогічному рішенні. Кожне завдання — це клас, що реалізує інтерфейс ShouldQueue. При невдачі завдання повторюється з експоненційною затримкою. Це гарантує, що тимчасові збої (наприклад, недоступність API) не призводять до втрати даних.

Архітектура та технічний стек

[1С] ←→ [Middleware] ←→ [Бітрікс] ←→ [CRM] ←→ [Маркетплейс] 

Middleware — окремий додаток (PHP, Node.js, Python, Go — за стеком команди). Його ядро:

1. Адаптери підключення: вміє читати/писати в кожну систему через її API
2. Маппінг даних: перетворює об'єкти з формату однієї системи у формат іншої
3. Черга завдань: зберігає завдання на синхронізацію, забезпечує повтори при збоях
4. Журнал обміну: історія всіх операцій з результатами
5. Конфігурація правил: які поля синхронізувати, в якому напрямку, з якими перетвореннями

Адаптери та маппери

Приклад адаптера для Бітрікс через REST API:

class BitrixAdapter { private string $webhookUrl; public function getOrders(array $filter = []): array { $response = $this->call('crm.deal.list', [ 'filter' => $filter, 'select' => ['ID', 'TITLE', 'STAGE_ID', 'OPPORTUNITY', 'UF_ORDER_ID'], ]); return $response['result'] ?? []; } public function updateProductStock(int $productId, int $quantity): bool { $response = $this->call('catalog.storeProduct.update', [ 'id' => $productId, 'fields' => ['AMOUNT' => $quantity], ]); return $response['result'] ?? false; } public function createOrder(array $fields): int { $response = $this->call('sale.order.add', ['fields' => $fields]); return $response['result']['order']['id'] ?? 0; } private function call(string $method, array $params = []): array { $response = file_get_contents( $this->webhookUrl . $method . '.json?' . http_build_query($params) ); return json_decode($response, true); } } 

Повний список методів описано в REST API Бітрікс24. Маппер з правилами трансформації:

class ProductMapper { private array $categoryMapping; private array $propertyMapping; public function oneCToBitrix(array $oneCProduct): array { return [ 'IBLOCK_ID' => config('bitrix.catalog_iblock_id'), 'XML_ID' => $oneCProduct['Ref_Key'], 'NAME' => $oneCProduct['Description'], 'ACTIVE' => $oneCProduct['DeletionMark'] ? 'N' : 'Y', 'DETAIL_TEXT' => $oneCProduct['КомментарийДляСайта'], 'IBLOCK_SECTION_ID' => $this->mapCategory($oneCProduct['ОсновнаяТоварнаяГруппа_Key']), 'PROPERTY_ARTICLE' => $oneCProduct['Артикул'], 'PROPERTY_WEIGHT' => $oneCProduct['Вес'] * 1000, 'PROPERTY_BRAND' => $this->resolveBrand($oneCProduct['Производитель_Key']), ]; } } 

Черга та надійність

class SyncProductsJob implements ShouldQueue { use Dispatchable, InteractsWithQueue, Queueable, SerializesModels; public int $tries = 3; public int $backoff = 300; public function handle(OneCAdapter $oneC, BitrixAdapter $bitrix, ProductMapper $mapper): void { $products = $oneC->getModifiedProducts($this->sinceDate); foreach ($products as $oneCProduct) { try { $bitrixFields = $mapper->oneCToBitrix($oneCProduct); $bitrix->upsertProduct($bitrixFields); SyncLog::create([...]); } catch (\Exception $e) { SyncLog::create([...]); } } } } 

Моніторинг

Middleware без інтерфейсу керування — чорна скриня. Мінімальний dashboard:

• Статус останніх сеансів обміну (успіх / помилка / час)
• Список помилок з можливістю повторного запуску
• Статистика: скільки об'єктів синхронізовано за добу/тиждень
• Ручний запуск синхронізації для окремого об'єкта або типу даних

Реалізується як простий Laravel/Symfony веб-інтерфейс або через Laravel Horizon.

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

Процес розробки

Терміни розробки

Зв'яжіться з нами для консультації. Замовте аудит — наші інженери оцінять ваш проєкт та запропонують оптимальне рішення.