Tipps zu Bonita

Nachfolgend einige Tipps zur Arbeit mit Bonita, Version 6.x.
Neu: Hinweise zur Arbeit mit Version 7

Inhalt

Links
Modellieren
–Diagramme und Pools – Versionen und Kopien
–Organisation
–Akteure im Prozess
–Konfiguration des Prozesses
–Prozess-Start
–Initialisieren von Variablen
–Groovy-Skripte
–Groovy-Skripte wiederverwenden
Deployen und Ausführen
Datenbank von Prozessen leeren
Export und Import von Prozessen
In das Log-File schreiben
Zugriff auf die Bonita-Datenbank

Zurück zur Downloadseite

Links

• Startseite Bonita Community: http://community.bonitasoft.com/
• Dokumentation: http://documentation.bonitasoft.com/
• Videos: http://www.bonitasoft.com/for-you-to-read/videos?page=1&category=Get%20Started
• Downloads: https://www.bonitasoft.com/downloads-v2. In der Regel ist der für das eigene Betriebssystem passende Download voreingestellt. Ansonsten kann man über „Customize your download“ die passende Version auswählen. Es wird einer der „Development“-Downloads benötigt, d. h. „Bonita BPM for Windows“ oder „Bonita BPM All in one“ (Linux, Mac, Windows).
• Erweiterungen und Beispielprozesse auf Github: https://github.com/bonitasoft-community
• Bonita Bugtracker: https://bonita.atlassian.net/secure/Dashboard.jspa

Seitenanfang

Hinweise zur Arbeit mit Bonita-Version 7

In Version 7 sind einige neue Features hinzugekommen (z. B. Business-Objekte und ein neuer UI-Designer). Solange man diese neuen Features nicht einsetzt, lässt sich genauso arbeiten wie in Version 6 und wie im Buch beschrieben. Z. T. finden sich manche Inhalte im Bonita-Studio an einer etwas anderen Stelle:

• Prozessvariablen: Im Eigenschaftsfenster finden sich im Tab „Daten“ links nun „Business variables“ für die neuen Business-Objekte. Möchte man gewöhnliche Prozessvariablen verwenden, muss man darauf achten, diese im rechten Feld hinzuzufügen.
• Konnektoren und Vorgänge zum Setzen von Variablenwerten: Diese trägt man nun im Tab „Execution“ ein. Konnektoren, die zu Beginn eines Tasks ausgeführt werden sollen, sind unter „Connectors in“ hinzuzufügen. Entsprechend werden Konnektoren, die nach Beenden eines Tasks ausgeführt werden sollen, unter „Connectors out“ eingetragen.
• Formulare: Für die herkömmlichen Formulare wählt man im Tab „Execution“ unter „Formulare“ den Typ „6.x“ aus. Das Formular selbst kann man unter dem Tab „6.x Application“ erstellen.

Seitenanfang

Modellieren

Diagramme und Pools – Versionen und Kopien

In Bonita ist zwischen Diagrammen und Pools zu unterscheiden. Ein Diagramm entspricht der Grafik im Studio. Für den Server und die Prozessausführung haben Diagramme keine Bedeutung.

Ein Pool enthält einen Prozess. Jeder Pool wird bei der Ausführung zu einer eigenen „App“ im Portal. Jeder Pool hat auch seine eigene Konfiguration (Zuordnung der Akteure zu Gruppen, mit zu exportierende Filter oder jar-Dateien). Daher muss man vor der Ausführung jeden Pool separat konfigurieren (jeweils den Pool anklicken, „Konfigurieren“ wählen).

Ein Diagramm kann mehrere Pools enthalten. In der Regel nutzt man dies, um aufgerufene Prozesse oder Nachrichten-austauschende Prozesse gemeinsam im selben Diagramm darzustellen.

Man kann aber auch Prozesse aufrufen oder als Nachrichtenempfänger nutzen, deren Pools sich in einem anderen Diagramm befinden. Damit das Bonita Studio diese erkennen kann, müssen sie sich ebenfalls im Workspace befinden (aber nicht unbedingt geöffnet sein). Man sollte daher darauf achten, dass zumindest die Pools, deren Prozesse man aus einem anderen Prozess aufrufen möchte, oder mit denen man Nachrichten austauschen möchte, einen Namen haben, der nur einmal vorkommt. In neueren Bonita-Versionen wird dies auch überprüft. Damit der Aufruf bzw. der Nachrichtenaustausch später bei der Ausführung funktionieren, müssen alle beteiligten Prozesse auf dem Server deployed sein.

