Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть"

Меня зовут Харитонов Михаил. Я – директор компании 2is, специализирующейся на системной интеграции.

Сегодня я хочу поделиться с вами опытом внедрения интеграционной шины, разработанной на 1С в компании «Газпром нефть». Я думаю, что это – чуть ли не первый проект, реализующий интеграционную шину на отечественном ПО в таких масштабах.

О себе и о компании 2is

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

• Компанию 2is я организовал в 2004 году, после того, как ушел из «1С». Возникли некоторые внутренние противоречия по развитию, захотелось быстрее и больше делать, все успевать.
• Компания специализируется на системной интеграции и консолидации. Любимые проекты – управленческий учет и финансы. Люблю двойную запись, регистр бухгалтерии и все, что с этим связано!
• Уже пять лет мы выпускаем продукт «2iS:Интеграция» – это фактически платформа для разработки сервисов по обслуживанию различных систем, баз, инфраструктуры, сбору отчетов и т.д. Это полноценная сервисная шина предприятия, которая позволяет понятным, стандартным образом подключать и разрабатывать свои сервисы для массового обслуживания баз, систем и управления ими.
• Судя по выступлениям на конференции, опять становится модной тема “экстремального программирования” (XP). Ничего там экстремального нет. Мы используем эту технологию с самого начала. “Парное программирование”, например, когда два программиста садятся и вместе пишут код – результат, конечно же, получается совсем другой. Это – синергия. Единственное, тяжело заставить их (программистов) это делать, но если получается, то результат превосходит все ожидания.

О проекте

По нашему проекту внедрения:

• Пилотный проект мы выполнили в 2015 году на одном из дочерних подразделений компании. Суть сводилась к тому, что мы переключили существующие обмены на тестовой среде (порядка 25-ти потоков) на нашу централизующую систему. Произошло все это быстро и безболезненно – были только мелкие ошибки в прикладных решениях из-за невозможности установки COM-соединения, которые решались оптимизацией правил. Я хочу сказать, что этот кейс работает для большого количества компаний. Когда к нам обращаются с желанием упорядочить обмены между множеством баз, мы отправляем в ответ опросник в Excel, где нужно расписать: систему-источник, систему-приемник, правила, план обмена, расписания, проблемы. Сначала люди удивляются, что для пяти конфигураций используются более пятидесяти правил обмена, но когда они создают этот список, им становится понятно, сколько стоит все это сопровождать, обслуживать и обновлять. Поэтому один из кейсов – это просто переключение существующих обменов на единую систему, которая будет управлять запуском заданий, контролировать ошибки, присылать уведомления и т.д.
• Основная цель проекта, обозначенная в договоре – это обеспечение централизации управления.

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

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

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

Когда мы начинали работать с разными разработчиками разных систем – все делали кто во что горазд: кто-то перечень полей пришлет в тексте на двенадцать страниц, кто-то – в HTML, кто-то – в Excel. В результате мы привели все к стандарту – Excel-форма плюс XML-схема (XSD). Других стандартов нет. Это дисциплинирует и упрощает работу.

В нашем пилотном проекте заказчик специально выбрал такой интересный набор – это несколько целевых систем (в том числе не 1С):

• «1С:УПП Битумные материалы»;
• «1С:ERP Смазочные материалы»;
• Самописная система диспетчеризации автотранспорта;
• 3 самописные базы на Firebird SQL для организации АРМ «ОТСД» (расшифровывается как «Оформление товаросопроводительных документов»). Что касается Firebird SQL, то эта СУБД приятно порадовала – бесплатная, легкая, быстро работает.
• И, конечно, главная система заказчика – это SAP. Она подключалась к шине, причем не сама, а через свою шину, брокер сообщений SAP PO. Надо сказать, что порадовала дисциплина и проработка всех подключений у SAP. Есть чему поучиться 1С консультантам – люди не усложняют себе жизнь на ровном месте.

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

Этапы проекта

По этапам все по классике, никаких Agile.

