Sven Böttcher, Apps Associates

Schlüsselworte

APEX, Activiti, Oracle BPM Suite, Workflows

Einleitung

Oracle Application Express (APEX) erfreut sich als Rapid Application Development Tool für die Entwicklung datenbankzentrischer Webanwendungen großer Beliebtheit. Die Gründe dafür sind unter anderem, dass APEX lizenzkostenfrei verwendet werden kann und die Entwicklung von Eingabemasken durch einen GUI-Editor schnell und einfach vonstatten geht. Durch die GUI-Editor gestützte Entwicklung wird ein prototypisches Vorgehen bei der Anwendungsentwicklung ermöglicht, wodurch sich die späteren Benutzer sehr gut in den Softwareentwicklungsprozess einbeziehen lassen. Auf diese Weise kann auf Missverständnisse oder gegebenenfalls auftretende Änderungswünsche bereits in einem frühen Stadium des Entwicklungsprozesses reagiert werden. Es kommt jedoch häufig vor, dass für eine komplexe Applikationslogik entsprechend komplexe Workflows umgesetzt werden müssen. An dieser Stelle bietet APEX, wie die meisten Tools für die Entwicklung von Eingabemasken, keinerlei Unterstützung. Die einzige Möglichkeit Workflows umzusetzen besteht hier in der manuellen Programmierung. Im Fall von APEX zum Beispiel in der Programmiersprache PL/SQL. Dies führt häufig zu einem sehr langen und komplizierten Programmcode, welcher fehleranfällig und nur schwer wartbar ist. Zudem kann der Programmcode im Allgemeinen nicht mehr von den Anwendern verstanden werden. Dies und der zumeist hohe Aufwand der Workflowprogrammierung erschweren wiederum die prototypische Anwendungsentwicklung. Eine Lösung dieses Dilemmas besteht in der Integration von APEX und einer Workflowengine, welche idealerweise in einer graphischen Beschreibungssprache (z.B. Business Process Model and Notation – BPMN) beschriebene Workflows ausführen kann. Im Rahmen des Vortrags wird eine Methode für die Integration von APEX und verschiedener Workflowengines (Activiti / Oracle BPM) vorgestellt und die sich ergebenden Vorteile in einer Live-Demonstration veranschaulicht.

Integration von Workflow Engines

Der Vorteil der Integration von Workflow Engines bzw. BPM Suiten und APEX besteht darin, dass die eigentlichen Workflows von Prozess Analysten modelliert und ohne eine „Reimplementierung“ (in PLSQL) durch Entwickler ausgeführt werden können. Die Idee der Integration besteht nun darin, dass der Programmablauf bzw. die Programmlogik durch die Workflow Engine gesteuert wird. Mittels APEX sollten dagegen Eingabemasken für die Nutzerinteraktion bereitgestellt werden. Die Verknüpfung von APEX und Workflows (also der Programmlogik) erfolgt dabei über Meta-Informationen innerhalb der modellierten Workflows. Für die Abfolge von Eingabemasken bzw. APEX Seiten würde das zum Beispiel bedeuten, dass zu jedem (Benutzer-) Task des Workflows festgelegt wird, mit welcher APEX Seite dieser Task zu bearbeiten ist. Diese Informationen könnten beispielweise in Dokumentationsfeldern der Tasks abgelegt werden. Daher stellt die Möglichkeit der Anreicherung von (Benutzer-) Tasks um Meta-Informationen eine Grundvoraussetzung für die Integration nach dem hier vorgestellten Ansatz dar. Die eigentliche Integration bzw. Kommunikation zwischen APEX und der Workflow Engine erfolgt über den Aufruf von Webservices. Die Aufrufe der Webservices werden durch APEX initialisiert und dienen Beispielsweise dem Starten von Prozessen, der Abfrage von als nächstes auszuführenden Tasks, der Zuweisung von Tasks und dem Beenden von Tasks. Da jeder Task über Meta-Information mit einer APEX-Seite verknüpft ist, kann einem Benutzer nach der Übernahme eines Tasks die entsprechende APEX Seite für die Bearbeitung dieses
Tasks angezeigt werden. Daher ist die zweite Anforderung an eine zu integrierende Workflow Engine, dass sich diese über Webservices steuern lassen muss (z.B. über eine REST API). Den Entwicklern kommt nun die Aufgabe zu, die Tasks des Workflows mit entsprechenden Meta-Informationen anzureichern, sowie die Implementierung der eigentlichen Integration von APEX und der Workflow Engine. Auch wenn Letzteres aufwändig erscheint, entsteht der Vorteil, dass die Webserviceaufrufe im Gegensatz zu in PLSQL implementierten Workflows nicht projektspezifisch sind und sich in den verschiedensten Projekten wiederverwenden lassen.

Activiti

Activiti ist eine quelloffene Workflow und Business Process Management (BPM) Plattform, die im Rahmen der Apache Lizenz kostenlos verwendet werden kann1. Die zentralen Komponenten von Activiti sind in Abbildung 1 dargestellt und können grob in die Bereiche Modellierung, Laufzeit und Management gegliedert werden.

Der eigentliche Kern der Activiti BPM Suite ist die Activiti Engine. Diese führt BPMN 2.0 Prozesse aus und kann entweder „standalone“, quasi als Java Programm, oder auf einem JEE konformen Application Server (z.B. Glassfish, Weblogic,…) betrieben werden. Die komplette Steuerung der Activiti Engine kann entweder Java basiert oder über eine REST API (Activiti REST) erfolgen. Für Letzteres wird ein JEE konformer Application Server benötigt und bildet die Grundlage für APEX Integration.

Activiti Komponenten

Abb. 1: Activiti Komponenten (Quelle: Activiti.org)

APEX und Activiti

