Wednesday, May 06, 2009

Using the Workflow Server

A number of people have enquired about the xProcess Workflow Server recently and whether they can download it from SourceForge and run it. Though you can download and build the source code (see instructions on the Wiki to find out how to do this - and which projects here), we’ve not included the Workflow Server in the pre-built packages for download. Instead we are supplying it as part of a support package for clients in order to ensure that we can put all the components in place for any specific implementation of workflow.

The xProcess Workflow Server runs on Tomcat and is designed to respond to events that occur within the xProcess Data Source (detected by the DataSourceMonitor) or in external systems (detected by custom Monitors). Typical uses for the Workflow Server are
  • to integrate with other systems, such as bug tracking systems, that are running in your environment
  • to notify users by email of changes to plans or processes
  • to update external systems with changes that have occurred in xProcess.
There are some useful blog articles (referenced below) that help understand more about the Workflow Server:
The last article in the list discusses the use of the in-built STD for definition the actions triggered by internal changes (e.g. sending notifications when the state of tasks, targets or resources change). Only this mechanism allows workflow mechanisms to be changed without writing Java code. However even this mechanism requires a significant amount of set up, for example to include email servers and to define OGNL actions, which are triggered on state changes. This is why it is best to download the source code itself if you want to really unleash the full potential of this feature of xProcess. You can build the Workflow Server directly, set up email servers and other configurations, and integrate with your own code for external system monitors.

Also included in the source code are a number of examples of workflow usage, including and integration with the “Flyspray” bug tracking system. When running, this automatically creates tasks to correspond with confirmed bugs in Flyspray, and also updates the status of the issues when the xProcess tasks are closed for example.
Post a Comment