Почему никто не любит обмены, и что с этим делать?

Всем здравствуйте! Меня зовут Лилия Алёхина. Я представляю компанию Самокат.

В большинстве компаний, где мне доводилось работать, реализация обменов выглядела следующим образом:

• Среди разработчиков (дай бог, если их в компании больше чем один) выбиралась жертва.

• Эта жертва делала обмен в одиночку под ключ (а это анализ, разработка, тестирование) - качество зависело от квалификации, опыта, личной ответственности и сроков.

• После запуска на проде - ошибки, хот-фиксы, доработки, откаты (много или мало зависело не только от качества, но и от правильного понимания задачи - это же разработчик, а не аналитик).

• В итоге все выливалось в переработки в авральном режиме, а все шишки сыпались на единственного исполнителя (а на кого же еще?).

И чем чаще ты пишешь обмены, тем чаще выбирают тебя, потому что у тебя же опыт.

Какая уж тут любовь?

В результате в подобных задачах имеем на рынке вот такую картину с разработчиками обменов 1С. Я считаю, что сложившуюся ситуацию нужно в корне менять.

А для этого необходимо повысить уровень комфорта при разработке обменов – и таким образом удовлетворить ту самую «потребность в безопасности» в пирамиде Маслоу.

Тогда разработчиков 3 типа станет больше, а значит, и результат будет лучше.

Я расскажу про подходы, которые мы внедрили в своей компании для реализации обменов.

И вы можете начать внедрять их в своей команде как кирпичики – вместе или по отдельности, с использованием тех же программных средств и подобной архитектуры или совсем других.

В целом я выделяю 5 следующих составляющих в реализации обмена, на которые стоит обратить внимание и поработать над их качеством:

• автоматизация рутинных операций;

• внятное техническое задание, написанное системным аналитиком;

• качественное тестирование перед запуском на прод;

• регулярная сверка результатов после запуска;

• и прозрачность системы в целом – с той простой целью, чтобы не только исполнитель мог потом с этим разобраться.

Подсистема событийной интеграции

В нашей компании разработана подсистема событийной интеграции. Мы отказались от использования классических планов обмена (там есть свои неприятности с блокировками в высоконагруженных системах – а это как раз про нашу компанию) в пользу двух регистров сведений.

• В первый по триггеру в транзакции пишется ссылка на объект, связанный с событием. Что важно, не всегда этот объект в итоге входит в событие. При этом отбор вынесен из транзакции в регламентное задание конвертации, чтобы в самой транзакции у нас был минимум манипуляций – зарегистрировали и забыли.

• Второй РС – это очередь сообщений к обмену, сюда уже пишется итоговый JSON.

• После транзакции информация обрабатывается последовательно 4 регламентными заданиями:

  • в источнике 2 регламентных задания отвечают за конвертацию и отправку в брокер сообщений;

  • в приемнике 2 – за получение из брокера и обработку на стороне базы-приемника.

Такой подход избавляет от многих проблем, которые есть у планов обмена, позволяет сегментировать сообщения к выгрузке и организовать гибкую многопоточность при загрузке.

Хочу заметить, что эта подсистема подходит не только для обмена между разными базами 1С, но и для обмена с другими внешними сервисами.

• Либо 1С – это источник, а приемник – внешний сервис, где обработкой сообщений занимаются уже какие-то другие департаменты, вообще не 1С-ники. Они уже дальше сами разбираются, что с этим делать.

• Либо наоборот, когда сообщение приходит из внешнего сервиса в брокер и дальше уже обрабатывается в вашей базе 1С.

В подсистеме используются единые алгоритмы конвертации в источнике и обработки в приемнике и соответственно единый формат сообщения.

Мы для себя решили, что описывать каждый раз весь обмен в коде с нуля – это нецелесообразно, т.к.:

• немасштабируемо;

• трудозатратно при разработке и для разбора другими разработчиками;

• приводит к неминуемому копипасту.

Если в вашей команде используется системный подход, то транспорт чаще всего плюс-минус одинаковый. И конвертация плюс-минус одна и та же – каждый раз перечисляются реквизиты, которые надо переносить.

В итоге мы постарались вынести максимум настроек в интерфейс, результатом чего стало 2 справочника:

• спр. «События», в котором:

  • состав события;

  • простые отборы;

  • включение обмена;

  • настройки для многопоточности (о них я расскажу дальше).

• спр. «Объекты метаданных» (он чем-то похож на правила конвертации объекта в «Конвертации данных 2»), в котором:

  • варианты полей поиска (здесь уже привет «Конвертации данных 3»);

  • псевдонимы объектов, реквизитов и табличных частей для JSON;

  • перечень реквизитов обмена с возможностью выключения для отдельных событий или в целом для обмена, если вы ими вообще не хотите обмениваться.

