Oracle Workflow 2.6 właściwe informacje dla właściwych osób

Na podstawie bezkresnych zasobów Sieci
Piotr Listosz
plistosz@nafta.net.pl

Wstęp

Zysk będący głównym motorem działania każdego przedsiębiorstwa,
wymusza realizowanie polityki, której celem jest ciągły rozwój firmy, przy
jednoczesnym ograniczaniu zatrudnienia. Pozytywnym skutkiem takiego postępowania
jest uzyskiwanie większych dochodów mniejszym nakładem sił. Jednakże aby
skutek ten był możliwy do osiągnięcia, konieczne jest wdrożenie sprawnego
mechanizmu zarządzania procesami biznesowymi, jakie na co dzień zachodzą w
przedsiębiorstwie. Jednym ze sposobów uproszczenia procedur administracyjnych,
jest wykorzystanie dobrego systemu zarządzania pracą grupową.

W odpowiedzi na ciągły rozwój przedsiębiorstw, na
przestrzeni ostatnich lat powstało sporo takich systemów, wśród których można
wymienić Microsoft Exchange, czy Novell Groupwise. Na szczególną uwagę zasługuje
jednak w pełni skalowalny, inteligentny system zarządzania procesami
biznesowymi, jakim niewątpliwie jest Oracle Workflow.

Ogólna charakterystyka systemu

Tłumaczenia terminu workflow próżno szukać w większości
słowników, jest to bowiem pojęcie nowe, wprowadzone na potrzeby systemów
zarządzania pracą grupową, a oznacza przepływ procesów biznesowych, jakie
realizuje się w przedsiębiorstwach.

Początkowo Oracle Workflow pomyślany był jako tradycyjne
narzędzie, przeznaczone do sterowania organizacją pracy w aplikacjach firmy
Oracle. Jednakże z czasem, gdy narzędzie to przeobraziło się w system zarządzania
złożonymi procesami zachodzącymi w biznesie, Oracle Workflow został udostępniony
jako niezależny produkt.

Wymiana różnorodnych informacji pomiędzy pracownikami
firmy oraz współpraca z jednostkami zewnętrznymi to kluczowe elementy działania
typowego przedsiębiorstwa. Problemem na jaki napotykają popularne systemy zarządzania
pracą jest to, że reguły według których odbywa się wspomniana wymiana
informacji ulegają ciągłym zmianom. Oracle Workflow doskonale radzi sobie z
tym problemem, gdyż jego działanie oparte jest na rozszerzalnej architekturze
sterowanej procesami. System ten umożliwia przekazywanie dowolnych typów
informacji, zarówno pomiędzy pracownikami przedsiębiorstwa, jak i na zewnątrz,
a także zapewnia automatyzację i ciągłe udoskonalanie procesów biznesowych,
sterowanych często modyfikowanymi regułami.

W przeciwieństwie do innych systemów organizacji pracy, które
ograniczają się do przesyłania informacji pomiędzy użytkownikami i
wymuszania pewnych czynności zatwierdzających, Oracle Workflow umożliwia
modelowanie złożonych procesów jakie zachodzą w biznesie. Przy pomocy tego
narzędzia można definiować procesy które wykonują się w pętli, rozgałęziają
się na działania przebiegające równolegle, spotykają się, rozkładają na
procesy podrzędne, rozdzielają w zależności od rezultatów określonego działania,
wygasają, itp. Ze względu na fakt, iż decyzja o ścieżce jaką będzie
przebiegał dany proces, podejmowana jest w oparciu o rezultaty procedury składowanej,
można wykorzystać pełną moc języka PL/SQL, by przy jego pomocy tworzyć
zasady biznesowe, sterujące procesami zdefiniowanymi w systemie Oracle Workflow.

Oracle Workflow rozszerza zasięg automatyzacji procesów
biznesowych, zachodzących zarówno w obrębie przedsiębiorstwa, jak i poza
nim, włączając w to postępowanie użytkowników poczty e-mail, przeglądarek
WWW oraz systemy obsługujące standardowe protokoły internetowe.

W zakresie integracji systemów, Oracle Worflow pozwala
definiować zdarzenia, których wystąpienie decyduje o uruchomieniu pewnych
czynności, czy przesłaniu komunikatów pomiędzy określonymi aplikacjami.
Komunikacja będąca skutkiem tych działań może zostać nawiązana zarówno
pomiędzy aplikacjami pracującymi w przedsiębiorstwie, jak i w odniesieniu do
systemów zewnętrznych. W ten sposób możliwe staje się zaimplementowanie
łączności typu punkt-punkt, lub korzystanie z Oracle Workflow jak z
koncentratora nadzorującego przekazywanie danych pomiędzy systemami, przy
minimalnym ingerowaniu w działanie tych ostatnich.

Integracji podlegają nie tylko aplikacje działające w
firmie, ale również jej pracownicy, bądź grupy pracowników (na przykład
działy przedsiębiorstwa), a także osoby współpracujące (dostawcy,
odbiorcy, potencjalni klienci). Oni również są automatycznie powiadamiani o
wystąpieniu określonych zdarzeń zdefiniowanych w systemie (na przykład
dostawca może być powiadomiony o utworzeniu zamówienia, a odbiorca o
wyprodukowaniu partii materiału gotowej do sprzedaży).

Informacje o zdefiniowanych w systemie użytkownikach i
rolach przechowywane są przez udostępnianą w Oracle Workflow usługę
katalogową (ang. Worflow directory service). Korzystając z protokołu
LDAP (ang. Lightweight Directory Access Protocol) można zsynchronizować
te informacje, z tymi zarejestrowanymi przez usługę OID (ang. Oracle
Internet Directory
). Dzięki takiej integracji możliwe staje się nie tylko
centralne zarządzanie danymi o użytkownikach, ale również publikowanie tych
danych w sposób pozwalający na dostęp do nich z poziomu innych systemów. Po
wykonaniu wspomnianej synchronizacji, możliwe jest egzekwowanie tylko jednego
procesu autoryzacji użytkownika, podczas jego logowania się do dowolnego
komponentu Oracle9i Application Server. Po takiej autoryzacji, użytkownik
ten może uruchamiać kolejne komponenty, bez konieczności podawania informacji
uwierzytelniających.

