Activiti BPMN Integration

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

Table of Contents

• 1 Required Changes to Activiti
  
  
  
  • 1.1 Outstanding
    
    
    
    • 1.1.1 Process/Task Instance Timestamps
    
    
    • 1.1.2 Database Foreign Key Compatibility
    
    
  
  
  • 1.2 Completed
    
    
    
    • 1.2.1 ProcessDefinition Structure
    
    
    • 1.2.2 Task Persistance
    
    
  
  


• 2 Topics for Discussion
  
  
  
  • 2.1 BPMN Transitions in Alfresco
    
    
    
    • 2.1.1 Problem Description
    
    
    • 2.1.2 Discussion
    
    
    • 2.1.3 Resolution
    
    
  
  
  • 2.2 The Start Task
    
    
    
    • 2.2.1 Problem Description
    
    
    • 2.2.2 Discussion
    
    
    • 2.2.3 Resolution
    
    
  
  
  • 2.3 Hiding Public Fields on Workflow DTO's
    
    
    
    • 2.3.1 Problem Description
    
    
    • 2.3.2 Discussion
    
    
    • 2.3.3 Resolution
    
    
  
  

Required Changes to Activiti

Outstanding

Process/Task Instance Timestamps

It would be good to record the time and date when a ProcessInstance starts and ends. Ideally it should be possible to search for process instances based on these timestamps.

Similarly it would be useful to record when a task was started and to be able to set a task 'Due Date' which can also be searched on.

Joram: the official BPMN spec doesnt have the notion of a duedate. Do you want to specify it in the process definition or programmatically?

Nick: I would store the due date programmatically. It could either be a property on the task instance or it could just be an execution variable. In either case the important point is that it must be possible to do searches based on the due date. E.g. Get all tasks due on this date, get all tasks due before this date, get all tasks due between date 1 and date 2, etc.

