Workflow module for the MOTECH platform
Below is documentation/explanation of some of the features and behavior of this module. The module should be built as a child project of the motech "modules" repository.
A workflow represents a sequence of commands (instructions) that are executed for workflow instances. The workflow consists only of a workflowTypeId and a list of workflow commands. It has some XML related annotations as I had originally started designing it with XML configuration in mind, but ultimately used Seuss programmatically to create it. XML configuration may still come into the picture.
The workflow command is a concrete class, but only because I was running into issues around having it an abstract class with Seuss. Any real commands should extend this class and override its execute method. The execute method accepts the workflow instance's data as a parameter and returns data (if any) that has been generated by that command.
Commands have a command type, command id, and whether they are synchronous or not. Right now asynchronous commands are not supported. These might be commands that are long running and the workflow should continue without them (or eventually come back to check on their success).
The platform service provider is the mechanism by which commands, which are not singleton services, retrieve various OSGi services. Each time a command is created, it is initialized with this platform service provider by the workflow manager.
The workflow manager is responsible for orchestrating workflow instances and their progression.
A work flow's custom data is modeled as followed:
Map<String, Map<String, Map<String, String>
The top level Map ties a specific workflow command to a Map<String, Map<String, String>
The second level Map ties a specific primary key to its data, Map<String, String>
The data is currently only one level deep, so that a primary key can be associated with arbitrary key-pair values
Example:
sqlQuery1: ["id1" : ["phoneNum" : "123456789", "language" : "en"], "id2" : ["phoneNum" : "000", "language" : "fr"]], sqlQuery2: ["id3" : ["name" : "Russell"]]
Where sqlQuery 1 and 2 are decoupled from one another. The goal is to provide data that can be used by subsequent commands, without the subsequent commands having any awareness of the features or behavior of its predecssor. The IVRCallCommand does not know that its data has been retrieved by an SQLQueryCommand, and it could have instead come from a WebServiceInvocation command or some other command designed to retrieve data.
It may be that the primary key tied to a map of data one layer deep is not enough, and that the data should be of arbitrary depth. This would be especially true in a generic web service where returned data has nested collections. For now the simplest approach has been adopted.
There are currently two custom commands: SQLQueryCommand and IVRCallCommand, each of which have helper classes packaged in the workflow module.
The SQLQueryCommand allows for generically querying a database, mapping its data into Motech, and storing that data as part of a workflow instance. This data can then be used in subsequent commands in the workflow.
The IVRCallCommand is used to schedule calls based on input data from elsewhere in a workflow instance. Right now it works as if the data it's using comes from a collection and iterates over the primary key.
This class has been used to extract data from the workflow instance's complex data structure.
MotechWorkflowDataService and WorkflowInstanceDataService are simple Motech data services for persisting workflows and workflow instances