По поводу псевдонимов замечу, что поскольку мы обмениваемся не только с 1С, но еще и с внешними сервисами, атрибуты в JSON у нас в латинской транскрипции, а не в русской, чтобы не смущать коллег.

Благодаря такому подходу:

• для реализации простого обмена в источнике код вообще писать не нужно (достаточно при настройке поставить нужные галочки), а в приемнике разработчику необходимо добавить 1 процедуру с одной строчкой выполняемого кода.

• в случае сложных обменов уже наработан фреймворк в виде процедур и функций общего модуля, используя который можно обрабатывать достаточно нетривиальные кейсы обмена. Это покрывает все возникающие потребности, и новых процедур уже давно в этом перечне не было.

Не буду останавливаться на каждой процедуре отдельно – за них говорит их название.

• Есть смысл упомянуть процедуры на стороне приемника ПроверитьЛогикуПоОбъекту() и ПроверитьЛогику(). Здесь реализуются проверки данных, они зависят от задачи и от того, какие могут быть косяки в данных – могут наращиваться по ходу тестирования или даже после запуска, если, например, уже на большом объеме реальных данных у нас появляются какие-то странные вещи. В целом важно понимать, насколько такие проверки целесообразны в конкретных процессах.

• То же касается и автоматической корректировки данных, что возможно в процедуре ПодготовитьСтруктуруКОбработке(). Например, если у нас в поле «Количество» пусто, можно при желании единицу ставить, или наоборот удалять такую строку – это все, опять же, на усмотрение по логике задачи.

Транспорт

Транспорт – тоже общий механизм, здесь используем брокер сообщений Apache Kafka.

Сегодня в сообществах 1С и не 1С брокер сообщений – то ли мем, то ли тренд. У многих команд формируется странное восприятие, что если сделать обмен с помощью брокера сообщений, то это решит все проблемы с обменами. Этакая панацея.

Мы долгое время в качестве транспорта использовали http-сервис. Нас более чем устраивала скорость, была гарантия доставки. Все было хорошо. Единственную проблему, которую мы решали, перенося транспорт на Apache Kafka – произвольное число получателей.

Мы решили остановиться на продукте компании «Серебряная Пуля», поскольку нам уже доводилось с ним сталкиваться пару лет назад и он устроил нас в качестве фундамента, на основе которого мы можем строить собственное решение.

Перенесли конфигурацию в расширение и сделали минимум доработок (они на слайде). Бонусом получили ускорение доставки при больших объемах.

В итоге полное время выполнения от регистрации до завершения обработки в приемнике – от 1 до 5 минут (при отсутствии ошибок в данных).

Многопоточность

Как ни крути, самое узкое место в плане производительности – это обработка сообщений после получения в базе-приемнике.

В ходе развития подсистемы нами был выработан подход к реализации многопоточности.

У каждого события есть:

• приоритет;

• дата возникновения события;

• вид аналитики для многопоточности.

Приоритет и дата обеспечивают порядок, в котором обрабатываются события.

Вид аналитики – критерий, по которому данные группируются в потоки:

• Вариант «Без аналитики» хорошо укладывается для нормативно-справочной информации и для документов прихода – для них порядок при организации многопоточности не важен.

• Вариант «По складу» разумно использовать для документов расхода, потому что у нас используются серии, для которых важен хронологический порядок проведения документов.

• Вариант «В один поток» – в качестве примера я могу привести документ перемещения товаров, где это приход на один склад, расход с другого склада, и здесь уже события логично выстроить в цепочке друг за другом.

Такое управление многопоточностью дает определенную гибкость в различных ситуациях и решает проблему со скоростью обработки на стороне приемника.

На слайде приведена таблица с примерами , какие настройки могут быть для событий по цепочкам документов:

• приоритет события;

• вид аналитики для многопоточности;

• состав события;

• и триггер - объект, при изменении которого событие возникает (обратите внимание, что есть варианты, когда сам триггер в состав события не входит).

Проработанное ТЗ

При таком подходе к реализации обменов техническое задание – это не какой-то огромный текст, который пишется бесконечное количество времени, а потом еще столько же времени согласуется со всеми участниками процесса (в случае обмена их еще нужно поискать).

Техническое задание при едином подходе к написанию обменов – это документ, написанный по единому образцу, без лишней воды со строго определенными разделами, понятными как системному аналитику, так и разработчику после написания хотя бы одного обмена.

