Собственно, это полная версия моей первой статьи из цикла по BizTalk Server. Публикую здесь в связи с тем, что в нескольких издениях вышел только значительно сокращенный (примерно 1/3) вариант. Продолжение следует.
При решении современных бизнес-задач с применением тех или иных ИТ технологий компании, и, особенно – крупные, сталкиваются с такой проблемой, как необходимость «бесшовной, прозрачной» поддержки бизнес-процессов основным приложением компании. На рынке существуют такие решения, чья функциональность действительно позволяет учесть все аспекты работы компании и предоставить единое интегрированное рабочее место сотрудникам для выполнения их повседневных задач. Но, как правило, такие решения могут позволить себе только очень крупные компании, поскольку сроки внедрения подобных решений измеряются 3-5 годами, и, соответственно, сами приложения и консалтинговые услуги по внедрению (анализ бизнесс-процессов и их моделирование, развертывание и конфигурирование непосредственно ПО, обучение специалистов и пользователей) стоят десятки, а порой – и сотни, миллионов долларов. И даже после успешного внедрение подобного решения у компаний остается еще масса мелких нерешенных по реализации незначимых бизнес-процессов, иногда стоимость автоматизации которых на подобных системах в порядки превышает экономический эффект от такой автоматизации. Кроме того, возникают в процессе и после внедрения возникают вопросы по интеграции различных приложений на уровне данных, порой – трудно сопоставимых.
Решить подобные вопросы для компаний, которые испытывают необходимость в переходе от использования ИТ как средства повышения персональной производительности каждого сотрудника к средству автоматизации и повышения эффективности бизнес-процессов и призван Microsoft BizTalk Server 2006. Это серверное решение представляет собой систему middleware и привносящую в работу компании, которая его внедряет, парадигму «информационной шины предприятия». Эта парадигма говорит о том, что информация, не зависимо от ее конечного представления (визуализации), должна свободно передаваться по предприятию в неком «аморфном» состоянии (реалии современных ИТ технологий таковы, что «аморфное» состояние на практике реализуется с использование XML) согласно указаниям предопределенной для нее бизнес-логике. При этом конечный пользователь – сотрудник компании с его рабочим местом и некими бизнес-приложениями – получает эту информацию автоматически в том формате, который требуется именно его АРМами для ее визуализации и изменения. Такой подход позволяет объединить в едином бизнес-процессе казалось бы несопоставимые приложения, обеспечить их взаимодействие без какой либо модификации или кодирования, а, возможно, и вообще исключить создание специальных приложений, используя в качестве клиентских мест штатные офисные продукты, такие, как Microsoft Office. Пользователи получат удобное средство работы с корпоративными данными и будут подключены в общую цепочку обработки этих данных, при этом оставаясь в рамках привычного знакомого интерфейса, например, Microsoft Excel или Word. Существует масса примеров реализации решений по автоматизации бизнес-процессов компании с применение только Microsoft BizTalk Server 2006 и Microsoft Office. Например, процесс оформления командировки сотрудником, где сотрудник заполняет на соответствующем разделе веб-портала компании под управление SharePoint форму, используя Microsoft InfoPath. В такой интерактивной форме он указывает различные атрибуты будущей поедки, такие, как направление, цель, даты, тип транспорта, аванс и т.п. и сохраняет форму в хранилище SharePoint. Данное хранилище мониторится BizTalk, который по событию извлекает форму из хранилища, проводит разбор данных и, определив, что имеет дело с данными о командировках, подгружает копию модуля описания бизнес-логики процесса согласования командировки сотрудников. Далее процесс может быть описан в виде примерной блок-схемы:
· определить при помощи службы каталогов, кто является руководителем сотрудника, получить его электронный адрес
· сформировать на основе данных о командировке специальное электронное сообщение руководителю и поместить его в хранилище почтовой системы Microsoft Exchange Server
· приостановить бизнес-процесс, ожидая ответа от пользователя определенного типа (здесь – электронного сообщения специального типа)
· руководитель получает сообщение в Microsoft Outlook с информацией о командировке в виде формы с кнопками «принять»/«отклонить» и принимает решение. Outlook генерирует сообщение согласно описанному формату ответного сообщения формы
· ответ поступает на адрес BizTalk, который сопоставляет его с ожидающим процессом, породившим начальное письмо, и, в зависимости от решения руководителя, либо останавливает процесс обработки при отказе, отправив сотруднику соответствующее уведомление, либо продолжает обработку бизнес-процесса – здесь процесс делится на несколько параллельно исполняемых процессов дальнейшей обработки:
o создать в календаре сотрудника запись, соответствующую датам его командировки с соответствующими атрибутами
o сформировать электронный документ в требуемом формате (например, WordML Microsoft Word) и поместить его в библиотеку входящих документов, используемую офис-менеджерами, SharePoint портала в представлении командировочного удостоверения. Соответсвующему сотруднику (секретарю или помощнику руководителя – данные получаются из службы каталогов) отправить уведомление. На основе этого документа создать соответствующий приказ.Сам документ будет распечатан секретарем непосредственно из оснастки портала, и в результате будет перенесен в библиотеку обработанных документов. Бумажная копия командировочного удостоверения с соответпечатями и подписями будет доставлена сотруднику
o сформировать запись в платежной системе предприятия для выплаты «суточных» сотруднику, отправить уведомление об этом в бухгалтерию и ожидать подтверждения через соответствующую веб-страницу портала. Бухгалтер подтверждает оплату через портал, скрепляя для достоверности операцию своей цифровой подписью, BizTalk «фиксирует» оплату в платежной системе и отправляет соответствующее уведомление сотруднику.
Таким образом различные бизнес-приложения функционируют как единая система под управление Microsoft BizTalk Server, позволяя эффективно автоматизировать любые бизнес-процессы в организации, как, например: внутренние административные процедуры, обмен данными и интеграция на уровне единого интерфейса различных бизнес-приложений, взаимодействие с внешними приложениями и системами, так – включение партнерских бизнес-систем как части собственной системы (здесь, примером может служить ситуация, когда компания имеет большое количество поставщиков материалов, сырья и комплектующих и при формировании планов производства продукции есть необходимость автоматизировать и контролировать процесс заказа и поставки всех необходимых компонент партнерами-поставщиками). С технологической стороны, применение Microsoft BizTalk Server становится эффективным для решения следующих ИТ задач и проблем:
· Несопоставимые приложения, как по фотматам, так и бизнес-логике обработки данных
· Высокая нагрузка на разработчиков при разработке модулей взаимодействия приложений, часто изменяющиеся бизнес-требования к системам, приводящим к необходимости модификации их кода
· Нестандартная отчетность и ограниченность мониторинга работы распределенных приложений, когда требуется анализ передаваемых сообщений между частями, статистики частоты использования тех или иных функций и данных
· Недостаточная функциональность наследованных приложений с невозможностью их модификации, когда приложению требуется обеспечить либо дополнительную логику работы, либо новый пользовательский интерфейс
Для реализации тех или иных возможностей в Microsoft BizTalk Server реализованно несколько подсистем, взаимодействующих между собой, а также разработана экосистема приложений и сервисов, обеспечивающий полный цикл разработки, развертывания, эксплуатации приложений для платформы BizTalk.
Ядром сервисов BizTalk Server является служба Orchestration and messaging engine, функции которой включают в себя реакцию на появление новых данных (сообщений, message) в тех или иных системах-источниках, их разбор и анализ, преобразование во внутренний XML формат, маршрутизация, загрузка и запуск экземпляра скомпилированного модуля описания бизнес-процесса (Orchestration), соответствующего данным, и дальнейшее сопровождение операций и преобразований данных, транзакций, параллельного выполнения, хранение промежуточных результатов, статистики, отправки в конечные системы-получатели и т.п.
Основной идеей работы службы Orchestration and messaging engine является принцип хранилища сообщений (MessageBox) и подписок (Subscription). Принимая сообщение из внешних источников, служба помещает его в хранилище, после чего анализируются подписки, т.е. присутствует ли в системе какой-то объект, который заинтересован в поступлении такого сообщения – собственно, подписка. Заинтересованность определяется различными условиями, свойственными как параметрам конкретного сообщения, так и состоянию системы вообще, например – если в определенном поле сообщения присутствует значение «CREDIT», то система вызовет модуль бизнес-логики, способый обработать это сообщение и вернуть его в хранилище для дальнейшей обработки или отправить по дальнейшему маршруту, или если сообщение поступило через источник, подключенный к общей папке на определенном сервере, то все такие сообщения будут автоматически упаковываться во вложения почтового сообщения и отправляться по SMTP.
Для взаимодействия с внешними системами, форматами их данными, протоколами передачи, шифрования и т.п. служба Orchestration and messaging engine использует принцип адаптеров, портов, труб.
Адаптеры являются программными модулями, исполняемыми либо на BizTalk Server, либо на системе-источнике/получателе данных. Их основными задачами является обнаружение событий по изменению состояния такой системы, а также представление информации системы, которая в самой системе может хранится в различных, иногда только логически связанных таблицах, файлах и т.п., в виде единого набора данных для обработки в BizTalk. Примером такого набора может служить, например, объект данных бизнес-задачи (Opportunity) системы класса CRM, элементы данных которого в самом приложении CRM хранятся во множестве различных таблиц и полей базы данных. Но, благодаря адаптеру, такой объект поступает на порт BizTalk в виде единого массива данных с регламентированным набором полей и их типов. Адаптер скрывает от разработчиков приложений на BizTalk физическое представление данных в конечной системе, позволяя оперировать «чистыми» данными и бизнес-логикой. Microsoft поставляет BizTalk Server c 22 адаптерами собственной разработки (как платными, так и бесплатными), среди которых Web Services, HTTP, SMTP, POP3, SQL, SharePoint, MSMQ и другие. Партнеры предлагают более 100 адаптеров к различным системам, таким, как SAP, Siebel, Temenos, Oracle и т.п.
Порт обеспечивает подключение бизнес-процесса непостредственно к конкретному экземпляру бизнес-системы для получения/отправки данных. Элемент порта обеспечивает повышенную гибкость, поскольку имеются возможности описать тип порта (направленность), тип адаптера, который будет использоваться для подключения к бизнес-системе через данный порт, и, для непосредственного подключения к конкретному экземпляру бизнес-системы, указать, например, адрес XML Web Service и параметры сессии требуемого сервиса получения/отправки данных. Наличие порта, как абстракции, поволяет распределить процесс разработки таким образом, что разработчик схемы бизнес-логики может только определить порт, как точку подключения, в процессе разработки и использовать его с временными параметрами тестовой системы, допустим, файловым хранилищем и соответствующим адаптером подключения к общим файловым папкам, где данные системы-источника представлены в виде файлов XML, а администратор бизнес-систем BizTalk Server при развертывании конечного решения в виде скомпилированного модуля описания бизнес-процесса с помощью административной консоли управления определяет параметры подключения порта к реально присутствующей в сети системе, например, непосредственно к базе данных бизнес-приложения, вызывая при помощи SQL Server-адаптера представление, возвращаемые данные которого по структуре соответствуют исходным требованиям модуля.
Кроме того, среди параметров порта присутствуют описания трансформации и фильтров, что позволяет, во-первых, не усложняя решение описанием бизнес-процессов преобразовать входящие/исходящие данные в нужные формат, а во-вторых – при помощи фильтра определить ту самую подписку и маршрутизацию – если определен фильтр по какому-либо из условий (будь-то значение любого поля или результата после преобразований, тип или имя принявшего порта, имя файла, под которым сообщение поступило во входящий порт) – служба маршрутизации автоматически отправит сообщение по тому порту, чьи условия фильтра будут соответствовать поступившего значениям экземпляра сообщения.
Такая архитектура портов и маршрутизации позволяет быстро создавать схемы маршрутизации данных без какого либо программирования – просто определяя структуру данных, порты и фильтры, а также переключатся между источниками/приемниками данных одного типа, использовать несколько источников данных одновременно без какого либо участия разработчиков в этом процессе.
«Труба» pipeline – способ преобразования «сырых» данных в XML-сообщения, которыми, собственно, и оперирует внутри модулей бизнес-процессов служба Orchestration and messaging. В трубе пришедшие из порта данные проходят расшифровку, проверку целостности и цифровой подписи разборку частей и сопоставление переменных с соответствующими элементами XML-схемы, описанной разработчиком, для дальнейшей передачи на обработку в модуль бизнес-логики. Трубы создаются в визуальном редакторе, который позволяет добавлять те или иные операции по пути движения данных. Набор функций и операций не является фиксированным, средства разработки и исполдения модулей бизнес-логики позволяют разработчикам добавлять в трубы вызовы своих внешних функций, например, из уже существующих DLL-библиотеки вызвать функцию собственного алгоритма шифрования данных.
Собственно, здесь, на выходе трубы сопоставив и разобрав поступившие на порт данные в XML-сообщение, служба Orchestration принимает решение о «простой» маршрутизации (описанной выше) сообщения или о запуске экземпляра соответствующего модуля описания бизнес-логики. Будучи скомпилированным в сборку .NET Framework, такой модуль исполняется в режиме управляемого кода, что обеспечивает его устойчивость, защищенность от ошибок и высокую, по сравнению с конкурентными решениями, производительность. Для обеспечения высокой надежности и сохранности данных, все промежуточные данные, вырабатываемые в процессе выполнения соответствующего бизнес-процесса, помещаются в хранилище на базе Microsoft SQL Server, обеспечивая тем самым транзакционную модель и позволяя быстро возвращаться в прерванных операциях к их состоянию или выполнять «откат» операции при каких-то условиях. Кроме того, сами запущенные экземпляры того или иного модуля бизнес-процессов в случае бездействия могут быть выгружены из памяти, а их состояние и состояние окружения будет также сохранено в хранилище в ожидании дальнейших вызовов и восстановления состояния – это делается для повышения быстродействия и рационального использования аппаратных ресурсов.
Модули описания бизнес-процессов разрабатываются на основе блок схем бизнес-процесса, которые подготавливаются бизнес-аналитиками с применением Microsoft Visio. Далее, средствами Microsoft Visual Studio 2005, которая позволяет импортировать данные описания, разработчики подготавливают законченное технологическое описание бизнес-процесса, описывая при помощи визуальных инструментов разработки, фактически представляющих собой блок-схемы, типы и источники данных (те самые порты), последовательность команд бизнес-процесса, связанных с преобразованием данных, запросом дополнительных данных из других внешних систем, условиями принятия решений, ожидание ввода пользователя, помещение результата или результатов работы бизнес-процесса в какую-то из систем. Средство построения бизнес-процессов имеет массу различных модулей, позволяющих быстро и гибко описывать все перечисленные выше процессы, и, как и в случае с трубами, разработчик может расширять функциональность элементов бизнес-логики, начиная с небольших фрагментов скриптов, расширяющих функциональность текущих блоков и заканчивая созданием и регистрацией на базе технологий .NET Framework собственных блоков бизнес-процессов.
Дополнительные средства разработки, такие, как, например Business Rule Engine, позволяют разработчику не сосредотачиваться на проработке тех или иных условий в блок-схеме описываемого бизнес-процесса. Достаточно описать словарь наименования условий внутри бизнес-процесса, и в отдельном инструменте, обеспечивающем построение собственно условий, описать запрос, соответствующий тому или иному условию. Данный инструмент – Business Rule Composer – позволяет эффективно строить сложные условия, в том числе с участивем внешних данных, причем описание условий отделено от использующей их блок-схемы. Таким образом имеется возможность менять условия, использующиеся в бизнес-процессе что называется «на лету», тем самым гибко реагировать на изменившиеся условия принятия решения в том или ином бизнес-процессе.
Проект Visual Studio, в котором присутствуют описаный в виде блок-схемы процесс с точками подключения к бизнес-системам в виде портов, определение типов данных в виде XML-сообщений, необходимые схемы преобразования из одного типа к другому, трубы, переменные и т.п., компилируется в подписанную сборку .NET Framework и публикуется на сервере BizTalk, где регистрируется в каталоге приложений, конфигурирование и настройка которых под задачи лежит уже на плечах администратора серверов BizTalk. Администратор, не вдаваясь в особенности програмирования, сам определяет параметры работы портов и адаптеров, подключая сборку к рабочим бизнес-системам, определяет защищенный рабочий пул будущего приложения и, собственно, запускает приложение в работу.
Вроде все – бизнес-процесс описан, скомпилирован, подключен к разрозненным системам и, обнаружив изменения в данных одной бизнес-системы, передает их, трансформируя, другим бизнес-системам для дальнейшей разработки – мы обеспечили бизнес необходимым процессом, связали несвязанные изначально приложения. Чего желать еще? На самом деле – многого. Бизнес привык задавать вопросы – а где сейчас, на какой стадии обработки, находятся мои данные, как часто в организации выполняются процессы того или иного вида, каково их количество и длительность, на каком этапе бизнес-процесса затрачивается наибольшее количество времени?
На все эти вопросы призвана ответить служба Business Activity Monitoring, в задачи которой входит сбор, анализ и визуализация данных о каждом выполенном или выполняющемся экземпляре того или иного бизнес-процесса на основании его информации в хранилище. Таким образом BizTalk Server освобождает разработчиков от необходимости написания специального кода, предоставляя возможность конечному пользователю самому решать, какие отчеты, в каком формате и с какими ключивыми показателями производительности он хочет видить. Кроме того, при внедрении автоматизированного бизнес-процесса, в котором BizTalk связывает разрозненные приложения в единый информационный поток, бизнес получает инструментарий, которого не было, да и не может быть, в уже существующих отдельных приложениях-учасниках бизнес-процесса – это анализ выполнения сотрудниками производственной дисциплины, эффективность работы каждого звена, и, как следствие, цифровые показатели работы подразделений над бизнес-задачами.
Благодаря перечисленным выше возможностям и тесной интеграцией со средствами разработки, Microsoft BizTalk Server 2006 по праву считается одним из наиболее конкурентоспособных продуктов в сегменте интеграции и автоматизации бизнес-процессов. Внедрение таких средств позволяет организации кардинально изменить ланшафт своих бизнес-процессов, сделать их более производительными и эффективными, предсказуемыми и гибкими, прозрачными и приложение-независимыми.