Questions & Answers

[alexanderan]

Hallo zusammen,

ich muss innerhalb eines Freigabe-Workflows nach der finalen Freigabe durch den Redakteur noch ein größeres Skript hinterher laufen lassen.

Abhängig von dem Ergebnis des Skriptes sollen die entsprechenden Transitionen ausgeführt werden (zwei an der Zahl).

Damit der Redakteur nicht durch den Lauf des Skriptes am weiterarbeiten gehindert wird, möchte ich hierfür einen neuen Thread starten.

Klappt auch soweit. Allerdings kann ich aus dem neuen Thread heraus über die Methode doTransition auf dem WorkflowScriptContext (das wird dem Thread übergeben) nicht die gewünschte Transition ausführen. Es wird allerdings auch keine Fehlermeldung ausgegeben.

Ich hoffe hier kann mir jemand einen Tipp geben, woran es hängen könnte.

Viele Grüße
Andreas

[gockel]

Ein asynchrones Schalten des Workflows ist nicht möglich und auch nicht sinnvoll.

Man würde ja immer Gefahr laufen, dass der Redakteur den Javaclient schon schliesst, während die asynchrone Aktion noch läuft.

Man sollte sich hier also ganz grundsätzlich die Frage stellen, ob für die Entscheidung welche Kante geschaltet wird, wirklich die langandauernde Aktion notwendig ist und vor allem warum die Aktion so lange dauert.

Um den Redakteur für den Zeitraum nicht vor einer grauen Wand (scheinbar eingefrorenem Client) warten zu lassen kann man natürlich auch einen Thread starten. Auf dessen Beendigung muss man dann aber innerhalb des Skriptes warten. So hat man z.B. die Möglichkeit eine Progressdialog anzuzeigen.

[VuuRWerK]

Ich möchte ganz gern mal diesen Thread wiederaufgreifen, auch wenn dieser mittlerweile 2.5 Jahre alt ist, jedoch habe ich ein ähnliches Problem wie der Thread-Starter.

Das Problem warum ich auf einen Thread zurückgreife um das "warten" auf die Abarbeitung eines ScheduleTasks zu handhaben ist der Tatsache geschuldet das der GenrierungsTask in diesem Fall sehr lange dauert und man dem Nutzer das warten und vorallem das blockieren der GUI nicht zumuten will. Wenn ich aber nicht warte bleibt das StoreElement immer in einem "komischen" lock-Zustand. Warum komisch? Das Objekt wird bei Aufruf von "Search -> Locked objects (session)" bzw. "Search -> Locked objects (server)" als "locked" angezeigt. Und auch ein bearbeiten ist nicht möglich da immer noch gelocked durch den Benutzer. Jetzt habe ich mitbekommen das dieses Verhalten nicht auftritt wenn man den generierungsTask abwartet und dann den Workflow abschließt.

Was an sich ja schon komisch ist, ist die Tatsache das ich das Objekt in einem "lock"-Zustand belassen muss da ich sonst immer bei den "Aufräumarbeiten" (nachdem mein Modul verlassen und Workflow beendet wurde!) diese IllegalStateException bekomme in welcher bemängelt wird dass das Element nicht gelocked sei. Ich bin ehrlich, so ganz durchblickt habe ich das noch nicht, ging aber immer davon aus das nach besagten "Aufräumarbeiten" das Element dann wieder "entlocked" wird. Scheinbar aber nicht, sonst würde es nicht in den obigen 2 Aufrufen erscheinen.

So, und wie schon eingehend vom ThreadStarter beschrieben lässt sich jetzt der Workflow nicht beenden weil das "doTransition" in einem anderen Thread (dem "WarteThread") ausgeführt wird.

Ich hoffe mir ist noch zu helfen

Grüße

Christian

[Peter_Jodeleit]

Ich hoffe mir ist noch zu helfen

:smileylaugh:

Ich versuch es mal: Muss der Workflow denn wirklich "auf die Abarbeitung eines ScheduleTasks" warten? Anscheinend wird ja sowieso nur auf das Ende gewartet - der Task ist es aber egal, ob jemand darauf wartet oder nicht - durchgeführt wird sie auf jeden Fall..

[VuuRWerK]

Also, eigentlich muss man nicht drauf warten. mir war nur eben aufgefallen wenn man es macht und danach den Workflow via

context.doTransition ("Final");

beendet, dass das Element nicht mehr in diesem "ominösen" Lock-Zustand verbleibt sondern ordnungsgemäß "unlocked" ist. Wartet man nicht, startet den GenerierungsTask und beendet dann den Workflow muss man das Element in einem "Unlocked"-Zustand belassen (da sonst IllegalStateException geworfen wird welche es bemängelt dass das Element nicht gelock ist) und nachdem auch die Generierung durch ist bleibt das Element weiterhin "locked".

Grüße

Christian