Questions & Answers

[renet]

Hallo zusammen,

aktuell sitze ich vor einem Corporate Content Problem, das ich vor kurzem übernommen habe. Und zwar wünscht sich der Kunde folgendes:

Wenn ein Paket in einem abonnierenden Projekt aktualisiert wurde, soll für jedes  geänderte oder gelöschte Element, das in der Struktur verlinkt ist (oder war), sowie für jedes neu hinzugekommene Element eine E-Mail an die Gruppe der Redakteure verschickt werden, die sie über diese Änderung informiert.

Nun wurde zur Realisierung ein Workflow entwickelt, der theoretisch für jedes geänderte/neue/gelöschte Element separat gestartet werden müsste. Das Paket ist so konfiguriert, dass der Workflow nach dem "Aktualisiert" bzw. "OK" Event (ich schätze eines von beidem reicht) des Pakets ausgeführt wird. In dem Workflow wird nun versucht über context.getStoreElement() auf das aktuelle Element zuzugreifen und über einen Abgleich mit der ImportInfo (ImportInfo.getUpdatedNode(Integer), ImportInfo.getNewNode(Integer), etc.) herauszufinden, ob es sich bei betreffendem Element um ein gelöschtes, hinzugefügtes oder aktualisiertes Element handelt. Für jeden Fall gibt es eine unterschiedliche Transition, die dann entsprechend ausgeführt wird.

Nun ist es aber so, dass der Workflow nach der Paket-Aktualisierung nicht für jedes Element ausgeführt wird, sondern nur 1x ohne ein StoreElement im Context (man kommt also nur über die ImportInfo an die Elemente dran).

Meine Fragen:

1. Gibt es eine Möglichkeit, das Paket bzw. den Workflow so zu konfigurieren, dass er für jedes bei der Paket-Aktualisierung angefasste Element ausgeführt wird?

2. Falls nicht, habe ich ja leider nicht die Möglichkeit, für jedes Element einen eigenen Workflow zu starten, weil sich Workflows z.B. nicht auf gelöschten Elementen starten lassen. (Oder?) Wie würde ich denn dann per API den Versand einer E-Mail mit entsprechendem FirstSpirit-Link an eine Benutzergruppe realisieren?

3. Oder gibt es eine ganz andere, elegantere Lösung für die obige Anforderung?

Vielen Dank für eure Unterstützung!

Viele Grüße

René Schubert

FirstSpirit Version: 5.0.319.57920 mit Corporate Content

[Anonymous]

Hallo René,

ich denke die eleganteste Lösung (jedoch nicht die einfachste bzw. umsetzungsschnellste) wird sein ein Modul zu erstellen, in dem die Klasse de.espirit.firstspirit.access.store.StoreListener erweitert wird und sich an den jeweiligen Store (z.B. PageStoreRoot) hängt, um bei Änderungen getriggert zu werden.

Diese Klasse bietet Methoden für alle von dir genannten Events (erstellen/ändern/löschen). Das Modul kann dann ebenfalls den Workflow starten und ihn über eine bestimmte Kante, je nach abgefangenem Event, weiterschalten.

Viele Grüße,

Nils

[renet]

Hallo Nils,

danke für den Hinweis. Das ist sehr interessant. Ich habe mir aber mal die Spezifikation des Interfaces angeschaut. Die zu implementierenden Methoden bekommen als einzigen Parameter nur ein StoreElement übergeben. Geht man nun davon aus, dass ich auf dem StoreElement (sofern zulässig) einen Workflow starten möchte, wie käme ich denn an den WorkflowAgent heran, um den Workflow zu starten?

Dasselbe Problem habe ich gerade beim Entwickeln innerhalb des Workflow Scripts. Dort komme ich über context.requireSpecialist(WorkflowAgent.TYPE); leider nicht an den WorkflowAgent heran, stattdessen bekomme ich eine Exception

IllegalStateException: No specialist found for 'de.espirit.firstspirit.workflow.WorkflowAgent$1@5bba98d5'

obwohl das ja eine Klasse ist, die durchaus existiert und in meiner IDE auch ohne Fehlermeldung importiert werden kann.

Noch mal zurück zu dem StoreListener: Mal angenommen ich hätte ihn fertig implementiert. Wie würde ich denn dafür sorgen, dass er automatisch beim Installieren des Moduls (oder spätestens vor dem Ausführen der Paket-Aktualisierung) an jeden von mir gewünschten Store in allen abonnierenden Projekten aktiviert wird?

Vielen Dank für die Hilfe!

LG

René

[Anonymous]

Hi René,

das Problem mit dem fehlenden WorkflowContext weiß ich spontan nicht zu lösen, vielleicht aber zu umgehen.

Ich stelle mir das so vor, dass die Implementierung des StoreListeners (z.B. als de.espirit.firstspirit.module.Service) sich in der zu implementierenden Methode installed() an die jeweiligen Stores hängt. Wird eine seiner Listener-Methoden getriggert, so werden 3 Dinge benötigt:

1. der zu startende Workflow,
2. das betreffende StoreElement
3. der UserService.

Der Workflow lässt sich auch über den StoreAgent (Typ: Store.Type.TEMPLATESTORE) mit der Methode getStoreElement(uid, type) finden. Dieses StoreElement lässt sich zu einem de.espirit.firstspirit.access.store.templatestore.Workflow casten und mit den Objekten über den UserService ein Task erstellen. Auf diesem Task lässt sich nun eine bestimmte Transition (doTransition()) starten, was im Prinzip den Workflow in Gang setzen sollte.

Hoffe ich. Hier komm ich wirklich ins Schwimmen, da die FirstSpirit-API meiner Meinung nach mehr aus Fallstricken besteht, als aus nachvollziehbaren Wegen.

Falls nicht wäre es vielleicht möglich die Mail einfach über das Modul selbst zu versenden, statt hier einen Workflow zu starten? Ich kenne den Workflow nun zwar nicht, aber es klang nicht so, dass dieser noch wesentlich mehr tut.

Viele Grüße,

Nils