Файл: Концепция сервисноориентированной архитектуры.rtf

3.2.2 Описание фрагмента интеграционной схемы

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

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

В глоссарии в Приложении 1 описаны понятия, относящиеся к данной предметной области. В Таблице 3.1 описана суть методов веб-сервиса, вызываемого в данном процессе.
Таблица 3.1. Методы веб-сервиса

Метод веб-сервиса	Описание сути метода
GetAgreementData	Возвращает набор данных о договоре из учетной системы (1С)
GetSaleAgreementList	Возвращает список договоров, связанных с согласуемым
CheckAgreement	Возвращает успех при наличии договора в системе ФК и неудачу при его отсутствии
GetAgreementHierarchy	Возвращает иерархию договоров из учетной системы (1С)
CheckConfirmDocumentDrafts	Проверяет наличие черновика плановых данных договора в системе ФК.

---

Описание шага «Формирование» с вызовами веб-сервисов: сотрудник создал в учетной системе 1С карточку договора и заполнил ее реквизиты (наименование, клиента и т.д.) и нажал на кнопку Согласование договора в карточке. Данное событие служит началом процесса Согласование договора, происходит переход в систему К2, открывается форма согласования К2. Система К2 вызывает метод GetAgreementData учетной системы 1С для получения заполненных реквизитов и вывода нужных из них на форму К2. По полученным сведениям К2 определяет, является ли это договором продажи или нет. Далее есть 2 сценария развития:

) Если договор НЕ является договором продажи (т.е. это договор с поставщиком), но при этом имеет связные с ним договоры продажи, вызывается метод веб-сервиса GetSaleAgreementList для проверки связных договоров. Поскольку только договоры продажи имеют плановые данные и, следовательно, только они могут иметь корректируемые договоры, вызов метода получения иерархии GetAgreementHierarchy не нужен. На этом загрузка формы завершается, пользователь видит окончательно загруженную форму. Открытие контрола ФК также недоступно, поскольку контрол является интерфейсом для заполнения плановых данных, а плановых данных у договоров с поставщиками не предусмотрено.

Далее есть 2 опции: отменить процесс (в таком случае происходит выход) или нажать «Запустить». При нажатии «Запустить» происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если черновики есть, пользователю выводится сообщение о необходимости сохранить или удалить черновик, и переход на следующий шаг не осуществляется. Если метод вернул успех, процесс переходит на Проверку администратором. В случае с договорами не продажи данный метод всегда возвращает успех в виду отсутствия плановых данных.

) Если договор является договором продажи, вызывается метод веб-сервиса CheckAgreement, который проверяет наличие этого договора в системе ФК и, если договор есть, метод возвращает успех, иначе инициируется отправка датаграммы для вставки договора в ФК, которая собирается из данных, полученных от 1С методом

---

GetAgreementData. После чего выполнение метода CheckAgreement возвращает успех. На форму К2 выводятся данные по договору, открытие формы на этом завершается, и пользователь видит полностью загруженную форму.

Если при этом договор является корректируемым, то происходит вызов веб-сервиса для получения из учетной системы иерархии договоров GetAgreementHierarchy. При нажатии с формы кнопки «Открыть контрол для заполнения ПД», К2 вызывает открытие формы ФК, и открывается интерфейс для заполнения ПД. Дальнейшие действия по заполнению плановых данных происходят уже в системе ФК. При сохранении версии плановых данных в контроле и нажатии кнопки «Вернуться к процессу К2» происходит переход обратно на форму К2, откуда можно также отменить процесс или запустить. При нажатии Запустить происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если метод возвращает успех, процесс переходит на шаг Проверка администратором. При возвращении неудачи выводится информационное сообщение о необходимости сохранить или удалить черновик плановых данных. При возвращении методом успеха процесс переходит на шаг Проверка администратором.

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

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

---

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

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

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

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

---

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

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

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

---