Author: maaroufi
Publication Date: 3/8/2013 12:29
Inside FirstSpirit workflows are an important instrument to handle tasks automatically. In general scripts, which are started by workflow-activities, are necessary for this automation.
This blogposting explains how to let a workflow start a deployment-schedule-task.
All examples, which are contained in this posting, are based on the default-release-workflow of FirstSpirit.
To start a schedule-task via a workflow-script the following steps are needed:
1. Create the schedule
2. Create the script
3. Extend the workflow
4. Try it!
That’s it. Easy, isn’t it? Now we are done and everything is fine. Next one…..
No, just kidding. Let’s take a closer look at the single steps.
Create the schedule
After opening the project properties a new default-schedule can be added inside the schedule-management. (If the schedule will be created inside the server-properties, the example of this blogposting won’t work!)
The new entry should be named as “deployment”. Furthermore it needs a generation and a deployment task in the “Actions”-tab.
Create the script
In the next step the script has to be created in the template store of the used FirstSpirit project. The code can be copied from here:
//!Beanshell
import de.espirit.firstspirit.access.AdminService;
import de.espirit.firstspirit.access.ReferenceEntry;
import de.espirit.firstspirit.access.ServicesBroker;
/////////////////////////////////////////////////
schedulename = "deployment";
scheduleEntry = null;
/////////////////////////////////////////////////
_project = context.getProject();
scheduleStorage = context.requireSpecialist(ServicesBroker.TYPE).getService(AdminService.class).getScheduleStorage();
allScheduleEntries = scheduleStorage.getScheduleEntries(_project); // get all ScheduleEntries of the current project
for (entry : allScheduleEntries) {
if (entry.getName().equals(schedulename)) { // search for the ScheduleEntry "deployment"
scheduleEntry = entry;
break;
}
}
if(scheduleEntry != null){
control = scheduleEntry.execute(); // Executing the deployment
control.awaitTermination(); // the workflow waits untill the schedule-task ended
}
else {
context.logError("The ScheduleEntry '" + schedulename + "' doesn't exist!");
}
context.doTransition("finito");
The script is very simple. It just gets all schedule-entries of the current project and searches for the one entry called “deployment”. This entry is executed. After the deployment ended the workflow goes on with the next transition.
Extend the workflow
At last the default-release-workflow has to be extended like this:
Between the last activity “AutomaticRelease” and the end-status “released” of the default-release-workflow a new status and a new activity were added. The name of the transition "Final" wasn't changed, because else it has to be changed in the script "finalRelease", too.
The new activity references the script, which was created in step two. In this example it was called “wf_deploy”. Furthermore the selection of the radiobutton “Execution” has to be changed to “Automatic”.
The last transition was called “finito” in this example. If the name is changed, it also has to be changed in the script at the last line:
context.doTransition("finito");
Try it!
Now all steps are done to start the schedule-task “deployment” with the extended workflow. It could be started in both FirstSpirit clients. Because the workflow waits until the deployment is done, it needs some time before it ends. It won’t appear a success-dialog at the end of the deployment or at the end of the workflow. The workflow ended when the workflow-element is released. The success of the deployment-task is displayed in the schedule overview inside the project properties.
Info: If a success-dialog should appear at the end of the schedule-task or when the workflow ended, this posting explains how it works.
NOTE: The script is just a small example how to start schedules with a workflow-script. Don’t use it in large projects, before you haven’t modified it! As it was said the workflow waits as long as the deployment-schedule-task ended. Imagine this deployment needs more than just a minute… !
Kommentare
10 Kommentare
Weltklasse! Genau dies benötige ich für eine PoC Präsentation nächste Woche, werde es gleich mal ausprobieren :smileyhappy:
Vielen Dank und weiter so mit diesen How-Tos, diese sind sehr hilfreich!
Viele Grüße
Markus
Hallo,
in meinem Use-Case müsste ich den Standard-Workflow "Datensatz freigeben" um die automatische Generierung erweitern.
Dieser sieht aber etwas anders aus, denn er endet direkt mit dem Freigabezustand.
Wie kann ich diesen Workflow so erweitern, dass
a) erst der Datensatz freigegeben wird
b) der Generierungsjob läuft?
Das Skript "finalRelease" einzubinden scheint hier nicht ganz zu passen, da es auf Seiten ausgelegt zu sein scheint.
Vielen Dank
Markus
Hallo Markus,
das sollte genauso funktionieren.
Ich hab es jetzt nicht ausprobiert. Aber wenn du zwischen die Schritte "Freigabe anfordern" und "Objekt freigegeben" bzw. "Freigabe prüfen" und "Objekt freigegeben" eine neuen Status und eine neue Aktivität (siehe auf dem Screenshot... entsprechend benannt) einfügst, der Aktivität das im Blogposting beschriebene Skript hinzufügst und die Aktivität automatisch ablaufen lässt, dann sollte das deine Frage beanworten. (Die Namensgebung der Transitionen ist dann zwar nicht mehr so schön, aber das lässt sich ja anpassen.)
Das Skript musst du natürlich von Hand anlegen. Es handelt sich dabei NICHT um ein bereits vorhandenes WF-Skript, wie "finalRelease".
LG Michaela
Hallo Michaela,
vielen Dank für deinen Vorschlag!
Dieser Workflow läuft zwar sauber durch, allerdings stimmt die logische Reihenfolge noch nicht. In diesem Fall wird erst generiert und dann erst freigegeben. Damit wird gerade die Änderung, für die der WF gestartet wurde, nicht bei der Generierung berücksichtigt.
Wie könnte man das Verhalten elegant umdrehen?
Das Häkchen "freigeben" lässt sich ja nur am Status vom Typ "Ende" setzen, so dass über diesen Weg keine weitere Generierung über den WF möglich ist.
Vielen Dank
Markus
Hallo Markus,
so ins Blaue vermutet, würde ich dann zusätzlich noch eine weitere Aktivität + Skript und einen weiteren Status hinzufügen. Ob das die schönste und eleganteste Lösung ist, kann ich dir allerdings nicht sagen.
An dieser Stelle würdest du jetzt in diesem Bsp noch das Skript "releaseentity" benötigen, dass dann den Datensatz freigibt (also das Äquivalent zu "finalrelease" für Seiten).
LG Michaela
Hallo Michaela,
ja, das war auch meine Vermutung!
Ich nehme an, dieses Skript "releaseentity" liegt noch nicht irgendwo vor, so dass ich es einfach übernehmen kann?
Zum selber schreiben fehlen mir leider die Skills :smileywink:
Viele Grüße
Markus
Hallo Markus,
taaadaa :smileywink:
************************************************************************************************
//!Beanshell
import de.espirit.firstspirit.access.store.contentstore.ContentWorkflowable;
content2 = context.getStoreElement();
workflowable = context.getWorkflowable();
entity = ((ContentWorkflowable) workflowable).getEntity();
content2.release(entity);
context.doTransition("triggerGeneration");
************************************************************************************************
Den Dank für das Skript bitte an Rouven richten. :smileyhappy:
Der zugehörige WF sieht so aus:
LG Michaela
Hallo Michaela,
besten Dank - jetzt funktioniert es wie gewünscht!!!
Viele Grüße
Markus
Hallo Michaela,
zunächst vielen Dank für die Blog-Beiträge. Die sind echt wertvoll, wenn man in die Modul-Entwicklung einsteigt.
Vielleicht kannst du mir an dieser Stelle auch bei einem Problem helfen, dass thematisch dem hier nahe kommt. Ich habe eine Workflow script (via executable class), dass einen generate-Task startet. Davor öffnet das Workflow script noch eine GUI (hinterlegt im Formular-Reiter des scripts) und verlangt eine Eingabe via CMS_INPUT_TEXT. Der generate-Task führt dann eine Teilgenerierung einer bestimmten XML-Datei durch. Nun soll die Eingabe aus dem Textfeld in die XML-Datei generiert werden. Ich weiß nur nicht genau wie ich die Information aus dem Textfeld an den Generate-Task übergeben kann und dann darauf im XML-Template zugreife. Geht das überhaupt?
Ich hatte dazu zwei Ideen, aber ich weiß nicht genau, ob das so umsetzbar ist.
1. Beim auslesen des Textfeldwertes schreibe ich diesen in irgendeine "Session", die ich dann via Template-Script im XML-Template wieder auslese ($CMS_RENDER(script:'gettextfieldinput')$)
2. Ich setze vor der Ausführung des generate-Tasks, an der Task-Instanz eine Variable mit dem Wert des Textfeldes. Dann schreibe ich die irgendwie ins Template ($CMS_VALUE('textfieldinput')$).
Oder habe ich evtl. eine viel einfachere Möglichkeit übersehen?
Viele Grüße,
Sebastian
Hallo Sebastian,
im Tab "Erweitert" einer Generierung lassen sich Variablen anlegen, denen ein Wert zugewiesen werden kann.
Die Übergabe einer Benutzereingabe durch das Skript an den Generierungstask ließe sich über diese Variablen realisieren, indem das Skript auf diese Variablen zugreift und ihnen die Eingaben des Benutzer zuweist, bevor die Generierung gestartet wird.
Ich vermute, dass dies Deiner zweiten Idee entspricht.
Ich hoffe, ich konnte Dir weiterhelfen. Solltest Du weitere Fragen haben, bitte ich Dich, diese im Developerbereich zu stellen, um hier eine Vermischung unterschiedlicher Thematiken zu vermeiden. :smileyhappy:
Viele Grüße
Michaela
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.