Wählt man „Ausführen“, so werden die Prozesse aller Pools in dem im Vordergrund geöffneten Diagramm deployed (auf den Server geladen) und der Prozess des gerade selektierten Pools gestartet. Enthält das Diagramm mehrere Pools und ist kein Pool selektiert, so wird irgendeiner der Prozesse gestartet. Im Portal lassen sich alle auf dem Server befindlichen Prozesse starten (soweit man als Benutzer dazu berechtigt ist).

Sowohl Diagramm als auch Pools haben eine Versionsnummer. Die Versionsnummer eines Diagramms dient nur der Verwaltung im Studio. So kann man beispielsweise mehrere Versionen eines Diagramms gleichzeitig im Workspace haben. Name und Versionsnummer kann man über die Eigenschaften des Diagramms ändern, die unten unter „Allgemein“ angezeigt werden, wenn man in die Fläche außerhalb der Pools klickt. Über „Bearbeiten“ beim Namen gelangt man zu einem Dialog, in dem man nicht nur Diagramm-Nname und Versionsnummern ändern kann, sondern auch die der Pools. Namen und Versionsnummern der Pools kann man aber auch ändern, wenn man einen Pool selektiert hat.

Ändert man die Versionsnummer eines Diagramms, so wird kein neues Diagramm angelegt. Es handelt sich nur um eine Änderung der Bezeichnung. Möchte man eine Kopie eines Diagramms anlegen, muss man „Diagramm>Duplizieren“ verwenden. Man muss dann einen anderen Namen oder aber zumindest eine andere Versionsnummer angeben.

Sofern in mehreren Diagrammen (oder mehreren Diagrammversionen) Pools mit gleichem Namen und gleicher Versionsnummer enthalten sind, werden diese beim Deployen nicht unterschieden. Es wird ein eventuell vorhandener anderer Prozess mit derselben Kombination aus Name und Versionsnummer mitsamt seinen (laufenden und archivierten) Prozessinstanzen gelöscht und durch den neuen Prozess ersetzt. In neueren Bonita-Versionen wird verhindert, dass man dieselbe Kombination aus Prozessname und Versionsnummer mehrfach verwendet. Allerdings kann man einen vorhandenen Prozess einfach verändern und erneut hochladen. Im späteren Betrieb möchte man in der Regel nicht, dass die ganzen Informationen über abgelaufene Prozessinstanzen verloren gehen. Daher ist es besser, eine neue Version des Prozesses zu erstellen (s. unten) und die alte Version auf dem Server zu deaktivieren.

Um eine neue Version eines Prozesses zu erstellen, muss man die Versionsnummer des betreffenden Pools ändern. Deployed man die neue Version auf den Server, so bleibt eine existierende Version des Prozesses mit einer anderen Nummer unverändert. Es sind dann zwei Versionen des Prozesses auf dem Server vorhanden, und man kann z. B. die ältere Version deaktivieren, so dass nur noch die neue Version verwendet wird, die archivierten Prozessinstanzen der alten Version aber bestehen bleiben (um z. B. nachzuvollziehen, wie ein bestimmter Prozess gelaufen ist).

Seitenanfang

Organisation

Die Organisationsstruktur, d. h. die vorhandenen Gruppen, Rollen und Benutzer kann einerseits in der Entwicklungsumgebung Bonita Studio bearbeitet werden, andererseits durch einen Administrator im Portal. Da man in der Community Edition die Organisationsstruktur vom Server nicht exportieren kann (z. B. um sie nach einer Neuinstallation wieder zu importieren), und man für die Akteur-Zuordnung im Studio die Gruppen etc. benötigt, empfiehlt es sich für unsere Zwecke, die Organisation prinzipiell im Studio zu bearbeiten und auf dem lokalen Server zu veröffentlichen.