Joram: If stored as a process variable, querying is already possible (<property name='dbSchemaStrategy' value='create-drop' />           
Currently we have create-drop and check-version in the DbSchemaStrategy interface. However, internally we also allow 'create-if-necessary' to be used. In the future (5.0+), we will have support for upgrading the database schema.

Nick: I think this is something different. We wanted a standalone DB deployer/patcher that could be called without needing to start up the ProcessEngine.

Joram: Ok, that is no problem.

Tom: You can create your main method, build a ProcessEngineConfiguration (with the ProcessEngineBuilder or with the ProcessEngineFactoryBean) and then obtain the DbSqlSessionFactory. Then the schema methods are available on that object. (so you don't even need to build the process engine)

Database Foreign Key Compatibility

The foreign key FK_TASK_PROCDEF and possibly others clash with old JBPM3 foreing keys. These foreign keys should be re-named to something that doesn't clash such as FK_ACT_* (e.g. FK_ACT_TASK_PROCDEF). This change is required by Alfresco as it will deploy both the JBPM and Activiti schemas together.

Completed

ProcessDefinition Structure

It would be very useful to expose the structure of process definitions so that the composition of the nodes and sequence flows can be determined. The primary user case for Alfresco currently is to determine the id of the start event. However, it would also be useful in the future to identify the id, name, type and description of all nodes in the process definition so that they may be exposed through the Alfresco API.

Joram: TBD when Tom is back. We've got this request on the forum a couple of times too.

Joram: What is the use case? Why do you need the start event id wen you already have the startFormKey ?

Nick: Two reasons: Firstly, the Alfresco WorkflowService API exposes the notion of a WorkflowNode which is equivalent to a node int he ProcessDefinition. This node has properties like name (equivalent to id), title (eq name), type (eq tag type: task, gateway, etc) and description. Since we have exposed this information in the past it would be good to continue providing it for backwards compatibility.

The other reason is that if no activiti:form attribute is specified, then the key used to find the Workflow Task Definition could default to the start event id.

Tom: Afaict this is functionality not for Alfresco but for users. Alfresco Workflow API should only target functionality that is needed by Alfresco. External users should use the Activiti API directly. 

Task Persistance

It may be required to persist a fake task instance in the Activiti DB to represent the start task. Is this currently possible in Activiti? Could it be made possible?

Joram: It is possible in Activiti to create a standalone task (ie one that is not attached to any process instance).
I'm not sure if it is possible to add a standalone task to an existing execution (without hacking at least, I'm sure it can be made working).
Is the start task a concept that can't be changed in the UI? Ie when running Activiti can't the start task be skipped (which is nicer for the users)?

The other question we have is about persisting the start task instance. If possible it would be good to be able to create a task instance, store the initialization variables in it and save it to the Activiti DB. The reason for this is that our client UI (and possibly other customer UI's) look up the start task using getTaskById() and then display the task in a standard TaskForm. This is how we currently display the historical data of the params used to initialize the process instance. The important point is that we re-use the TaskForm UI component, so we want to keep that data in a Task format if possible.

Joram: Currently, process variables are stored on execution level, not on tasks. So unless the task is part of the process definition, this approach is hard to do (with the current state of the codebase). If a task is required by Alfresco at the beginning of a process, then this might be OK.
However, I'm actually more in favour of using the history data in the database for this purpose (its on the roadmap but not yet implemented - but we can always prioritize). Would that work? Would it be able to make that compliant with the Task Format?

Nick: OK it sounds like the 'fake task' approach just isn't feasible, so we will just use the HistoryService to find the parameters passed in when the ProcessInstance was created. I believe this feature has not been implemented yet and it is now a blocker for me so can you do it ASAP? Thanks.

Tom: I'll look at it in the coming days and get back to you with a more concrete planning.

Topics for Discussion

BPMN Transitions in Alfresco

Problem Description

Alfresco assumes that a given task is directly linked to a set of possible transitions and allows the user's to pick a specific transition fromt he list of available transitions. BPMN has a much more loosely coupled relationship between tasks and transitions. Task nodes do not directly control transitioning, instead this is controlled by a different node called an Exclusive Gateway. The gateway will have mutliple transitions associated with it. It evaluates an expression associated with each transition and selects the first transition whose expression evaluates to true.

Tasks can be used to control which transition is selected by settign variables to control which expression(s) evaluate to true. This mechanism allows for the Gateway node to be at any arbitrary position downstream of the controlling Task node.

Discussion

• We could place a restriction on what process definitions are supported. There should be a specific 'pattern' for the process definition task/gateway combination. Firstly, the gateway should immediately follow the task node. Secondly, the task shoudl set some variable with an easily distinguished name (e.g. #task name#TransitionResult) and the expressions associated with the transitions should simply be direct comparisons (e.g. 'reviewTaskTransitionResult=='approve').          
  
• Alternatively Activiti might directly support the notion of associating a task node with a gateway node. New Activiti XML tags could be created to implement this behaviour.
  

Resolution

Alfresco will not directly support the notion of multiple transitions associated to a task. Instead there will be a single default ('Next') transition.

In the Forms UI by default there will only be a single button to select from and the field(s) used to determine transition flow will not be distinguished from any other data field. As possible future work a new Form Control type might be introduced (ActivitiTransitionButtonControl ?) allowing users to identify data used in transitions and distinguish it from other form data, possibly using the transition button mechanism currently used for jBPM Forms.

The Start Task

Problem Description

Alfresco has the notion of a Start Task which is used to capture various data used to initialize a workflow instance. The Start Task Definition is useful for defining what variables are required/optionally available when starting a given workflow. The Start Task Instance is used to store what those initialization parameters were and this information is used by the Share Workflow UI.

Discussion

• The simplest way to implement this is to require that every ProcessDefinition should have a Task Node immediately after the Start event which represents the Start Task. This would be equivalent to how this issue was handled for JBPM. Should the process definition be validated for this Start Task on deployment?
  
• An alternative approach is to have Activiti store the parameters used to initialize the Process Instance. These variables can then be retrieved at some later point. The Start Task Definition in the Alfresco Task Model would still be used to definie the metadatafor the initialization variables. This approach would probably require some changes to the WorkflowService API and the Share UI.          
  

Resolution

The Start Task Definition will be identified using the 'activiti:form' attribute on the start-event tag in the process definition. This can be obtained from an Activiti ProcessDefinition via the getStartFormKey() method.
To store the initialization parameters a fake WorkflowTask needs to be created/persisted. Most likely this will be implemented by storing a 'startTaskId' variable on the ProcessInstance. The actual initialization variables would be retrieved from Activiti via the HistoryService and aWorkflowTask instance would be constructed on the fly to hold these variables.
It is important that the fake start task be accessible via methods like getTaskById() so the start task Id will probably have some easily identifiable signature, such as starting with the word 'start'.

Hiding Public Fields on Workflow DTO's

Problem Description

Currently all WorkflowService DTO's expose their fields publicly. This is generally bad practice in Java so it would be preferable to restrict access to these fields and instead provide Getter methods for the fields.

Discussion

• Is there any reason not to deprecate public access to fields and switch fields to private in a later release?
  

Resolution

The public fields will be depracated and eventually hidden. Getter methods and constructors will be used to replace them. Eventually the DTO objects may be hidden behind interfaces.
Activiti
Engineering Notes