All the administration procedures are executed by launching ant tasks declared in the ant file build.xml, for instance:
Administration scripts are however needed to call asynchrnous tasks:
- upgrading the index
- expiring and archiving tickets
- recalling postponed tickets
- feeding the helpdesk from misc sources
Main administration tasks
| Initializing the database | ant init-data |
| Upgrading the database | ant upgrade |
| Starting|stopping|restarting the application |
ant start|stop|restart |
| Updating the index | ant update-index |
| Rebuilding the index | ant rebuild-index |
| Unlocking the index | ant unlock-index |
| Archiving closed tickets | ant archive-tickets |
| Expiring non approved tickets | ant expire-tickets |
| Recalling postponed tickets | ant recall-tickets |
| Sending daily ticket reports | ant send-ticket-reports |
| Sending FAQ updates reports |
ant send-faq-reports |
| Feeding the helpdesk | ant feed |
 | Starting/stopping portlets Starting/stopping esup-helpdesk when the application is deployed as a portlet should not be done with the start/stop tasks. In this case, start/stop your portal, or better just the esup-helpdesk context. |
Setting up administration scripts
| This part shows how to set up administration scripts and launch asynchronous tasks for a quick-start deployment. These procedures must adapted for the other deployment modes (portlet et servlet). |
On a Unix system
We presume here that the project base is /usr/local/helpdesk.
Administration scripts
The file env.sh contains the current version:
The script helpdesk.sh is used to run synchrnous tasks (start, stop, deploy, ...):
The script helpdesk can be installed in the folder /etc/init.d for the application to automatically start when the server boots:
Le redémarrage de l'application pourra ainsi se faire en appelant :
| Démarrage automatique de l'application au boot Pour faire en sorte que l'application démarre automatiquement au boot du serveur, utiliser le programme chkconfig. |
Asynchronous tasks
Calling asynchronous tasks is needed for:
- updating the index
- expiring and archiving tickets
- recalling tickets
- sending daily reports
The script helpdesk-cron.sh is used to call asynchronous tasks (update-index, archive-tickets, recall-tickets, ...):
Asynchrnous tasks are called periodically thanks to the following lines in the file /etc/crontab:
On a Windows system
 | TODO Any Windows deployer? |
1 Comment
comments.show.hidemai 03, 2010
Vincent Bonamy
When we use batch calls with the helpdesk-cron.sh script, for each batch command the esup-helpdesk application is loaded in batch mode so that the Indexer (for example) can update the lucene index.
For the Indexer, the indexation of some new tickets can be quick (indeed, if there is no new ticket, the execution time is about 1 second) but the call of the batch command itself with helpdesk-cron.sh script can be about 10 seconds because of the loading of all the spring beans (and during this 10 seconds, the CPU is near to 100% of use).
* So the best is in fact to call this script on a dedicated server for this kind of jobs.
* But if we have only one server for esup-helpdesk, the best can be to call this cron tasks directly from the esup-helpdesk already loaded on tomcat server.
Indeed we can make this easily with Spring + Quartz !http://static.springsource.org/spring/docs/current/spring-framework-reference/html/scheduling.html#scheduling-quartz
To use Quartz instead of Cron, you can modify Batch.java so that required batch methods are public :
* public static void updateIndex(final boolean rebuild)
* public static void archiveTickets() {
* public static void expireTickets(final boolean alerts) {
* public static void recallTickets() {
* public static void sendTicketReports() {
* public static void sendFaqReports() {
Next we can add quartz jobs with spring : http://static.springsource.org/spring/docs/current/spring-framework-reference/html/scheduling.html#scheduling-quartz
Below the content of a cron.xml file defining spring beans so that esup-helpdesk tasks work : you can import cron.xml in properties/applicationContext.xml.
Don't forget to add quartz.jar (for example quartz-1.8.0.jar) in webapp/WEB-INF/lib/ and redeploy.http://www.quartz-scheduler.org/