Wie die Veröffentlichung auf einem separat installierten Server mit der Community Edition funktioniert, wurde nicht ausprobiert. Im Gegensatz zur kommerziellen Version steht auf dem Server keine Import-Funktion für die Organisation zur Verfügung. Entweder man kann die Veröffentlichung über die Wahl eines anderen Servers in den Voreinstellungen ermöglichen, oder man muss die Gruppenstruktur im Portal nachbauen. Ggf. könnte man für die Datenübernahme bei eine Neuinstallation einen Export und Import mit Hilfe eines Datenbankskripts realisieren.

Anlegen und Bearbeiten einer Organisation:

„Organisation>Verwalten“. Hier kann man mehrere Organisationen anlegen. Von diesen kann jedoch auf dem Server immer nur eine aktiv sein. Normalerweise wird man daher nur mit einer Organisation arbeiten. Hat man zwei Prozesse, bei denen die Akteure Benutzergruppen aus verschiedenen Organisationen zugeordnet sind, kann man diese nicht beide auf dem Server nutzen, da ja immer nur eine Organisation aktiv ist.

Für die Organisation können Gruppen angelegt werden, die hierarchisch geschachtelt sein können, d. h. eine Gruppe kann Untergruppe einer anderen Gruppe sein. Meist ist es sinnvoll, eine oberste Gruppe zu haben, damit man sehr leicht alle Benutzer gleichzeitig einem Akteur zuordnen kann. Bei den Gruppeninformationen gibt es zwei Felder mit der Bezeichnung „Name“. Der erste ist der interne Name, der zweite der im Portal angezeigte Name. Eine typische Gruppenstruktur ist die Organisationshierarchie eines Unternehmens. Ordnet man später einen Akteur einer Gruppe zu, so können die Mitglieder der Untergruppen ebenfalls die Tasks dieses Akteurs durchführen.

Zusätzlich können Rollen angelegt werden. Rollen lassen sich nicht hierarchisieren. Typischerweise handelt es sich um allgemeine Rollen wie „Mitglied“, „Leiter“ o.ä., die allen Gruppen vorkommen können. Mindestens eine Rolle ist notwendig.

Jeder Benutzer benötigt ein oder mehrere Zugehörigkeiten, wobei eine Zugehörigkeit eine Kombination aus Gruppe und Rolle ist (z. B. „Mitglied der Gruppe Einkauf“ oder „Leiter der Gruppe IT“).
Über „Organisation>Veröffentlichen“ wird eine auszuwählende Organisationsstruktur auf den Server exportiert. Diese ist dann die aktive Organisationsstruktur. Damit ein Prozess auf dem Server ausgeführt werden kann, müssen seine Akteure den Gruppen, Rollen, o. ä. der aktiven Organisation zugeordnet sein. Unter Standard-Benutzer wird ein Benutzer eingetragen, der beim Start des Portals (z. B. über die Schaltfläche „Portal“) automatisch eingeloggt wird.

Seitenanfang

Akteure im Prozess

Im Prozess legt man Akteure an, indem man den Pool selektiert und unter „Akteure“ beliebige Akteure einträgt. Ein Akteur repräsentiert eine bestimmte Rolle, die man in einem Prozess spielt. Soll der Prozess manuell gestartet werden können (s.u.), so muss man einen Akteur als Initiator kennzeichnen. Nur dieser Akteur kann den Prozess starten – wobei man diesem Akteur beim Konfigurieren aber z. B. auch die oberste Gruppe zuordnen kann, so dass jeder Benutzer den Prozess in seiner Liste der „Apps“, d. h. der zu startenden Prozesse, eingetragen bekommt.

Für jeden Benutzer-Task muss definiert sein, welcher Akteur ihn ausführt. Dies kann über die Lane geschehen oder direkt beim Benutzer-Task. Selektiert man eine Lane, so kann man unter „Akteur“ einen der im Pool definierten Akteure auswählen. Defaultmäßig gilt dieser Akteur dann auch für jeden Benutzer-Task in dieser Lane. Man kann aber auch in den Benutzer-Task gehen, dort „Nachstehenden Akteur verwenden“ anklicken und hier direkt einen der im Pool definierten Akteure auswählen.

Durch die Zuordnung eines Akteurs wird dafür gesorgt, dass der Task später immer zugleich bei allen Benutzern in die Tasklist eingetragen wird, die über ihre Rollen, Gruppen u. ä. dem Akteur zugeordnet sind.