Oprócz wykonywanej centralnie autoryzacji, Oracle Workflow
zapewnia centralne sterowanie procesami biznesowymi. System ten udostępnia listę
działań (ang. worklist), z poziomu której można przeglądać zgłoszenia
odnoszące się do odpowiednich procesów biznesowych, jak również odpowiadać
na te zgłoszenia. Ponadto ten scentralizowany system jest równocześnie
systemem rozproszonym, gdyż lista działań o której mowa, może być dostępna
z dowolnego miejsca, przy pomocy komputera wyposażonego w standardową przeglądarkę
sieci Web. Użytkownik po wyświetleniu wspomnianej listy, może decydować o
tym jakie działania mają zostać wykonane w danym momencie, a także dowolnie
sortować i grupować te działania, organizując pracę w sposób najbardziej
mu odpowiadający. Takie podejście do problemu pozwala skupiać się na działaniach
najważniejszych (tych które muszą być wykonane najprędzej), a także unikać
częstych zmian kontekstu w jakim musi być rozpatrywane każde z działań.

Użytkownik może przegladać zgłoszenia, korzystajac w tym celu z listy działań.
Rys. 1. Użytkownik może przeglądać zgłoszenia, korzystając w tym celu z
listy działań.

Obowiązki idące w parze z preferencjami pracowników
przedsiębiorstwa to kluczowy element sukcesu w biznesie. Obiekty systemu Oracle
Workflow dostępne są z poziomu standardowych przeglądarek oraz programów
klienckich poczty elektronicznej. Dane uzyskiwane z systemu mogą różnić się
poziomem szczegółowości, a także mogą być prezentowane zarówno przy
pomocy zwykłego tekstu jak i kodu HTML. Informacje generowane przez Oracle
Workflow mogą być w sposób automatyczny generowane dynamicznie, jak też
personalizowane w odniesieniu do konkretnego ich odbiorcy. Wszystkie te elementy
pozwalają w sposób znaczący dostosować stan systemu do preferencji jego użytkowników.

W systemie Oracle Workflow zaimplementowane zostały
zaawansowane zasady przekazywania reakcji na określone zdarzenia. Dzięki tym
zasadom możliwe jest zależne od okoliczności, odpowiednie przyporządkowywanie
odpowiedzialności za przebieg procesów biznesowych. Często w firmach istnieją
osoby odpowiedzialne za synchronizowanie zbierania informacji, jakie są niezbędne
do podejmowania kluczowych decyzji. System Oracle Workflow może automatycznie
przekazywać te informacje do owych osób, dbając jednocześnie o kompletność
danych. Część pracy jaką wykonuje na co dzień asystent szefa firmy, to działania
rutynowe, a co za tym idzie, nadające się doskonale do zautomatyzowania. Takie
podejście pozwala skupić się na sytuacjach nietypowych, a realizacją pozostałych
obarczyć maszynę. Dzięki systemowi Oracle Workflow pracownik odpowiedzialny
za kluczowe operacje wykonywane w przedsiębiorstwie, może bez obaw wyjechać
na urlop. System sam zadba o przekazywanie innym pracownikom rezultatów występowania
pewnych zdarzeń, a inne – mniej istotne – pozostawi na liście zdarzeń do
powrotu z urlopu. W Oracle Workflow można zarządzać z wyprzedzeniem okresem
wykonywania się pewnych działań, ustalając dla nich odpowiednie ramy
czasowe, lub pozostawiając ów przedział czasu otwarty. Dzięki wymienionym
cechom można zarówno zaoszczędzić czas, jak i uniknąć „wąskich
gardeł”, jakie pojawią się przy źle zaplanowanym podziale pracy.

Powiadomienia o wystąpieniu pewnych zdarzeń, jakie rozsyłane
są przez system, pozwalają kierownictwu śledzić rozwój procesów
biznesowych w firmie. Powiadomienia te mogą być przekazywane do dowolnych
aplikacji Oracle pracujących w przedsiębiorstwie, co zdecydowanie przyczynia
się do uproszczenia zarządzania biznesem.

Podstawowe pojęcia

Przed zapoznaniem się z budową i działaniem systemu Oracle
Workflow, należy przyswoić sobie kilka pojęć, jakie często przewijają się
podczas opisów systemów organizacji pracy. Oto te pojęcia:

Działanie (ang. activity) – jednostka pracy
reprezentująca jeden logiczny krok, realizowany podczas procesu biznesowego.
Działanie może być funkcją, powiadomieniem, zdarzeniem biznesowym lub
podprocesem.

Zdarzenie (ang. event) – incydent mający miejsce
w aplikacji intranetowej lub internetowej, który może być znaczący dla
innych obiektów w systemie lub dla programów zewnętrznych (przykładem
zdarzenia w aplikacji obsługującej hurtownię może być utworzenie zamówienia).
Do definiowania zdarzeń służy aplikacja Event Manager, o której za chwilę.

Funkcja (ang. function) – procedura składowana PL/SQL,
definiująca zasady biznesowe, realizująca zautomatyzowane operacje zachodzące
wewnątrz aplikacji, lub pobierająca informacje.

Element (ang. item) – określony proces, dokument
lub transakcja, zarządzana w procesie biznesowym.

Typ elementu (ang. item type) – grupa elementów
określonej kategorii, współdzieląca ten sam zestaw atrybutów.

