Математико-механический факультет Кафедра системного программирования Решение задач интеграции программных решений в финансовой индустрии

Скачать 398.15 Kb.

Название	Математико-механический факультет Кафедра системного программирования Решение задач интеграции программных решений в финансовой индустрии
страница	4/5
Дата публикации	10.01.2015
Размер	398.15 Kb.
Тип	Решение

100-bal.ru > Бухгалтерия > Решение

1 2 3 4 5

Сравнение EAI платформ на примере реализации импорта информации о сделках

В качестве Enterprise Application Integration (EAI) платформ для сравнения использовались:

Microsoft BizTalk Server 2009 – платформа от Microsoft, используется для интреграции приложений и автоматизации бизнес процессов.
IBM WebSphere Message Broker 7.0 – альтернативная платформа, широко используемая для промышленной интеграции.

Были разработаны 2 решения одной интеграционной задачи на каждой из платформ и написаны программы, представляющие собой исходную и целевую системы для интеграции. Тестовый веб-сервис генерирует файл со сделками для импорта, который обрабатывается EAI платформой. Сделки импортируются через веб-сервис бухгалтерской системы, результат загрузки также обрабатывается EAI и передается обратно в тестовый веб-сервис для сохранения результата. Общая схема реализованного мной решения такова:

integration test solution

Интерфейсы систем

В нашем примере интеграции интерфейсом исходной системы (системы управления портфелем) является XML схема, в которой система публикует информацию о сделках. Была разработана следующая схема (SourceTradeSchema.xsd):

Корневой элемент TradeRequest cодержит элемент Header (несущий информацию о самом файле со сделками) и коллекцию элементов TradeData, каждый из которых содержит свойства самой сделки и дочерний элемент со свойствами ценой бумаги. Все свойства сделки, ссылающиеся на справочники исходной системы (Fund, Broker, PrimeBroker, Strategy, TradeType), представлены кодом (атрибут Сode) и именем (атрибут Name). Для каждой сделки (элемент TradeData) передается поле TradeId, которое будет содержать строковое представление Guid, уникального идентификатора каждой сделки, который должен быть использован для ссылки на данную запись при сохранении результата ее импорта.

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

public void StoreTestResult(string testTradeId, string errorMessage, bool posted)

Параметр testTradeId должен содержать уникальный идентификатор сделки, отправленной системой в файле запроса.

Целевая система нашей интеграции, - бухгалтерская система,- предоставляет веб-сервис TradeImportService с одним методом ImportTrades:

public LoaderOutput ImportTrades(TradeLoader trades)

Схема TradeLoader:	Схема LoaderOutput:

Данный метод принимает массив записей Trade, проверяет для каждой условия целостности и корректности данных (наличие ценной бумаги, кода прайм брокера, стратегии и типа сделки, а, также, что общая стоимость сделки не превосходит установленный лимит) и для каждой записи возвращает запись TradeUploadStatus, куда копируется внешний идентификатор сделки и результат валидации.

Наше интеграционное решение в первую очередь должно осуществлять корректную трансформацию между схемой TradeRequest (системы управления портфелем) и TradeLoader (бухгалтерской системы). Логика трансформации должна учитывать допустимые значения в целевой системе, например, TradeType может быть только BY, SL, SH и BC, для того, чтобы сделка была обработана бухгалтерской системой.

Реализация на Microsoft BizTalk

Интеграционное решение на Microsoft BizTalk состоит из двух процедур обработки сообщений (в терминах BizTalk – orchestration):

TradesToAccountingSystem.odx – принимает файл со сделками, вызывает веб-сервис бухгалтерской системы и обрабатывает результат:

ReciveTrades – получает сообщение типа SourceTradeSchema.xsd из порта. Данный порт настраивается во время установки приложения на сервер BizTalk и привязывается к конкретному транспорту (адаптеру), в нашем случае мы используем File адаптер. Каждый раз, когда в указанной директории появляется xml файл, происходит проверка его схемы и, если схема соответствует той, на которую подписана процедура, то происходит ее вызов.
ConstructAccSysRequest – вызывается компонента маппинга для трансформации сообщения в формат параметров метода веб-сервиса бухгалтерской системы. BizTalk предоставляет визуальный инструмент создания трансформаций сообщений (XML или плоских файлов):