• Первый этап, самый сложный, заключался в написании технического проекта и спецификации на каждую систему. Этот этап длился с января по февраль. Акт за первый этап нам подписали в апреле, хотя закончили в феврале.
• Параллельно вовсю кипела разработка в 1С и написание программы методики испытаний, поэтому второй этап прошел легко.
• С тестированием тоже проблем особых не было, разве что были трудности с придумыванием эффективных способов провести нагрузочное и пользовательское тестирование.
• Большое количество ошибок прикладного рода всплыло на этапе опытно-промышленной эксплуатации. Разумеется, мы постарались заранее предусмотреть все возможные риски.
  • На одной из систем использовался откат на старый механизм обмена, т.е. договорились, что если за два часа продуктивный обмен не восстанавливается, то мы его выключаем и включаем старый механизм.
  • Также на Firebird SQL параллельно работали и старый и новый режимы обмена. Старый обмен работал через FTP, куда выгружались текстовые файлы, а для работы использовался уже новый режим. Проблем не возникло, поэтому старый просто выключили, остался новый.
  • Были ошибки, которые не удалось предусмотреть в сценариях пользовательского тестирования. Например, если документ помечен на удаление, то, значит, он должен себя вести по-особенному – этот момент не был протестирован.

Интеграционные компоненты

Подробнее об интеграционных компонентах:

• Для подключения к конфигурациям 1С была разработана встраиваемая подсистема «Агент подключения к шине», которую можно объединить с любой конфигурацией в пять шагов – любой 1С-ник за десять минут справится со встраиванием этой подсистемы. В дальнейшем мы планируем ее сделать в виде расширения – ждем версию 8.3.11, где обещают готовую механику. В подсистеме есть:
  • Справочник по настройке узлов обмена – узлы можно привязать к любым планам обмена и к любым уже существующим узлам, т.е. переключить на шину. Допустим, был какой-то обмен по плану обмена, взяли на шину – переключили узел.
  • Журнал регистрации событий по обмену – отдельный по каждой системе. У заказчика было требование, чтобы система обладала информацией о том, как у нее проходят обмены, длительность, успешно или нет, есть ли ошибки.
  • Было много дебатов с заказчиком по поводу хранения в подсистеме правил обмена. По-хорошему, правила должны храниться в единой базе, в центре, версионироваться, предоставлять доступ под определенными ролями и учетками в шине, обновляться по понятному регламенту, чтобы один набор правил мог использоваться для большого количества баз и систем. Но нам не удалось убедить отдел безопасности, и заказчик все-таки захотел хранить правила на стороне каждой системы. Это другой взгляд на вещи, когда каждая система – это свой мирок, в который нельзя давать никому вмешиваться извне. Поэтому по согласованию с заказчиком правила обмена для каждой системы тоже хранятся во встраиваемой в нее подсистеме.

Для подключения к не 1С-системам в шине использовался WSDL веб-сервис, содержащий две универсальные операции:

• PostData (поместить данные);
• И GetData (получить данные).

Внутреннее устройство шины данных

Так выглядит веб-сервис для подключения любых систем к сервисной шине в конфигураторе – входящие (in), выходящие (out) параметры (входы, выходы).

Это – спецификация всех параметров операции GetData веб-сервиса шины. Когда вызывается веб-сервис, передается идентификатор отправителя или получателя узла обмена.

• Для 1С узел обмена – это узел любого плана обмена.
• В SAP узел обмена – это тип, т.е. на каждый тип свой канал, свой интерфейс, свой отдельный веб-сервис, свой разработчик. Поэтому сколько типов, столько каналов обмена с SAP.

Задача шины в первую очередь – принимать данные и отдавать их «брокеру сообщений».

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

По устройству метаданных в шине есть много деталей и внутренних «фишек».