Atrybut elementu (ang. item attribute) –
cecha skojarzona z określonym elementem, będąca de facto zmienną, której
wartość może być odczytywana bądź ustawiana przez aplikację zarządzającą
tym elementem. Atrybut elementu dostępny jest dla wszystkich działań biorących
udział w procesie.

Zawiadomienie (ang. notification) – egzemplarz
komunikatu przesłanego do użytkownika.

Działanie zawiadamiające (ang. notification activity)
– jednostka pracy wymagająca interwencji użytkownika. W wyniku pojawienia się
działania zawiadamiającego wysyłany jest komunikat, którego odbiorcą jest użytkownik
posiadający informacje niezbędne do zakończenia procesu, jakiego owo działanie
zawiadamiające dotyczy.

Komunikat (ang. message) – informacja wysłana w
wyniku zajścia działania zawiadamiającego. Komunikat musi być zdefiniowany
przed skojarzeniem tej informacji z działaniem zawiadamiającym.

Subskrypcja zdarzenia (ang. event subscription) –
Rejestracja wskazująca, że określone zdarzenie jest znaczące dla systemu
oraz określająca proces jaki zostanie wykonany w chwili pojawienia się tego
zdarzenia. Proces taki może obejmować wywołanie utworzonego wcześniej kodu,
wysłanie komunikatu o zdarzeniu do procesu biznesowego lub wysłanie tego
komunikatu do programu zewnętrznego.

Proces (ang. process) – zbiór czynności jakie
muszą być wykonane po to, by zrealizować cel biznesowy.

Przejście (ang. transition) – Powiązanie
definiujące w procesie wykonanie jednego działania i aktywację kolejnego.

Agent (ang. agent) – węzeł komunikacyjny
istniejący w zdefiniowanym wcześniej systemie. Komunikacja zachodząca w
systemach oraz między nimi, realizowana jest wskutek przesyłania komunikatów
pomiędzy agentami. W pojedynczym systemie może być zdefiniowanych kilka różnych
agentów, z których każdy reprezentuje inne rozwiązanie komunikacyjne. Przykładowy
system może być wyposażony w różnych agentów do obsługi komunikacji
przychodzącej i wychodzącej, komunikacji odbywającej się z udziałem różnych
protokołów, różnych częstotliwości rozgłaszania lub innych metod. Ważne
jest aby zdefiniować wszystkich agentów, jacy mogą zostać wykorzystani w
procesie komunikacyjnym.

System (ang. system) – logicznie odizolowane środowisko
software’owe, takie jak komputer pełniący rolę hosta lub instancja bazy
danych. Należy zdefiniować wszystkie systemy z których lub do których będą
odwoływały się zdarzenia. Każdy system może być wyposażony w jeden lub więcej
punktów komunikacyjnych zwanych agentami. Po zdefiniowaniu systemu należy określić
skojarzonych z nim agentów, którzy zostaną użyci w procesie komunikacji
zachodzącej pomiędzy zdarzeniami biznesowymi.

Komponenty systemu

System Oracle Workflow składa się z następujących
komponentów:

Oracle Workflow Builder – Narzędzie graficzne pozwalające
tworzyć, przeglądać lub modyfikować procesy biznesowe, udostępniając w tym
celu technikę „przeciągnij i upuść”. Użytkownik posługujący
się tym programem może korzystać ze wszystkich obiektów dostępnych w fazie
modelowania procesów, włączając w to takie obiekty jak działania, typy
elementów, oraz komunikaty. Użytkownik może w dowolnej chwili dodawać, usuwać
lub zmieniać działania zachodzące w procesie biznesowym, a także konfigurować
nowe zależności istniejące pomiędzy tymi działaniami. Można tu operować
na modelu ogólnym, bądź też według potrzeb rozwijać działania składające
się na określony proces, uzyskując w ten sposób większy poziom szczegółowości.
Oracle Workflow Builder można uruchomić z dowolnego komputera, posiadającego
dostęp do Internetu.

Workflow Engine – Mechanizm zainstalowany na serwerze
bazy danych Oracle, odpowiedzialny za monitorowanie stanów procesu biznesowego
oraz koordynowanie przesyłania danych pomiędzy procesami. Zmiany stanu procesu
biznesowego, takie jak na przykład zakończenie określonego działania,
sygnalizowane są mechanizmowi Workflow Engine poprzez API PL/SQL lub API języka
Java. Działający w oparciu o elastycznie definiowane zasady przebiegu procesów
biznesowych, mechanizm ten określa, które działania nadają się do
uruchomienia i uruchamia je. Workflow Engine potrafi obsługiwać skomplikowane
reguły sterujące przebiegiem procesów, włączając w to pętle, rozgałęzienia,
procesy wykonujące się równolegle a także procesy podrzędne. W rzeczywistości
mechanizm Workflow Engine jest zwyczajnym pakietem PL/SQL, którego procedury
wywoływane są w chwili zajścia określonych zdarzeń.
Workflow Engine zarządza wszystkimi zautomatyzowanymi aspektami każdego
elementu procesu biznesowego, a jego procedury aktywowane są w chwili zmiany
stanu tegoż procesu. Jako że mechanizm o którym mowa, wbudowany jest w serwer
bazy danych Oracle, podlega on automatycznemu odtwarzaniu po awarii, zgodnie z
regułami zdefiniowanymi dla tej bazy danych. Takie rozwiązanie zapewnia
integralność każdej transakcji, jaka była realizowana w chwili wystąpienia
problemów.
Dodatkowo Workflow Engine może zostać skonfigurowany jako mechanizm
drugoplanowy, desygnowany do wykonywania działań zbyt kosztowych, aby można
je było egzekwować w czasie rzeczywistym.
Jako aplikacja kliencka Workflow Engine wykonuje następujące usługi:

  • Zarządza stanem wszystkich działań odnoszących się
    do danego procesu, a w szczególności określa jakie nowe działanie ma
    pojawić się w chwili, gdy zostaną spełnione wymagane warunki wstępne.

  • Automatycznie wykonuje funkcje związane z działaniami i
    wysyła zawiadomienia.

  • Zarządza historią stanu działania.

  • Lokalizuje błędne warunki i wykonuje kod obsługi błędów.

