Дипломная (вкр): Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений

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

Интеграцию систем в процессе Согласования договора на шаге Формирования с участием большего числа систем (вспомогательных, для добавления в процесс актуальных данных) можно рассмотреть на следующем примере:

Компания собирается заключить договор с клиентом-организацией N на продажу лицензий ПО, т.е. планируется некий проект продажи и, возможно, предоставления сопутствующих услуг установки и обучения персонала. Первым делом назначается директор клиента, сотрудник Компании, ответственный за работу с этим клиентом и за заключение с ним сделок. Далее Директор клиента заводит организацию-клиента в системе CRM, где указывает ее данные, статус, проходит процесс проверки организации на чистоту. После этого назначаются менеджер договора и администраторы. Администратор заводит сущность договора в 1С, при этом для договора генерируется уникальный идентификационный номер. В карточке заполняется часть атрибутов, которые можно завести только в учетной системе 1С. Далее в карточку нужно внести информацию об организации, по которым 1С не является мастер-системой. В справочнике организаций 1С хранятся только GUID организации и ее наименование из CRM. Хранить такой справочник в учетной системе необходимо для возможности выбора организации из выпадающего списка в карточке договора. Притом в карточке договора кроме наименования организации должны содержаться и другие данные организации: реквизиты, адреса. Полная информация по организации-клиенту хранится только в CRM. При заведении новой организации, либо при изменении существующей, в шину отправляется полная датаграмма, которая раздает датаграммы в заинтересованные смежные системы, предварительно «обрезав» их по заранее настроенным фильтрам, которые настроены индивидуально для разных систем.

Так, в систему 1С приходит идентификатор, наименование и признак архивности, другие смежные системы могут потреблять более обширные данные, например, еще и реквизиты.

Когда сотрудник выбирает в выпадающем списке в карточке договора наименование организации, из данных справочника организации берется идентификатор этой организации и вызывается метод получения данных соответствующего веб-сервиса с идентификатором организации. Метод возвращает нужные данные по организации из CRM, и необходимые поля по организации заполняются в карточке договора автоматически. То же самое происходит при заполнении сотрудника, данные о котором приходят из системы HRMS. Вызовы смежных систем, от которых в процессе Согласования договора требуется только подтянуть нужную информацию в процесс (описанный выше пример вызовов CRM и HRMS систем), не вынесены на интеграционную схему с целью не перегружать модель. Данные методы являются методами получения информации, при выполнении которых не происходит преобразования данных в смежных системах, и их вызов не зависит от сценария развития процесса, поэтому в интеграции систем они играют вспомогательную роль.

Итак, сервисно-ориентированная архитектура позволяет веб-сервисам подгружать необходимые данные из различных мастер-систем в процесс. Эффективность такого подхода заключается в возможности хранить данные не в справочнике одной системы, а распределить полные данные по предметным областям систем, а в справочниках смежных систем хранить только уникальные ключи. Это позволяет облегчить базы данных организации, потому что хранение всех данных в одной базе, к которой все подряд системы будут обращаться при необходимости, имеет множество недостатков. Прежде всего, тяжело поддерживать целостность и актуальность таких данных, поскольку достаточно затруднительно назначить ответственных за поддержание данных отдельных таблиц в общей базе. Также, при таком хранении данных повышается риск дублирования данных, что тоже «утяжеляет» базу. Еще один существенный недостаток - время обработки запросов. Допустим, в организации имеется одна база данных, которая состоит из множества связанных или несвязанных таблиц (таблицы в базе могут храниться кластерами по предметным областям). Запрос к таблице такой базы, особенно при множественных операциях JOIN будет выполняться гораздо дольше, чем запрос к какому-либо справочнику системы, получению из него идентификатора сущности и вызову веб-сервиса для получения данных из мастер-системы по этому ключу для вывода их на форму.

Для подтверждения этого был проведен эксперимент: в процессе Согласования было замерено открытие формы в системе К2 на шаге Формирование, в которую подтягиваются данные из смежных систем с помощью вызовов методов получения данных. Это время составило 3 секунды. Если бы в Компании была общая база данных для всех систем, то при заполнении карточки договора потребовалось бы объединение таблиц: Agreement (договор), SystemUser (пользователь системы), Organization (организация), Firm (фирма), Direction (направление), Process (процесс), Manufacturer (производитель), Activity (активность) и нескольких других, содержащих большое количество атрибутов и строк каждая, а также несколько промежуточных таблиц-маппингов, описывающих связи многие-ко-многим.

Тестовый SQL-запрос с 1 условием из 8 таблиц произвольной базы данных, где таблицы имеют следующее количество строк: 57414, 7848, 17253, 50971, 116269, 35939, 18224, 26510 строк (что по объему даже меньше, чем справочники систем) выполнялся 9 секунд. Таким образом, выполнение SQL-запроса к массивной базе происходит дольше, чем получение данных с помощью веб-сервисов из распределенных справочников. Поскольку данные преимущественно динамичные, в такой базе будет неизбежно происходить постоянно обновление данных, а также к ней будет поступать слишком много запросов за единицу времени, что также увеличит время выполнения запроса.

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

3.3 Анализ одной точки интеграции

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

Поскольку в процессе Согласования договора преимущественно участвуют ранее описанные системы 1С:ERP, К2 и Финансовый калькулятор, далее будет рассмотрена точка интеграции этих трех систем и перечислены веб-сервисы от каждой системы, опубликованные в реестре. Кроме того, будет представлен пример вызова одного из сервисов в формате XML, также представленного на интеграционной схеме. Описание систем, участвующих в интеграции представлено в Таблице 3.2.