Следующие два шага – SendAccSystemMessage и RecieveImportStatus – вызов веб-сервиса бухгалтерской системы и получения сообщения, содержащего LoaderOutput класс, возвращенного методом ImportTrades. Как и с получением сообщения о сделках, порты, используемые для вызова веб-сервиса, настраиваются при установке на BizTalk сервер – выбирается адаптер SOAP и вводится адрес веб-сервиса.
ConstructImportStatus – отображение сообщения LoaderOuput во внутреннею XML схему, которую мы будем использовать для обработки результатов загрузки. Здесь так же использует инструмент маппига BizTalk.
LogToFile – приложение может сохранить полученные результаты загрузки сделок в файл (в процедуре настраивается только логический порт, куда и как будет передано сообщение, на самом деле, настраивается во время установки).
RouteImportStatus – вызов второй процедуры обработки сообщений, цель которой переслать результат загрузки в исходную систему.

ImportStatusRouter.odx – реализация шаблона проектирования Message Router [EIP]. Принимает сообщение с результатами загрузки, разбивает на массив результатов по каждой записи и в зависимости от типа записи, перенаправляет сообщение в исходную систему:

SetCounter, InterateOverStatuses, IncrementExp составляют цикл по всем записям содержащимся во входном сообщении.
ExtractImportStatus – используя выражение XPath, извлекается одна запись EntityImportStatus из набора таких записей в обрабатываемом сообщении:

ImportStatus = xpath(ImportStatuses, "/*[local-name()='ImportStatus']/*[local-name()='EntityImportStatus']["+position+"]");

EntityTypeSwitch – в зависимости от типа записи управление перенаправляется на соответствующую ветку:

System.Convert.ToString(xpath(ImportStatus, "string(/*[local-name()='EntityImportStatus']/*[local-name()='EntityType'])")) == "Trade"

Для сделок вычисляем параметры метода StoreTestResult из полей записи EntityImportStatus, используя xpath выражения (шаг PopulateTestEnpointMsg), затем вызывается этот метод на веб-сервисе исходной системы.

Реализация на IBM Message Broker

Подобное решение было разработано и на IBM WebShere Message Broker, были написаны две процедуры обработки сообщений (в терминах Message Broker – message flow).

TradesToAccountingSystem.msgflow – запускается при появлении xml файла со сделками в определенной директории, производит отображение данных в формат веб-сервиса бухгалтерской системы, вызывает метод загрузки сделок на этом веб-сервисе и передает статусы загрузки в очередь MQ:

FileInput – используется узел (node) FileInput, для запуска всей процедуры при появлении файла и разбора этого файла в соответствии с выбранной XML схемой.
ProduceTradeRequest – узел Mapping. IBM Message Broker, как и BizTalk, обладает визуальным инструментом построения трансформаций между сообщениями, который используется для того, чтобы из файла со сделками получить данные для передачи веб-сервис бухгалтерской системы.
InvokeAccSysWebService – узел Subflow. Среда разработки Message Broker генерирует процедуру вызова веб-сервиса по файлу WSDL, эта процедура берет на себя составление сообщения SOAP, вызов метода веб-сервиса по HTTP и обработку ответа. В данном случае, эта процедура сгенерирована для веб-сервиса бухгалтерской системы.
RemoveResponseHeader – узел HTTPHeader - используется, чтобы удалить из сообщения, полученного на предыдущем узле, заголовок HTTP. Нам нужно это сделать, чтобы обеспечить корректную обработку статусов загрузки, это некая специфика работы Message Broker c сообщениями – несмотря на то, что удаляемый нами заголовок не является частью XML и никак не используется в последующей трансформации, он автоматически переносится в результат трансформации.
LogImportDone – узел Trace используется здесь, чтобы записать полученные статусы загрузки в текстовый файл

MapImportStatus – узел Mapping. Используем трансформацию, которая из сообщения с массивом из N записей TradeUploadStatus, сделает N сообщений формата EntityImportStatus, каждое из которых обрабатывается процедурой разбора статусов загрузки. В отличие от BizTalk инструмент маппинга Message Broker имеет возможность создать несколько сообщений из одного исходного, для этого используется оператор for:

MQOutput – узел MQOutput отсылает каждое сообщение, полученное в предыдущей трансформации, в очередь сообщений “IMPORTSTATUSES”, развернутую на диспетчере очередей IBM WebSphere MQ. IBM WebSphere MQ (MQSeries) – система обмена сообщениями с гарантированной доставкой (message oriented middleware), является необходимым компонентом ПО для установки и работы IBM Message Broker. В данном случае использование очереди MQ обуславливается двумя причинами. Во-первых, последний узел нашей процедуры возвращает набор сообщений, а несколько сообщений нельзя передать в узел Subflow, можно лишь отправить на терминал выхода (такие узлы как MQOutput, FieOutput). Во-вторых, очередь MQ работает существенно быстрее, чем запись того же сообщения в файл и затем чтение этого файла узлом FileInput.

