Налаштування двосторонньої синхронізації 1С та 1С-Бітрікс
Двостороння синхронізація — технічно найскладніша схема обміну: зміни в будь-якій із систем повинні потрапити в іншу без втрати даних і без конфліктів версій. У нашій практиці ми стикалися з проєктами, де стандартний CommerceML частково покриває задачу (каталог з 1С + замовлення в 1С), але повноцінний двосторонній обмін вимагає чіткого визначення правил пріоритету та механізмів виявлення конфліктуючих змін. Без правильної стратегії синхронізації ви ризикуєте зіткнутися з втратою даних, неузгодженістю інформації та необхідністю ручного втручання в процес обміну.
Правила пріоритету — фундамент двостороннього обміну
До початку розробки потрібно відповісти на питання: яка система майстер для кожного поля? Це критично, оскільки за відсутності чітких правил система не знає, яке значення вважати істинним при конфлікті. Ми пропонуємо таблицю пріоритетів, засновану на 150+ реальних проєктах, де двосторонній обмін працює надійно:
| Поле | Майстер-система | Обґрунтування |
|---|---|---|
| Ціна | 1С | Фінансовий облік в 1С |
| Залишки | 1С | Складський облік в 1С |
| Опис товару | Сайт | SEO-контент пишеться на сайті |
| Фото товару | Сайт | Фотографії завантажуються в медіатеку сайту |
| Статус замовлення | 1С | Замовлення виконується в 1С |
| Адреса доставки | Сайт | Покупець вводить на сайті |
| Реквізити покупця | 1С | Юридично значущі дані в 1С |
Порушення цих правил веде до «мерехтіння» даних: 1С перезаписує опис → редактор виправляє → 1С знову перезаписує → втрата роботи. Такий цикл деморалізує команду та призводить до частих помилок. Ми гарантуємо, що при правильному налаштуванні система блокує перезапис захищених полів і поважає зміни, зроблені в кожній системі згідно з її компетенцією.
Чому двостороння синхронізація викликає конфлікти?
Конфлікт версій виникає, коли одне поле змінилося в обох системах між сеансами обміну. Власний обробник гнучкіший за стандартний агент у 3–5 разів, оскільки дозволяє точково контролювати кожне поле. Ми виявляємо конфлікти через timestamp останньої зміни, що зберігається в користувацьких властивостях елемента.
// Хранить в доп. поле элемента время последнего обновления с сайта $lastSiteUpdate = $element['UF_LAST_SITE_UPDATE']; // timestamp $lastExchangeUpdate = $element['UF_LAST_EXCHANGE_UPDATE']; // timestamp из 1С if ($lastSiteUpdate > $lastExchangeUpdate) { // Поле изменялось на сайте после последнего обмена — не перезаписывать } Механізми синхронізації та обробка помилок
Стабільна двостороння синхронізація вимагає надійної системи обробки помилок і відновлення. Ми використовуємо кілька шарів захисту:
-
Логування всіх транзакцій — кожна зміна записується в окрему таблицю з часом, статусом (успіх/помилка) і текстом помилки. Це допомагає діагностувати проблеми.
-
Черга завдань (Job Queue) — зміни в 1С не проходять одразу. Вони ставляться в чергу з повторними спробами: якщо перша спроба синхронізації впала (наприклад, елемент не знайдено), система повторить через 5 хвилин, потім через 15, потім через годину.
-
Відкат при конфлікті — якщо виявлено конфлікт версій (обидва поля змінилися), система створює запис у системі завдань і чекає рішення адміністратора замість сліпого перезапису.
-
Мапування даних — ми явно вказуємо, яке поле 1С відповідає якому полю Бітрікса. Нестандартні поля (користувацькі властивості) мають бути описані в конфігурації.
Як захистити поля при імпорті з 1С?
На стороні сайту — контроль полів через обробники подій. Це швидше та надійніше, ніж редагувати XML-схему CommerceML. Приклад коду:
// Защита полей от перезаписи при импорте из 1С \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'iblock', 'OnIBlockElementBeforeUpdate', function(\Bitrix\Main\Event $event) { $fields = $event->getParameter('fields'); $elementId = $event->getParameter('id'); $protected = getProtectedFields($elementId); foreach ($protected as $fieldCode) { unset($fields[$fieldCode]); } return new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::SUCCESS, ['fields' => $fields] ); } ); Кейс з нашої практики: двостороння синхронізація для дистриб'ютора
Компанія-дистриб'ютор, 15 000 SKU. Наш клієнт використовує 1С для цін і залишків, сайт — для описів і SEO. Двічі на рік — переоцінка в 1С, змінюються ціни на 80% асортименту. До налаштування двостороннього обміну при переоцінці ціни оновлювалися, але одночасно перезаписувалися SEO-описи, написані копірайтерами. Ми внесли поле DETAIL_TEXT у «захищений список» через користувацьку властивість UF_PROTECT_DESCRIPTION. Після впровадження — жодного випадку втрати SEO-контенту за 8 місяців експлуатації. Досвід показує, що такий підхід підходить для 90% проєктів.
Синхронізація зображень
Зображення — окрема складність. Якщо 1С передає зображення через CommerceML (<Картинки>), а сайт має додаткову галерею з ретушованими фото, ми:
- захищаємо основне зображення (
PREVIEW_PICTURE) флагом «оброблено фотографом»; - додаємо нові фото з 1С, не видаляючи існуючі.
Терміни налаштування
| Завдання | Термін |
|---|---|
| Двосторонній обмін з правилами пріоритету | 2–4 дні |
| + виявлення конфліктів версій | +1–2 дні |
| + двостороння синхронізація користувачів | +1–2 дні |
Що входить у вартість роботи
- Налаштування правил пріоритету та мапування полів.
- Реалізація механізму виявлення конфліктів версій.
- Логування та черга повторних спроб.
- Документація з описом схеми обміну.
- Надання доступів до довідкових матеріалів.
- 2 години навчання для вашої команди.
- 1 місяць технічної підтримки після запуску.
Про нашу компанію
Ми — команда інтеграторів із 5-річним досвідом на ринку. За цей час виконали понад 150 проєктів зі складними обмінами даних. Використовуємо перевірені методи, зокрема алгоритми виявлення конфліктів з версійним контролем, що дозволяє уникнути втрати даних. Економія часу на налагодженні обміну — до 30% порівняно з типовими рішеннями.
Бажаєте отримати консультацію щодо вашого проєкту? Оцінимо терміни та складність безкоштовно. Зв'яжіться з нами — ми допоможемо налаштувати обмін без втрати даних.