Möchte man die Auswahl der Benutzer einschränken oder z. B. einen Benutzer dynamisch auswählen, so kann man zusätzlich einen Akteur-Filter setzen. Es gibt eine Reihe vordefinierter Filter, wie z. B zur Auswahl eines Einzelnutzers mit einer bestimmten ID oder zur Auswahl des Prozessinitiators. Zudem kann man eigene Filter programmieren.

Seitenanfang

Konfiguration des Prozesses

Bevor man den Prozess deployen kann, muss man ihn konfigurieren. Insbesondere müssen die Akteure konkreten Gruppen, Rollen o.ä. aus der aktiven Organisation zugeordnet werden. Zudem sind ggf. zusätzlich verwendete .jar-Dateien oder sonstige verwendete Dateien anzugeben, die mit deployed werden müssen.

Über die Schaltfläche „Konfiguration“ gelangt man in den entsprechenden Dialog. Hier kann man zunächst die Akteure zuordnen. Es werden alle Akteure aus dem Pool angezeigt und man kann eine oder mehrere Gruppen und/oder Rollen bzw. Zugehörigkeiten auswählen. Die direkte Zuordnung von Benutzern ist auch möglich, aber in der Praxis meist nicht empfehlenswert – sonst muss die Zuordnung bei jedem Mitarbeiterwechsel geändert werden.

Schließlich sollte man unter „Authentifizierung“ noch den Benutzer eintragen, der nach Deployen und Start mittels „Ausführen“ als erster automatisch eingeloggt ist und den Prozess startet. Es sollte ein Benutzer sein, der den Prozess auch starten kann (d. h. er ist über seine Einordnung in die Organisation dem Akteur zugeordnet, der Prozess-Initiator ist).

„Anonymer Benutzer“ wird normalerweise nicht benötigt. Möchte man den Prozess über das Intra- oder Internet zur Ausführung durch jedermann ohne Log-In anbieten, so muss man einen Benutzer mit der Zuordnung und den Berechtigungen anlegen, die der anonyme Benutzer haben soll. Dieser Stellvertreter-Benutzer wird hier eingetragen.

Hat man eigene jar-Dateien oder ähnliches in seinem Prozess verwendet, so müssen diese unter Prozess-Abhängigkeiten eingetragen werden. Die anderen Eintragungen (Konnektoren, Akteur-Filter) werden in der Regel automatisch richtig vorgenommen.

Seitenanfang

Prozess-Start

Prozesse können manuell und automatisch gestartet werden.

Für den manuellen Start ist es erforderlich, dass ein Akteur im Pool als Initiator festgelegt ist. Nach dem Deployen erhalten alle betreffenden Benutzer im Portal unter „Apps“ einen Eintrag mit dem Namen des Pools, über den sie den Prozess starten können. Ist kein Akteur festgelegt, so ist nur ein automatischer Start möglich.

Ein automatischer Start eines Prozesses erfolgt, wenn der Prozess von einer Aufrufaktivität aufgerufen wird oder wenn bei einem Nachrichten-empfangenden Startereignis eine Nachricht eingegangen ist. Zudem ist ein Start über das Java API durch ein Programm möglich.

Der manuelle Start des Prozesses kann mit einem Formular erfolgen, in dem man zu Beginn benötigte Werte einträgt. Zum Anlegen dieses Formulars selektiert man den Pool (links in der Titelzeile) und legt im Tab „Anwendung“ unter „Pageflow > Formulare“ das gewünschte Formular an. Im Gegensatz zu anderen Formularen kann man als Anfangswerte für die einzelnen Felder nur Konstanten verwenden, jedoch keine Variablen. Diese sind noch nicht initialisiert, da der Prozess noch gar nicht gestartet ist (siehe unten „Initialisieren von Variablen“).

Möchte man kein Startformular haben, so muss man im Tab „Anwendung“ unter „Pageflow > Formulare“ „Überspringen“ auswählen. Defaultmäßig ist aber „Pageflow“ selektiert. Ändert man dies nicht und legt man auch kein Formular an, so wird ein Default-Formular mit Feldern für alle im Pool definierten Variablen erzeugt.

