- Using code fragments to specify work is not really declarative: it does not only specify what should be executed but also how.
- By embedding the code in your process your are also usually linking your process to one specific environment. For example, creating a new personnel record is usually done differently in different locations / companies.
- If code fragments are used to communicate with external services, the process has no way of knowing this, which might result in errors in later stages. For example, a piece of code might be used to request the asynchronous execution of an external service, but the process might have been completed or aborted by the time the results return.
- It is usually difficult to test your process in a test environment without having to change the code (or making it a lot more complex), as the code usually refers to specific services and you don't really want to contact production services during testing.
Work item handlers are used to link abstract work item to the actual implementation that knows how to contact the specific external services. They must implement the executeWorkItem(WorkItem, WorkItemManager) method and signal the WorkItemManager upon completion (or abortion) of the work item, including possible results (as name-value pairs). These results can then of course be used in the process instance. Work item handlers need to be registered (at deployment or even at runtime) at the process engine. This allows us to for example to register a custom work item handler in test cases to simulate a specific environment.
The use of work items allows users to easily extend the power of the process engine themselves, by creating domain-specific work item nodes. The process designer supports the definition of different types of work items using a configuration file that defines the name, the parameters, the results and possibly a custom icon for the work item.
We have already created a small set of work items for common problems that can be used out of the box:
- Sending email
- Logging messages
- Finding files on a file system
- Archiving files
- Executing system commands
We are working on adding more work items by default, like invoking a web service, integration with services on the JBoss ESB, etc. With the help of the community, we hope to extend this set of work items significantly so we can offer users a large selection of work items in different application domains.