Ein Business Process ist eine Abfolge von Aktivitäten, die entweder interaktive Tätigkeiten durch Personen oder Batchprozesse sind. Im Fall von Batchprozessen wird von der Business Process Engine direkt eine Anwendung aufgerufen und der abwickelnde Thread der Engine verbleibt im Aufruf der Anwendung, bis diese ausgeführt wurde und der Aufruf zurückkehrt. Im Falle einer interaktiven Tätigkeit kann eine Anwendung nicht direkt aufgerufen, sondern nur ein Benutzer benachrichtigt werden, der eine Anwendung zu starten hat. Durch die Einbindung der Anwendung in den Business Process erfolgt bei Beendigung der Aufgabe eine Rückmeldung an die Process Engine, die aufgrund der Prozessdefinition die nächste Aktivität ermittelt.
Die Definition der Prozesse erfolgt in XPDL. Libra liefert die Prozessdefinition für die einzelnen Anwendungsbereiche mit den Anwendungen aus. Diese Definitionen können in der Einführungsphase auf die konkrete Organisation und deren Bedürfnisse hin angepasst und im späteren Betrieb weiter geändert werden. Da XPDL ein offener Standard ist und in vollem Umfang von der Libra Process Engine unterstützt wird, können quelloffene Werkzeuge wie JaWE als grafische Editoren in der Pflege der Prozessdefinitionen verwendet werden.
Eine prozessorientierte Anwendung kommuniziert als Client mit der Process Engine. Typische Aufrufe sind
- Workflow Prozess erstellen
- GetNextActivityInstanceWithLock ReleaseActivityInstance
- Complete Activity
Alle API sind in der "Stateless Session Bean" implementiert. Wenn eine asynchrone Ausführung notwendig ist, weil der Caller zu lange in dem Aufruf verbleiben würde, geschieht das "hinter" der Session Bean. Die asynchrone Verarbeitung bleibt für den API Client verborgen.
Das API ist für eine interaktive Anwendung konzipiert, die den Zustand des Objektes hinsichtlich seiner möglichen Bearbeitung in den Workflow Zuständen speichert. Es gibt die nächste offene ActivityInstance zurück. "Offen", und das heißt angelegt, ist eine Activity Instance, weil eine andere beendet wurde oder der Prozess gestartet wurde. Wenn mehrere Activity Instanzen offen sein sollten, wird immer nur eine zurückgegeben. Theoretisch könnten auch alle offenen zurückgegeben werden. Es besteht dann jedoch eine Asymmetrie zu den Beendigungsaufrufen, in denen pro Activity Instanz weitere Daten wie Completion Code mit zurück gegeben werden müssen. Das Übermitteln der nächsten offenen Activity Instanz ist mit einem Lock verbunden. Das Lock wird auf die Activity Instanz und den Prozess insgesamt gelegt.
Wenn eine Activity, die eine Exit Activity ist (d.h. keine ausgehenden Transitions hat), beendet wird, wird der Workflow Prozess beendet - und zwar unabhängig davon, ob andere noch zur Beendigung anstehende Activities bestehen. Noch ausstehende Activities können über das API beendet werden. Applikationen, die im Laufen begriffen sind, laufen weiter. Aber wenn über das API nach neuen Activities gefragt wird, werden keine mehr (ohne Exception) zurückgegeben. Bei Beendigung einer Activity werden alle Notifikationen für dieselbe entfernt, bei Beendigung des Prozesses werden alle Notifikationen für den Prozess entfernt.
Bei Prozesserstellung werden alle Data Items und alle formalen Parameter als Attribute angelegt. Besteht Namensgleichheit von Data Items und formalen Parametern, wird der formale Parameter ignoriert. Da formale Parameter keine Initializer haben, können reine OUT Parameter auf diese Weise initialisiert werden: es wird ein namensgleicher Data Item angelegt.
Handelt es sich um einen Subprozess, werden die "Actual Parameters" der Parent Activity angewandt, d.h. reine IN Parameter werden evaluiert und dem Attribut des Subprozesses, das durch den der Ordinalzahl nach entsprechenden formalen Parameter identifiziert wird, zugewiesen. Bei IN-OUT Parametern, wird der Actual Parameter nicht evaluiert, sondern als Namen eines Data Items (Attributs) des Parent Prozess verstanden, dessen Wert dem Attribut des Subprozesses, das durch den der Ordinalzahl nach gleichen formalen Parameter identifiziert wird, zugewiesen wird. Der n-te Actual Parameter evaluiert also entweder bei IN direkt zu einem Wert oder bei IN-OUT durch Referenz auf ein Data Item. Dieser Wert wird einem Attribut des Subprozesses zugewiesen. Der Name (und gegebenenfalls auch der Typ) des Attributs ergibt sich aus dem n-ten formalen Parameter des Subprozesses. Bei Beendigung des Subprozesses werden die Werte von allen Attributen des Subprozesses, die durch einen IN-OUT und OUT Parameter seiner formalen Parameter Liste identifiziert werden, auf Attribute des Parent Prozesses kopiert. Das Attribut des Parent Prozesses wird durch die Actual Parameter List der aufrufenden Activity ermittelt: der n-te formale Parameter entspricht dem n-ten aktuellen Parameter, der wiederum den Namen des Attributs des Parent Prozesses enthält.