Wie bereits oben erwähnt, verfügt die Activiti über eine sehr vollständige REST API mit derer Activiti komplett gesteuert werden kann. Des Weiteren lassen sich Tasks über den Activiti Modeler (mit dem auch die Workflows Modelliert werden) mit den benötigten Meta-Informationen anreichern.
APEX und Activiti passen aber auch hinsichtlich der benötigten Infrastruktur bestens zusammen. Da APEX in der Oracle Datenbank läuft und sich diese problemlos als Activiti Repository verwenden lässt, wird hier keine zusätzliche Datenbank benötigt. Wird auf APEX (wie von Oracle empfohlen) mittels der Oracle REST Data Services (ORDS) zugegriffen, wird auch für das Deployment der Activiti RESTAPI und des Activiti Modelers keine zusätzlichen Infrastruktur benötigt. Die APEX Infrastruktur lässt sich von Activiti einfach mitbenutzen (siehe Abb. 2).

______________________
1 Quelle: http://activiti.org/

 

APEX und Activiti Infrastruktur

Abb. 2: APEX und Activiti Infrastruktur

Für die Integration beider Tools wurde eine PLSQL Bibliothek geschrieben, die im Wesentlichen eine Menge von Webservice aufrufen darstellt. Über diese Webserviceaufrufe wird die Activiti Engine wie oben beschrieben gesteuert und diese liefern als Ergebnis die benötigten Meta-Informationen zurück. Diese Informationen werden über den Activiti Modeler mit den Tasks eines Workflows verknüpft. Dazu dient das Dokumentationsfeld von Tasks und die Metainformationen werden innerhalb dieses Feldes durch Kommas getrennt in die Zeichen /{…}/ gefasst und so als Meta-Informationen kenntlich gemacht. Momentan lassen sich als Meta-Informationen die zur Bearbeitung des Tasks aufzurufende APEX Seite, allgemeine Informationen zu dem Task und zu setzende APEX Page Items verwenden. Durch apex_page:page_number lässt sich zum Beispiel die Seite page_number aufrufen und durch set_page_item(page_item:activiti_process_variable) das Page Item page_item auf den Wert der Activiti Prozess Variable activiti_process_variable setzen. Über get_info(activiti_process_variable)} lassen sich allgemeine Informationen zu dem Task abfragen. Auch diese müssen vorher mittels einer Activiti Prozess Variable gesetzt werden. Eine vollständige Meta-Information würde zum Beispiel wie folgt aussehen: /{apex_page:201,set_page_item(P201_TICKET_ID:ticket_id) ,get_info(ticket_info)}/. Auf diese Weise erfolgt eine wechselseitige Steuerung zwischen APEX und Activiti. Durch APEX werden Prozesse gestartet, Aktivitäten zugewiesen und abgeschlossen sowie benötigte Activiti Prozess Variablen gesetzt. Activiti steuert dagegen die anzuzeigenden APEX Seiten, setzt APEX Page Items und bestimmt , welche Aktivitäten durch welche Benutzer als nächstes ausgeführt werden können (siehe Abb. 3).

Wechselseitige Steuerung zwischen APEX und Activiti

Abb. 3: Wechselseitige Steuerung zwischen APEX und Activiti

APEX und die Oracle BPM Suite

Die Oracle BPM Suite bietet „Out-of-the-box“ mit der Integration von ADF-Formularen bereits gute Möglichkeiten der Entwicklung von Eingabemasken. Dennoch spricht zunächst nichts gegen eine Integration von APEX und der Oracle BPM Suite. Tasks lassen sich beispielsweise über den Oracle Business Process Composer über das Dokumentationsfeld einfach mit den benötigten Meta-Informationen versehen und die Dokumentation „REST API for Business Process Management“ verspricht eine ausreichende REST API für die Steuerung der durch die Process Engine ausgeführten Prozesse (auch wenn diese bei weitem nicht so vollständig ist, wie die Activiti REST API). Doch bereits nach den ersten nicht erfolgreichen REST aufrufen stellt sich Ernüchterung ein. So führt beispielsweise der Aufruf zum Starten eines Prozess zum dem Resultat „405 Method Not Allowed“. Hier ist zum jetzigen Zeitpunkt für die Ressource process nur die get Methode implementiert. Zum Starten eines Prozesses wird laut Dokumentation allerdings die post Methode verwendet. Bis die entsprechenden Methoden von Oracle bereitgestellt werden, kann nach der hier vorgestellten Methode keine Integration erfolgen.

Fazit

Durch die vorgestellte Methode lässt sich APEX mit diversen Workflow Engines bzw. BPM Plattformen integrieren. Die Voraussetzungen dafür sind zum einen, dass sich die zu integrierende Workflow Engine über Webservices steuern lässt und sich zum anderen Tasks um Meta-Informationen anreichern lassen. Während beispielsweise eine Integration mir der Activiti BPM Plattform prototypisch durchgeführt wurde, konnte eine Integration mit der Oracle BPM Suite nicht erfolgen, da benötigte Methoden noch nicht implementiert sind. Auch wenn die Integration zunächst einen recht hohen Entwicklungsaufwand fordert, ergibt sich der Vorteil, dass diese in anderen Projekten wiederverwendet werden kann. Konkrete Workflows die in PLSQL programmiert werden sind dagegen sehr spezifisch und werden von Prozess Analysten und den Anwendern der Applikation nicht verstanden. Durch die toolgestützte, grafische Entwicklung und die anschließende Einbindungen dieser Workflows in APEX lässt sich der Rapid Prototyping Ansatz zu mindestens auf Teile der Programmlogik ausweiten. Des Weiteren lassen sich Fehler in der Programmlogik minimieren, da die zeitaufwändige Reimplementierung der Workflows in PLSQL entfällt.