Notifications System – Usługi powiadamiające,
odpowiedzialne za wymianę komunikatów zachodzącą podczas realizacji procesu
biznesowego. Oracle Workflow pozwala na włączenie w procesy biznesowe użytkowników,
przydzielając im zadanie obsługi tych działań, które nie mogą zostać
zautomatyzowane. Przykładem takich działań jest wydanie zgody na
zapotrzebowanie, czy też potwierdzenie zamówienia. Zadaniem mechanizmu
Notifications System jest przekazywane zawiadomień o zajściu określonych
zdarzeń do ról, które mogą być skojarzone z konkretnym użytkownikiem lub
grupą użytkowników. Dowolny użytkownik posiadający daną rolę może
wykonywać operacje na otrzymanym zawiadomieniu. W skład każdego zawiadomienia
wchodzi komunikat, który zawiera wszystkie informacje jakich potrzebuje użytkownik,
aby podjąć odpowiednią decyzję. Informacje te mogą być osadzone w treści
komunikatu lub dołączone doń w formie odrębnego dokumentu. System Oracle
Workflow interpretuje każdą odpowiedź na działanie zawiadamiające i na tej
podstawie określa sposób, w jaki należy przejść do następnego działania w
procesie biznesowym.

Workflow Monitor – Aplikacja pozwalająca administratorom
i użytkownikom oglądać postępy zachodzące w procesie biznesowym. Z aplikacją
tą można połączyć się z dowolnego komputera, wyposażonego w przeglądarkę
WWW obsługującą języka Java. Workflow Monitor pozwala wyświetlić widok
notatek diagramu określonego procesu biznesowego, dzięki czemu użytkownik
monitorujący ma dostęp do graficznego opisu stanu procesu. Ponadto Workflow
Monitor przedstawia odrębne podsumowania dotyczące stanu poszczególnych
elementów procesu oraz każdego działania realizowanego w procesie.

Business Event System – System korzystający z
infrastruktury Oracle Advanced Queuing, dzięki której możliwa jest
komunikacja pomiędzy zdarzeniami biznesowymi zachodzącymi w obrębie jednego
systemu, jak i pomiędzy różnymi systemami. Jest to jeden z najważniejszym
komponentów systemu Oracle Workflow. Jednym z elementów Business Event System
jest aplikacja Event Manager, która umożliwia rejestrowanie subskrypcji określonych
zdarzeń oraz działań, przy pomocy których można modelować przebieg procesu
biznesowego. W momencie zajścia zdarzenia lokalnego, wykonywany jest
subskrybowany kod. Wywołanie to jest częścią tej samej transakcji, w której
wykonał się kod wywołujący zdarzenie. Przetwarzanie subskrypcji może
obejmować wykonywanie zdefiniowanego wcześniej kodu (zależnego od informacji
przekazywanej wraz ze zdarzeniem), wysłanie informacji o zdarzeniu do procesu
biznesowego lub wysłanie tej informacji do innych systemów.
Business Event System umożliwia programistom aplikacji:

  • Definiowanie zdarzeń biznesowych, kluczowych dla procesów
    zachodzących w firmie.

  • Rejestrowanie subskrypcji powiązanych z tymi zdarzeniami

  • Wywoływanie zdarzeń biznesowych (lub odwoływanie się
    do nich) w kodzie aplikacji

Businnes Event System umożliwia użytkownikom:

  • Dostosowywanie działania aplikacji do własnych potrzeb,
    bez konieczności modyfikowania ich standardowego kodu.

  • Przekazywanie wiadomości do i z systemów
    Business-To-Business

  • przekazywanie wiadomości do i z aplikacji pracujących w
    przedsiębiorstwie.

Działaniem procesu biznesowego steruje wspomniany wyżej
Event Manager, który zawiera rejestr systemów, agentów, zdarzeń oraz
subskrypcji tych zdarzeń. W chwili zajścia zdarzenia biznesowego, Event
Manager dokonuje identyfikacji odpowiedniej subskrypcji zdarzenia i wykonuje ją.
W wyniku realizacji tego procesu mają miejsce poniższe operacje:

  • Wykonanie utworzonego wcześniej kodu, w odpowiedzi na
    komunikat zdarzenia.

  • Przesłanie zdarzenia biznesowego do zdefiniowanego
    procesu biznesowego albo

  • Przeadresowanie zdarzenia biznesowego do agenta systemu
    lokalnego lub zewnętrznego.

W chwili wystapienia zdarzenia, zgłoszonego badz to przez źródło
lokalne, badz zewnętrzne, Event Manager realizuje funkcję, której zadaniem
jest przesłanie tego zdarzenia do procesu biznesowego lub przeadresowanie go do
lokalnego lub zewnętrznego agenta.
Rys. 2. W chwili wystąpienia zdarzenia, zgłoszonego bądź to przez źródło
lokalne, bądź zewnętrzne, Event Manager realizuje funkcję, której zadaniem
jest przesłanie tego zdarzenia do procesu biznesowego lub przeadresowanie go do
lokalnego lub zewnętrznego agenta.

Otoczenie systemu

Dzięki współpracy z systemami przekazywania poczty e-mail
oraz standardowymi przeglądarkami sieci Web, Oracle Workflow staje się
systemem ogólnodostępnym, bez konieczności instalacji oprogramowania
klienckiego.

Użytkownicy poczty elektronicznej mogą otrzymywać
zawiadomienia dotyczące zaległych elementów procesu i odpowiadać na te
zawiadomienia, również przy użyciu poczty e-mail.

