За последние пять лет я сделал с десяток интеграций с 1С, и первую из них мы переписывали ровно через месяц. Тогда задача казалась простой: забрать справочник номенклатуры и заказы, дёрнуть пару методов и разложить по своей базе. Как выяснилось, «просто» — самое опасное слово в интеграциях с 1С.
Главный урок: начинать надо не с кода, а с протокола обмена. У 1С есть несколько дорог — HTTP-сервисы, написанные руками, OData, обмен через планы обмена и регистры сведений, файловый обмен. Я пробовал почти всё и теперь почти всегда выбираю HTTP-сервисы: ты сам контролируешь структуру ответа, версионирование и права. OData соблазняет скоростью старта, но потом выясняется, что любое изменение реквизита ломает запросы на стороне клиента, а рычагов для настройки производительности там мало.
Второе, на чём горят почти все, — идентификаторы. Ни в коем случае не привязывайтесь к наименованию или коду объекта: их переименуют, и вся связка рассыплется. Работайте с GUID и храните его у себя как внешний ключ. И держите отдельную таблицу соответствий: наша сторона, сторона 1С, дата последней синхронизации, статус. Эта таблица экономит больше времени, чем любой рефакторинг.
Обязательно проектируйте идемпотентность с первого дня. Сеть рвётся, сервисы перезапускаются, пользователь жмёт кнопку дважды — и вот у вас уже два одинаковых заказа. Мы вводили на каждый документ внешний идентификатор, который передаём из своей системы, и на стороне 1С ищем по нему перед созданием. Это ровно та доработка, что стоит час работы, а экономит неделю разбирательств.
Отдельная боль — ошибки. 1С легко отдаёт код 200 и при этом пишет в теле ответа «Объект не найден», потому что так устроена типичная обработка в самописном HTTP-сервисе. Если ваш клиент смотрит только на HTTP-статус, вы будете считать сломанную выгрузку успешной. Мы до сих пор живём по правилу: сначала проверяем тело ответа, а уже потом статус. И договоритесь с разработчиками 1С о едином формате ошибки сразу, иначе каждый метод будет отвечать по-своему и разбор инцидентов превратится в археологию.
Производительность — сюжет для отдельного поста. Тяжёлые операции лучше выносить в порционную выгрузку с пагинацией, а не просить «дай всё за период». Запрос остатков по всем складам и всей номенклатуре положит базу в час пик. Ещё одна деталь: справочники в 1С большие, связи между объектами пересчитываются на лету, поэтому иногда дешевле подписаться на события изменений и забирать только дельту, чем каждый раз выгружать всё целиком.
И последнее, что я считаю обязательным, — тестовый контур. Копия базы с обезличенными данными, а не «давайте потестим на проде, там же ночью всё равно никто не работает». Плюс короткий документ с описанием контракта: какие методы, какие поля обязательные, как обрабатываем ошибки, что делаем при расхождении сумм. Через полгода этот текст спасёт и вас, и коллег, которые придут на ваше место.
По итогам того самого переписанного проекта я собрал для себя чек-лист: протокол, идентификаторы, идемпотентность, формат ошибок, нагрузка и тестовый контур. Он не идеален, но с ним следующие интеграции уходили в продакшн без переделок. А какой неочевидный подводный камень ловили вы в своих связках с 1С? Расскажите свою историю — вместе мы соберём чек-лист, который спасёт не одного новичка.
Главный урок: начинать надо не с кода, а с протокола обмена. У 1С есть несколько дорог — HTTP-сервисы, написанные руками, OData, обмен через планы обмена и регистры сведений, файловый обмен. Я пробовал почти всё и теперь почти всегда выбираю HTTP-сервисы: ты сам контролируешь структуру ответа, версионирование и права. OData соблазняет скоростью старта, но потом выясняется, что любое изменение реквизита ломает запросы на стороне клиента, а рычагов для настройки производительности там мало.
Второе, на чём горят почти все, — идентификаторы. Ни в коем случае не привязывайтесь к наименованию или коду объекта: их переименуют, и вся связка рассыплется. Работайте с GUID и храните его у себя как внешний ключ. И держите отдельную таблицу соответствий: наша сторона, сторона 1С, дата последней синхронизации, статус. Эта таблица экономит больше времени, чем любой рефакторинг.
Обязательно проектируйте идемпотентность с первого дня. Сеть рвётся, сервисы перезапускаются, пользователь жмёт кнопку дважды — и вот у вас уже два одинаковых заказа. Мы вводили на каждый документ внешний идентификатор, который передаём из своей системы, и на стороне 1С ищем по нему перед созданием. Это ровно та доработка, что стоит час работы, а экономит неделю разбирательств.
Отдельная боль — ошибки. 1С легко отдаёт код 200 и при этом пишет в теле ответа «Объект не найден», потому что так устроена типичная обработка в самописном HTTP-сервисе. Если ваш клиент смотрит только на HTTP-статус, вы будете считать сломанную выгрузку успешной. Мы до сих пор живём по правилу: сначала проверяем тело ответа, а уже потом статус. И договоритесь с разработчиками 1С о едином формате ошибки сразу, иначе каждый метод будет отвечать по-своему и разбор инцидентов превратится в археологию.
Производительность — сюжет для отдельного поста. Тяжёлые операции лучше выносить в порционную выгрузку с пагинацией, а не просить «дай всё за период». Запрос остатков по всем складам и всей номенклатуре положит базу в час пик. Ещё одна деталь: справочники в 1С большие, связи между объектами пересчитываются на лету, поэтому иногда дешевле подписаться на события изменений и забирать только дельту, чем каждый раз выгружать всё целиком.
И последнее, что я считаю обязательным, — тестовый контур. Копия базы с обезличенными данными, а не «давайте потестим на проде, там же ночью всё равно никто не работает». Плюс короткий документ с описанием контракта: какие методы, какие поля обязательные, как обрабатываем ошибки, что делаем при расхождении сумм. Через полгода этот текст спасёт и вас, и коллег, которые придут на ваше место.
По итогам того самого переписанного проекта я собрал для себя чек-лист: протокол, идентификаторы, идемпотентность, формат ошибок, нагрузка и тестовый контур. Он не идеален, но с ним следующие интеграции уходили в продакшн без переделок. А какой неочевидный подводный камень ловили вы в своих связках с 1С? Расскажите свою историю — вместе мы соберём чек-лист, который спасёт не одного новичка.