Таблица 3.2. Точка интеграции по процессу Согласование договора

Далее будет рассмотрен один из веб-сервисов системы Финансовый калькулятор под названием Integration, и представлено описание одного из методов сервиса (CheckAgreement). Затем будет проанализирована датаграмма одного вызова этого сервиса и ответа смежной системы.

Веб-сервис Integration, поставляемый системой Финансовый калькулятор, предназначен для интеграции систем ФК и К2, ФК и 1С. Методы (операции веб-сервиса) включают:

CheckOutAgreementPlanData: метод для блокировки плановых данных договора в системе ФК, необходим для прекращения всем пользователям доступа к редактированию договора в момент работы с этим договором другого пользователя;

CheckInAgreementPlanData: метод для снятия блокировки с плановых данных договора при прекращении с ним пользовательской работы;

MarkAsOfficial: метод для пометки последней версии договора, как окончательной;

CreatePDAVersion: метод для перевода чернового варианта договора в официальный и включения этой версии в проект;

SetAgreementPlanDataProperties: метод для получения изменений по договору, произведенных в др. системах (напр., различные статусы утверждения);

GetPlanData: метод для получения плановых данных;

CheckAgreement: метод для проверки наличия договора в системе (напр., чтобы убедиться, что сущность просинхронизировалась успешно из учетной системы);

CheckConfirmDocumentDrafts: метод для проверки наличия черновиков в системе.

Рассмотрим подробнее метод CheckAgreement. Метод CheckAgreement вызывается при первоначальном создании карточки договора в 1С на шаге Формирование. При этом в случае отсутствия договора в ФК при вызове метода CheckAgreement система ФК запрашивает данные по договору из системы 1С посредством шины (с помощью метода GetAgreementData, метод из другого веб-сервиса, опубликованного системой 1С). На основании полученных данных в системе ФК создается договор, после чего передается ответная информация о наличии договора в К2 через шину (см. Приложение 4).

Согласно требованиям к производительности из ТЗ: время на обработку одного вызова при наличии договора в ФК - не более 1сек., при отсутствие договора в ФК - не более 2 секунд, не считая времени выполнения метода GetAgreementData.

Пример входящего на ФК вызова CheckAgreement в виде XML-датаграммы, в которой передается параметр-идентификатор договора приведен ниже. Записи взяты из журнала интеграционных логов системы ФК данные получены запросом к таблице интеграционных логов:

SELECT * FROM IntegrationLogEntry AS ile.[TimeStamp] < '2017-04-20 14:59:33.007' and ile.[TimeStamp] > '2017-04-20 14:50:33.007' AND(ile.[Content] AS NVARCHAR(MAX)) LIKE '%CheckAgreement%'BY ile.[TimeStamp] DESC

Время сделанного вызова 2017-04-20 14:52:31.667. Датаграмма входящего сообщения:

<soapenv:Envelope xmlns:soapenv="#"896682.files/image005.gif">

Рисунок 3.1. Результат запроса к таблице логов

Как видно на данном примере, обмен информации (а именно получение датаграммы с кодом договора, проверки таблицы в базе системы ФК на предмет наличия договора и его вставка) произошел за 0,033 секунды.

Итак, преимущества веб-сервисов в ИТ-архитектуре очевидны. Использование веб-сервисов и сервисной шины для обмена данных между системами делает возможным формирование журнала логов, в котором записываются все входящие и исходящие вызовы на стороне каждой из систем. Записи в таких журналах содержат текст XML-датаграмм, временной штамп (TimeStamp), наименование операции, наименование источника сообщение, направление вызова (in/out). Логирование вызовов позволяет быстро определить ошибку и понять, на стороне какой системы произошел сбой. Таким образом, сокращается время на диагностику и правку ошибок, снижаются трудозатраты системных инжененров, и обеспечивается бесперебойный информационный обмен между системами.

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

Заключение

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

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

Итак, в ходе данной работы были рассмотрены особенности SOA, позволяющие бизнесу эффективно использовать приложения для поддержки бизнес-процессов. Прежде всего, подтверждение заявленной гипотезы о том, что SOA является эффективным подходом к построению архитектуры в компании с потребностью в объемном функционале для удовлетворения бизнес-потребностей, было найдено в научных статьях и исследованиях. В рамках обзора научной литературы были рассмотрены как статьи теоретического характера, так и результаты практических исследований. С помощью качественных методов анализа и сравнительной характеристики были выделены значимые особенности архитектуры, проанализированы приведенные в публикациях примеры и, на основе изложенного в литературе, была подготовлена база для последующего практического исследования. Особенно важным аспектом в анализе литературы было определение глубины проработанности проблемы, которое показало, что проблема исследована больше на теоретическом уровне и мало опирается на реальные кейсы внедрения архитектуры. Такой результат позволяет сделать вывод, что даже при высоком интересе ИТ-специалистов к предмету и при его очевидной выгоде, в практической сфере применения SOA осталось много не изученного, и в области оптимизации процесса перехода на SOA может быть сделано множество открытий.

В теоретической и практической главах была достигнута цель доказать целесообразность использования SOA в компании, и для достижения цели были выполнены все поставленные задачи:

были изучены особенности сервисно-ориентированного подхода к организации ИТ-инфраструктуры в компании;

был проведен анализ научных статей на тематику сервисно-ориентированной архитектуры с целью подтвердить наличие и актуальность проблемы;