Обмен работал год. Никто ничего не менял. В понедельник заказы с сайта перестали доходить до 1С.
«Никто ничего не менял» почти всегда означает, что обновилась конфигурация, сменилось время на сервере или у справочника выросло число позиций. Обмен с 1С ломается не от кода, а от окружения вокруг него, и ломается предсказуемыми способами.
Разберём эти способы по симптомам: что видит пользователь, где искать причину и чем лечить. Обзор методов интеграции есть в большом гайде, а про настройку OData мы написали отдельно.
С чего начинать любой разбор
Прежде чем гадать, загляните в два места.
Журнал регистрации 1С. Здесь видно, дошёл ли запрос до базы вообще, под каким пользователем он выполнялся и чем закончился. Половина разборов заканчивается прямо здесь: запрос не доходил, потому что у пользователя обмена отобрали роль после обновления.
Логи промежуточного слоя. Если между сайтом и 1С стоит middleware, у него должны быть логи с идентификатором запроса, длительностью и телом ответа при ошибке. Если их нет, начните с того, чтобы они появились — без них дальше вы будете угадывать.
Дальше идём по симптомам.
Симптом: кракозябры вместо русских букв
Классика, которая живёт десятилетиями. 1С исторически тяготеет к Windows-1251, веб живёт в UTF-8.
Опасность в том, что перекодировка может теряться не там, где вы смотрите. Точек, где текст меняет кодировку, обычно три: выгрузка из 1С, транспорт (заголовок Content-Type и параметр charset), приём на стороне сайта. Сломаться может любая.
Диагностика простая: возьмите строку с буквой «я» и проследите её байты на каждом этапе. В UTF-8 «я» занимает два байта, в Windows-1251 всего один. Как только вы видите, где двухбайтовая последовательность превратилась в вопросительные знаки, вы нашли место.
Отдельная разновидность беды: двойная перекодировка, когда текст переводят из 1251 в UTF-8 дважды. Выглядит характерно: вместо «Наименование» приезжает «Ðаименование». Значит, где-то в цепочке стоит лишняя конвертация, и лечится это её удалением, а не добавлением третьей.
Симптом: даты съехали на несколько часов
Форматом дат в 1С обычно занимаются сразу, а вот часовыми поясами почти никогда. Именно они дают самые неприятные ошибки, потому что данные выглядят правдоподобно.
1С хранит дату без указания зоны. Сайт, база данных и сервер приложений могут жить в разных зонах, и при передаче никто явно не говорит, в какой зоне пришло значение. Каждое звено достраивает её по своим настройкам.
Результат: заказ, оформленный в 23:40, попадает в 1С следующим днём. Отчёты за месяц расходятся на границе периода, и никто не понимает почему.
Лечение состоит из двух правил. Передавайте время в ISO 8601 с явным указанием зоны или в UTC, и фиксируйте зону на всех серверах цепочки. Договорённость «у нас всё в московском времени» работает ровно до первого сервера, который развернули с настройками по умолчанию.
Симптом: суммы расходятся на копейки
Цена в 1С хранится как число с фиксированной точностью. В JSON она превращается в число с плавающей точкой, а дальше начинается известная арифметика, в которой 0.1 + 0.2 не равно 0.3.
На одной позиции разница незаметна. На заказе из сорока строк она вырастает до рубля, и бухгалтерия приходит с вопросами.
Решение известное: не передавайте деньги числами с плавающей точкой. Есть два рабочих варианта: передавать сумму строкой либо целым числом в копейках. Второй удобнее, если обе стороны договорились и нигде по дороге не делят на сто «для красоты».
Заодно проверьте округление. Если сайт округляет к ближайшему, а 1С по своим правилам, расхождение появится даже при честной передаче.
Симптом: 1С «висит», пользователи жалуются на тормоза
Обмен и работа пользователей идут в одной базе и конкурируют за одни таблицы. Массовая запись из интеграции берёт блокировки, а менеджер в этот момент пытается провести документ и ждёт.
Что обычно вызывает это:
- запись тысяч записей в одной транзакции вместо порционной
- обмен в разгар рабочего дня
- параллельные потоки, которые пишут в один и тот же регистр
- отсутствие ограничения скорости на стороне middleware
Лечится очередью и порционностью. Отправляйте пакетами по несколько сотен записей, ограничивайте число одновременных потоков, тяжёлые выгрузки уводите на ночь. Если объёмы такие, что ночи не хватает, начинается разговор про отдельную базу для обмена или про репликацию, а не про настройку интеграции.
Симптом: заказы задваиваются
Сайт отправил заказ, 1С его приняла и начала отвечать, связь оборвалась. Сайт не получил подтверждения и отправил заказ повторно. В 1С их стало два.
Отличить «запрос не дошёл» от «ответ не вернулся» со стороны сайта невозможно в принципе. Поэтому защита строится на стороне приёмника: у каждого заказа должен быть внешний идентификатор с сайта, а 1С перед созданием обязана проверить, нет ли уже документа с таким идентификатором.
Это не про надёжность сети, а про архитектуру. Даже идеальный канал не отменяет перезапусков, деплоев и повторов из очереди.
Тот же принцип работает и в обратную сторону, когда события едут из 1С на сайт. Подробнее эта механика разобрана в статье про настройку API на сайте.
Симптом: обмен встал после обновления конфигурации
Обновление типовой конфигурации меняет структуру данных: появляются реквизиты, исчезают старые, меняются типы. HTTP-сервисы, написанные под прежнюю структуру, начинают отдавать ошибки либо, что хуже, отдают пустые значения без ошибки.
Опаснее всего второй вариант: обмен формально работает, данные приезжают, но часть полей пустая. Заметить это можно через неделю, когда накопятся заказы без контрагента.
Профилактика простая и дешёвая: набор проверок на стороне middleware, который гоняется после каждого обновления 1С. Запросить один известный товар, один документ и сверить, что нужные поля на месте и нужного типа. Пять минут работы, которые ловят большинство таких поломок в день обновления, а не через неделю.
Сюда же относится ситуация с ролями: обновление может сбросить права пользователя обмена. Проверка доступа должна входить в тот же набор.
Симптом: выгрузка отваливается по таймауту
Полная выгрузка каталога на пятьдесят тысяч позиций легко занимает десятки минут. Веб-сервер, прокси и HTTP-клиент к такому не готовы, и запрос обрывается где-то в середине.
Дальше начинается неприятное: часть данных уже записана, часть нет, а повтор запускает всё заново с начала.
Правильная схема в том, чтобы вообще не укладывать выгрузку в один запрос. Разбейте на страницы, ведите отметку последней успешной синхронизации и забирайте только изменения. Тогда обрыв стоит одной страницы, а не всей выгрузки.
Чек-лист диагностики
Заключение
Почти все поломки обмена с 1С сводятся к тому, что две системы по-разному понимают одни и те же данные: байты текста, момент времени, сумму денег, факт создания документа. Код при этом может быть безупречным.
Отсюда практический вывод. Договорённости о форматах стоит зафиксировать письменно на старте проекта, а набор проверок после обновления написать до того, как случится первое обновление. Обе вещи занимают день и экономят те самые понедельники, когда «никто ничего не менял».
Читайте также
