Шаппелл esb сервисная шина предприятия

В июле 2008 года в Издательстве «БХВ-Петербург» выходит книга Дэвида А. Шаппелла «ESB-Сервисная Шина Предприятия». Приобрести издание можно непосредственно в компании Progress Teсhnologies и у наших партнеров, а также в крупнейших книжных магазинах на территории РФ и интернет-магазинах.

Стоимость книги: 499 рублей, включая НДС.

Книга посвящена широкому кругу вопросов интеграции распределенных информационных систем в рамках реализации архитектуры SOA, ключевым технологическим элементом которой является сервисная шина предприятия ESB. В рамках книги подробно рассматриваются теоретические и практические аспекты прикладной интеграции – концепции, принципы построения и реализации интеграционных решений. Детально рассматриваются подходы к проектированию и шаблоны интеграции прикладных систем на основе сервисной шины ESB. В данной книге обсуждаются вопросы развития стандартов Web-сервисов и их использование на сервисной шине ESB. Книга снабжена богатым графическим материалом, а также компакт-диском с программным продуктом Sonic ESB компании Progress Software Corp.

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

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

Видео:Плюсы и минусы сервисной шины данных I Enterprise service bus (ESB) I kt.teamСкачать

Полистать книгу

Для тех, кто уже приобрел книгу «ESB-Сервисная Шина Предприятия» и хочет активировать лицензии, пожалуйста заполните регистрационную форму:

Видео:Шины VS брокеры сообщений | KT.Team | Андрей ПутинСкачать

Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB

Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее — ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:

• Порядок и единообразие архитектурных связей
• Централизованное управление
• Конфигурация приложений на стороне сервера
• Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
• Протоколо-независимость разрабатываемого программного кода
• Широкие возможности конфигурирования шины и приложений

При этом ESB обеспечивает транзакционный контроль, преобразование данных, сохранность и гарантированную доставку сообщений. Доступ ко всем сервисным службам через единую точку позволяет осуществлять конфигурирование коммуникации сервисов централизованно. Так же централизованно можно управлять сбойными событиями для массовой обработки ошибок.
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» — если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:

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

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

Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.

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

Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.

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

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

Но гибкость приложений под IBM WebSphere ESB не ограничивается средой их работы. Громадный вклад в это делают возможности разработки. Поскольку, системы не только нужно иметь, где запускать, но еще нужно разрабатывать и дорабатывать, эти интересные пункты упускать нельзя:

SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).

Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).

Читайте также: Тип шины amd k15 что это

Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.

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

Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.

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

В статье использованы следующие изображения: 1 2 3 4 5

Видео:Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать

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

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

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

Видео:Сравнение ESB-систем | Ключевые отличия от брокеров сообщений | kt.teamСкачать

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

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

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

Видео:DATAREON ESB. Коротко о главномСкачать

О проекте

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

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

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

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

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

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

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

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

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

Видео:СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать

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

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

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

  Читайте также: Резина это шины или колеса

  Видео:Интеграция систем на примере шины ESB · Евгений Путилин · ЛАФ #системныйаналитикСкачать

  

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

  

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

  • Для подключения к конфигурациям 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 определенных полей. Сформулировали этот единый формат, описали его здесь в метаданных шины – и теперь системы будут получать и забирать данные в этом формате.

      Видео:Корпоративная сервисная шина данных DATAREON ESB. Знакомство с продуктом. Урок 1Скачать

      

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

      Если говорить о 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С:Конвертация данных”.

      Видео:Опыт внедрения ESB интеграционной шины в ПАО «Газпром Нефть» Михаил ХаритоновСкачать

      

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

      

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

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

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

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

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

        

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

        Видео:Шины данных и интеграции | ESB шина данных | Интеграция 1С ERPСкачать

        

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

        

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

        Видео:Установка и настройка шины DATAREON ESBСкачать

        

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

        

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

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

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

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

        

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

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

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

        

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

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

        

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

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

        

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

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

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

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

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

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

        

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

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

        

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

        

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

        Видео:Архитектура шины DATAREON ESBСкачать

        

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

        

        Перспективы

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

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

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

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

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

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

        В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

        • Свежие записи
          • Нужно ли менять пружины при замене амортизаторов
          • Скрипят амортизаторы на машине что делать
          • Из чего состоит стойка амортизатора передняя
          • Чем стянуть пружину амортизатора без стяжек
          • Для чего нужны амортизаторы в автомобиле

          🔥 Видео

          1С ШИНА. ШИНА ДАННЫХ 1С. УСТАНОВКАСкачать

          

          Абиссинская скважина // когда нет альтернативы добычи водыСкачать

          

          DevCon.3 11. Пример интеграции информационных систем через 1С:ШинуСкачать

          

          Интеграция 1С с СУБД при помощи сервисной шины данных DATAREON ESBСкачать

          

          Типовые расширенные коннекторы DATAREON ESBСкачать

          

          Различия SOA и микросервисной архитектуры за 9 минутСкачать