Notice : OFBiz gave up on Workflow Engines. Shark was implemented last but never really used in OFBiz. Instead of using a Workflow Engine, OFBiz uses an Event Driven Architecture (EDA) and ECAs (SECA, EECA, MECA) are used in OFBiz to drive the Workflow. ECA is the acronym of Event Condition Action. SECAs are for Services (triggered on services conditions), EECA are for Entity (triggered on entities conditions), MECAs are for Mail.
The Open for Business Workflow Engine is based on the WfMC and OMG specifications. (See the related documents for information on these specs.) The Workflow Engine is a member of the Services Framework, and is tightly integrated with the Entity Engine. It uses the entities found in entitymodel_workflow.XML for definition information and entitymode_workeffort for runtime storage. All changes to a process or activity are persisted real-time. Therefore, the engine does not run in a thread, it is simply a group of APIs and common objects which handle the flow. When a change to the workflow is made, the engine then processes that change. When finished, the engine returns. Hence, if the application does crash, or the system reboots, the workflow will continue right where it left off upon restart.
The Workflow Engine is not designed for processing flow of a web site. This is a common misconception. Web site flow is controlled by the Control Servlet. Workflow is the processing of manual and automatic activities to fulfill a specific goal.
OFBiz Workflow Engine uses XPDL as its process definition language. This is an open standard, and very flexible. In cases where the XPDL spec does not specifically state or leaves the implementation up to the vendor, we have noted them in the section "XPDL Extensions," below.
There are a number of attributes the WfMC says is left to the vendor. Here we will document our extensions: (These are implemented as 'ExtendedAttributes')
ACTIVITY EXTENDED ATTRIBUTES
IMPLEMENTATION/TOOL EXTENDED ATTRIBUTES & ACTUAL PARAMETERS
<ActualParameter>expr:orderNumber=orderId</ActualParameter>will map the context attribute orderId to a buffered variable named orderNumber then if you did:
<ActualParameter>orderNumber</ActualParameter>the parameter orderNumber would be passed to the service with the value of orderId.
DEFAULT STARTING ACTIVITY
By default when a workflow is started, the first activity in the list is set as the default starting activity. This means that when a workflow is started normally, we will run the first activity first, then follow the transitions. This is the most common way to invoke a workflow. However, there may be times when the workflow should be invoked from a number of different starting points. In this case, the client API would be used to call the appropriate activity to begin. The transitions would follow from that point. Only activities with the 'canStart' ExtendedAttribute are allowed to initiate a workflow.
The client API for the OFBiz Workflow engine consists of a set of global services and a factory class. The factory class named org.ofbiz.workflow.WfFactory, can either create a new instance of a workflow component (process/activity/assignment) or it can locate an existing instance. Instances are stored in the WorkEffort entity and are loaded as necessary. The set of global services found in org.ofbiz.workflow.WorkflowServices are setup to make assigning, accepting and completing assignments/activities easier. It is not required to use these services, but it is highly recommended. You will want to review the JavaDocs for these classes.
The workeffort web application shows an example of a workflow web client. From this interface you can accept assignments which are currently assigned to your group/role and edit the state. Try http://localhost:8080/workeffort.
The combination of manual and automatic activities is what makes a workflow so powerful. The OFBiz Workflow Engine currently implements NO, ROUTE, TOOL:Procedure, and SUB-FLOW type activities. TOOL:Application type activities are not yet implemented but will be in a future release.
The current version of the OFBiz Workflow Engine does not implement LOOPS. These too will be added in a future release.
To use the workflow engine you must first have a process you wish to invoke. Design your process in XPDL format. Once your design is complete, import the XPDL file into the workflow entities. You can do this from the webtools web interface. After the workflow is imported it can now be made available for execution. The easiest way to invoke a workflow is to define it as a service. Create a service definition for the workflow process and set its engine-type to 'workflow'. From there you can start a workflow process just like running any other service.
We know this documentation does not go into much detail. And we apologize for that. However, we spend a most of our time writing the code base, so documentation doesn't get full attention. We realize the need for good documentation, but our resources are limited. If you or anyone you know is interested in helping The Open For Business Project by contributing time writing better documentation, please contact the e-mail address at the top of this document. Thank you.