Dowolny użytkownik posiadający dostęp do standardowej
przeglądarki WWW, może zostać włączony w proces biznesowy. Użytkownicy
sieci Web mają dostęp do strony domowej Oracle Workflow, z poziomu której mogą
wywoływać inne strony, odpowiadające za różne elementy działania systemu.
(Wykaz stron dostępnych dla użytkowników i administratorów znajduje się w
tabeli poniżej.)

System Oracle Workflow 2.6 wyposażony jest w mechanizmy
odpowiedzialne za umieszczanie zadań w kolejkach oraz za pobieranie ich stamtąd.
Dzięki tym mechanizmom system potrafi współpracować z infrastrukturą Oracle
Advanced Queuing. Pozwala to na rozsyłanie komunikatów do różnych aplikacji
i systemów, a także na korzystanie z protokołów HTTP i HTTPS, które umożliwiają
integrację z innymi systemami powiadamiającymi, takimi jak MQ*Series, czy
TIBCO.

Oracle Advanced Queuing to mechanizm kolejkujący zadania w
bazie danych Oracle. Umożliwia on asynchroniczną komunikację pomiędzy
aplikacjami oraz oferuje rozszerzalną architekturę, pozwalającą na
integrowanie systemów rozproszonych. (Więcej informacji na temat komunikacji
synchronicznej i asynchronicznej znajduje się w dalszej części tego tekstu).
Integracja Advanced Queuing z bazą danych wprowadza do procesu przekazywana
komunikatów dodatkowy poziom funkcjonalności, a także ułatwia działania
operatorskie, zapewnia bezpieczeństwo, niezawodność, dostępność oraz
skalowalność.


Rys. 3. Korzystając z infrastruktury Advanced Queuing,
Business Event System umożliwia komunikację pomiędzy różnymi systemami.

Zdarzenia – podstawowy element systemu

Bardzo często pojawiający się w tym tekście termin zdarzenie
biznesowe
, oznacza po prostu dowolne zdarzenie, które może być interesujące
dla użytkowników lub zespołu programistów. Zdarzeniem biznesowym może być
na przykład przygotowanie zamówienia handlowego. Innym przykładem zdarzenia będzie
aktualizacja takiego zamówienia. Pojęciem ściśle związanym ze zdarzeniem
biznesowym jest subskrypcja zdarzenia biznesowego. W wyniku takiej
subskrypcji realizowane są zazwyczaj poniższe operacje:

  • Wykonanie przygotowanego wcześniej kodu PL/SQL

  • Wysłanie komunikatu o zdarzeniu biznesowym do
    predefiniowanego procesu.

  • Zaistnienie komunikacji asynchronicznej z wykorzystaniem
    Oracle Advanced Queuing.

Chcąc wyłączyć lub ponownie włączyć subskrypcję określonego
zdarzenia, wystarczy skorzystać z opcji udostępnianych przez system. Nie występuje
tu konieczność jakiejkolwiek modyfikacji kodu procedur składowanych.

Każde zdarzenie biznesowe zdefiniowane w aplikacji,
przystosowuje jej działanie do potrzeb użytkowników, konsultantów oraz
programistów. Zatem im więcej występuje takich zdarzeń, tym większa jest
elastyczność aplikacji i możliwość dodawania do niej własnej logiki, bez
konieczności modyfikowania standardowego kodu.

Dawniej jedynym sposobem ingerencji w logikę aplikacji było
definiowanie wyzwalaczy (ang. trigger), umożliwiających testowanie
warunków, które były interesujące dla użytkownika. Przykładem może być
wyzwalacz before row insert, zdefiniowany w tabeli zamówień i testujący,
czy zostały spełnione warunki konieczne do sporządzenia zamówienia (na przykład,
czy w magazynie nie brak jest zamawianego towaru). Użytkownik mógł ingerować
w kod aplikacji, drogą obsługi wyjątków generowanych przez takie wyzwalacze.

Business Event System będący komponentem Oracle Workflow
udostępnia możliwość definiowania i dokumentowania miejsc w aplikacji, z
poziomu których można dostosowywać tę aplikację do potrzeb użytkowników.
Na przykład po wprowadzeniu nowego zamówienia, może zostać wygenerowane
zdarzenie utworzono zamówienie, a użytkownik który utworzy subskrypcję
tego zdarzenia, będzie mógł uruchomić kod mający za zadanie zaakceptowanie
bądź odrzucenie zamówienia.

Procesy biznesowe

System Oracle Workflow zarządza procesami biznesowymi na
podstawie zdefiniowanych zasad. Zasady te, nazywane definicją procesu
biznesowego (ang. workflow process definition), obejmują działania
pojawiające się w trakcie realizacji procesu oraz relacje jakie zachodzą pomiędzy
tymi działaniami. Działanie o którym jest tu mowa, może być funkcją składowaną
PL/SQL, funkcją zewnętrzną, zawiadomieniem wysyłanym do użytkownika bądź
roli z opcjonalnym żądaniem odpowiedzi, zdarzeniem biznesowym lub podprocesem,
który sam może składać się z działań podrzędnych.

Proces biznesowy inicjowany jest w chwili wywołania przez
aplikację funkcji pochodzącej z API mechanizmu Workflow Engine. Następnie,
mechanizm ten przejmuje ów proces, przetwarzając zgodnie z definicją składające
się nań elementy (którymi mogą być dokumenty, transakcje lub inne procesy).
W zależności od tej definicji (czyli od zasad, które decydują o przebiegu
procesu), Workflow Engine wykonuje pewne zautomatyzowane, przygotowane wcześniej
operacje, a także wywołuje odpowiednich agentów, w chwili gdy wymagane jest
odwołanie się do systemu zewnętrznego.

Poniższy diagram przedstawia przebieg prostego procesu
biznesowego, którego jedynym elementem jest kierowanie żądań do menedżera
(lub menedżerów), w celu ich zatwierdzenia.

