Let a Workflow-Script start a Schedule-Task
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… !
10 Comments