Einerseits kann ein Startformular praktisch sein, andererseits ist das Modell dann nicht ganz so aussagekräftig. Wenn man modellieren möchte, dass man erst einen Auftrag erfasst, und er anschließend geprüft wird, verwendet man normalerweise zwei Benutzer-Tasks. Da man den Auftrag nun aber bereits mit dem Startformular erfassen kann, entfällt der Erfassungs-Task. Von daher ist das Modell aussagekräftiger, wenn man den Pageflow des Pools überspringt.

Nachteil ohne Startformular: Nach „Start“ erschien bislang noch einmal eine separate Seite mit einer Schaltfläche „Fall starten“. Man hat also einen Klick mehr, der keinen direkten Nutzen bringt. Begründung für die Einführung dieses Buttons war, dass man sonst über den „Back“-Buttton des Browsers versehentlich eine zweite Prozessinstanz starten könnte. Dies wurde mit Version 6.3.1 geändert. Es erscheint nun die Schaltfläche „Fall starten“ nicht mehr.

Noch einen weiteren Unterschied gibt es: Während das Startformular nur für den Benutzer angezeigt wird, der den Prozess startet, wird das Formular des ersten Tasks für alle Benutzer angezeigt, die dem betreffenden Akteur zugeordnet sind. Sind der betreffenden Lane z. B. alle Einkäufer zugeordnet, dann wird nach dem Start des Prozesses der erste Task allen Einkäufern in die Taskliste gelegt. Will man das verhindern, muss man beim Akteur dieses Tasks den Filter „Initiator“ setzen.

Seitenanfang

Initialisieren von Variablen

Variablen im Pool legt man an, indem man den Pool selektiert (links in der Titelzeile des Pools, sonst wird die Lane selektiert) und unter „Daten“ „Hinzufügen“ wählt.

Für die Variablen kann man Default-Wert angeben. Diese Default-Werte werden erst beim Start des Prozesses zugewiesen. Das bedeutet, dass die Werte im Formular, das zum Starten eines Prozesses verwendet wird, noch nicht zur Verfügung stehen. Wird der Variablen über das Start-Formular ein Wert zugewiesen, so wird dieser Wert verwendet (wird nichts eingetragen, ist der Wert z. B. ein leerer String oder im Falle einer Zahl der Wert 0). Der Default-Wert aus dem Pool wird in diesem Fall gar nicht genutzt.

Nutzt man das automatisch von Bonita generierte Startformular (indem man im Pool kein Formular anlegt, aber Pageflow selektiert lässt), so werden Eingabefelder für alle Variablen erzeugt, d. h. alle Variablen erhalten ihre Werte vom Startformular, und die Default-Werte werden nicht genutzt.

Möchte man, dass die Defaultwerte bereits im ersten Formular zur Verfügung stehen, so muss man im Pool unter „Anwendung“ bei „Pageflow>Formulare“ „Überspringen“ wählen. Das erste Formular ist dann das des ersten Schrittes. Wenn dieses Formular angezeigt wird, ist der Prozess bereits gestartet und die Variablen sind mit den im Pool angegebenen Default-Werten initialisiert.

Seitenanfang

Groovy-Skripte

An ganz vielen Stellen in Bonita kann man Groovy-Skripte verwenden, um etwas zu berechnen, zu konvertieren etc. Beispiele, wo dies möglich ist:

• In einem eigenen Konnektor „Skript>Groovy“
• Bei fast allen anderen Konnektoren kann man den Output ebenfalls mit Hilfe eines Groovy-Skriptes verarbeiten und dann einer Variablen zuordnen
• In Dialogen bei den einzelnen Interaktionselementen unter „Daten“ bei der Angabe von Anfangswerten und beim Ausgabevorgang
• Bei jedem Task unter „Vorgänge“. Dort kann man bei Beendigung des Tasks ein Groovy-Skript ausführen und den Rückgabewert einer Variablen zuweisen.
• An anderen Stellen, immer dort wo neben einem Feld ein kleiner Bleistift ist, erhält man durch Anklicken des Bleistifts die Möglichkeit, ein Groovy-Skript anzulegen.

Wenn man Java kann, ist die Erstellung eines Groovy-Skriptes ganz einfach, denn Groovy erweitert Java nur. Normaler Java-Code kann ohne Probleme verwendet werden.
Für ein Groovy-Skript muss man in Bonita immer einen Namen eingeben. Da er in den Eigenschaftsdialogen bei der Zuordnung angezeigt wird, sollte er beschreiben, was das Skript tut bzw. welches Ergebnis es erzeugt.