RouteImportStatus.msgflow – реализация Message Router в нашем интеграционном решении:

MQ-ImportStatus – узел MQInput. Получаются все сообщения из MQ очереди “IMPORTSTATUSES”. Предполагается что все сообщения из очереди буду в XML cхеме EntityImportStatus.
EntityTypeRouter – узел Route. Данный узел может иметь несколько терминалов выхода и на основании результата выражения xpath перенаправляет сообщение на соответствующий терминал. В нашем случае мы используем следующее условие для терминала Trade (результаты исполнения сделок). Если ни одно условие не верно для сообщения, то оно отправляется на терминал Default, за которым в нашей процедуре идет сохранение этого сообщения в файл (OtherStatusesLog – узел FileOutput).

$Body/Ent:EntityImportStatus/EntityType = 'Trade'

MapTradeStatus – узел Mapping, который вызывает трансформацию сообщения EntityImportStatus в параметры метода StoreTestResult веб-сервиса.
StoreTestResult_TestStartService – узел Subflow, который содержит процедуру вызова метода веб-сервиса, сгенерированную по WSDL веб-сериса.
LogError – узел Trace. В случае, если произошла ошибка вызова веб-сервиса, записываем сообщение об ошибке в файл, для чего к этому узлу привязаны терминалы Fault и Failure предыдущего узла.

Развитие интеграционного решения

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

Добавление еще одной системы, отправляющей данные по сделкам. Для того, чтобы поддержать еще одну исходную систему, нужно добавить процедуру обработки сообщений (в случае BizTalk – orchestration, IBM Message Broker – message flow) аналогичную уже существующей. Если вторая система публикует данные в XML файл того же формата, что и первая, то это не будет необходимым. Также, можно сделать процедуру, которая приводит формат данных второй системы к уже поддерживаемому, и потом просто вызвать процедуру загрузки сделок. В процедуру обработки статусов загрузки нужно добавить отсылку статусов во вторую систему. Таким образом, наш диспетчер статусов (message router) при обработке статуса загрузки сделки (ветка Trade в обеих реализациях) отправит статус два раза - в первую и вторую систему. Требованием к системам будет корректно обрабатывать статусы на те идентификаторы сделок, что не были отправлены данной системой. Если это условие не исполняется, то нужно добавлять дополнительное поле в схему EntityImportStatus (например, SourceSystem), которое будет обозначать исходную систему, заполнять этот параметр в процедуре загрузки сделок (для каждой из исходной систем) и создавать еще один диспетчер, который отправляет статус загрузки в правильную исходную систему в зависимости от значение этого поля.

Добавление еще одной сущности, которую нужно загружать в бухгалтерскую систему. Например, помимо сделок, нужно также иметь интеграцию между системой получения информации о ценных бумагах и бухгалтерской системой. Во-первых, бухгалтерская система должна иметь интерфейс загрузки данных о ценных бумагах. Во-вторых, в интеграционном решении должна быть добавлена процедура, принимающая от исходной системы данные о ценных бумагах, вызывающая интерфейс бухгалтерской системы для их сохранения и возвращающая результат сохранения по уже определенной схеме EntityImportStatus, но с полем EntityStatus заданным как “Security”. Процедура обработки статусов потребует при этом минимальных изменений. Диспетчеру статусов нужно будет добавить еще одно условие для “Security”, за которым следует отправка статуса загрузки в исходную систему.

Тестирование производительности

Для проверки правильности работы и быстродействия созданного интеграционного решения был написан инструмент для тестирования. Запускаемые тесты имеют следующую структуру:

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

Тестовая база данных имеет следующие таблицы:

Тестовые сделки генерируются в базе данных на основе набора данных по акциям, входящим в состав индекса S&P Global BMI, списка возможных значений портфеля, брокера, прайм брокера, стратегии и типа сделки. Хранимая процедура принимает на вход количество записей, которое нужно сгенерировать, делает выборку этого количества случайных записей из таблицы SecData (данные по акциям) и затем подставляет случайные значения для остальных свойств сделки. Результаты сохраняются в таблицу GeneratedTrade. Запуск теста осуществляется веб-сервисом TestStartService, который имеет два метода:

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

public void StartTest(string testName, string targetSystemName)

Метод, сохраняющий статус загрузки сделки. Ищет строку с отправленной сделкой по параметру testTradeId, сохраняет результат загрузки в таблицу TestResult вместе со временем получения статуса.

public void StoreTestResult(string testTradeId, string errorMessage, bool posted)

Этот веб-сервис был написан на Microsoft .NET 3.5, для работы с базой данных использовалась технология Linq to SQL.

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

