Автоматизація наскрізних бізнес-процесів підприємств з використанням BPEL

С. Бітюков, старший консультант Oracle СНД

Як виходить, що організація працює? Чому в результаті дій великого кількості людей, документообігу, накопичення та перетворення даних у інформаційних системах в кінцевому підсумку виходить той самий результат, який очікується? Як помислити про те, що відбувається в організації, в досить абстрактних і простих термінах і не йдучи при цьому занадто далеко від реальності?

Бізнес-процес - Одна з концепцій, яка призначена саме для цього. До речі, існують та інші терміни, що позначають те ж саме, але в деяких особливих видах людської діяльності. Наприклад, у державному та муніципальному управлінні прийнято говорити про регламенти, у тому числі електронних, однак ми будемо далі говорити про бізнес-процеси як про поняття, найбільш часто використовується в літературі, в першу чергу англомовної. Можна по-різному визначати, що ж це таке (і на такому свавіллі і утворюються різні школи і методики), проте важливо те, що бізнес-процес являє собою деяке дію, що складається з більш дрібних дій, пов'язаних між собою деяким чином, і зафіксоване деяким формальним способом. Формалізація дуже важлива, тому що як тільки вона з'являється, то разом з нею приходить можливість застосовувати весь апарат роботи з формальними системами - тобто засоби аналізу, моделювання, верифікації та багато чого ще.

Навколо цієї ідей виникла ціла індустрія 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-орієнтованої інтеграції чекає велике майбутнє. Вигоди, які отримують підприємства від впровадження описаної технології, вельми незначні - навіть якщо ставитися з певною часткою скепсису до її глобалізаційним перспективам - оскільки такі можливості як автоматизація партнерських відносин, реалізація композитних послуг є важливими конкурентними перевагами, які отримують підприємства, що впроваджують дану технологію. Для організацій державного і муніципального управління впровадження даної технології є частиною реалізації концепції електронного уряду.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://citcity.ru/