Workflow deployment

This section describes some deployment and management topics concerning workflow.

jBPM persistence (database tables)

jBPM stores all its persistent state in database tables. These tables are installed in the same database as those of the Daisy repository server. This avoids the work of setting up an additional database, and means no extra effort is required for backup.

The database tables are automatically created when the repository server starts up for the first time. After creation, this fact is recorded in the daisy_system table by adding an entry named jbpm_schema_version containing the jBPM version number. Since creating the schema can take quite some time, a warn message is printed to the log before and after doing it, and also to standard out. To force the recreation of the jBPM tables, drop all tables whose name starts with "JBPM_" and execute this statement on the database:

delete from daisy_system where name = 'jbpm_schema_version'

jBPM uses hibernate for persistence. When using MySQL, the created tables are InnoDB tables (this is achieved by configuring an appropriate hibernate dialect), which is important to guarantee consistency of the tables. The database connections for hibernate are taken from the same connection pool as used by the rest of Daisy.

Deployment of default/sample process definitions

When the jBPM tables are first created, Daisy will also deploy some default (or sample, if you wish) processes.

The source for the samples can be found in the Daisy source tree at:

services/workflow/server-impl/src/processes

or in the .zip files embedded inside daisy-workflow-server-impl-<version>.jar.

It is possible to trigger re-installation of the sample workflows through the Admistration console of the Daisy Wiki (and hence through the Daisy Work flow API). This can be useful when installing a new Daisy version.

The “workflow” user

When installing Daisy, a special user called “workflow” is created. This user can be used to access the Daisy repository in process definitions, i.e. for when processes need to retrieve or update information in the repository. This user is required to have the Administrator role. The user to be used as workflow user is configured in the myconfig.xml.

When workflow is not available

If you see an error like the following:

Received exception from repository server.
Extension named "WorkflowManager" is not available.

it is likely caused by the fact that the workflow user (see previous section) is not configured correctly.

Notification mails

Task URL

In the task assignment notification mails, an URL to the task is included. This URL is configured in the myconfig.xml (which is located in <daisy data dir>/conf) and is by default the following:

<taskURL>http://localhost:8888/daisy/${site}/workflow/performtask?taskId=${taskId}</taskURL>

The variable ${site} contains the value of the daisy_site_hint process variable, if it is available.

Mail templates

The mechanism to load mail templates uses a fallback system allowing a mail template to be loaded from different locations. The default mail templates are included inside the workflow implementation jar, but it is possible to replace this with custom versions. Mail templates are also locale-dependent, using a fallback system similar to the Java resource bundles. The mail template language is Freemarker.

The locations for loading mail templates are configured in the myconfig.xml, the default configuration is as follows:

<mailTemplates>
  <!-- built-in templates (loaded from the classpath) -->
  <location>resource:/org/outerj/daisy/workflow/serverimpl/mailtemplates/</location>
  <!-- custom templates in the datadir -->
  <location>${daisy.datadir}/templates/workflow/</location>
</mailTemplates>

Process cleanup

Daisy itself does not perform any cleanup of finished or stalled processes. Everything is kept forever until explicitly deleted.