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

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

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

Для підготовки даної роботи було використані матеріали із російського сайту internet.