Im Skript selbst kann man auf die Werte alle Variablen aus dem Prozess (aber auch z. B. lokale Variablen aus dem Task) zugreifen (über „Prozessvariable wählen …“ auswählen, oder direkt den Variablennamen eintragen). Daneben gibt es ein paar „bereitgestellte Variablen“, z. B. die ProcessDefinitionID u. ä, die man verwenden kann, wenn man Methoden des Bonita API nutzt.

Wichtig: Eine Änderung der Werte der Prozessvariablen in dem Skript hat keine Auswirkung auf die Werte der Prozessvariablen im Prozess außerhalb des Skripes! Es handelt sich also immer um einen Call by Value – und zwar unabhängig davon, ob es sich um einfache Datentypen oder aber Objekte, Arrays, Listen o. ä. handelt.

Um Werte von Prozessvariablen zu ändern, muss man den betreffenden Wert am Ende des Skriptes zurückgeben (nach Java-Syntax mit „return“, in Groovy kann man return auch weglassen und nur den Wert oder die Variable hinschreiben) und in dem jeweiligen Dialog der betreffenden Prozessvariablen wieder zuweisen. Schließlich muss man unter dem Skript noch den passenden Rückgabetyp eintragen, der dann auch dem Typ der Variablen entsprechen muss, der das Skript-Ergebnis zugewiesen wird. Beim Groovy-Konnektor ist automatisch „java.lang.Object“ eingetragen, was man auch nicht ändern kann. In diesem Fall ist man selbst dafür verantwortlich, dass der Typ des Skript-Ergebnisses derselbe ist wie der der Variablen, die den Wert aufnehmen soll.

Seitenanfang

Groovy-Skripte wiederverwenden

Möchte man Groovy-Skripte wiederverwenden, dann kann man diese unter „Entwicklung > Groovy-Skripte verwalten“ anlegen. Dabei muss man eine statische Methode definieren. Die betreffende Methode kann dann in jedem Groovy-Skript-Editor rechts oben unter „Kategorien > Benutzerdefiniert“ ausgewählt werden. Möchte man auf Inhalte von Prozessvariablen zugreifen, dann muss man diese als Parameter an die betreffende Methode übergeben.
Siehe auch http://documentation.bonitasoft.com/using-expressions-and-scripts#L101

Seitenanfang

Deployen und Ausführen

Der in der Standardinstallation integrierte Server wird durch „Ausführen“ oder „Portal“ gestartet. Bei „Ausführen“ wird zugleich der Prozess aus dem geöffneten Diagramm deployed und ausgeführt.

Dabei werden die Formulare des Prozesses zunächst außerhalb des Portals als reine Webanwendung angezeigt. Eingeloggt ist dabei automatisch der User, der in der Konfiguration unter „Authentifizierter Benutzer“ eingetragen ist. Der Prozess kann in diesem Modus solange durchgeführt werden, bis er von dem automatisch eingeloggten Benutzer aufgrund seiner Rechte nicht weiter ausgeführt werden kann. Anschließend kann man über den angezeigten Link ins Portal wechseln. Man kann aber auch schon vorher ins Portal wechseln und unter „Aufgaben“ seine anstehenden Tasks finden.

Den Link zur Ausführung außerhalb des Portals könnte man z. B. in eine Webseite integrieren, wo externe Benutzer (z. B. Kunden), die nicht mit dem Portal arbeiten, einzelne Schritte durchführen. Die anschließende Weiterverarbeitung kann dann von Mitarbeitern unter Nutzung des Portals erfolgen. Für Kunden u. ä. würde man natürlich den Link zum Portal aus den Formularen entfernen.
Das Deployment auf dem integrierten Server und der automatische Start mit „Ausführen“ ist nur für Testzwecke gedacht. Für eine produktive Anwendung würde man eine separate Server-Installation verwenden (auf Tomcat, JBoss oder einem anderen J2EE Server). Mit „Server>Build“ erzeugt man eine „.bar“-Datei, die man als Administrator ins Portal importieren kann („App-Verwaltung>Apps installieren“).