Przebieg prostego procesu biznesowego, ogladany w podsystemie Workflow
Monitor.
Rys. 4. Przebieg prostego procesu biznesowego, oglądany w podsystemie Workflow
Monitor.

Rysunek ten określany jest mianem diagramu procesu. Ikony
reprezentują tu działania, natomiast strzałki odzwierciedlają przejścia
pomiędzy działaniami. Na proces przedstawiony na rysunku składa się kilka
działań, będących de facto procedurami PL/SQL. Wśród tych działań można
wymienić:

Wybór decydenta (ang. select approver) –
zgodny z zasadami biznesowymi wybór osoby, która może zatwierdzić żądanie.

Weryfikacja tożsamości (ang. verify authority)
– sprawdzanie, czy osoba wybrana do zatwierdzenia żądania, ma do tego
odpowiednie uprawnienia.

API języka Java i PL/SQL

Podczas programowania systemu Oracle Workflow można korzystać
zarówno z języka Java, jak i PL/SQL. API podsystemów Workflow Engine oraz
Notifications dostępne jest poprzez pakiety PL/SQL oraz widoki publiczne.
Interfejs Oracle Workflow Java ujawnia API jako metody Javy, które mogą być
wywoływane przez dowolny program napisany w tym języku taki, którego celem
jest zapewnienie komunikacji z systemem Oracle Workflow. Metody Javy odwołują
się bezpośrednio do widoków i procedur pochodzących z odpowiednich pakietów
PL/SQL, a komunikują się z bazą danych Oracle Workflow poprzez JDBC.

Podział procesów

Chcąc przy pomocy systemu Oracle Workflow efektywnie zarządzać
procesami biznesowymi, należy zrozumieć koncepcje przebiegów synchronicznych
i asynchronicznych.

Przebieg synchroniczny to taki, który w żadnym punkcie jego
trwania nie może zostać przerwany. Mając do czynienia z przebiegiem tego
typu, można natychmiast odczytywać wartości rejestrowane w atrybutach elementów
lub bezpośrednio w bazie danych. Rozwiązanie takie jest efektywne tylko wówczas,
gdy proces biznesowy nie trwa zbyt długo. W przeciwnym razie użytkownik
zostanie zmuszony do oczekiwania na zakończenie pracy aplikacji, która będzie
sprawiała wrażenie zawieszonej. Mając do czynienia z takim przypadkiem, należy
zastanowić się nad skorzystaniem z przebiegu asynchronicznego.

Przebieg asynchroniczny to taki, który jednorazowo nie może
zostać wykonany w całości. Workflow Engine nie może w prosty sposób zakończyć
procesu opartego na takim przebiegu, gdyż realizacja działań jakie są w nim
zdefiniowane, skutkuje przerwaniem tego przebiegu. W celu rozwiązania tego
problemu, mechanizm Workflow Engine aktywuje tabele kontrolne, po czym zwraca
sterowanie do modułu wywołującego (to znaczy tego, który zainicjował proces
biznesowy). Proces pozostaje w stanie zawieszenia do momentu otrzymania
komunikatu (zajścia działania zawiadamiającego) lub zadziałania podsystemu
Workflow Engine, skonfigurowanego jako mechanizm drugoplanowy. Przykładami działań
wymuszających przebieg asynchroniczny są działania odroczone, powiadomienia
wymagające odpowiedzi, zadania blokujące, czy zadania oczekujące.

Workflow Engine obsługuje również specjalną klasę procesów
synchronicznych zwaną wymuszonymi procesami synchronicznymi. Wymuszony proces
synchroniczny w całości wykonuje się w pojedynczej sesji SQL i nigdy nie
aktualizuje żadnej tabeli bazy danych. Szybkość wykonania takiego procesu
jest o wiele większa niż typowego procesu synchronicznego.

Administrowanie systemem

Czynności jakie należy wykonać, by prawidłowo zainstalować
system Oracle Workflow na bazie danych Oracle 8.1.6 lub Oracle 8.1.7 opisane są
w dokumencie Oracle Workflow 2.6 Server Installation Notes. Po
przeprowadzeniu tej procedury można zalogować się jako administrator systemu
i uruchomić stronę domową Oracle Workflow (Oracle Workflow 2.6 Homepage).
Strona ta zapewnia centralny dostęp do wszystkich podsystemów Oracle Worflow,
współpracujących z siecią Web.

W tabeli 1 wyszczególnione zostały łącza umieszczone na
stronie, o której mowa, oraz zadania jakie można dzięki nim wykonywać.

Strona domowa systemu Oracle Workflow, dzięki której możliwe staje się centralne zarzadzanie systemem, przy wykorzystaniu komputera wyposażonego w
standardowa przegladarkę sieci Web.
Rys. 5. Strona domowa systemu Oracle Workflow, dzięki której możliwe staje się
centralne zarządzanie systemem, przy wykorzystaniu komputera wyposażonego w
standardową przeglądarkę sieci Web.

Tabela 1. W poniższej tabeli wyszczególnione są łącza
umieszczone na stronie domowej Oracle Workflow (Oracle Workflow 2.6 Homepage),
oraz zadania jakie można dzięki nim wykonywać.