• Справа на слайде описываются классификаторы и все метаданные инфобаз – их конфигурации, все поля и свойства.
• Слева – основное ядро. У нас есть:
  • Описание инфобаз;
  • Настройки узлов обмена для каждой инфобазы – узлов может быть много, они привязываются к планам обмена;
  • Правила маршрутизации объектов в шине, т.е. объект приехал, настраиваем при каких условиях этот объект нужно преобразовать и передать другим системам, системам подписок;
  • Конвертация в самой шине между разными форматами;
  • Схемы XSD, описание форматов систем;
  • Два регистра для хранения всех сообщений – принимаемые сообщения обмена и отправляемые сообщения обмена и сообщения обмена данными. Сами сообщения упакованы в пакеты. С помощью PostData данные получили, сделали запись в принимаемых сообщениях. С помощью GetData данные отправили – появилась запись в отправляемых сообщениях, и в тот момент, когда система забирает уже подготовленный пакет, у записи появляется признак, что она отправлена, дата отправки, статус.
  • Журналы регистрации событий в привязке к соответствующим метаданным.

Здесь показаны вспомогательные сервисные объекты метаданных.

Основной перечень сервисных метаданных, используемых в шине.

Подключение любой новой системы к шине выглядит так, как показано на слайде.

На каждую подключаемую к шине систему - создаем подсистему, например, назовем ее шдОбмен_1С_ERP_СМ.

Также создаем в шине план обмена – в данном случае, шд1С_ERP_СМ. Этот план обмена будет регистрировать в шине те объекты, которые нужно передать этой подключаемой системе. Узлов обмена с этой системой может быть много, т.е. сколько нам каналов обмена с данной системой нужно, столько узлов и создаем. Например, по одному узлу - справочники, по другому -  документы, и отдельно, например, логи и журналы по разным расписаниям. Или, как по классике - два узла - оперативный и неоперативный.

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

Мы можем в шине описать формат, как удобный для какой-то любой системы (конкретно здесь про SAP идет речь).

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

Что дает такое описание метаданных (в виде объекта системы)?

Если говорить о SAP и каких-то других системах (не 1С), то они работают чаще всего по схеме XML (XSD-схеме). Известно, что со схемами XML в 1С все хорошо, более того, для каждого объекта, описанного в метаданных, можно автоматически получить его схему XML, сформировать для него объект XDTO, записать этот объект в текст XML по соответствующей схеме. Если у нас объекты так хранятся и получаются, мы без программирования можем их сериализовать и десериализовать в XML, JSON и т.д.

На скриншоте вы можете увидеть «Заказ клиента», метаданные которого описаны, подстраиваясь под SAP. Как вы видите, всем реквизитам даны замечательные русские названия, но в комментарии к каждому реквизиту записаны английские восьмисимвольные имена полей в SAP.

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

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

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

Либо они могут ложиться «один в один», без программирования по XDTO (XSD-схеме), либо можно написать правила конвертации, которые из подключаемой 1С-системы преобразуют данные в эти форматы. А эти форматы сразу заберут другие системы: SAP и прочие без программирования.

Также обычными правилами конвертации мы можем преобразовывать форматы разных систем в самой шине. Представим себе, что мы в метаданных напишем справочники «Контрагенты_БП», «Контрагенты_УТ», «Контрагенты_УПП» – пять справочников добавим со своей структурой, опишем. Достаточно написать правила преобразования, которые будут применяться внутри шины, и все это будет работать. Одна система прислала данные, появился новый элемент справочника «Контрагенты_БП». Система понимает, правила настроены, что его нужно еще в «Контрагенты_УТ» передать, она делает конвертацию по обычным правилам КД2 из одного формата в другой. Это изящное решение позволило нам накрыть весь спектр любых систем и форматов использованием единого инструментария - правил обмена, разработанных в “1С:Конвертация данных”.

Порядок подключения новой системы к шине данных

Итак, еще раз по порядку подключения:

• описываем метаданные;
• делаем правила конвертации;
• настраиваем узлы, расписание, и обмены работают.

Варианты разбора и передачи сообщений:

• • для систем на 1С – правила конвертации;
  • для других систем – схема XSD, т.е. используется объект XDTO.

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

На слайде описаны преимущества такого подхода описания метаданных.

Правила маршрутизации в шине

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

Тестирование

По поводу тестирования.

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

