Розробка кастомного обміну 1С та 1С-Бітрікс
Стандартний CommerceML вирішує 80% типових завдань: товари, ціни, залишки, замовлення. Але коли в компанії 50 000 товарів з серіями, характеристиками та безліччю цін, типовий обмін перетворюється на проблему. Дані передаються добами, за найменшої помилки виникають дублі та пропуски. Кастомний обмін усуває ці складнощі завдяки точному маппінгу та паралельній обробці. Ми розробляємо інтеграції «під ключ»: від аудиту до підтримки в продакшені. Розберемо, коли потрібен кастомний обмін, які архітектури працюють і як уникнути типових помилок.
На відміну від CommerceML, кастомний REST API передає лише змінені записи — це в 5 разів швидше при першому запуску. Подійний обмін через webhook дає актуальність у реальному часі, а не раз на годину. Така архітектура краще підходить для магазинів з високим трафіком.
Коли необхідний кастомний обмін?
Стандартний обмін ламається в таких ситуаціях:
- Нестандартна конфігурація 1С без підтримки CommerceML (галузеві рішення, самописні конфігурації)
- Передача даних, яких немає в CommerceML: заявки, тендери, сервісні звернення
- Вимоги до реального часу: оновлення залишків негайно при зміні в 1С
- Складна трансформація даних: дані з кількох довідників 1С збираються в один об'єкт Бітрікс
- Інтеграція кількох систем: 1С + CRM + Бітрікс через єдиний шлюз
Приклад з практики: виробнича компанія передавала в Бітрікс не лише товари, а й специфікації на комплектуючі, пов'язані з кожним замовленням. CommerceML не вміє передавати багаторівневі вкладення, довелося проектувати JSON-контракт з вкладеними масивами.
Архітектурні варіанти кастомного обміну
Варіант 1: HTTP-сервіси 1С (REST API)
Сучасні конфігурації (УТ 11.4+, ERP 2.5+, КА 2.5+) підтримують публікацію HTTP-сервісів. 1С публікується на веб-сервері (Apache/nginx), Бітрікс звертається до endpoint'ів по REST.
class OneCApiClient
{
private string $baseUrl;
private string $token;
public function getProducts(array $filters = [], int $limit = 100, int $offset = 0): array
{
return $this->request('GET', '/hs/exchange/products', [
'modified_since' => $filters['modified_since'] ?? null,
'limit' => $limit,
'offset' => $offset,
]);
}
public function createOrder(array $orderData): array
{
return $this->request('POST', '/hs/exchange/orders', $orderData);
}
public function updateOrderStatus(string $orderId, string $status): bool
{
$result = $this->request('PUT', "/hs/exchange/orders/{$orderId}/status", [
'status' => $status,
]);
return $result['success'] ?? false;
}
private function request(string $method, string $path, array $data = []): array
{
$ch = curl_init();
$url = $this->baseUrl . $path;
if ($method === 'GET' && $data) {
$url .= '?' . http_build_query($data);
}
curl_setopt_array($ch, [
CURLOPT_URL => $url,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
'Authorization: Bearer ' . $this->token,
'Content-Type: application/json',
],
CURLOPT_CUSTOMREQUEST => $method,
]);
if ($method !== 'GET') {
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
}
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
if ($httpCode !== 200 && $httpCode !== 201) {
throw new \RuntimeException("1C API error: HTTP {$httpCode}. Response: {$response}");
}
return json_decode($response, true);
}
}
Варіант 2: Подійний обмін (webhooks з 1С)
1С при зміні даних надсилає HTTP-запит на Бітрікс. Для цього в конфігурації 1С додається підписка на події (зміна залишків, зміна статусу замовлення) та HTTP-запит при спрацюванні.
На стороні Бітрікс — endpoint для прийому подій:
// /local/api/1c/webhook.php
$payload = json_decode(file_get_contents('php://input'), true);
$eventType = $payload['event_type'] ?? '';
switch ($eventType) {
case 'stock_changed':
StockSyncHandler::handle($payload['products']);
break;
case 'order_status_changed':
OrderStatusHandler::handle($payload['order_id'], $payload['status']);
break;
case 'price_changed':
PriceSyncHandler::handle($payload['prices']);
break;
}
http_response_code(200);
echo json_encode(['ok' => true]);
Подійний обмін дає актуальність даних у реальному часі — без опитування за розкладом. Це особливо важливо для інтернет-магазинів з високим трафіком.
Трансформація даних
Кастомний обмін вимагає явної логіки маппінгу. Типовий складний кейс: в 1С товар зберігається в трьох пов'язаних довідниках (Номенклатура, Характеристики, Серії), в Бітрікс це має бути один елемент інфоблоку з торговими пропозиціями.
class ProductTransformer
{
public function transform(array $oneCNomenclature): array
{
$product = [
'NAME' => $oneCNomenclature['name'],
'CODE' => \CUtil::translit($oneCNomenclature['name'], 'ru'),
'XML_ID' => $oneCNomenclature['guid'],
'ACTIVE' => $oneCNomenclature['active'] ? 'Y' : 'N',
'DETAIL_TEXT' => $oneCNomenclature['description'],
'PROPERTY_ARTICLE' => $oneCNomenclature['article'],
'PROPERTY_BRAND' => $this->getBrandId($oneCNomenclature['manufacturer_guid']),
];
// Собираем торговые предложения из характеристик
$offers = [];
foreach ($oneCNomenclature['characteristics'] as $char) {
$offers[] = [
'XML_ID' => $char['guid'],
'NAME' => $oneCNomenclature['name'] . ' / ' . $char['value'],
'PROPERTY_COLOR' => $this->getColorId($char['color_guid']),
'PROPERTY_SIZE' => $char['size'],
'CATALOG_PRICE_1' => $char['price'],
'CATALOG_QUANTITY' => $char['stock'],
];
}
$product['OFFERS'] = $offers;
return $product;
}
}
Черги для надійної доставки
Прямий синхронний обмін ламається при недоступності однієї з систем. Надійна схема — через чергу:
// При изменении заказа в Битрикс — добавить задачу в очередь
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'sale',
'OnSaleOrderSaved',
function(\Bitrix\Main\Event $event) {
$order = $event->getParameter('ENTITY');
if ($order->isNew() || $order->getFields()->isChanged('STATUS_ID')) {
// Добавить в очередь на передачу в 1С
\MyProject\Queue\ExchangeQueue::push([
'type' => 'order_sync',
'order_id' => $order->getId(),
'created_at' => time(),
]);
}
}
);
Воркер обробляє чергу та повторює спроби при тимчасовій недоступності 1С. Ми використовуємо такий підхід у всіх проєктах — це дає гарантію доставки навіть при мережевих збоях.
Як гарантувати стабільність обміну?
- Версіонування API:
/hs/exchange/v2/products— оновлення 1С не ламають працюючі інтеграції. - Моніторинг: алепти при падінні черги або перевищенні часу обробки.
- Документування контракту: кожен endpoint, формат даних, коди помилок.
- Регулярне тестування на стенді перед оновленням конфігурації 1С.
Детальніше про гарантії
Наші сертифіковані інженери мають досвід інтеграції з 1С: УТ, ERP, КА, а також з самописними конфігураціями. Ми гарантуємо стабільність обміну завдяки чергам, моніторингу та версіонуванню. Замовте аудит — отримайте план модернізації безкоштовно.Що входить в роботу
- Аудит поточної схеми обміну (виявлення вузьких місць, помилок, дублювання)
- Проектування архітектури: вибір протоколу (REST, webhook, черга), узгодження контракту
- Розробка: написання API-клієнта, обробників подій, трансформерів
- Документація: опис endpoint'ів, форматів, інструкція з розгортання
- Тестування на тестовому контурі: обсяг тестів покриває всі сценарії
- Запуск та моніторинг протягом двох тижнів після старту
- Навчання відповідальних осіб: як додавати нові об'єкти, логувати помилки, перезапускати обробку
Терміни розробки
| Складність | Приклади | Термін | Обсяг робіт |
|---|---|---|---|
| Простий REST-клієнт для стандартних об'єктів | Синхронізація 1–2 довідників | 3–5 днів | 1-2 ітерації |
| Двосторонній обмін з трансформацією | Нестандартна структура номенклатури | 2–4 тижні | 3-4 ітерації |
| Подійний обмін + черги | Реальний час, висока надійність | 3–6 тижнів | 4-6 ітерацій |
| Повноцінний інтеграційний шлюз | Кілька систем, складна бізнес-логіка | 1–3 місяці | 6+ ітерацій |
Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальну архітектуру та назвемо терміни протягом дня. Досвід понад 10 років і десятки успішних інтеграцій дозволяють нам давати реалістичні оцінки без сюрпризів. Замовте аудит поточного обміну — безкоштовно.