390 likes | 599 Views
Практический опыт использования Ensemble. Борис Егоров. Происхождение видов. О чем вы думаете, когда слышите. «Интеграция приложений». ?. Происхождение видов. Две или несколько систем, содержащие данные... Обмен данными... Отслеживание изменений в данных...
E N D
Практический опыт использования 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
Обработка ошибок • Сводилась к ручному анализу статусов • Интегрируемые системы вовсе не обязаны быть транзакционными
Обработка ошибок • <scope> • <throw> • <catch> • <catchall> • <compensate> • <compensationhandlers> • <compensationhandler> • <faulthandlers>
Обработка ошибок <process language='objectscript' request='Test.Scope.Request' response='Test.Scope.Response' > <sequence> <trace value='"before scope"'/> <scope> <trace value='"before assign"'/> <assign property="SomeProperty" value="1/0"/> <trace value='"after assign"'/> <faulthandlers> <catchall> <trace value='"in catchall faulthandler"'/> <trace value= '"%LastError "_ $System.Status.GetErrorCodes(..%Context.%LastError)_ " : "_ $System.Status.GetOneStatusText(..%Context.%LastError)' /> </catchall> </faulthandlers> </scope> <trace value='"after scope"'/> </sequence> </process>
Обработка ошибок <scope> <throw fault='"BuyersRegret"'/> <faulthandlers> <catch fault='"BuyersRegret"'> <compensate target="RestoreBalance"/> </catch> </faulthandlers> <compensationhandlers> <compensationhandler name="RestoreBalance"> <assign property='context.MyBalance' value='context.MyBalance+1'/> </compensationhandler> </compensationhandlers> </scope>
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")) • <alert> в BPL • <alert value="The system needs service right away."/> • Автоматическое создание alert-сообщений элементами продукции • Параметр Alert on Error • Параметр Alert Retry Grace Period (BO)
Контроль импорта данных • Разные источники данных • Разные проверки • Разные люди, отвечающие за разные сегменты данных • Цели • workflow • контроль принятых решений
Контроль импорта данных • Первичный импорт • Маршрутизатор (роутер) • Бизнес-процесс, специфичный для источника/сущности • Библиотечные проверки • Роли workflow • Финальное сохранение (не показано)
Контроль импорта данных • Бизнес-служба читает источник, сырые данные сохраняются • добавляются поля статуса (обработано, отброшено, в процессе обработки) • идентификатор «пачки» • хэшисходных значений полей • Если хэш импортируемых данных совпадает с имеющимися, и статус – «в обработке», запись игнорируется • Формируется сообщение – билет (источник, пачка, [конкретная запись]), передается роутеру
Контроль импорта – зачем роутер? • Для возможности коррекций при помощи преобразований данных • Для более простой настройки • Изменения без остановки продукции • Итог работы – передача сообщения специфичному для сущности/источника бизнес-процессу
Контроль импорта • Специфичный бизнес-процесс • открывает сырые данные • выполняет проверки при помощи своей внутренней логики, или «библиотечных вызовов» • при необходимости осуществляется выставление workflow-задач • Результат работы – исправленные данные в хранилище сырых данных • Если идет обработка не пачкой, а по записям – проверка на то, что пачку можно сохранять (при необходимости выставить task на одобрение)
Спасибо. Продолжение следует.http://writeimagejournal.com Борис Егоров