activiti5源码与流程活动自动与手工触发执行例子.docx
Activiti源码分析Activiti的基础编程框架Activiti基于Spring，ibatis等开源中间件作为软件平台，在此之上构建了非常清晰的开发框架。上图列出了Activiti的核心组件。1.ProcessEngine：流程引擎的抽象，对于开发者来说，它是我们使用Activiti的facade，通过它可以获得我们需要的一切服务。2.XXService（TaskService,RuntimeService,RepositoryService.):Activiti按照流程的生命周期（定义，部署，运行）把不同阶段的服务封装在不同的Service中，用户可以非常清晰地使用特定阶段的接口。通过ProcessEngine能够获得这些Service实例。TaskService,RuntimeService,RepositoryService是非常重要的三个Service：TaskService：流程运行过程中，与每个任务节点相关的接口，比如complete,delete,delegate等等RepositoryService:流程定义和部署相关的存储服务。RuntimeService：流程运行时相关服务，如startProcessInstanceByKey. 关于ProcessEngine和XXService的关系，可以看下面这张图： 3.CommandContextIntercepter(CommandExecutor):Activiti使用命令模式作为基础开发模式，上面Service中定义的各个方法都对应相应的命令对象（xxCmd), Service把各种请求委托给xxCmd，xxCmd来决定命令的接收者，接收者执行后返回结果。而CommandContextIntercepter顾名思义，它是一个拦截器，拦截所有命令，在命令执行前后执行一些公共性操作。比如CommandContextIntercepter的核心方法： Java代码 1. public <T> T execute(Command<T> command) 2. CommandContext context = commandContextFactory.createCommandContext(command); 3. 4. try 5. /执行前保存上下文 6. Context.setCommandContext(context); 7. Context.setProcessEngineConfiguration(processEngineConfiguration); 8. return next.execute(command);/执行命令 9. 10. catch (Exception e) 11. context.exception(e); 12. 13. finally 14. try 15. /关闭上下文，内部会flush session，把数据持久化到db等 16. context.close(); 17. finally 18. /释放上下文 19. Context.removeCommandContext(); 20. Context.removeProcessEngineConfiguration(); 21. 22. 23. 24. return null; 25. 关于命令模式的细节说明，网上有很多资料，这里不展开。我只是想说一下我看到Activiti的这种设计之后的两点感受：1）一个产品或者一个项目，从技术上必须有一个明确的、唯一的开发模型或者叫开发样式（真不知道怎么说恰当），我们常说希望一个团队的所有人写出的代码都有统一的风格，都像是一个人写出来的，很理想化，但做到很难，往往我们都是通过“规范”去约束大家这样做，而规范毕竟是程序之外的东西，主观性很强，不遵守规范的情况屡屡发生。而如果架构师给出了明确的开发模型，并使用一些基础组件加以强化，把程序员要走的路规定清楚，那你想不遵守规范都会很难，因为那意味着你写的东西没发工作。就像Activiti做的这样，明确以Command作为基本开发模型，辅之以Event-Listener，这样编程风格的整体性得到了保证。2）使用命令模式的好处，我这里体会最深的就是 职责分离，解耦。有了Command，各个Service从角色上说只是一些协调者或者控制者，他不需要知道具体怎么做，他只是把任务交给了各个命令。直接的好处是臃肿的、万能的大类没有了。而这往往是我们平时开发中最深恶痛绝的地方。 4.核心业务对象（Task，ProcessInstance，Execution.):org.activiti.engine.impl.persistence.entity包下的类是Activiti的核心业务对象。它们是真正的对象，而不是只有数据没有行为的假对象，搞java企业级开发的人也许已经习惯了下面的层次划分：controller->service->dao->entity, entity只是ORMapping中数据表的java对象体现，没有任何行为（getter/setter不能算行为），对于面向对象来说，这当然是有问题的，记得曾听人说过这样的话“使用面向对象语言进行设计和开发 与 面向对象的设计和开发 是两回事”，面向对象讲究的是“封装”，“多态”，追求的是满足“开-闭”原则的、职责单一的对象社会。如果你认同上述观点，那么相信Activiti会让你感觉舒服一些，以TaskEntity为例，其UML类图如下：（图2：TaskEntity类）TaskEntity实现了3个接口：Task，DelegateTask和PersistentObject。其中PersistentObject是一个声明接口，表明TaskEntity需要持久化。接口是一种角色的声明，是一份职责的描述而TaskEntity就是这个角色的具体扮演者，因此TaskEntity必须承担如complete,delegate等职责。但是这里有些遗憾的是像complete这么重要的行为没有在3个接口中描述，因此“面向抽象”编程对于TaskEntity来说还没有完全做到。但至少Activiti告诉我们：1）牢记面向抽象编程,把职责拆分为不同的接口，让接口来体现对象的职责，而不用去关心这份职责具体由哪个对象实现；2）entity其实可以也应该是真正的对象。 5.Activiti的上下文组件（Context）上下文（Context）用来保存生命周期很长的、全局性的信息。Activiti的Context类（在org.activiti.engine.impl.context包下）保持如下三类信息： （图3：Context类）CommandContext：命令上下文，保持每个命令需要的必要资源，如持久化需要的session。ProcessEngineConfigurationImpl：流程引擎相关的配置信息。它是整个引擎的全局配置信息，mailServerHost，DataSource等。单例。该实例在流程引擎创建时被实例化，其调用stack如下图：（图4：ProcessEngineConfiguration的初始化）ExecutionContext：刚看到这个类感觉有些奇怪，不明白其作用。看其代码持有ExecutionEntity这个实例。而ExecutionEntity是Activiti中非常重要的一个类，/TODO 6.Activiti的持久化框架（组件）Activiti使用ibatis作为ORMapping工具。在此基础之上Activiti设计了自己的持久化框架，看一张图： （图5：Activiti持久化框架） 顶层接口是Session和SessionFactory，这都非常好理解了。Session有两个实现类：DbSqlSession：简单点说，DbSqlSession负责sql表达式的执行。AbstractManager:简单点说，AbstractManager及其子类负责面向对象的持久化操作同理DbSqlSessionFactory与GenericManagerFactory的区别就很好理解了。 持久化框架也是在流程引擎建立时初始化的，具体见图4. 7.Event-Listener 组件Activiti允许客户端代码介入流程的执行。为此提供了一个基础组件，看图：（图6：用户代码介入流程的基础组件）用户可以介入的代码类型包括：TaskListener，JavaDelegate，Expression，ExecutionListener。ProcessEngineConfigurationImpl持有DelegateInterceptor的某个实例，这样就可以随时非常方便地调用handleInvocation 8.Cache 组件对Activiti的cache实现很感兴趣，但现在我了解到的情况（也许还没有了解清楚）其cache的实现还是很简单的，在DbSqlSession中有cache实现： Java代码 1. protected List<PersistentObject> insertedObjects = new ArrayList<PersistentObject>(); 2. protected Map<Class<?>, Map<String, CachedObject>> cachedObjects = new HashMap<Class<?>, Map<String,CachedObject>>(); 3. protected List<DeleteOperation> deletedObjects = new ArrayList<DeleteOperation>(); 4. protected List<DeserializedObject> deserializedObjects = new ArrayList<DeserializedObject>(); 也就是说Activiti就是基于内存的List和Map来做缓存的。具体怎么用的呢？以DbSqlSession.selectOne方法为例： Java代码 1. public Object selectOne(String statement, Object parameter) 2. statement = dbSqlSessionFactory.mapStatement(statement); 3. Object result = sqlSession.selectOne(statement, parameter); 4. if (result instanceof PersistentObject) 5. PersistentObject loadedObject = (PersistentObject) result; 6. 缓存处理 7. result = cacheFilter(loadedObject); 8. 9. return result; 10. Java代码 1. protected PersistentObject cacheFilter(PersistentObject persistentObject) 2. PersistentObject cachedPersistentObject = cacheGet(persistentObject.getClass(), persistentObject.getId(); 3. if (cachedPersistentObject!=null) 4. /如果缓存中有就直接返回 5. return cachedPersistentObject; 6. 7. /否则，就先放入缓存 8. cachePut(persistentObject, true); 9. return persistentObject; 10. Java代码 1. protected CachedObject cachePut(PersistentObject persistentObject, boolean storeState) 2. Map<String, CachedObject> classCache = cachedObjects.get(persistentObject.getClass(); 3. if (classCache=null) 4. classCache = new HashMap<String, CachedObject>(); 5. cachedObjects.put(persistentObject.getClass(), classCache); 6. 7. /这里是关键：一个CachedObject包含被缓存的对象本身：persistentObject和缓存的状态：storeState 8. /Activiti正是根据storeState来判别缓存中的数据是否被更新是否与db保持一致的。 9. CachedObject cachedObject = new CachedObject(persistentObject, storeState); 10. classCache.put(persistentObject.getId(), cachedObject); 11. return cachedObject; 12. 看了Activiti的缓存设计，我现在最大的疑问是Activiti貌似不支持cluster，因为其缓存设计是基于单机内存的，这个问题还需要进一步调查。 9.异步执行组件Activiti可以异步执行job（具体例子可以看一下ProcessInstance startProcessInstanceByKey(String processDefinitionKey);），下面简单分析一下其实现过程，还是先看图：（图7：异步执行组件核心类）JobExecutor是异步执行组件的核心类，其包含三个主要属性：1）JobAcquisitionThread jobAccquisitionThread:执行任务的线程 extends java.lang.Thread2)BlockingQueue<Runnable> threadPoolQueue3)ThreadPoolExecutor threadPoolExecutor:线程池 方法ProcessEngines在引擎启动时调用JobExecutor.start，JobAcquisitionThread 线程即开始工作，其run方法不断循环执行AcquiredJobs中的job，执行一次后线程等待一定时间直到超时或者JobExecutor.jobWasAdded方法因为有新任务而被调用。 这里发现有一处设计的不够好：JobAcquisitionThread 与JobExecutor之间的关系是如此紧密（你中有我，我中有你），那么可以把JobAcquisitionThread 作为JobExecutor的内部类来实现，同时把ThreadPoolExecutor threadPoolExecutor交给JobAcquisitionThread 来管理，JobExecutor只负责接受任务以及启动、停止等更高级的工作，具体细节委托给JobAcquisitionThread ，责任分解，便于维护，JobExecutor的代码也会看起来更清晰。 10.PVMPVM:Process Virtal Machine,流程虚拟机API暴露了流程虚拟机的POJO核心，流程虚拟机API描述了一个工作流流程必备的组件，这些组件包括：PvmProcessDefinition：流程的定义，形象点说就是用户画的那个图。静态含义。PvmProcessInstance：流程实例，用户发起的某个PvmProcessDefinition的一个实例，动态含义。PvmActivity：流程中的一个节点PvmTransition：衔接各个节点之间的路径，形象点说就是图中各个节点之间的连接线。PvmEvent：流程执行过程中触发的事件 以上这些组件很好地对一个流程进行了建模和抽象。每个组件都有很清晰的角色和职责划分。另外，有了这些API，我们可以通过编程的方式，用代码来“画”一个流程图并让他run起来，例如：Java代码 1. PvmProcessDefinition processDefinition = new ProcessDefinitionBuilder() 2. .createActivity("a").initial().<strong style="background-color: #ff0000;">behavior</strong>(new WaitState() 3. .transition("b").endActivity().createActivity("b") 4. .behavior(new WaitState().transition("c").endActivity() 5. .createActivity("c").behavior(new WaitState().endActivity() 6. .buildProcessDefinition(); 7. PvmProcessInstance processInstance = processDefinition 8. .createProcessInstance(); 9. processInstance.start(); 10. PvmExecution activityInstance = processInstance.findExecution("a"); 11. assertNotNull(activityInstance); 12. activityInstance.signal(null, null); 13. activityInstance = processInstance.findExecution("b"); 14. assertNotNull(activityInstance); 15. activityInstance.signal(null, null); 16. activityInstance = processInstance.findExecution("c"); 17. assertNotNull(activityInstance); 以上代码都很简单，很好理解，只有一点需要说明一下，粗体红色背景的behavior方法，为一个PvmActivity增加ActivityBehavior，这是干什么呢？ActivityBehavior是一个interface,其接口声明很简单：Java代码 1. /* 2. * author Tom Baeyens 3. */ 4. public interface ActivityBehavior 5. 6. void execute(ActivityExecution execution) throws Exception; 7. 我的理解：Activiti把完成一个PvmActivity的行为单独建模封装在ActivityBehavior中。execute方法只有一个参数ActivityExecution，为啥这么设计？ 为了更好地理解ActivityBehavior的作用，我们以TaskEplete方法为例,分析其执行过程，先看complete的代码：Java代码 1. public void complete() 2. fireEvent(TaskListener.EVENTNAME_COMPLETE); 3. 4. Context 5. .getCommandContext() 6. .getTaskManager() 7. .deleteTask(this, TaskEntity.DELETE_REASON_COMPLETED, false); 8. 9. if (executionId!=null) 10. getExecution().signal(null, null); 11. 12. 代码很简单，也很好理解（可能出乎我们的意料，因为完成一个task，其实有很多事情要做的）：1.fireEvent：通知Listener，本任务完成了。2.数据持久化相关的动作3.getExecution().signal(null, null)：发信号，这里面隐藏的东西就多了，总体来说，完成了当前任务流程怎么走，怎么生成新的任务都是在这里完成的。进去看看：Java代码 1. public void signal(String signalName, Object signalData) 2. ensureActivityInitialized(); 3. SignallableActivityBehavior activityBehavior = (SignallableActivityBehavior) activity.getActivityBehavior(); 4. try 5. activityBehavior.signal(this, signalName, signalData); 6. catch (RuntimeException e) 7. throw e; 8. catch (Exception e) 9. throw new PvmException("couldn't process signal '"+signalName+"' on activity '"+activity.getId()+"': "+e.getMessage(), e); 10. 11. ExecutionEntity.signal方法核心工作就是把发信号的工作委托给PvmActivity的activityBehavior. 这里的设计存在问题，很显然其触犯了一个代码的坏味道：消息链。它让ExceutionEntity没有必要地与SignallableActivityBehavior 产生了耦合，更好的做法应该是PvmActivity提供signal方法，其内部调用ActivityBehavior完成发信号工作。 其实看看PvmActivity的接口声明，我不免也有疑问，本来属于PvmActivity的很重要的职责在其接口声明中都没有体现，why？Java代码 1. /* 2. * author Tom Baeyens 3. */ 4. public interface PvmActivity extends PvmScope 5. 6. boolean isAsync(); 7. 8. PvmScope getParent(); 9. 10. List<PvmTransition> getIncomingTransitions(); 11. 12. List<PvmTransition> getOutgoingTransitions(); 13. 14. PvmTransition findOutgoingTransition(String transitionId); 15. 把思路拉回来，我们继续看activityBehavior.signal方法内部的具体实现。/待续Activiti 5.3：流程活动自动与手工触发执行分类： Workflow2011-03-23 12:51 2849人阅读 评论(2) 收藏 举报活动exceptionclassstringobjectdeploymentActiviti 5.3支持流程活动自动执行与手工触发执行。其中，自动执行是指，在启动流程之前，准备流程所需要的控制流程进度的变量数据，启动流程之后，无需外部干预，就能够按照预定义的流程执行；手工触发执行是指，执行到流程中某个个结点后流程暂时停止运行，直到收到外部发送的信号以后，才会继续向前推进，这样情况可以更加精细地控制流程。下面主要通过基于Activiti 5.3的<parallelGateway>、<serviceTask>、<receiveTask>、<userTask>元素来看一下。首先，我们在测试的过程中，用到JUnit 3.x，为了方便，这里给了一层封装，代码如下所示：java view plaincopy1. package org.shirdrn.workflow.activiti; 2. 3. import junit.framework.TestCase; 4. 5. import org.activiti.engine.FormService; 6. import org.activiti.engine.HistoryService; 7. import org.activiti.engine.IdentityService; 8. import org.activiti.engine.ManagementService; 9. import org.activiti.engine.ProcessEngine; 10. import org.activiti.engine.ProcessEngines; 11. import org.activiti.engine.RepositoryService; 12. import org.activiti.engine.RuntimeService; 13. import org.activiti.engine.TaskService; 14. 15. /* 16. * author shirdrn 17. */ 18. public abstract class AbstractTest extends TestCase 19. 20. private ProcessEngine processEngine; 21. protected String deploymentId; 22. protected RepositoryService repositoryService; 23. protected RuntimeService runtimeService; 24. protected TaskService taskService; 25. protected FormService formService; 26. protected HistoryService historyService; 27. protected IdentityService identityService; 28. protected ManagementService managementService; 29. 30. Override 31. protected void setUp() throws Exception 32. super.setUp(); 33. if(processEngine=null) 34. processEngine = ProcessEngines.getDefaultProcessEngine(); 35. 36. repositoryService = processEngine.getRepositoryService(); 37. runtimeService = processEngine.getRuntimeService(); 38. taskService = processEngine.getTaskService(); 39. formService = processEngine.getFormService(); 40. historyService = processEngine.getHistoryService(); 41. identityService = processEngine.getIdentityService(); 42. managementService = processEngine.getManagementService(); 43. initialize(); 44. 45. 46. Override 47. protected void tearDown() throws Exception 48. super.tearDown(); 49. destroy(); 50. 51. 52. protected abstract void initialize() throws Exception; 53. 54. protected abstract void destroy() throws Exception; 55. 这里面，主要是在测试之前做一些初始化工作，主要包括流程引擎实例的构建，及其流程提供的基本服务。下面测试会用到该抽象类。自动执行<serviceTask>元素，可以实现自动活动，语法如下所示：xhtml view plaincopy1. <serviceTask id="serviceTaskId" name="serviceTaskName" 2. iviti:class="org.shirdrn.workflow.activiti.gateway.ServiceTaskClass"/> 其中，activiti:class属性为该结点对应的处理类，该类要求实现org.activiti.engine.delegate.JavaDelegate接口，该接口定义如下所示：java view plaincopy1. package org.activiti.engine.delegate; 2. 3. public interface JavaDelegate 4. 5. void execute(DelegateExecution execution) throws Exception; 6. 7. execute方法的参数DelegateExecution execution可以在流程中各个结点之间传递流程变量。下面给出一个具体的例子：自动执行的流程，如图所示： 对应的流程定义文件为GatewayTest.testAutomaticForkJoin.bpmn20.xml，如下所示：c-sharp view plaincopy1. <?xml version="1.0" encoding="UTF-8"?> 2. <definitions xmlns="http:/www.omg.org/spec/BPMN/MODEL" xmlns:xsi="http:/www.w3.org/2001/XMLSchema-instance" xmlns:activiti="http:/activiti.org/bpmn" xmlns:bpmndi="http:/www.omg.org/spec/BPMN/DI" xmlns:omgdc="http:/www.omg.org/spec/DD/DC" xmlns:omgdi="http:/www.omg.org/spec/DD/DI" typeLanguage="http:/www.w3.org/2001/XMLSchema" expressionLanguage="http:/www.w3.org/1999/XPath" targetNamespace="http:/www.activiti.org/test"> 3. <process id="AutomaticParalellBasedForkJoin" name="AutomaticParalellBasedForkJoin"> 4. <startEvent id="startevent7" name="Start"></startEvent> 5. <parallelGateway id="parallelgateway12" name="Fork"></parallel