Falls nach „Ausführen“ nicht der Browser aufgeht, kann man seinen Browser unter „Voreinstellungen>Browser“ eintragen.

Im Portal kann man den nun deployten Prozess unter „App“ erneut starten.

Gelegentlich treten im Portal Probleme mit dem Login auf. Z. B. wird man beim Starten eines Tasks zum Login umgeleitet, oder man kann sich nicht mehr erfolgreich einloggen. In diesem Fall kann es hilfreich sein, den Cache des Browsers zu leeren.

Seitenanfang

Datenbank von Prozessen leeren

Wenn man möchte, dass beim Start des Servers („Ausführen“ oder „Portal“) kein Prozess und keine Prozessinstanz verfügbar ist, muss man unter Voreinstellungen>Datenbank „Datenbank beim Beenden bereinigen“ wählen. Dies ist insbesondere beim Entwickeln und Testen nützlich, weil nicht immer die ganzen zum Testen angelegten und gestarteten Prozesse im System bleiben, sondern man immer mit einem leeren System beginnen kann. Möchte man hingegen einen echten Betrieb simulieren, bei dem die Prozesse und die laufenden Prozessinstanzen auch nach einem Neustart noch vorhanden sind, so muss man das Häkchen entfernen.

Da man meistens die Organisation (Gruppen, Rollen, User) nicht neu veröffentlichen möchte, kann man durch das Häkchen bei „Standard-Organisation beim Starten laden“ dafür sorgen, dass sie trotz des Leerens der Datenbank am Anfang direkt wieder vorhanden ist.

Seitenanfang

Export und Import von Prozessen

Über Exportieren und Importieren können die Prozesse in der Modellierungsumgebung als .bos-Dateien (zip-Files mit definierter Struktur) gespeichert und ausgetauscht werden.

Wichtig (Datenverlust möglich): In einigen Bonita-Versionen gibt es manchmal ein Problem mit den .bos-Dateien. Beim Import behauptet Bonita, der Export sei mit einer alten, nicht kompatiblen Version erstellt worden. Dies scheint insbesondere bei Prozessen der Fall zu sein, die durch Duplizieren eines anderen Prozesses (oder einer anderen Version entstanden sind).

Wenn man den Diagramm-Namen vor dem Export ändert, funktioniert der Import oftmals wieder. Um sicherzugehen, sollte man jede .bos-Export-Datei testen, ob sie importierbar ist (in einer anderen Installation von Bonita). Auch ist sinnvoll von Zeit zu Zeit das gesamte default-Verzeichnis im Workspace-Ordner zu sichern (im Standardfall unter C:\BonitaBPMCommunity-6.x.x\workspace\default).

Seitenanfang

In das Log-File schreiben

Möchte man selbst in das Log-File der Bonita Engine schreiben, um z. B. Variablenwerte überprüfen zu können, kann man folgenden Code in einem Groovy-Skript verwenden:

import java.util.logging.Logger;
Logger logger= Logger.getLogger("org.bonitasoft");
logger.severe("This text is in the log ");

Das Log-File kann man im Bonita-Studio unter „Hilfe > Protokoll der Bonita BPM Engine“ öffnen.

Seitenanfang

Zugriff auf die Bonita-Datenbank

Möchte man selbst auf die Datenbank zugreifen, in der Bonita die Prozesse speichert, kann dies bei der Standardinstallation über folgende Zugangsdaten geschehen (Bonita 7.4 und höher):

• Verwendeter jdbc-Treiber: org.h2.Driver
• JDBC URL: jdbc:h2:file:<Installationsverzeichnis>\workspace\default\h2_database/bonita_journal.db
• Benutzername: sa
• Kein Passwort

Unter Bonita 6 war die URL  jdbc:h2:tcp://localhost:9091/bonita_journal.db;MVCC=TRUE;DB_CLOSE_ON_EXIT=TRUE;IGNORECASE=TRUE
In den ersten 7er-Versionen war es jdbc:h2:tcp://localhost:9091/bonita_journal.db

Die Datenbank mit den Business-Daten liegt im selben Verzeichnis und heißt business_data.db. Sie lässt sich aber auch direkt aus dem Bonita Studio heraus inspizieren: „Development – Business Data Model – Browse data (h2 console)“.

Seitenanfang
Zurück zur Downloadseite