Erweiterung von Workflows mit groovy Prozessen


#1

letzte Woche habe ich das Thema angesprochen. @metasnw meinte, es wäre für andere im Forum auch von Interesse. Es geht um Geschäftsprozesse (BP) allgemein und die Workflow engine im package org.compiere.wf im Besonderen.
Wer sich zum Thema Workflow (wf) einlesen will, den verweise ich auf den Wikipedia-Artikel, und zum Vertiefen das activiti-Handbuch. Eine Übesicht der BPM-Notation ist hier.

Stichworte ohne Vertiefung:

  • Activities/Aktionen werden im BP grafisch als Rechtecke dargestellt, sie werden auch Knoten oder wf-Schritte genannt
  • Tasks sind elementare Aktionen, die durch Personen “User Task” ausgeführt werden (Rechner einschalten), oder automatisch ablaufen (“Auftrag fertigstellen” in metasfresh)
  • der typische Dokumenten-wf in mf/ADempiere beinhaltet die Belegaktionen Prepare und Complete

Hier ist eine mögliche Erweiterung des typischen Dokumenten-Workflows beschrieben. Zwischen Prepare und Complete wurde ein Prozeßschritt p definiert, der unter bestimmten Bedingungen ausgeführt wird:

p ist als AD_Prozess definiert und muss als Klasse implementiert werden. Das bedeutet, dass die wf-Anpassung eine Erweiterung von metasfresh nach sich zieht, da compiliert werden muss. Geht es auch anders?

  • Knoten in Workflow, typischerweise kennt man “vorbereiten” und “fertigstellen”, können auch ganz normale AD_Prozesse sein, wie oben gezeigt
  • AD_Prozesse (die mit dem Rädchen) können in java oder in einer script Sprache, etwa groovy, implementiert werden, siehe hier
  • die übliche Aussagelogik sagt: dann können goovy scripte auch als Knoten im Workflows definiert werden
  • der grosse Vorteil einer script-Implementierung ist, dass für die wf-Änderung die metasfresh Applikation nicht neu kompiliert werden müßte. Die scripte werden in die DB kopiert und zur Laufzeit übersetzt und ausgeführt. Wow!

Die Logik gilt für mf leider nicht, denn der Start eines AD_Prozesses (mit Rädchen ) ist anders implementiert als der Start eines AD_Prozesses als AppsProcess. Das ist schade, denn die Vorteile sind nicht zu übersehen.
Daher mein Vorschlag, die Stelle in MWFActivity und die Abhängigen anzupassen:

public class MWFActivity extends X_AD_WF_Activity implements Runnable {
...
	private boolean performWork (Trx trx) throws Exception {
           ...
        		/******	Process      ******/
        		else if (MWFNode.ACTION_AppsProcess.equals(action)) {
                             ...  // hier Änderungen notwendig
                        }
}

#2

Den Ausführungen des Kollegen kann ich nur zustimmen.
Gerade durch das Erstellen / Customizen von Prozessen per Groovy kann metasfresh sich einen sehr großen Vorteil im Feld der ERP-Lösungen erarbeiten. Denn nicht jeder Berater draußen will bauen und dann deployen. Oft werden Prozesse draußen im Feld auf Zuruf implementiert. Und da ist bauen oft kontraproduktiv. Zumal es ja mit Groovy möglich ist, auf alle bestehenden Java-Objekte zu zugreifen.
Und gerade im Bereich von Satelliten-Anwendungen kann man so komplett auf Bauen verzichten, wenn man die betreffenden Prozesse in Groovy erstellen kann.