activitiWord下载.docx
《activitiWord下载.docx》由会员分享，可在线阅读，更多相关《activitiWord下载.docx（30页珍藏版）》请在冰豆网上搜索。
ActivitiEngine—ActivitiBPM的核心引擎
运行时核心组件，解析流程定义文件
（.bpmn20.xml
文件
）
，将其转化为纯粹的内存
Java
对象，以供运行时各个功能使用；
Activiti引擎，基于流程虚拟机（PVM）进行构建（关于PVM的详细介绍，参见8.1.2章节），是Activiti项目的绝对的底层核心组件。
它可以直接运行原生的BPMN2.0规范格式的流程定义。
是业内目前第一个，也是唯一的一个从建模到执行，完全按照BPMN2.0规范进行实现的BPM项目。
这也是笔者选择它作为BPM开源产品介绍的最直接原因。
Activiti引擎具备三个重要的特性。
首先就是事件监听器。
这个特性允许引擎可以直接执行一个动作（即为流程图中的某个特定的事件，定义的一段java代码或脚本）。
这意味着，开发人员可以利用特定的技术细节来装饰完善一个流程，而这个细节不会在流程图中显示。
此特性提高了业务人员与技术人员之间的协作，而业务人员不用面对流程图中的技术问题。
第二个特性是定制活动。
Activiti引擎实现了对BPMN的支持，有很多可直接使用的活动类型。
但是业务人员仍旧有可能需要一些与这些已定义的活动不匹配的活动类型。
在这种情景下，开发人员可以采用java代码编写一个定制的活动，用来实现业务人员所描述的复杂行为。
这个功能应该说是非常好用的功能，因为对于商业产品来讲，活动类型都是定义好的。
是一个封装的黑盒子，是不可能提供定制功能的。
另一个创新的特性是，它提供了对某些冗长的BPMN规范进行实现的快捷方式或捷径。
例如采用比BPMN的XML格式更紧凑的XML描述格式。
而这种XML格式不是Activiti的专有扩展，它可以被转换为有效的BPMNXML。
所以说，Activiti的流程定义，并不是百分百的BPMN的XML格式。
协作工具（CollaborationTool）组件
ActivitiCycle完全是一种新类型的BPM组件。
它是一个用来促进业务人员、开发人员和IT操作人员协作的web应用程序。
目前，大多数的BPM产品都关注于怎样将业务人员创建的分析流程模型转换为可执行流程模型。
实际的情况就是，这些BPM产品为业务人员和开发人员提供独立的工具，但是对于他们之间的协作并没有提供很好的支持。
在现实的场景中，业务文档有业务人员所持有，而软件程序由开发团队所管理，被部署的软件应用则被IT管理人员所管理。
三者之间不能很好的协作。
我们可以想象这样一个场景，业务经理用文档来维护需求和visio格式的流程图，开发人员管理可执行的流程和大量的java源文件，IT维护人员管理部署在tomcat中的.war文件和存储在Activiti数据库中的流程。
ActivitiCycle首先分为左右两个区域，左侧区域是所有交付物的浏览器，这些交付物存储在仓库中。
包括：
·
一个网络驱动器，例如Vision图，图片，word文档，excel图表等；
一个业务模型仓库，例如Signavio建模器中包含的BPMN流程模型；
一个SVN仓库，包含java源文件和可执行的BPMN流程；
一个包含业务文档的maven仓库；
Activiti实例，包含一系列被部署的各个版本的交付组件；
右侧区域，则分为上中下三个部分，分别是左侧选中交付物的具体明细（包含查看、设定所有人、增加关联链接）、工作区域和讨论区。
现在业务分析员、开发人员和维护人员，可以在为他们自己提供的区域内，利用相关工具进行工作，而ActivitiCycle则负责组织他们的协作。
ActivitiAPI
1.ProcessEngine
processEngine
=
ProcessEngines.getDefaultProcessEngine（）;
2.
3.RuntimeService
runtimeService
processEngine.getRuntimeService（）;
4.RepositoryService
repositoryService
processEngine.getRepositoryService（）;
5.TaskService
taskService
processEngine.getTaskService（）;
6.ManagementService
managementService
processEngine.getManagementService（）;
7.IdentityService
identityService
processEngine.getIdentityService（）;
8.HistoryService
historyService
processEngine.getHistoryService（）;
9.FormService
formService
processEngine.getFormService（）;
通过
ProcessEngineBuilder
读取
activiti
的配置文件，就可以生成流程引擎实例。
通过流程引擎实例
processEngine,
我们就可以通过
getXXXService（）
取得各种包含
workflow/BPM
方法的
service
。
RepositoryService
：
提供方法获取各种流程和部署文件的信息
.
TaskService:
提供对任务相关的各种操作
identityService:
管理用户和用户组。
FormService:
获取或者绑定数据到流程实例上
RuntimeService:
提供操作部署文件，流程文件和流程实例的方法
ManagementService:
提供管理员对流程引擎的监控，和流程引擎服务应用无关。
HistoryService:
提供正在执行和过去执行的各种流程实例信息
●Activiti.cfg.xml文件内必须包含一个Id为’processEngineConfiguration’的bean。
processEngineConfiguration对象可以通过解析xml文件得到也可以通过java代码得到
ProcessEngineConfigurationprocessEngineConfiguration=ProcessEngineConfiguration.createStandaloneProcessEngineConfiguration（）;
processEngineConfiguration.setJdbcDriver（"
com.mysql.jdbc.Driver"
）;
processEngineConfiguration.setJdbcUrl（"
jdbc:
mysql:
//localhost:
3306/activiti?
autoReconnect=true"
processEngineConfiguration.setJdbcUsername（"
root"
processEngineConfiguration.setJdbcPassword（"
0000"
processEngineConfiguration.setDatabaseSchemaUpdate（"
true"
processEngineConfiguration.setJobExecutorActivate（false）;
ProcessEngineprocessEngine=processEngineConfiguration.buildProcessEngine（）;
System.out.println（processEngine.toString（））;
●要根据你在build.*.properties文件指定的属性来创建数据的配置文件，在setup文件内运行antcfg.create，可以在setup/build/activiti.cfg内找到生成的配置文件。
●processEngine以及那些服务对象都是线程安全的。
ProcessEngines.getDefaultProcessEngine（）会在第一次被调用时初始并构建processengine，接下来对该方法的调用返回的都是同一个流程引擎。
利用ProcessEngines.init（）、ProcessEngines.destroy（）可以正确创建、关闭流程引擎。
●流程初始化：
xml文件中流程定义的id属性（这个id接下来可以通过RuntimeService的startProcessInstanceByKey方法来启动该流程定义的一个新流程实例。
这个方法总是选取流程定义的最新部署版本）作为流程定义的key属性；
xml文件中流程定义的name属性作为流程定义的name属性，如果不指定name属性，那么id属性作为name；
带有特定key的流程第一次被部署时，被分配的版本号为1，同一key值的流程定义的后续部署，版本号会被设置为比当前最大的部署版本号大1的值，key属性用来区分流程定义；
流程定义的id属性被设置为{processDefinitionKey}:
{processDefinitionVersion}:
{generated-id}，其中generated-id是唯一性的数字，用来确保缓存在集群环境下流程定义id的唯一性。
●部署流程：
1.流程定义将存储到为Activiti引擎配置好了的持久化数据仓库中。
因此通过我们的部署业务流程，就确保了在重启引擎后也能获得该流程定义。
2.BPMN2.0流程定义文件会被解析到一个内存对象模型，可以通过ActivitiAPI对它进行操作。
部署“
1.使用activitiProbe部署
2.编程式部署
StringbarFileName="
path/to/process-one.bar"
;
ZipInputStreaminputStream=newZipInputStream（newFileInputStream（barFileName））;
repositoryService.createDeployment（）.name（"
process-one.bar"
）.addZipInputStream（inputStream）.deploy（）;
3.使用ant部署
<
taskdefname="
deploy-bar"
classname="
org.activiti.engine.impl.ant.DeployBarTask"
>
<
classpath>
filesetdir="
..."
includename="
activiti-cfg.jar"
/>
your-db-driver.jar"
/fileset>
${activiti.home}/lib"
activiti-engine-${activiti.version}.jar"
ibatis-sqlmap-*.jar"
/classpath>
/taskdef>
deploy-barfile="
.../yourprocess.bar"
/>
●ProcessInstanceprocessInstance=runtimeService.startProcessInstanceByKey（"
financialReport"
将创建一个流程实例，并首先通过start事件。
通过start事件后，流程会沿着start事件的所有输出流执行，执行到第一个任务。
此时activiti引擎会向持久化数据库中存储一个任务。
此时，关联在该任务上的用户或组的分配得以解析，并且也被存储到数据库中。
Activiti引擎会继续流程的执行步骤直到流程进入一种等待状态，比如用户任务。
在这样的一种状态，流程实例的当前状态被存储到数据库中。
流程会保持该状态直到所有用户决定完成其任务。
那时，流程引擎会继续执行流程直到流程进入一个新的等待状态或流程终点。
●事件用于对发生在流程生命周期的事情进行建模。
事件总是被形象成一个圆圈。
存在两种主要的事件类型：
捕获事件和抛出事件。
⏹捕获：
流程执行到该事件时，会等待事件触发。
事件触发类型由内部图标或xml中的类型声明来定义。
捕获事件视觉上可以通过白色的图标区分
⏹抛出：
流程执行到该事件时，事件就会触发。
该事件触发的类型由内部图标或xml中的类型声明来定义。
黑色图标区分。
●Start事件：
总是捕获型的，从概念上将，该事件会一直等待直到触发发生。
Activiti特有属性：
formKey和initiator
Activiti:
formKey指向一个用户必须在启动新流程实例时填写的表单模板。
可以包含任何文本，用于标示你的表单。
但对于内置的表单渲染，Activiti:
formKey的值最好是所在的同一个流程归档文件内的资源的引用。
startEventid="
request"
activiti:
formKey="
org/activiti/request.form"
●NoneStart事件：
没有为启动流程实例指定触发器，这意味着流程引擎不能预期什么时候流程实例要被启动。
Nonestart事件使用在通过调用startProcessInstanceByXXX方法启动流程实例
ProcessInstanceprocessInstance=runtimeService.startProcessInstanceByXXX（）;
子流程总是使用nonestart事件。
由不带内图标的圆表示
Xml表示：
不带子元素的普通start事件声明：
start"
name="
mystartevent"
●Timerstart事件用于在给定的时间点创建流程实例。
它可以用在只启动一次的流程中，也可以用你在特定时间间隔下启动的流程。
子流程不能用timerstart事件。
theStart"
timerEventDefinition>
timeDate>
2011-03-11T12:
13:
14<
/timeDate>
/timerEventDefinition>
/startEvent>
●End事件：
结束事件总是抛出型的。
这意味着当流程执行到结束事件时，有一个结果会被抛出。
结果的类型是以事件的内部黑色图标来表示的。
●NoneEnd事件：
意味着没有指定在进入该事件时抛出的结果。
这样，流程引擎除了结束当前的执行路径不会在执行任何其他操作。
Xml表示为没有子元素的普通的end事件的声明。
不带内部图标的粗边框圆：
endEventid="
end"
myendevent"
●ErrorEnd事件：
当流程执行到errorend事件时，会结束当前的执行路径，并抛出error。
Error可以被与之匹配的中间边界error事件捕获。
如果没有找到匹配的边界error事件，默认会使用noneend事件。
Xml表示为带有errorEventDefinition子元素的end事件。
图标为内有error图标的特殊end事件
myErrorEndEvent"
errorEventDefinitionerrorRef="
myError"
/endEvent>
●定时器事件：
Timer事件是被定义的定时器触发的事件。
可以作为start事件、internediate事件或boundary事件来使用。
只有开启jobexecutor时，定时器事件才能被触发（即，需要在activiti.cfg.xml中将jobExecutorActivat设置为true，默认为false）。
定时器只能有一个下面的元素：
1.timeDate：
该格式以ISO8601格式指定了触发事件的确定时间
2.timeDuration：
指定定时器事件在触发前运行多长时间，
timeDuration>
P10D<
/timeDuration>
3.timeCycle：
指定循环的时间间隔
timeCycle>
R3/PT10H<
/timeCycle>
示例：
boundaryEventid="
escalationTimer"
cancelActivity="
attachedToRef="
firstLineSupport"
${duration}<
/boundaryEvent>
●顺序流
sequenceFlowid="
flow1"
sourceRef="
targetRef="
theTask"
●带条件的顺序流：
可以在顺序流上定义条件。
当顺序流左侧是BPMN2.0的活动时，就会计算输出顺序流上的条件。
选取条件成立的输出顺序流来执行。
带条件的顺序流是以xml中含有conditionExpression子元素的普通流来表示。
目前仅支持tFormalExpression，目前conditionExpression只能使用UEL，在此使用的表达式的解析的结果必须是布尔类型的值。
flow"
conditionExpressionxsi:
type="
tFormalExpression"
!
[CDATA[${order.price>
100&
&
order.price<
250}]]>
/conditionExpression>
/sequenceFlow>
●默认顺序流：
所有的BPMN2.0任务以及getways都可以有一个默认的顺序流。
只有当没有其他顺序流被选取的情况下，才选取该顺序流。
exclusiveGatewayid="
exclusiveGw"
ExclusiveGateway"
default="
flow2"
task1"
${conditionA}<
task2"
flow3"
task3"
${conditionB}<
●单一分支（ExclusiveGateway）当多个顺序流条件为true的情况下，xml中最
升级会员 