Transcript Document
Практический опыт использования Ensemble
Борис Егоров
Происхождение видов
О чем вы думаете, когда слышите
«Интеграция приложений»
?
Происхождение видов
• Две или несколько систем, содержащие данные...
• Обмен данными...
• Отслеживание изменений в данных...
• Расписания передачи данных...
• Сбор данных по отчетности...
• Конвертация данных... словари... вспомогательные данные...
• Накопление данных...
Происхождение видов
• Данные, данные, данные...
• Координация данных • 90% всех проектов, в которых есть слово «интеграция» • Сложность – не архитектурная – техническая (производительность) – постановочная • Extract, Transform, Load (ETL)
Exract, Transform, Load
• Координация данных • Две и более систем, синхронизация по расписанию • План работы – Связаться с первой – Связаться с второй – Трансформация данных • Наиболее часто встречающийся случай – синоним слова «интеграция» • Восприятие заказчика
Как это выглядит в Ensemble?
• +трансформация данных • дьявол в деталях...
ETL-сложности: Скорость
• synchronous call, in-proc invocation для бизнес-операций • лучше 1 большое сообщение, чем 10 более мелких • мета-сообщения (tickets) • преобразования данных, основанные на COS • пул процессов, отключение трассировки • веб-сервисы – не самая хорошая идея • накопление данных и внутренняя обработка
ETL-сложности: Преобразования
• Прежде всего - постановочная • Преобразование данных – отображение source-сообщения на target-сообщение • Вызывается из служб, операций, процессов • Способы задания – графическое представление / XML – код на Cache’ Object Script • «Изобразительные» средства преобразований • Ensemble Data Transformation Language
«Изобразительные возможности»
• Набор Ens.Util.FunctionSet
– ToUpper/ToLower – Lookup/Exists (^Ens.LookupTable(table,value)) – ... обертки для COS-функций, но доступны непрограммисту • Набор функций – расширяем (наследование FunctionSet) • Произвольный код – максимальное быстродействие, сложные алгоритмы с сохранением «цивилизованного» интерфейса.
Общая часть – организация взаимодействия
• Модель допустимого взаимодействия определяет инструменты • Безконфликтные – интервальное сканирование (BS) • системы через API, каталогов выгрузки, и т.д.
– вызов API по требованию Ensemble (BO) • Требующие вмешательства во внешние системы – обращение к Ensemble (BS + композитные) – работа с хранилищем Ensemble (все интерфейсы + композитные)
Общая часть – организация взаимодействия
• Головная боль – отслеживание изменений • SQL-адаптер – Поле идентификатора – ^Ens.AppData
• В общем случае – не решается, кроме как полным кэшированием данных и сравнением • Частные случаи – таблицы журналов изменений – даты модификаций и пр.
– ...
Общая часть – организация взаимодействия
• Интерфейсов – нет • Эмуляция работы пользователя • Rational Robot • Дешевые/бесплатные альтернативы • http://www.ixbt.com/soft/autosoft-part1.shtml
• Возможная проблема исполнения на той же машине
Сообщения
• «Хорошие» сообщения не зависят от характеристик источника • Часто возникающая ситуация – с offline взаимодействием • Сообщения – мощный механизм абстракции
Родственник ETL – Data Hub
• Сбор многоаспектных данных • «Композитные объекты» – несколько независимых частей • Сборка объектов • Дилемма – Легко собирать данные, трудно получать объекты – Труднее собирать данные, легче получать объекты Школа Бюджето получатель Объекты госимущества Демогр. данные Подчиненный Департамента Образования
Родственник ETL – Data Hub
• «Универсальная структура данных» • Сущности – объект, атрибут, показатель, узел классификатора + структуры для составляющих • Сложные алгоритмы дальнейшей обработки и проставления ссылок
Родственник ETL – Data Hub
• Все «части» композитного объекта встраиваются в иерархию классов • Смысловая связность • Простота дальнейшего использования
Data Hub – сборка данных
• Сборка объектов – алгоритмическая (миф?) – фактографическая (мастер-индекс, трудоемкость обновления) – смешанная
Data Hub – сборка данных
• Классификаторы – в виде экземпляров данных • типы данных – узел классификатора, классификатор и т.д.
• В виде мета-информации (классы) – облегчает сборку композитных объектов – усложняет сбор исходных данных – облегчает дальнейшее использование собранных данных
Моделирование бизнес-процессов
• Упрощение взаимодействия с заказчиком • Свобода реализации (диаграммы / код) • Легкий переход к процессам в Cache’ – приложениях
Устранение разрыва
• Бизнес-процесс с точки зрения человека-аналитика • Бизнес-процесс с точки зрения интеграционной платформы • Компоненты бизнес-процессов
Сложность отладки
• Асинхронные взаимодействия • «Дорогое» для реконструкции окружение
Открытость Ensemble
• Очень многие механизмы открыты – генерация исполнимых бизнес-процессов – трансформации данных – визуализации схем – workflow – ...
Расширяемость workflow
• Стратегии распределения задач (в наследниках %TaskResponse) • Настройки workflow-портала • Настройки сообщений • Собственные клиенты (ZEN и др.) • Встраивание во внешние приложения • Пакет EnsLib.Workflow
Маршрутизация сообщений (routing engine)
• Маршрутизирующие бизнес-правила – критерии – действия – трансформации
Маршрутизация сообщений (routing engine)
Маршрутизация сообщений (routing engine)
• Изначально вводился для HL7 • EnsLib.MsgRouter.RoutingEngine
– параметр RoutingRule • В 2007.1 – опция “Do all rules”
Версионность бизнес-процессов
• Время работы бизнес-процесса может составлять месяцы • Атрибут version (задается вручную) • Существование экземпляров различных версий • Отдельные версии генерируемых классов – MyBPL.V1.Context and MyBPL.V1.Thread1
– MyBPL.V2.Context and MyBPL.V2.Thread1
Обработка ошибок
• Сводилась к ручному анализу статусов • Интегрируемые системы вовсе не обязаны быть транзакционными
Обработка ошибок
•
Обработка ошибок
Обработка ошибок
Alert
• Служит для уведомления о проблеме • Элемент продукции с именем Ens.Alert отвечает за обработку всех alert в продукции (бизнес-операция) • Ens.AlertRequest
– Property SourceConfigName As %String; Property AlertText As %String; • Alert-сообщения всегда сохраняются в event log
Alert - формирование
• Метод SendAlert –
Do ..SendAlert(##Class(Ens.AlertRequest).%New( $LB(..%ConfigName, “Message Text"))
•
Контроль импорта данных
• Разные источники данных • Разные проверки • Разные люди, отвечающие за разные сегменты данных • Цели – workflow – контроль принятых решений
Контроль импорта данных
• Первичный импорт • Маршрутизатор (роутер) • Бизнес-процесс, специфичный для источника/сущности • Библиотечные проверки • Роли workflow • Финальное сохранение (не показано)
Контроль импорта данных
• Бизнес-служба читает источник, сырые данные сохраняются – добавляются поля статуса (обработано, отброшено, в процессе обработки) – идентификатор «пачки» – хэш исходных значений полей • Если хэш импортируемых данных совпадает с имеющимися, и статус – «в обработке», запись игнорируется • Формируется сообщение – билет (источник, пачка, [конкретная запись]), передается роутеру
Контроль импорта – зачем роутер?
• Для возможности коррекций при помощи преобразований данных • Для более простой настройки • Изменения без остановки продукции • Итог работы – передача сообщения специфичному для сущности/источника бизнес-процессу
Контроль импорта
• Специфичный бизнес-процесс – открывает сырые данные – выполняет проверки при помощи своей внутренней логики, или «библиотечных вызовов» – при необходимости осуществляется выставление workflow задач • Результат работы – исправленные данные в хранилище сырых данных • Если идет обработка не пачкой, а по записям – проверка на то, что пачку можно сохранять (при необходимости выставить task на одобрение)
Спасибо. Продолжение следует.
http://writeimagejournal.com
Борис Егоров