Проблема синхронізації 1С та Magento 2
Ви запустили інтернет-магазин на Magento 2, а 1С — основа обліку. Товари, ціни, залишки — все має бути синхронізовано в реальному часі. На практиці інтеграція часто перетворюється на головний біль: невідповідність даних, втрата замовлень, помилки в залишках. Одного разу ми виправляли інтеграцію, де через тайм-аут REST-з'єднання пропало 20% замовлень. Після переходу на чергу RabbitMQ — нуль втрат. Правильна архітектура з чергою та обробкою помилок — запорука стабільної роботи. Замовте консультацію — ми проаналізуємо ваші дані та запропонуємо рішення.
Чому пряма REST-інтеграція ненадійна?
Пряме REST-з'єднання працює, але ненадійне при пікових навантаженнях. Черга повідомлень (RabbitMQ або Redis) дає гарантію доставки та дозволяє уникнути втрати даних. Порівняння підходів:
| Характеристика | Пряме REST | Через чергу |
|---|---|---|
| Надійність | Низька (збій → втрата) | Висока (retry, persistence) |
| Продуктивність | Обмежена швидкістю відповіді | Асинхронна, масштабується |
| Обробка помилок | Ручна | Автоматична (retry) |
Інтеграція через чергу втричі надійніша — це перевірено на десятках проєктів. Magento Developer Documentation також рекомендує асинхронну архітектуру. CommerceML — стандарт обміну даними, спрощує узгодження форматів. Для каталогів із десятками тисяч товарів прямий REST-запит на оновлення всіх залишків може тривати хвилинами, блокуючи інші операції. Черга розбиває операцію на дрібні завдання, що обробляються асинхронно. Це виключає тайм-аути та знижує навантаження на сервер.
Архітектура з чергою: як це працює
Типова архітектура включає проміжний шар, який ізолює Magento від 1С. У цьому шарі працюють три компоненти: черга повідомлень (RabbitMQ або Redis), трансформер даних та обробник помилок з retry-логікою. Черга приймає події від 1С та Magento, трансформер переводить дані у потрібний формат, а обробник повторює запити при збоях. Надійність забезпечується persistent-повідомленнями в RabbitMQ та дублюванням у базу даних.
1С ←→ Integration Layer ←→ Magento 2
Integration Layer:
- Queue (RabbitMQ / Redis)
- Transformer (1С-формат ↔ Magento-формат)
- Error Handler
- Retry Logic
Як реалізувати синхронізацію залишків з MSI?
Magento 2.3+ використовує Multi-Source Inventory. Оновлення залишків через MSI API — обов'язковий крок. Ось як це виглядає в коді:
def update_stock_msi(self, sku: str, source_code: str, qty: float):
payload = {
"sourceItems": [{
"sku": sku,
"source_code": source_code,
"quantity": qty,
"status": 1 if qty > 0 else 0
}]
}
requests.post(f"{self.m2_url}/rest/V1/inventory/source-items",
headers=self.m2_headers, json=payload)
Цей метод оновлює залишки для конкретного складу (source_code). MSI API дозволяє гнучко керувати множиною точок зберігання, що критично для компаній з кількома складами або постачальниками. У випадку legacy-інвентарю (Magento 2.2 і нижче) використовувався інший ендпоінт, але з версії 2.3 рекомендується саме MSI.
Імпорт товарів та вивантаження замовлень
Нижче — Python-воркер, який забирає товари з 1С та створює або оновлює їх в Magento.
import requests
import json
from magento.models.product import Product
class OneCMagentoSync:
def __init__(self, m2_url, m2_token, onec_url, onec_auth):
self.m2_url = m2_url
self.m2_headers = {"Authorization": f"Bearer {m2_token}", "Content-Type": "application/json"}
self.onec_url = onec_url
self.onec_auth = onec_auth
def sync_products(self):
# Get products from 1C
response = requests.get(f"{self.onec_url}/products", auth=self.onec_auth)
products_1c = response.json()
for product_data in products_1c:
self.upsert_product(product_data)
def upsert_product(self, data: dict):
sku = data['sku']
# Check existence in Magento
check = requests.get(f"{self.m2_url}/rest/V1/products/{sku}", headers=self.m2_headers)
payload = {
"product": {
"sku": sku,
"name": data['name'],
"price": float(data['price']),
"status": 1,
"type_id": "simple",
"attribute_set_id": 4,
"extension_attributes": {
"stock_item": {
"qty": int(data['quantity']),
"is_in_stock": int(data['quantity']) > 0
}
}
}
}
if check.status_code == 200:
# Update
requests.put(f"{self.m2_url}/rest/V1/products/{sku}",
headers=self.m2_headers, json=payload)
else:
# Create
requests.post(f"{self.m2_url}/rest/V1/products",
headers=self.m2_headers, json=payload)
Цей воркер передбачає, що в 1С є REST API для отримання товарів. Якщо ні — можна використовувати вивантаження в CSV або CommerceML. Важно налаштувати мапінг атрибутів: наприклад, поле 'sku' в 1С може називатися 'article'. Ми створюємо словник відповідностей для кожного клієнта.
Для повноцінного обліку важливо передавати замовлення з Magento в 1С. Код нижче отримує необроблені замовлення та надсилає їх.
def export_orders_to_1c(self):
# Get unprocessed orders
response = requests.get(
f"{self.m2_url}/rest/V1/orders",
params={
"searchCriteria[filter_groups][0][filters][0][field]": "status",
"searchCriteria[filter_groups][0][filters][0][value]": "pending",
"searchCriteria[pageSize]": 50
},
headers=self.m2_headers
)
orders = response.json()['items']
for order in orders:
order_1c = self.transform_order(order)
# Send to 1C
result = requests.post(
f"{self.onec_url}/orders",
json=order_1c,
auth=self.onec_auth,
timeout=10
)
if result.status_code == 200:
# Mark order as transferred to 1C
requests.post(
f"{self.m2_url}/rest/V1/orders/{order['entity_id']}/comments",
headers=self.m2_headers,
json={"statusHistory": {"comment": "Transferred to 1C", "status": "processing"}}
)
При вивантаженні замовлень важливо відстежувати статус: замовлення не повинне двічі потрапити в 1С. Ми використовуємо унікальний ID замовлення та перевіряємо його існування в 1С перед надсиланням. Також застосовуємо транзакційну логіку — якщо 1С не відповіла, замовлення залишається в черзі.
Щоб уникнути втрати даних, всі операції ставляться в чергу RabbitMQ. Persistent-повідомлення не зникають навіть при перезапуску.
import pika # RabbitMQ
def publish_to_queue(self, event_type: str, data: dict):
connection = pika.BlockingConnection(pika.URLParameters(RABBITMQ_URL))
channel = connection.channel()
channel.queue_declare(queue='magento_1c_sync', durable=True)
channel.basic_publish(
exchange='',
routing_key='magento_1c_sync',
body=json.dumps({"type": event_type, "data": data}),
properties=pika.BasicProperties(delivery_mode=2) # persistent
)
connection.close()
Ми налаштовуємо dead-letter exchange для повідомлень, які не вдалося обробити після кількох спроб. Це дозволяє не втрачати проблемні дані, а аналізувати їх окремо.
Типові помилки та як їх уникнути
Найчастіше проблеми виникають через некоректний мапінг атрибутів (наприклад, різний формат ціни), невідповідність одиниць вимірювання та конфлікти залишків при паралельному записі. Рішення — використовувати чергу та транзакційний API. Ми також документуємо всі трансформації даних, щоб уникнути сюрпризів. Додатково, для виключення дублювання замовлень, налаштовуємо idempotent-ключі.
Процес впровадження та терміни
- Аудит даних — виявити невідповідності в номенклатурі, цінах, одиницях вимірювання.
- Проектування схеми обміну — визначити мапінг полів, формати, протокол.
- Розробка інтеграційного шару — реалізувати чергу, трансформери, обробники помилок.
- Налаштування MSI — синхронізація залишків по складах.
- Тестування на копії даних — перевірка повноти та коректності.
- Запуск в експлуатацію — включення синхронізації в пілотному режимі.
- Моніторинг та підтримка — відстеження метрик, обробка збоїв.
| Етап | Результат |
|---|---|
| Аналітика | Схема даних, план міграції |
| Розробка | Інтеграційний шар, налаштування черг |
| Тестування | Пробний запуск, звірка даних |
| Документація | Інструкції для адміністратора |
| Навчання | Передача знань вашій команді |
| Підтримка | KPI моніторингу, SLA 99.9% |
Базова синхронізація (каталог + залишки в один бік) — 10–14 днів. Двостороння інтеграція із замовленнями, чергою та моніторингом — 3–4 тижні. Конкретні терміни розраховуємо індивідуально після аудиту даних.
Гарантії та результати
Ми надаємо письмову гарантію на коректність синхронізації протягом 3 місяців після впровадження. Будь-які збої виправляються безкоштовно. Сертифіковані спеціалісти з Magento та 1С з понад 10-річним досвідом забезпечують відповідність найкращим практикам. Скорочення витрат на підтримку до 40% та прискорення обробки замовлень на 50% — типові результати після впровадження. Отримайте консультацію — перший аналіз даних безкоштовно. Зв'яжіться з нами для оцінки вашого проєкту.