Задача обычно формулируется так: «нужно, чтобы сайт видел остатки из 1С». Дальше начинается развилка, от которой зависит и цена работ, и скорость вашей учетной системы на ближайшие годы.
Разберем три схемы обмена, их честную стоимость владения и требования, без которых любая из них разваливается на объеме. Выбор делается один раз, а живут с ним годами.
Три схемы и чем они отличаются
| Схема | Как работает | Когда подходит | Слабое место |
|---|---|---|---|
| Выгрузки по расписанию | Регламентное задание формирует файл или пакет данных раз в N минут | Каталоги, прайсы, справочники, отчетность | Данные всегда немного устарели |
| Через промежуточный сервис | Учетная система пишет в очередь или хранилище, потребители читают оттуда | Несколько потребителей, высокая нагрузка, разные скорости | Дороже в разработке, нужен еще один компонент |
| Прямой обмен в реальном времени | Внешняя система запрашивает данные напрямую или получает уведомления о событиях | Остатки на витрине, статусы заказов, оплаты | Нагрузка ложится на рабочую базу |
Ошибка выбора почти всегда идет в одну сторону: берут реальное время там, где хватило бы расписания. Причина понятная — так звучит современнее. Плата за это приходит позже, когда учетная база начинает тормозить в рабочее время.
Когда реальное время действительно нужно
Проверяется одним вопросом: что произойдет, если данные будут отставать на десять минут.
Для остатков на витрине интернет-магазина ответ серьезный: продадите то, чего нет, и получите отмену заказа. Для статусов заказа тоже: покупатель видит устаревшую информацию и звонит в поддержку. Для оплат критично, потому что от них зависит отгрузка.
А вот для каталога, прайса, справочника контрагентов, аналитических отчетов десятиминутное отставание не значит ничего. Здесь расписание дешевле, надежнее и не трогает рабочую базу в часы пик.
Практический подход — смешанный. Критичные данные идут в реальном времени узким потоком, остальное уезжает по расписанию. Так нагрузка остается управляемой, а бизнес получает актуальность там, где она нужна.
Есть и промежуточный вариант, который часто оказывается лучшим: расписание с коротким интервалом. Обмен раз в две-три минуты воспринимается пользователями как реальное время, а нагрузку создает предсказуемую и легко ограничиваемую. Прежде чем строить сложную схему с уведомлениями, стоит проверить, хватит ли этого.
Нагрузка на рабочую базу
Главный технический риск прямого обмена. Внешняя система задает вопросы тогда, когда ей удобно, а отвечает на них ваша учетная база, в которой в этот момент работают люди.
Типичный сценарий отказа выглядит так: сайт запрашивает остатки по всей номенклатуре каждые пять минут, запрос тяжелый, выполняется полминуты и держит блокировки. В час пик к нему добавляется закрытие смены на складе, и система встает для всех.
Защита строится на трех приемах. Первый — отдавать данные из подготовленных структур, а не считать их на лету при каждом запросе. Второй — ограничивать частоту и объем: постранично, только изменения, с квотой на потребителя. Третий — выносить тяжелое чтение на отдельную копию базы, если объем это оправдывает. Причины торможения учетной системы в целом разобраны в отдельной статье.
Кто кого спрашивает: опрос или уведомление
Внутри прямого обмена есть еще одна развилка, которую редко проговаривают, а она определяет и нагрузку, и свежесть данных.
При опросе внешняя система периодически спрашивает: «есть новые заказы? изменились остатки?». Реализуется просто, работает предсказуемо, но большинство запросов возвращают пустой ответ и создают лишнюю нагрузку. Чем чаще опрос, тем свежее данные и тем выше цена.
При уведомлении инициатором становится та сторона, у которой произошло событие: провели документ — отправили сообщение. Нагрузка минимальна, данные свежие, но появляется требование к надежности: если получатель недоступен, сообщение надо сохранить и повторить позже.
Практическое правило: уведомления для событий, опрос для сверки. То есть статусы и заказы передаются по событию, а раз в сутки идет контрольный обмен, который ловит все, что потерялось. Такая пара работает устойчиво и стоит недорого.
Гарантия доставки: повторы и порядок
Любой обмен когда-нибудь прерывается: сеть, перезагрузка, обновление на стороне партнера. Вопрос в том, что происходит после.
Обмен без гарантии доставки теряет данные молча. Заказ не создался, оплата не дошла, статус не обновился, и никто об этом не узнает до звонка клиента. Правильная схема хранит очередь того, что надо передать, помечает успешно переданное и повторяет неудачное с нарастающей паузой.
Второе требование — повторы не должны портить данные. Если сообщение о заказе пришло дважды, документ должен создаться один раз. Достигается это внешним идентификатором и проверкой на дубль перед созданием.
Третье — порядок событий. Статус «отгружен» не должен обгонять статус «собран», иначе логика на принимающей стороне сломается. Порядок либо гарантируется механизмом очереди, либо обеспечивается номером версии в самом сообщении.
Версионирование: чтобы обновление не роняло партнера
Интеграция живет годами, и за это время меняется и ваша система, и система партнера. Без правил совместимости каждое изменение превращается в согласованный простой.
Базовое правило простое: добавлять поля можно, убирать и переименовывать — нельзя. Принимающая сторона обязана игнорировать незнакомые поля и продолжать работу, падение на неизвестном поле — ошибка проектирования. Если изменение ломающее, вводится новая версия интерфейса, а старая живет параллельно до тех пор, пока все потребители не переехали.
Это звучит как избыточная бюрократия для обмена между двумя системами внутри одной компании, но именно здесь она окупается: обновление учетной системы не должно требовать одновременного обновления сайта, мобильного приложения и складского терминала.
Безопасность доступа
Обмен открывает дверь в учетную систему, и дверь эта должна быть узкой.
Отдельный технический пользователь под каждую интеграцию, с правами только на те объекты, которые ему нужны, и с запретом интерактивного входа. Разделение по интеграциям нужно и для разбора: по журналу сразу видно, кто именно обращался к данным. Никаких полных прав «чтобы точно работало». Отдельный ключ доступа, который можно отозвать, не трогая остальные обмены. Ограничение по адресам, откуда допустимы запросы, если это возможно.
Отдельно про то, что уходит наружу. Выгрузка для сайта не должна содержать закупочные цены, данные о марже и персональные данные сотрудников. Проверять состав выгрузки надо на этапе проектирования: потом никто не вспомнит, что именно в нее попало, а данные к тому моменту уже лежат на стороне партнера.
И про логи: журнал обмена сам по себе становится хранилищем данных, поэтому его состав и срок хранения тоже подчиняются требованиям к персональным данным. Хранить в журнале полные тела сообщений с данными физических лиц дольше необходимого — распространенная и легко устранимая ошибка: чувствительные поля маскируются при записи.
Журналирование и мониторинг
Разбор любого инцидента упирается в вопрос «что именно передавалось». Без журнала ответа нет, и спор с партнером превращается в обмен предположениями.
Минимальный состав записи: время, направление, тип операции, идентификатор объекта, отправленные данные, ответ, результат. Хранить достаточно недели-двух для технического разбора и дольше для операций с деньгами.
Мониторинг важнее журнала. Кто-то должен узнать об остановке обмена раньше, чем клиент. Простейшее правило работает почти везде: если за час не было ни одной успешной операции в рабочее время, уходит уведомление ответственному. Второе правило — контроль очереди: если необработанных сообщений больше порога, это тоже сигнал. Оба уведомления должны уходить человеку, который может что-то сделать. Общий почтовый ящик для таких сигналов бесполезен: туда никто не смотрит.
Полезно и обратное: отчет за сутки с числом успешных операций по каждому направлению. Он занимает три строки, приходит утром и позволяет заметить, что вчера обмен прошел десять раз вместо привычных ста, — до того, как это заметит клиент.
Что делать с интеграцией, доставшейся по наследству
Частая ситуация: обмен работает, написан неизвестно кем, документации нет, и трогать его страшно. Разбор делается по шагам.
Сначала инвентаризация: какие системы обмениваются, чем именно, с какой периодичностью, через какие учетные записи. Дальше — поиск журналов, а если их нет, то первым делом добавляется журналирование, потому что без него дальнейший разбор слепой.
Потом проверяются опасные места: есть ли защита от повторов, что происходит при обрыве, кто узнает об остановке, какие права у технического пользователя. Обычно первые две недели работы дают полную картину и список из трех-пяти критичных доработок.
Отдельная категория наследства — обмены, написанные внешними обработками, которые запускает по расписанию планировщик на чьем-то компьютере. Формально они работают, фактически держатся на одной машине, одной учетной записи и памяти одного сотрудника. Такие конструкции переносятся в регламентные задания на сервере в первую очередь, это дешево и снимает самый глупый из возможных рисков.
Переписывать интеграцию с нуля стоит, если она сделана правкой типовой конфигурации, не имеет журналов и работает через учетную запись администратора. В остальных случаях дешевле привести в порядок существующую: добавить журнал, защиту от повторов, ограничить права и настроить мониторинг. Это две-три недели работы против нескольких месяцев на переписывание. Механика обновляемых доработок разобрана в статье про расширения.
Тестовый контур и как проверять обмен
Тестирование интеграции отличается от тестирования обычной доработки: нужны две стороны, и вторая обычно вам не подчиняется.
Минимум, о котором надо договориться на старте: у обеих сторон есть тестовые контуры, они связаны между собой, и данные в них похожи на реальные. Проверка обмена на трех выдуманных позициях ничего не доказывает, потому что реальные проблемы приходят из объема и из нестандартных случаев.
Обязательные сценарии проверки: обрыв связи в середине передачи, повторная отправка одного и того же сообщения, ответ с ошибкой от принимающей стороны, поток на объеме близком к реальному, одновременная работа обмена и пользователей в базе.
Последний сценарий проверяют реже всего, а он самый показательный: именно там выясняется, что обмен держит блокировки и мешает людям работать. Как принимаются такие этапы работ, описано в статье про критерии приемки.
Сколько стоит и от чего зависит
Работы по интеграции начинаются от 120 000 ₽. В эту сумму укладывается один обмен по понятному сценарию: проектирование, разработка, журналирование, тестирование на реальных данных, документация.
Дорожает от следующего: число обменивающихся сущностей, требование реального времени, необходимость промежуточного сервиса, нестандартная логика на стороне партнера, отсутствие тестового контура у второй стороны, требования к безопасности. Как в принципе считается оценка работ по учетной системе, разобрано в статье про цену доработок.
Срок обычно три-четыре недели на один обмен, из которых заметная часть уходит на согласование доступов и тестирование со стороной партнера. Второй и третий обмен в том же проекте делаются заметно быстрее: очереди, журналирование и мониторинг уже собраны и переиспользуются. Прикинуть бюджет можно в калькуляторе.
Документация, которой хватает
Интеграцию поддерживают годами, часто уже другие люди. Объем документации, который реально работает, невелик и укладывается в несколько страниц.
Нужны: схема обмена в одну картинку или абзац с перечислением участников и направлений; описание каждой передаваемой сущности с составом полей и правилами заполнения; расписание и периодичность; список ошибок с расшифровкой, что делать при каждой; учетные записи и где лежат ключи доступа; порядок действий при остановке обмена.
Последний пункт важнее прочих и почти всегда отсутствует. Инструкция «что делать, если обмен встал» на полстраницы экономит часы паники: где посмотреть журнал, как перезапустить очередь, кому звонить со стороны партнера, что проверить в первую очередь.
Документация пишется не для галочки, а для того, чтобы через год человек без доступа к исходному разработчику мог понять, что происходит. Хороший тест: дайте ее своему системному администратору и попросите объяснить схему своими словами.
Когда интеграция не нужна
Обмен нужен раз в месяц. Пятнадцать минут ручной выгрузки в месяц не окупают ни разработку, ни сопровождение, ни разбор инцидентов, которые у любого обмена случаются. Автоматизируйте, когда операция стала ежедневной.
Данные нужны одному человеку для отчета. Часто задача решается настроенным отчетом с автоматической отправкой на почту, а не двусторонним обменом.
Вторая система скоро меняется. Если сайт или складская программа в планах на замену, интеграцию делать рано: она уедет вместе с системой.
Чек-лист приемки интеграции
- Описан состав обмена: что, куда, с какой периодичностью, в каком формате.
- Есть защита от повторной обработки одного и того же события.
- При обрыве данные не теряются, есть очередь и повторы.
- Тяжелые запросы к рабочей базе ограничены по объему и частоте.
- Технический пользователь имеет минимальные права, ключ можно отозвать.
- В выгрузку не попадают закупочные цены и персональные данные без необходимости.
- Ведется журнал с возможностью найти конкретную операцию.
- Настроено уведомление об остановке обмена.
- Описан порядок изменений: как добавляются поля и вводятся новые версии.
- Передана документация, по которой другой подрядчик разберется без вас.
Десять пунктов отделяют обмен, который работает годами, от конструкции, которую страшно трогать. Что входит в наши работы по обменам — на странице интеграции 1С по API.