Разработка кастомного обмена 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 лет и десятки успешных интеграций позволяют нам давать реалистичные оценки без сюрпризов. Закажите аудит текущего обмена — бесплатно.