ЗооПАРк, искры и грохот шестеренок: стандартизация интеграционных потоков

Меня зовут Алексей Кудинов. Я занимаюсь интеграцией между системами 1С и внешними решениями. Мой соавтор Сергей Ведутенко прошел путь от стажера до ведущего разработчика 1С, является специалистом широкого профиля.

ТЕХНОНИКОЛЬ – это международный производитель строительных материалов.

• На текущий момент в компании более 70 заводов.

• Мы продаем нашу продукцию в 118 стран мира.

• Выручка за прошлый год составила более 211 миллиардов рублей.

TN Digital – цифровое сердце нашей компании, в котором мы с Сергеем работаем.

Если говорить про стэк 1С, то сейчас в компании трудится более 80 человек. Все из них имеют квалификацию "Профессионал" и выше. И на текущий момент ими реализовано более 40 внутренних проектов.

Компания ТЕХНОНИКОЛЬ на рынке уже давно, и за это время мы накопили определенное количество проблем:

• В администрировании большое количество 1С баз с бессчетным количеством обменивающейся информации.

• В связи с законодательством часто нужно контролировать передаваемую информацию.

• Блокировки таблицы регистрации 1С (проблема – замедление работоспособности базы).

Упомянутые проблемы усугубились в связи с тем, что с 2023 года к нам присоединилось более 17 производственных площадок, то есть по факту это более 17 заводов, и нагрузки на наши внутренние информационные системы увеличились.

За 30+ лет существования нашей компании мы накопили большой зоопарк систем. Часть из них представлена на рисунке.

Технологии за это время довольно часто менялись, программы и продукты тоже. В итоге мы решили, что все наши интеграционные потоки можно разделить по трем категориям:

• Способы взаимодействия между системами,

• Технологии обмена, если мы говорим, что это обмен между 1С,

• Различные форматы взаимодействия тоже накопились за это время.

Стандартизация способов и форматов взаимодействия

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

Поэтому в способах взаимодействия мы приняли решение оставить только два:

• RabbitMQ там, где нам нужна асинхронная передача данных.

• REST там, где эта передача асинхронным способом невозможна, и нам нужен синхрон. Таких процессов немного, порядка 8-10%, поэтому в основном используется Rabbit.

Формат обмена мы выбрали JSON. Он также понятен и человекочитаем, как и XML, который в основном использовался раньше. Но в отличие от XML он более легок, а самое главное, JSON – это стандарт для многих систем и языков программирования на текущий момент.

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

Обработка персональных данных и требования законодательства

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

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

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

Кроме того, нам необходимо фиксировать и хранить всю передачу данных – чтобы при необходимости можно было подтвердить, что передача была или не была осуществлена.

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

JSON Schema – это язык описания структур и правил для JSON-документов. С его помощью можно определить, какие поля должны присутствовать в документе, являются ли они обязательными, в каких условиях и в каком формате. Также можно задавать допустимые значения для перечислений и другие ограничения.

JSON Schema позволяет валидировать JSON-данные при их передаче между системами, обеспечивая соответствие заранее заданному формату. Он гибок и расширяем. Начиная с версии Draft-07, поддерживается механизм паттернов, основанный на регулярных выражениях, который позволяет осуществлять проверку строковых полей. Это дает возможность контролировать содержимое полей: например, выявлять передачу персональных данных или других сведений.

Сервис валидации на базе RabbitMQ и Go

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

Сервис написан на языке Go и дополнительно реализует REST-интерфейс. Это позволяет внутренним системам обращаться к нему за актуальными JSON-схемами – получать описание конкретной схемы или набор схем, согласованных для определенной системы.

Кроме того, сервис автоматически получает все утвержденные JSON-схемы из GitLab. Отдел информационной безопасности согласовывает схемы, после чего они сохраняются в GitLab, а сервис автоматически забирает их себе.

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

Например, верхний кусочек кода, который можно найти в любом учебнике по 1С: выборка изменений по плану обмена. Да, он прост и понятен, но при этом создает значительные задержки при обращении к таблицам регистрации планов обмена и может даже привести к их блокировке.

В версии платформы 1С 8.3.16 появились новые возможности: код немного изменился, появилась выборка по составу метаданных. Это действительно улучшило ситуацию – задержки сократились. Однако в одной из наших самых нагруженных систем мы по-прежнему сталкиваемся с проблемами.

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

Основные особенности универсальной системы обмена данными

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

