Автоматизация сквозных бизнес-процессов предприятий с использованием BPEL
С.Битюков, старший консультант Oracle СНГ
Источник:
12 Октябрь 2005 г
Как получается, что организация работает? Почему в результате действий большого количества людей, документооборота, накопления и преобразования данных в информационных системах в конечном итоге получается тот самый результат, который ожидается? Как помыслить о том, что происходит в организации, в достаточно абстрактных и простых терминах и не уходя при этом слишком далеко от реальности?
Бизнес-процесс – одна из концепций, которая предназначена именно для этого. Кстати, существуют и другие термины, обозначающие то же самое, но в некоторых особых видах человеческой деятельности. Например, в государственном и муниципальном управлении принято говорить о регламентах, в том числе электронных, однако мы будем далее говорить о бизнес-процессах как о понятии, наиболее часто используемом в литературе, в первую очередь англоязычной. Можно по-разному определять, что же это такое (и на таком произволе и образуются различные школы и методики), однако важно то, что бизнес-процесс представляет собой некоторое действие, состоящее из более мелких действий, связанных между собой некоторым образом, и зафиксированное некоторым формальным способом. Формализация очень важна, потому что как только она появляется, то вместе с ней приходит возможность применять весь аппарат работы с формальными системами – то есть средства анализа, моделирования, верификации и много чего ещё.
Вокруг этой идей возникла целая индустрия BPM – моделирования бизнес-процессов, Business Process Modeling. Много решений пришло на возникший таким образом рынок, и остались наиболее удачные. И так бы продолжалось и далее, но постепенно стало понятно, что моделирование - это, конечно, тоже важно, но между аналитиком, который рисует диаграммы (так как хорошо известно, что человеку удобнее работать с образами) и программистом, который на основе этих диаграмм осуществляет непосредственное программирование самих процессов, существует некоторая дистанция, преодоление которой неизбежно связано с ошибками – как вследствие простой невнимательности, так и обусловленной различием представлений программиста и аналитика о семантике используемой в диаграммах нотации и, соответственно, придаваемому диаграммам смыслу.
Отладка также непроста, но что самое неприятное, происходит постепенное – по мере разработки систем – рассогласование диаграмм и их реализаций.
Естественно, сразу же возник вопрос – а можно ли сделать так, чтобы диаграммы бизнес-процессов были сами же их реализациями? До определённой степени поставленную таким образом задачу решили Workflow-системы. Однако только до определённой степени, и вот почему.
Особенно на Западе, автоматизация предприятий велась давно. По мере совершенствования технологий оказывалось, что та или иная задача наконец-то может быть автоматизирована. Так автоматизировались всё более и более сложные части – и, наконец, количество начало переходить самым диалектическим образом в качество, и появилась возможность автоматизировать сквозные бизнес-процессы, то есть, фактически, автоматизировать целые функции предприятий. Но тут же выяснилась и главная трудность – системы-то разные, и многие из них весьма древние, унаследованные. А значит, именно интеграционная работа начинает выходить на первый план. Традиционные же Workflow-системы на интеграцию в большинстве своём не ориентированы.
В рамках архитектуры SOA любая система представляется как набор сервисов – однако такие сервисы не обязаны быть SOAP-ориентированными WEB-сервисами. Многие сервисы бывает просто нецелесообразно представлять в таком виде – например, когда происходит обмен большими объёмами данных, то передача их по протоколу SOAP будет подразумевать их представление в виде XML, то есть не только расходы процессорного времени на его обработку, но и, что много хуже, существенно большую нагрузку на каналы связи. Для таких сервисов реализуются специализированные адаптеры – например, адаптеры доступа к файлам, базам данных, ERP-системам, и многим другим информационным ресурсам. Впрочем, существуют стандарты разработки адаптеров “вообще” - например, JCA (Java Connector Architecture), и эти стандарты обычно поддерживаются BPEL-средствами.
Реализовать несколько сот связей между полутора дюжинами “островками автоматизации” - это не под силу знаменитому Average Joe, даже если он будет трудиться по ночам и выходным. Однако эту проблему решили в рамках архитектуры SOA (Service-Oriented Architecture), в рамках концепции единой информационной шины, что позволяет сократить число связей. Впрочем, эта проблема – не единственная, которая решается в рамках архитектуры SOA.
Итак, подведём некоторый промежуточный итог. Важными оказались: формализация бизнес-процессов, их наглядное представление, отождествление описания и реализации, возможность интеграции разнородных систем, единая информационная шина. Добавив сюда XML, веб-сервисы и ряд других стандартов, получаем новый стандарт BPEL.
Похожим образом рассуждали аналитики крупнейших компаний IT-индустрии, когда вели разработки и принимали различные стандарты описания бизнес-процессов. Некоторые стандарты были более удачными, некоторые – менее, однако именно по BPEL (более точно, BPEL4WS 1.1) индустрия достигла широкого консенсуса. BPEL “выстрелил” - появился совершенно новый рынок – рынок BPEL-ориентированных интеграционных средств.
BPEL – это не только могучее средство интеграции, но также и алгоритмически полный язык, система типов которого – это система типов XML; язык с весьма выразительными управляющими конструкциями, поддержкой параллельного исполнения, детальной обработкой исключений, поддержкой транзакций, взаимодействия процессов между собой и много чем ещё. Однако при всём при том BPEL довольно сильно ограничивает аналитика в некоторых вещах. Грубо говоря, BPEL не позволяет осуществить произвольную передачу управления внутри бизнес-процесса – нарисовать “стрелку-переход” между любыми двумя “квадратиками”, изображающими простые действия. В этом ограничении есть определённый смысл.
Ещё на заре развития программирования стало понятно, что идея произвольного перехода в программе является порочной.
Дейкстра выдвинул тезис о необходимости так называемого “структурного программирования”, то есть, фактически, отказа от использования оператора произвольного перехода GOTO в пользу циклов. Эта идея оказалась плодотворной, и с тех пор все основные языки программирования высокого уровня её реализуют. Настолько радикальным зачастую бывает представление о вреде GOTO, что язык попросту не содержит такой конструкции.
Интересной особенностью BPEL является механизм корреляций. Для того, чтобы понять, зачем он нужен, необходимо в первую очередь обратить внимание на то, что есть разница между описаниями процессов и их экземплярами – примерно такая же как между классами и объектами. Одному описанию процесса в каждый момент времени может соответствовать сколько угодно экземпляров процессов, и взаимодействие между экземплярами процессов может быть устроено довольно сложно. Однако как при взаимодействии определить, какой именно экземпляр процесса должен получить данные? Механизм корреляций позволяет декларативным способом описать правила поиска экземпляра по передаваемым данным. Наличие таких довольно тонких возможностей демонстрирует степень проработанности стандарта.
Бизнес-процессы могут подразумевать взаимодействие не только с информационными системами, но и с людьми. Более того, наивное представление о бизнес-процессах вообще не подразумевает ничего иного, кроме людей. Поэтому поддержка так называемых “human workflow”, то есть таких бизнес-процессов, которые бы описывали информационное взаимодействие именно между людьми, чрезвычайно важна.
Конечно, люди могут ничего другого не делать, кроме как набирать и редактировать XML-данные. Однако такой способ включения людей абсолютно неприемлем, и обычно в workflow-системах предусматривается некоторый специализированный интерфейс, представляющий те же самые данные в удобном для человека виде – что включает в себя много чего и, в принципе, допускает настоящее программирования представления информации.
В то время как технологические предпосылки определили конкретное историческое развитие данной технологии, политические тоже сыграли свою роль.
Считается порочным, когда предприятие функционирует “непрозрачным” способом (по крайней мере для собственника) – то есть когда невозможно, грубо говоря, взять лупу и внимательно рассмотреть каждый конкретный бизнес-процесс, когда существует какая-то тайна, кроме чётко ограниченной коммерческой. Считается также, что предприятие выигрывает, когда оно может легко входить и выходить из конфигураций, предназначенных для достижения конкретных экономических целей – а это подразумевает определённую унификацию того, как предприятия взаимодействуют друг с другом. Но и в таких конфигурациях тоже протекают бизнес-процессы, пересекающие границы предприятий.
Изменчивость во внешней по отношению к предприятию среде порождает изменчивость во внутренней, то есть непрерывная интеграционная работа становится отличительной чертой современного предприятия, и чем более оно включено во взаимодействие с другими предприятиями, чем быстрее темп отношений – тем более от успеха именно интеграционной работы начинает зависеть успех предприятия. Некогда проектировать, программировать и отлаживать; традиционное программирование становится всё менее пригодным для решения повседневных задач бизнеса. Необходимо сделать как-то так, чтобы аналитики могли сразу придумывать правильные процессы, и как можно быстрее запускать их в работу. Современные средства разработки для BPEL как раз это и обеспечивают.
Неудивительно поэтому, первые успешные внедрения BPEL оказались именно в сфере телекоммуникаций и финансов.
Компания Oracle предлагает готовое BPEL-ориентированное интеграционное решение Oracle BPEL Process Manager 10g. В состав этого решения входит средство разработки на базе Oralce JDeveloper 10g и сервер, который сам существует в двух вариантах. Первый вариант – для разработчиков, основан на Oracle Containers for Java (OC4J) и базе данных Oracle Lite.
Второй вариант – для промышленного использования, исполняется под управлением Oracle Application Server 10g и СУБД Oracle 10g. Кроме того, в поставку входит Worklist Application и BPEL Console. Последнее приложение предназначено для управлением процессами в реальном времени, их аудита и контроля. См.
Исторически, это решение разрабатывалось независимой компанией Collaxa, которая впоследствии была приобретена. С тех пор решение сохранило ряд довольно полезных свойств, которые включают в себя независимость от сервера приложений (Oracle BPEL Process Manager может функционировать под управлением, например, JBoss и BEA Weblogic, а также некоторых других), а также специализированный plug-in для среды разработки с открытым исходным кодом Eclipse 3.0. В целом, можно ожидать, что индустрию BPEL-ориентированной интеграции ждёт большое будущее. Выгоды, которые получают предприятия от внедрения описанной технологии, весьма значительны – даже если относиться с некоторой долей скепсиса к её глобализационным перспективам – поскольку такие возможности как автоматизация партнёрских отношений, реализация композитных услуг являются важными конкурентными преимуществами, которые получают предприятия, внедряющие данную технологию. Для организаций государственного и муниципального управления внедрение данной технологии является частью реализации концепции электронного правительства.