Многие привыкли, что обмен – это исключительно техническая задача, в которой не нужен анализ. В начале я рассказывала, чем это плохо. Обмен – это такой же бизнес-процесс. И я считаю, что он даже еще более критичный. Однажды вы ставите его на выполнение, и дальше он выполняется сам и делает с вашими данными бог весть что. И если никто в этот процесс раньше не вникал, это проблема.

Наличие проработанного аналитиком ТЗ очень важно, хотя бы для того, чтобы не переделывать задачу по несколько раз. В качестве побочного эффекта имеем документацию и сплоченную команду, готовую выдавать качественный результат в короткие сроки.

Если возвращаться к фильму «Веном», который был выбран как визитка секции «Интеграция и обмен данными», мы здесь имеем уже тройную симбиотическую систему разработчик + инструмент + аналитик. Такой тройной эффект есть и в природе, если поискать. Т.е. здесь мы движемся эволюционным путем.

Тестирование и регулярная сверка

Тестирование – важная составляющая в реализации любой интеграционной задачи. Поэтому после реализации и код-ревью задача передается аналитику.

На слайде приведены этапы тестирования, которые мы выделяем. Отдельно остановлюсь на тестировании на ограниченной и полной выборке – при больших объемах часто проявляют себя кейсы, которые, как говорится, нарочно не придумаешь.

• Тестирование на полной выборке справедливо для нормативно-справочной информации.

• Тестирование на ограниченной выборке справедливо для документов – тут в зависимости от объема выбирается какой-то период. Мы можем взять документы за месяц из исторических данных. Можем взять за неделю.

Именно на этих этапах тестирования вы выявите максимальное количество кейсов. И если их избегать, то можно поймать очень много неожиданного и неприятного после запуска на проде.

Плюс мы придерживаемся стратегии, что при обменах изменения должны быть идентичными с интерактивными изменениями данных. ОбменДанными.Загрузка = Ложь – это на моем опыте то, чего обязательно придерживаться при обмене с внешними системами, потому что если с другой базой 1С еще можно надеяться, что источник отвечает за корректность данных, то внешние сервисы часто разрабатываются людьми, очень далекими от учета.

После запуска очередного обмена в регулярное выполнение добавляется алгоритм сверки по нему. Для этого в подсистеме реализован механизм сравнительных отчетов. Он доступен из пользовательского интерфейса, чтобы вне релизов можно было комфортно вносить изменения и как-то играть с данными, которые он возвращает.

• Пишется 2 запроса – к текущей базе и к внешней базе – в пользовательском интерфейсе, что позволяет вносить изменения вне релиза. Плюс есть возможность добавить процедуру постобработки. Результат выполнения показывает расхождения в данных в удобоваримом виде.

• Ничего не мешает писать запрос и к внешним сервисам, если возникнет такая необходимость, и получится договориться с коллегами «по ту сторону» о том, что мы шлем им запрос, и они нам взамен присылают данные в нужном формате.

• Сверка выполняется регламентным заданием. Настроена метрика в Prometheus. В случае отклонений приходит уведомление.

• События сгруппированы в функционалы. И по ним можно настроить уведомления ответственным в случае ошибок, сбоев и успешном выполнении. Например, кому-то из пользователей нужно узнавать, что появился новый контрагент, чтобы что-то там в нем урегулировать – например, завести ему договор.

Прозрачность + Стабильность = Любовь

В итоге описанный подход обеспечивает прозрачность при разработке, поддержке и мониторинге обменов. Обмен перестает быть черным ящиком, процесс становится осязаемым и контролируемым.

После запуска обслуживание можно передать даже на первую линию поддержки, чтобы освободить ваших разработчиков от постоянной слежки за обменом, все ли там хорошо, чтобы не поднимать его в час ночи, если что-то не так, и чтобы в принципе человек уже дальше занимался своей работой и приносил пользу.

Система масштабируема:

• и в плане реализации обменов (достаточно добавить единые расширения в новую базу, что делается за полдня);

• и в плане подключения новых потребителей сообщений за счет брокера.

Комфортно работать не только команде, но и руководству - увольнение разработчика перестает быть фобией: обмены не парализованы и не живут своей жизнью при смене части команды.

Если в своей работе вы внедрите хотя бы некоторые из озвученных подходов, то вы определенно упростите разработку обменов в своей команде, не придется краснеть за свои обмены, не будет страшно при очередном запуске, а возможно вы и ваши коллеги даже полюбят писать обмены так же, как все любят реализовывать другие сложные задачи автоматизации бизнеса.

Спасибо за внимание!

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.