Первая особенность – это транспорт сообщений RabbitMQ. Чем Rabbit полезен для нашего обмена?

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

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

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

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

Следующая особенность нашего обмена – это неблокирующая выборка изменений. Как говорилось ранее, при большом объеме обмена данными использование метода «ВыбратьИзменения» приводит к ожиданиям на таблицах регистрации.

Есть два простых и известных метода регистрации изменения данных:

1. Использовать типовую регистрацию с использованием механизма платформы,

2. Использовать вспомогательный регистр сведений.

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

Следующая особенность – это принцип «один объект, одно сообщение». Этот принцип подразумевает, что каждое сообщение в системе должно содержать только одну единицу информации. Когда каждое сообщение обрабатывается независимо, это значительно облегчает тестирование и отладку системы.

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

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

Как это работает. Перед началом обработки сообщения с данными мы проверяем на необходимость отправки ping-сообщения по настройкам. Или, если отправляется первое сообщение с данными в приемник, мы принудительно запускаем ping-сообщение. Ping-сообщение отправляет служебное сообщение в приемник. Если в ответ не приходит подтверждение о получении, значит, связь потеряна или не настроена. Без подтверждения работоспособности приемника сообщения из источника выгружаться не будут.

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

Как это работает. В системе ведется нумерация сообщений источника и приемника. При загрузке сообщения мы проверяем, что если последний номер сообщения из источника равен номеру принятого сообщение из приемника. Если это не так, то мы понимаем, что произошел либо backup системы, либо сообщение не обработалось совсем. В этом случае мы запускаем механизм восстановления, который сохраняет номера неполученных сообщений и отправляет их в источник, который и попытается повторно отправить эти сообщения.

Алгоритм обработки сообщений: выгрузка и загрузка

Рассмотрев все особенности нашего универсального обмена, расскажу про алгоритм обработки сообщения – выгрузку и загрузку.

Начнем с выгрузки:

1. Сначала мы проверяем на необходимость отправки ping-сообщения.

2. Если ping-сообщение не требуется отправлять, то далее для запроса получаем зарегистрированные к обмену данные.

3. После этого каждый зарегистрированный объект будет выгружен отдельным сообщением по принципу «один объект – одно сообщение».

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

5. Выгружаем JSON-сообщение в RabbitMQ.

6. Последовательно пронумеровываем исходящее сообщение в пределах получателя.

Загрузка сообщения:

1. Загружаем JSON-сообщение из RabbitMQ.

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

3. После этого последовательно пронумеровываем принятые сообщения в пределах источника.

4. Для каждого загружаемого объекта определяем состав загружаемых реквизитов по согласованной JSON-схеме.

5. Загружаем объект по данным сообщения.

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

Процесс создания и согласования JSON-схем

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

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

В обработке выбираем обменивающийся объект, определяем состав передаваемых данных и выгружаем JSON-схему.

Сформированная JSON-схема автоматически выгружается и отправляется на согласование в отдел управления информационной безопасности.

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

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

Загрузка интеграционных схем в системы-получатели

Следующий этап – это загрузка интеграционной схемы в информационные системы приемника. По регламентному заданию загружаем согласованные JSON-схемы из сервиса валидации JSON и сохраняем их в отдельный справочник «Правила интеграционной схемы».

В этом справочнике хранится состав передаваемых данных объекта, на основании которого будет и формироваться JSON-сообщение при выгрузке и загрузке, и читаться.

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

Как видно на картинке, для справочника «Контрагенты» у производственного подразделения «Москва» обновилась версия правил под номером 2, а для производственных подразделений «Рязань» и «Санкт-Петербург» правило осталось под номером 1. Тем самым мы хотели показать, что ушли от строгого обновления информационных баз в одно время.

Результаты внедрения новой системы обмена

Таким образом мы попытались решить все те проблемы, про которые рассказывали ранее.

• Добились уменьшения нашего зоопарка обменов.

• Облегчили контроль за соблюдением законодательств и по передаче разных пакетов данных.

• Уменьшили время ожидания. На картинке показан трафик – сверху старый, снизу новый.

На новый механизм обменов было переведено порядка 10?12% из того зоопарка, который у нас сейчас существует. Но, несмотря на это, мы полностью убрали пики на ожиданиях. Среднее время ожидания в одной из самых наших высоконагруженных систем упало с 66 секунд до 50. Когда мы доведем результат до 100%, работать нам станет намного легче.

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

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