Связываем 1С, корпоративный портал, банк, документооборот, площадки и мессенджеры, чтобы данные ходили сами, а не переносились копированием в таблицу. Каждый обмен пишется в журнал целиком — видно, что, куда, когда и почему ушло.
Написать обмен, который работает на счастливом сценарии, — несложно. Ценность появляется там, где внешняя система не ответила, ответила ошибкой, ответила «хорошо», но ничего не сделала, или прислала одно и то же событие дважды. Именно на этих случаях интеграции обычно и разваливаются — тихо, без единой записи в журнале.
Поэтому мы строим обмен так: очередь вместо прямого вызова (проведение документа не ждёт внешнюю систему), повтор при сбое, защита от повторной обработки одного события и журнал, в который пишется ответ внешней системы целиком, а не отметка «успех». Без последнего разобрать случай «портал ответил, что всё хорошо, а поле не изменилось» невозможно.
Есть два способа связать системы: внешняя дёргает вашу учётную или ваша учётная сама опрашивает внешнюю. Второй вариант часто оказывается проще и безопаснее: публиковать 1С в интернете не требуется, хватает исходящего соединения. Мы предпочитаем его всюду, где это возможно, — меньше открытых дверей, меньше согласований со службой безопасности.
Отдельный слой — предохранители на время обкатки. Пока обмен не проверен, он работает по белому списку: обрабатываются только явно перечисленные объекты. Это позволяет включить интеграцию в боевой базе, ничего в ней не сломав.
Журнал с полным содержанием. На каждую операцию — что послужило основанием, куда ушёл запрос, каким было тело, что именно ответила внешняя система, за сколько миллисекунд, от чьего имени и автомат это был или человек.
Сверка количества. Любая операция, которая перекладывает записи, обязана считать их до и после и показывать расхождение. «Обмен прошёл успешно» при потерянных строках хуже явной ошибки.
Сторож. Обмен, который тихо перестал работать, опаснее обмена, который падает с ошибкой. Ставим проверку, что он живой, и оповещение при первом же молчании.
Половина работы оказалась не в коде, а в разборе данных: поле «продавец» в CRM было свободной строкой, и одно юридическое лицо писали пятью способами. Пока это не разобрано, обмен будет исправно переносить мусор.
Поэтому в интеграционных проектах мы всегда закладываем шаг «посмотреть, что реально лежит в полях» — до того, как писать перенос. Об этом же страница про дашборды: качество данных всплывает одинаково в обеих задачах.
Копия учётной базы, на которой можно отлаживать. Если тестового контура нет — поможем его получить; отлаживать сразу в боевой мы не станем.
Отдельная учётка с минимально необходимыми правами — не администратор. Так в журнале видно, что операцию сделал обмен, а не человек.
Человек, который скажет, какой документ считается правильным и что делать со спорным случаем. Это решение бизнеса, а не разработчика.
Нет, это обычная ситуация в стройке: типовых конфигураций почти не встречается. Мы читаем метаданные вашей базы и делаем обмен под её реальную структуру, а расширение ставится без снятия конфигурации с поддержки.
Обмен построен через очередь: документ не блокируется, неудачная попытка повторяется, а в журнале остаётся точный ответ внешней системы, а не отметка «успех». Именно это позволяет разобрать случай «портал ответил, что всё хорошо, а поле не изменилось».
Часто да. Если инициатором обмена сделать саму учётную систему — она сама опрашивает внешнюю по расписанию, — публиковать её в интернете не требуется, хватает исходящего соединения. Это заметно проще с точки зрения безопасности.
Расскажите, что болит. Разберём ваш ландшафт и предложим, с чего имеет смысл начать, — без обязательств с вашей стороны.