• Первый тест – это приемка/отправка пакетов сообщений, т.е. фактически, это тестирование платформы 1С на уровне работы веб-сервиса, проверка способности 1С одновременно принять много запросов с разным объемом и записать их в свои таблицы и регистры.
• Второй тест – это внутренняя обработка сообщений в шине, т.е. работа регламентных заданий. Здесь время зависит от сложности трансформаций и обработки объектов. Одно дело – сериализовать \ десериализовать объекты по схеме, другое дело – преобразовать объекты по правилам конвертации. Разница в три-пять раз.

Сценарное тестирование

Сценарии написали по классике – таблички в Excel, на каждый тип объекта своя табличка, где расписываются все шаги бизнес-процессов работы с объектами для различных ролей пользователей. Автоматически прогоняется тест, где пользователь с определенной ролью создает объект, получает результат, этот результат сверяется с эталоном. Но работает сей подход не очень хорошо, пользователи находят много другого, чего не было учтено в СИТ-ах (сценариях тестирования).

Тестирование одновременных вызовов

Производительность сильно зависит от версии платформы. Когда мы начинали тестировать, использовалась одна версия платформы, и все падало на 5-6 вызовах. После того, как мы платформу обновили, произошла очень большая оптимизация. На текущий момент производительность следующая:

• В одну секунду 23 вызова «Поместить», т.е. шина в секунду записывает 23 пакета. Причем, производительность не зависит от объема пакета – при увеличении или уменьшении мегабайт, передаваемых в пакетах, особой разницы мы не нашли.
• Получение данных в секунду поменьше – семь вызовов.

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

Говоря про масштабирование, мне шина иногда представляется, как матрица из большого количества кубиков, которые выстроены, например, в линеечку, а линеечка – это сервера. При необходимости такие шины можно размножать – если сервера не хватает, то проще поставить рядом с ним второй такой же маленький, повесить на него вторую шину и развести потоки, например, по типам данных, как учил SAP – одна шина обрабатывает справочники, другая – документы. Настройки потоков можно копировать между базами. Это как 1СFrеsh-архитектура – захотели, слили две базы, захотели, разделили. Также с шинами. Получается утилитарная технологическая вещь.

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

Соответственно, результаты теста были ухудшены неоптимальной конфигурацией.

Тестирование скорости обработки данных в шине

Запускались параллельные регламентные задания от 1-го до 50-ти, которые выполняли обработку пакетов, а именно, распаковывали пакеты по 1000 объектов в каждом, и записывали эти объекты в соответствующие справочники или документы (в транспортные объекты шины).

Средняя скорость обработки для одного потока – 100 объектов в секунду.

А для 50 параллельных потоков – 1000-1100 объектов в секунду.

Понятно, что там идет нелинейная зависимость. Мы достигали ее насыщения – где-то 50 при данном железе уже не дает нужный прирост. Нет смысла так выжимать при таком железе.

Производительность для требований заказчика нормальная, все устроило. Тесты приняты. Сбоев и падений не зафиксировано.

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

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

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

Еще про масштабируемость.

Очень хорошо себя зарекомендовали возможности COM-соединений – мы «испахали» их вдоль и поперек. Именно технология DCOM позволяет масштабировать выполнение задач на разных серверах. Обычных задач, реализованных с помощью обычных 1С-ных обработок, запускаемых в нужных нам базах по расписанию. Благодаря подключению и настройке DCOM на удаленных серверах можно распределить тяжелые операции по набору серверов. Это если мы говорим про различные произвольные управляющие и интеграционные сервисы.

Перспективы проекта. Планы развития «2iS:Интеграции»

Перспективы

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

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

Будем делать «Агент обмена с шиной» в виде расширения, чтобы это все внедрялось максимально легко, без снятия конфигураций 1С с поддержки.

Очень много в последнее время запросов по MDM. У нас есть хорошие кейсы. Как правило, внедрение шины связано с желанием упорядочить инфраструктуру, навести порядок в справочниках, внедрить систему BI. А для того, чтобы внедрить систему BI, должны быть единые справочники и единые идентификаторы, поэтому это взаимосвязано. MDM и BI притягивают шину. Эти вещи очень сильно связаны.

И недавно вышла финальная 1C:Enterprise Development Tools – будем смотреть инструментарий, оцениваем возможности применения.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.