Используя созданный тестовый инструмент было проведено тестирование производительности интеграционных решений, созданных на Microsoft BizTalk и IBM WebShere Message Broker на основании шести тестов:

Тест	Описание	Время выполнения теста, сек
Тест	Описание	Microsoft BizTalk	IBM Message Broker
Простой импорт	Отправляется два файла, первый с 20-ю сделками, 5-ти секундной задержкой и затем второй файл с 10-ю сделками	17	7
Импорт 1000 сделок	Импортируется один файл с одной тысячей сделок	691	33
Импорт большого объема сделок	Импортируется один файл с пятью тысячами сделок	-	245
Постоянная нагрузка	Импортируется 20 файлов по 100 сделок в каждом, между каждым импортом 5-ти секундная задержка	188	105
Увеличивающаяся нагрузка	Импортируется 5 файлов, каждый файл содержит в два раза больше сделок, чем предыдущий (начиная с 50-ти), пауза между запуском импорта уменьшается с 5-ти секунд на 1 секунду на каждом шаге	320	47
Холодный старт	Импортируется один файл с 100 сделками, после полного перезапуска системы	93	31

Тестирование проводилось на компьютере с операционной системой Microsoft Windows XP Service Pack 3, процессор Intel Core2 2.13 Ггц, операционная память 2.0 Гб. Все компоненты интеграционного решения, тестового веб-сервиса и веб-сервиса бухгалтерской системы были развернуты на одном компьютере:

Для BizTalk: IIS Server, SQL Server 2005, Microsoft BizTalk, Microsoft Enterprise Single Sign-On.
Для IBM Message Broker: IIS Server, SQL Server 2005, IBM MQSeries, IBM Message Broker.

Как видно из результатов выполнения тестов, решение на Microsoft BizTalk, существенно медленнее обрабатывает сообщения большого объема. Дополнительный анализ показал, что причина низкой производительности кроется в выбранном способе разбиения сообщения с набором записей EntityImportStatus на отдельные сообщения (в процедуре ImportStatusRouter.odx). Дело, вероятно, в скорости работы цикла (узел Loop) и в том, что на каждом шаге этого цикла, создается новое сообщение, которое сначала сохраняется BizTalk в свою базу данных, и лишь за тем обрабатывается. Для оптимизации можно предложить другой способ разбиения сообщений (через компонент BizTalk для парсинга сообщений - pipeline), либо написать собственный адаптер для веб-сервиса, который будет разбивать сообщения более быстро, либо потребовать от исходной системы метод, позволяющий сохранять статусы для целого набора сделок, а не по одной. Последний вариант убирает необходимость разбивать сообщения в принципе. Тем не менее, верно то, что BizTalk не подходит для обработки больших объемов данных.

С точки зрения легкости освоения и простоты разработки, две рассматриваемые системы весьма схожи, и нельзя отдать предпочтение какой-либо из систем. На разработку и отладку решения на BizTalk, мне потребовалось порядка 14ти часов работы, на IBM Message Broker – 18 часов. При этом я уже имел опыт разработки на BizTalk, помимо этой работы, а платформу IBM я осваивал с нуля. В пользу BizTalk говорит то, что выражения для обработки сообщений (за рамками средства визуального построения трансформаций) можно писать на C# и XPath, тогда как в IBM Message Broker для тех же задач используется собственный внутренний язык EQSL, который нужно изучать дополнительно. Преимуществом IBM Message Broker, безусловно, является скорость работы, кроме этого эта система поддерживает большинство операционных систем (Windows, Linux, IBM z/OS, Solaris), BizTalk же работает только на Windows.

Стоимость лицензии выше у IBM Message Broker и составляет 97300$ для Enterprise Edition, 25000$ для Starter Edition (до 10ти message flow) [Сравнение EAI]. Кроме этого для работы системы потребуется IBM WebSphere MQ. Лицензия Microsoft BizTalk обойдется в 35000$ за Enterprise edition и 8500$ за Standard edition (ограничение на работу только пяти приложений на BizTalk сервере) [BizTalk Pricing & Licensing]. Кроме этого, потребуются лицензии Microsoft SQL Server Standard Edition для баз данных BizTalk и Microsoft Visual Studio для разработки приложений.

В случае, когда интегрируемые системы созданы на разных программных платформах и велики требования к производительности интеграции и объемам передаваемых данных, по моему мнению, следует использовать IBM WebSphere Message Broker. Microsoft BizTalk хорошо подходит для интеграции систем на технологиях Microsoft, особенно в тех случаях, когда автоматизируются длительные и сложные бизнес-процесы.