Łącze Czy wymagane
są uprawnienia administratora?
Opis
Worklist Nie Wyświetla listę zawiadomień pojawiających się w procesie
biznesowym. Korzystając z owej listy można te zawiadomienia zamykać lub
przeadresowywać, a także przeglądać szczegółowe dane na ich temat.
Find Notification Nie Lokalizuje zawiadomienia które spełniają określone kryteria oraz
pozwala wykonywać operacje na tych zawiadomieniach.
Notification Rules Nie Pozwala przeglądać i definiować zasady, w oparciu o które tworzone są
zawiadomienia.
Find Processes Nie Umożliwia sformułowanie zapytania o listę egzemplarzy procesu
biznesowego, które spełniają określone kryteria. Po znalezieniu żądanego
egzemplarza, można przeglądać jego szczegółowy stan, korzystając w
tym celu z aplikacji Worflow Monitor.
User Preferences Nie Pozwala definiować preferencje użytkownika, dotyczące jego współdziałania
z systemem Oracle Workflow.
Global Preferences Tak Umożliwia definiowanie preferencji globalnych, dotyczących wszystkich
użytkowników systemu Oracle Workflow.
Document Nodes Tak Służy do definiowania węzłów systemu zarządzania dokumentem, do którego
to systemu ma mieć dostęp Oracle Workflow.
Type Definition Nie Udostępnia stronę Find Item Type, przy pomocy której można zadać
zapytanie o żądaną definicję typu elementu.
Launch Processes Tak Umożliwia testowanie określonej definicji procesu biznesowego (tj.
zasad decydujących o przebiegu procesu).
Demonstration Page Tak Zapewnia dostęp do strony Demonstration, na której można uruchomić
dowolny z przykładowych procesów biznesowych, udostępnionych przez
Oracle.
Events Tak Pozwala przeglądać oraz definiować zdarzenia biznesowe.
Find Event/Group Tak Umożliwia formułowanie zapytań o zdarzenia oraz grupy zdarzeń, które
spełniają określone kryteria.
Systems Tak Pozwala przeglądać i definiować systemy, biorące udział w procesie
komunikacyjnym.
Find System Tak Umożliwia zadawanie zapytań o systemy, które spełniają określone
kryteria.
Agents Tak Pozwala przeglądać i definiować agentów, biorących udział w
procesie komunikacyjnym.
Find Agent Tak Umożliwia zadawanie zapytań o agentów, którzy spełniają określone
kryteria.
Event Subscriptions Tak Służy do przeglądania i definiowania subskrypcji zdarzeń.
Find Subscription Tak Pozwala zadawać zapytania o subskrypcje, które spełniają określone
kryteria.
Check Setup Tak Umożliwia sprawdzenie konfiguracji podsystemu Business Event System
oraz ustalenie harmonogramu dla procesów nasłuchujących i lokalnych
agentów.
Raise Event Tak Wywołuje zdarzenie biznesowe w podsystemie Event Manager.
System Signup Tak Pozwala kojarzyć ze sobą systemy, które dzięki temu mogą wymieniać
między sobą komunikaty o zdarzeniach biznesowych.

Oracle Workflow w praktyce

Oracle Workflow to nie tylko zagadnienie teoretyczne. System
ten funkcjonuje w wielu firmach, miedzy innymi w szwajcarskich laboratoriach
CERN (European Laboratory for Particle Physics). CERN to instytut skupiający
5 tysięcy pracowników lokalnych oraz 4 tysiące osób pracujących w
laboratoriach rozrzuconych po całym świecie. Zgodnie z panującą tendencją,
instytut stara się ograniczać liczbę zatrudnionych, dbając jednocześnie o
rozwój firmy. W środowisku takim istotne jest wydajne administrowanie zarówno
zasobami ludzkimi, jak i realizowanymi procesami. Jednym ze sposobów uzyskania
odpowiedniej wydajności jest stosowanie właściwego systemu zarządzania
procesami biznesowymi.

System działający w CERN skupia się głównie na
przekazywaniu dokumentów elektronicznych do osób odpowiedzialnych za ich
akceptowanie. Autoryzacja dokumentu polega na wprowadzeniu hasła do specjalnego
pola skojarzonego z tym dokumentem. Aby system zarządzania procesami
biznesowymi mógł sprawnie decydować o tym, kto może akceptować dokumenty
podczas określonych etapów przetwarzania, udostępniona jest specjalna baza
danych z uprawnieniami odnoszącymi się do każdej operacji wykonywanej w
procesie biznesowym.

Obecnie w CERN przetwarzanych jest około 120 tysięcy
dokumentów rocznie. Sytuacja w CERN jest o tyle skomplikowana, że o procesie
przetwarzania dokumentów finansowych decydują nie tylko zasady obowiązujące
w tym instytucie, lecz również wymagania innych firm, które finansują
projekty realizowane w CERN. Obecnie, w zależności od typu dokumentu, osoby
odpowiedzialnej za jego utworzenie oraz osoby finansującej prace, których
dotyczy ów dokument, może być on przetwarzany na około 270 różnych sposobów.

System zarządzania procesami biznesowymi nie jest w CERN
niczym nowym. Od 1992 roku był tam bowiem stosowany system zaimplementowany w języku
C, w którym definicje procesów przechowywane były w bazie danych Oracle.
Jednakże wraz z rozwojem aplikacji, jej pielęgnacja stawała się coraz
trudniejsza, czy wręcz niemożliwa. Nie od razu zdecydowano się na zmianę
systemu, gdyż po przeanalizowaniu rynku stało się jasne, że żadna z istniejących
aplikacji nie spełnia wymagań stawianych przez CERN. W związku z tym programiści
zatrudnieni w instytucie zdecydowali, że sami utworzą nowy mechanizm zarządzania
procesami biznesowymi, a jego jądro będzie napisane w języku Java.

Po trzech miesiącach pracy na rynku pojawił się system
Oracle Workflow, który ze względu na swą otwartą architekturę wydał się
rozwiązaniem doskonałym do zastosowania w laboratoriach CERN, a ponadto umożliwiał
wykorzystanie kodu w Javie, jaki zdołano do tej pory napisać.

Jedną z cech Oracle Workflow, która zdecydowanie przemawiała
na korzyść tego systemu, było graficzne narzędzie pozwalające na
projektowanie procesów, a mianowicie Oracle Workflow Builder. Graficzna
wizualizacja była bowiem tym elementem, którego brakowało w pierwotnym
systemie działającym w CERN. W takiej sytuacji SQL*Plus był jedynym narzędziem,
które pozwalało wyjaśnić określone decyzje podejmowane przez mechanizm zarządzający
procesem biznesowym.

