activiti

扩展activiti使用自己的用户表和群组表

http://my.oschina.net/winHerson/blog/118172

activiti使用总结

http://www.kafeitu.me/activiti/2012/03/22/workflow-activiti-action.html

activiti实战源码

https://github.com/henryyan/activiti-in-action-codes

Activiti 5.16 用户手册

http://www.mossle.com/docs/activiti/

activiti数据库相关脚本说明：

• engine: the tables needed for engine execution. Required.
• identity: the tables containing users, groups and memberships of users to groups. These tables are optional and should be used when using the default identity management as shipped with the engine.
• history: the tables that contain the history and audit information. Optional: not needed when history level is set to none. Note that this will also disable some features (such as commenting on tasks) which store the data in the history database.

  activiti相关数据表说明：

  The database names of Activiti all start with ACT_. The second part is a two-character identification of the use case of the table. This use case will also roughly match the service API.

  • ACT_RE_*: RE stands for repository. Tables with this prefix contain static information such as process definitions and process resources (images, rules, etc.).
  • ACT_RU_*: RU stands for runtime. These are the runtime tables, that contain the runtime data of process instances, user tasks, variables, jobs, etc. Activiti only stores the runtime data during process instance execution, and removes the records when a process instance ends. This keeps the runtime tables small and fast.
  • ACT_ID_*: ID stands for identity. These tables contain identity information, such as users, groups, etc.
  • ACT_HI_*: HI stands for history. These are the tables that contain historic data, such as past process instances, variables, tasks, etc.
  • ACT_GE_*: general data, which is used in various use cases.

activiti：

1. 获得ProcessEngine类的实例， 它是所有Activiti引擎功能的中心入口

1

2

3

4

5

6

7

8

9

ProcessEngineprocessEngine=ProcessEngines.getDefaultProcessEngine();

 

RuntimeServiceruntimeService=processEngine.getRuntimeService();

RepositoryServicerepositoryService=processEngine.getRepositoryService();

TaskServicetaskService=processEngine.getTaskService();

ManagementServicemanagementService=processEngine.getManagementService();

IdentityServiceidentityService=processEngine.getIdentityService();

HistoryServicehistoryService=processEngine.getHistoryService();

FormServiceformService=processEngine.getFormService();

ProcessEngines.getDefaultProcessEngine()会在第一次调用时 初始化并创建一个流程引擎，以后再调用就会返回相同的流程引擎。 使用对应的方法可以创建和关闭所有流程引擎：ProcessEngines.init() 和 ProcessEngines.destroy()。

ProcessEngines会扫描所有activiti.cfg.xml 和 activiti-context.xml 文件。 对于activiti.cfg.xml文件，流程引擎会使用Activiti的经典方式构建： ProcessEngineConfiguration.createProcessEngineConfigurationFromInputStream(inputStream).buildProcessEngine(). 对于activiti-context.xml文件，流程引擎会使用Spring方法构建：先创建一个Spring的环境， 然后通过环境获得流程引擎。

所有服务都是无状态的。这意味着可以在多节点集群环境下运行Activiti，每个节点都指向同一个数据库， 不用担心哪个机器实际执行前端的调用。 无论在哪里执行服务都没有问题。

RepositoryService可能是使用Activiti引擎时最先接触的服务。 它提供了管理和控制发布包和流程定义的操作。 这里不涉及太多细节，流程定义是BPMN 2.0流程的java实现。 它包含了一个流程每个环节的结构和行为。 发布包是Activiti引擎的打包单位。一个发布包可以包含多个BPMN 2.0 xml文件和其他资源。 开发者可以自由选择把任意资源包含到发布包中。 既可以把一个单独的BPMN 2.0 xml文件放到发布包里，也可以把整个流程和相关资源都放在一起。 （比如，’hr-processes’实例可以包含hr流程相关的任何资源）。 可以通过RepositoryService来部署这种发布包。 发布一个发布包，意味着把它上传到引擎中，所有流程都会在保存进数据库之前分析解析好。 从这点来说，系统知道这个发布包的存在，发布包中包含的流程就已经可以启动了。

除此之外，服务可以

• 查询引擎中的发布包和流程定义。
• 暂停或激活发布包，对应全部和特定流程定义。 暂停意味着它们不能再执行任何操作了，激活是对应的反向操作。
• 获得多种资源，像是包含在发布包里的文件， 或引擎自动生成的流程图。
• 获得流程定义的pojo版本， 可以用来通过java解析流程，而不必通过xml。

正如RepositoryService负责静态信息（比如，不会改变的数据，至少是不怎么改变的）， RuntimeService正好是完全相反的。它负责启动一个流程定义的新实例。 如上所述，流程定义定义了流程各个节点的结构和行为。 流程实例就是这样一个流程定义的实例。对每个流程定义来说，同一时间会有很多实例在执行。 RuntimeService也可以用来获取和保存流程变量。 这些数据是特定于某个流程实例的，并会被很多流程中的节点使用 （比如，一个排他网关常常使用流程变量来决定选择哪条路径继续流程）。 Runtimeservice也能查询流程实例和执行。 执行对应BPMN 2.0中的'token'。基本上执行指向流程实例当前在哪里。 最后，RuntimeService可以在流程实例等待外部触发时使用，这时可以用来继续流程实例。 流程实例可以有很多暂停状态，而服务提供了多种方法来’触发’实例， 接受外部触发后，流程实例就会继续向下执行。

任务是由系统中真实人员执行的，它是Activiti这类BPMN引擎的核心功能之一。 所有与任务有关的功能都包含在TaskService中：

• 查询分配给用户或组的任务
• 创建独立运行任务。这些任务与流程实例无关。
• 手工设置任务的执行者，或者这些用户通过何种方式与任务关联。
• 认领并完成一个任务。认领意味着一个人期望成为任务的执行者， 即这个用户会完成这个任务。完成意味着“做这个任务要求的事情”。 通常来说会有很多种处理形式。

IdentityService非常简单。它可以管理（创建，更新，删除，查询…）群组和用户。 请注意， Activiti执行时并没有对用户进行检查。 例如，任务可以分配给任何人，但是引擎不会校验系统中是否存在这个用户。 这是Activiti引擎也可以使用外部服务，比如ldap，活动目录，等等。

FormService是一个可选服务。即使不使用它，Activiti也可以完美运行， 不会损失任何功能。这个服务提供了启动表单和任务表单两个概念。启动表单会在流程实例启动之前展示给用户， 任务表单会在用户完成任务时展示。Activiti支持在BPMN 2.0流程定义中设置这些表单。 这个服务以一种简单的方式将数据暴露出来。再次重申，它时可选的， 表单也不一定要嵌入到流程定义中。

HistoryService提供了Activiti引擎手机的所有历史数据。 在执行流程时，引擎会保存很多数据（根据配置），比如流程实例启动时间，任务的参与者， 完成任务的时间，每个流程实例的执行路径，等等。 这个服务主要通过查询功能来获得这些数据。

ManagementService在使用Activiti的定制环境中基本上不会用到。 它可以查询数据库的表和表的元数据。另外，它提供了查询和管理异步操作的功能。 Activiti的异步操作用途很多，比如定时器，异步操作， 延迟暂停、激活，等等。后续，会讨论这些功能的更多细节

此项目被张贴在activiti 。书签的 permalink