Grundregeln und Restriktionen für BPM in CURSOR-CRM

CURSOR-CRM ist eine Software, die eine auf BPMN basierende Prozess-Maschine enthält

Hierbei wird auf den bisher noch nicht vollständigen BPMN-Funktionsumfang der Activiti-Prozess-Maschine zurückgegriffen, die um CURSOR-CRM spezifische Funktionen erweitert wurde. Der genutzte BPMN Umfang wurde auf die Funktionen beschränkt, die notwendig sind, um Arbeitsabläufe in CURSOR-CRM zu automatisieren. Dies ist eines der Werkzeuge, um Prozesse in CURSOR-CRM abzubilden, zu automatisieren und zu optimieren.

CURSOR-BPM - die Schaltzentrale des BPM-Administrators

Die Administration und Verwaltung der in CURSOR-CRM verwendeten BPMN-Prozesse ist nur über den Rich Client möglich. Modellierung, Instanz-Verwaltung und Laufzeitüberwachung der Prozesse sind nur dort möglich. Die Laufzeitumgebung erlaubt aber eine parallele Ausführung und Abarbeitung der Prozesse in Rich Client und im Web Client gleichermaßen. Es ist problemlos möglich, für die Arbeit in den verschiedenen Prozessphasen den Client beliebig zu wechseln. Eine Bearbeitung von Benutzer-Aktionen im Rahmen einer Prozessausführung ist nicht via App möglich.

Es gilt zu beachten, dass zur Veröffentlichung eines Prozesses nicht die vollständige Lauffähigkeit geprüft und gewährleistet werden kann. Es obliegt in der Verantwortung des Prozess-Architekten, dies durch Prüfungen auf dem Testsystem sicherzustellen.

Interaktion und Prozesslogik entsprechend der JavaEE 3-Schichten-Architektur

Die Prozess-Verarbeitung folgt folgendem Grundsatz: Benutzerinteraktion erfolgt auf dem Client, die Datenverarbeitung und Berechnung erfolgen auf dem Applikationsserver und die Datenhaltung erfolgt in der Datenbank. Der durch die Prozess-Maschine gesteuerte Prozessablauf findet auf dem Applikationsserver statt. Der CRM-Daten und Prozess-Daten werden in separaten Tabellen unabhängig voneinander in der Datenbank gespeichert und können durch Einstellungen am Prozess miteinander synchronisiert werden.

Jede schreibende und lesende Operation findet in einer Transaktion statt, die durch den Applikationsserver gesteuert wird. Die Transaktion beginnt, wenn die Kontrolle an den Applikationsserver übergeben wird (Starten, Weiterführen eines Prozesses) und endet, wenn der Anwender wieder die Kontrolle erhält oder der Prozess endet. Die Transaktion wird durch jeden BPMN-Wartezustand (Benutzeraktion, Zeitgesteuertes Ereignis oder eingehendes Zwischenereignis) unterbrochen. Die Transaktionsdauer ist durch den Applikationsserver auf fünf Minuten begrenzt. Für die Massendatenverarbeitung muss die Ausführung auf mehrere Transaktionen verteilt werden (vgl. zeitliches Zwischenereignis oder asynchroner Prozess-Aufruf).

Für Lesende Operationen auf größeren Datenmengen kann die Grenze von 10000 Datensätzen nur durch eine Server-Konfiguration erhöht werden. Diese Einstellung erfordert aber auch einen höheren Ressourcenverbrauch und entsprechend angepasste Speichereinstellungen im Applikationsserver und Client.

Prozess-Logiken in Groovy abbilden

Als Prozess-Skript-Sprache wird Groovy eingesetzt. Groovy ist eine mächtige Skriptsprache, die den java-Standard um einige Programmier-Konstrukte erweitert. Einige davon sollten aber nicht eingesetzt werden, da sie den Ressourcen-Verbrauch der java-Laufzeitumgebung sowie die Performanz negativ beeinflussen können oder den Regeln der java-EnterpriseEdition widersprechen:

closure: Methoden als Variablen sollten nicht verwendet werden. Hierfür wird es eine Skriptbibliothek geben.
generierte Klassen: groovy erlaubt es Klassen und Objekte zur Laufzeit zu erstellen und zu kompilieren. Ohne Cache und ohne Aufräum-Mechanismus kann dies zu Problemen in der Laufzeitumgebung führen.
direkter Datenbankzugriff: java erlaubt es direkte Datenbankverbindungen herzustellen. Dies ist nach der javaEE-Regeln verboten und kann zu Datenbank-Deadlocks führen.
kundenspezifische Dritt-Bibliotheken: Es ist möglich in CURSOR-CRM auf Dritt-Bibliotheken zuzugreifen und diese auch in BPM-Prozesse einzubinden. CURSOR übernimmt keine Gewährleistung für diese Funktionen und deren Effekte.

Empfehlung zu Groovy

Um die Skripte einheitlich lesbar zu halten, empfiehlt sich die Verwendung der Java-Syntax, da Groovy verschiedene Syntax-Erweiterungen erlaubt, die Dritte ggf. nicht direkt verstehen. Dies erleichtert die spätere Nacharbeit durch Kollegen bzw. den Kunden.

Prozessmasken-Design konform für die Web Client Nutzung

Die Web-Client-Masken werden aus den im GUI-Builder erzeugten Masken im XML-Format generiert.

Zur Vermeidung von Fehlern im Web Client müssen die Namen jedoch folgendem regulären Ausdruck genügen:

[A-Za-z][A-Za-z0-9_.]* (Beginnt mit einem ASCII-Buchstaben (keine Umlaute) und wird gefolgt von beliebig vielen ASCII-Buchstaben, Ziffern oder den Zeichen Unterstrich oder Punkt (keine Leerzeichen)).

Warnungen im Maskendesign werden in der Protokoll-Datei (WebMaskBuilder.log) zusammen mit der Webmaske als .xhtml-Datei vermerkt. Die Dateien finden sich im temporären Verzeichnis des CRM Clients.

Folgende Element bzw. Eigenschaften werden auf dem Web Client noch nicht unterstützt:

Panel: 'Rahmen anzeigen' und 'Überdeckt Hintergrund'
Schalter: 'Kontextmenü'
Masken-Report: 'Toolbar anzeigen' und 'Rahmen anzeigen'
Web-Komponente: 'Navigation erlaubt'
Radio-Buttons

Unterstützte Datenbanken

Die Process Engine Activity unterstützt nur Oracle und MSSQL. Damit ist CURSOR-BPM ebenfalls nur mit diesen beiden DBMS freigegeben und nicht funktionsfähig mit allen übrigen DBMS, insbesondere nicht mit DB2 (AS400) und Informix.

Maximale Skript-Größe

Groovy und Java erlauben es nicht unendliche große Skripte zu erstellen. Eine Grenze für die Größe einer einzelnen Methode liegt bei 65535 byte. Das Problem tritt dann zu Tage, wenn ein Groovy-Skript nicht in einzelne Methode unterteilt wird. Für Ausführung des Groovy-Skripts wird eine Java-Klasse geniert und kompiliert. Verwendet man keine Methoden im Skript, so wird das Skript als eine große Methode in die generierte Klasse verpackt. Sind dies über 1000 Zeilen, so kann es schnell zu diesem Fehler führen:

CODE

MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large!

Daher sollte man lange Code für die Übersichtlichkeit und Wartbarkeit in mehreren Methoden aufteilen.