Innym obszarem, w którym Oracle Workflow doskonale zastąpił
istniejący system, była obsługa błędów. W dotychczasowym systemie następowało
blokowanie dokumentów, które z jakichś powodów nie mogły być zatwierdzone
(na przykład osoba której powierzono to zadanie była nieobecna). Rozwiązanie
takiego problemu wymagało zazwyczaj „ręcznej” interwencji, co przy
dużym obciążeniu pracą było nie do zaakceptowania. W systemie Oracle
Workflow z problemem tym poradzono sobie dzięki tzw. procesom błędu,
które są automatycznie inicjowane w chwili pojawienia się sytuacji
problematycznej. Procesy te udostępniają bardziej rozproszoną strukturę zarządzania
kontrowersyjnymi dokumentami, w porównaniu z tą jaka była dostępna w starym
systemie.

Aby system zarządzania procesami biznesowymi mógł być w
pełni efektywny, musi istnieć możliwość zintegrowania go z istniejącym środowiskiem.
W CERN wykorzystywane są cztery główne typy aplikacji, które współdziałają
z mechanizmem sterującym procesami. Te aplikacje to:

  • podstawowa baza danych, zawierająca opis struktur
    organizacji, lokalizację biur, dane o dostawcach, informacje na temat
    projektów, uprawnienia osób zatwierdzających dokumenty itp.

  • baza danych zasobów ludzkich, gromadząca informacje o
    pracownikach i hierarchii obowiązującej w firmie

  • interfejs do bazy dokumentów, przechowującej dokumenty
    powstające w instytucie oraz informacje o ich stanach (odrzucony,
    zatwierdzony itp.)

  • interfejs do systemów odbiorczych, będących miejscem
    docelowym dla zaakceptowanych dokumentów (może to być na przykład system
    zakupów, do którego trafiają zaakceptowane zamówienia, bądź baza
    danych zasobów ludzkich, gdzie rejestrowane są podania o urlop)

Zaimplementowany w CERN Oracle Workflow współpracuje z powyższymi
systemami na następujących płaszczyznach:

  • Funkcje napisane w języku Java pobierają na żądanie
    informacje z podstawowej bazy danych (na przykład uprawnienia pracownika
    mogącego zatwierdzić podanie o urlop)

  • Również na żądanie wyszukiwane są informacje w bazie
    zasobów ludzkich (na przykład dane osoby udającej się na urlop)

  • Interfejs do bazy dokumentów działa w dwóch kierunkach
    – Oracle Workflow pobiera informacje dotyczące dokumentu (na przykład dane
    pracownika który go utworzył), a baza danych dokumentów aktualizowana
    jest informacjami zwróconymi przez proces biznesowy (na przykład danymi na
    temat stanu dokumentu, zmieniającego się w chwili jego odrzucenia bądź
    zaaprobowania)

  • Dokument trafiający do systemów odbiorczych przechodzi
    przez specjalny program transferujący, który jest wywoływany w ostatnim
    stadium procesu biznesowego.

Proces wdrażania systemu Oracle Workflow starano się
przeprowadzić w CERN w sposób możliwie jak najmniej absorbujący użytkowników.
Przejście ze starego systemu do nowego odbywało się stopniowo, dzięki czemu
w chwili pojawienia się problemów na jakiejś płaszczyźnie, możliwy był
powrót do dotychczasowego rozwiązania. Przez jakiś czas oba systemy działały
jednocześnie, z tym że w Oracle Workflow wyłączono opcje zawiadamiania. Dzięki
temu można było na bieżąco porównywać stary system z nowym. W chwili gdy
działanie tego ostatniego wydało się zadawalające, dotychczasowy system
został odłączony w sposób nieodczuwalny dla użytkowników.

Pomimo iż Oracle Workflow jest w CERN wciąż we wczesnej
fazie użytkowania, to rezultaty osiągnięte do tej pory wydają się być
zadawalające. System ten nie jest tak skomplikowany jak inne rozwiązania tej
klasy, a jego moc bierze się stąd, że jest on w pełni rozszerzalny przy
zastosowaniu języka PL/SQL oraz Java. Niemal niemożliwe jest znalezienie na
rynku takiego systemu organizacji pracy, który pozwoliłby na całkowitą
integrację z istniejącym środowiskiem, bez konieczności modyfikacji tego
ostatniego. Jednakże otwarta architektura systemu Oracle Workflow sprawia, że
zadanie to jest możliwe do realizacji. W tak skomplikowanej strukturze jak
instytut CERN, system ten sprawdza się doskonale.

Wymóg czasów

Trudno wyobrazić sobie działalność dużej firmy,
zatrudniającej setki lub tysiące pracowników, bez sprawnego systemu zarządzania
pracą grupową. Efektem braku takiego systemu może być przerost zatrudnienia,
niewykorzystywanie pełnego potencjału pracowników, zatrudnianie niewłaściwych
osób na nieodpowiednich stanowiskach, a co za tym idzie, brak wywiązywania się
z kontraktów, zmniejszenie zysków, utrata prestiżu firmy, czy nawet jej
bankructwo. Informacja jest obecnie jednym z najistotniejszych aspektów każdej
działalności, a sprawne zarządzanie tą informacją, wyznacznikiem sukcesów
na rynku.

Spośród wielu systemów zarządzania pracą grupową, jakie
są obecnie dostępne na rynku, tylko nieliczne mogą poszczycić się takimi możliwościami
jak Oracle Workflow, a niemal żaden z nich nie zapewnia tak dużej elastyczności
w dostosowywaniu działania produktu do konkretnych potrzeb użytkowników.