Activiti 6.0 用户指南：快速入门与配置详解

需积分: 16 49 浏览量更新于2024-07-19 1 收藏 11.32MB PDF 举报

《Activiti 6.0 用户手册》是 Activiti 开发团队针对其版本 6.0.0 提供的一份详尽指南，旨在帮助用户深入了解和使用 Activiti 这个流程管理平台。该手册分为多个章节，涵盖了从入门到高级配置的全面内容。 1. **介绍** 部分首先明确了许可证信息，确保用户了解 Activiti 的使用条款。下载和源代码链接对于想要尝试或参与开发的人来说非常重要。同时，手册指出需要 JDK 7 及以上版本以及推荐的集成开发环境（IDE）。在遇到问题时，提供了一个报告问题的渠道，而实验性功能则可能包含某些未稳定但可能在未来版本中成熟的功能。 2. **快速入门** 通过 "一分钟版本" 和 Activiti 环境设置，新手可以快速理解如何安装和启动一个基本的 Activiti 实例。接着介绍了数据库的设置，包括如何将 Activiti jar 文件及其依赖项集成到项目中，并给出后续步骤的指导。 3. **配置** 是手册的核心部分，详述了如何创建 ProcessEngine 对象，这是一个关键组件，负责管理和执行流程定义。指南深入到 ProcessEngineConfiguration 类的使用，涉及数据库配置、JNDI 数据源、支持的数据库类型以及如何创建数据表。升级数据库、JobExecutor（自 6.0.0 版本起引入）的激活机制、邮件服务器配置、历史记录处理以及配置表达式和脚本中的配置 bean 都被详细介绍。 - **JobExecutor**：新版本中引入的 JobExecutor 负责处理任务调度，用户需要知道如何配置它的启用状态。 - **邮件服务器配置**：与工作流相关的通知可以通过邮件发送，这部分解释了如何设置邮件服务器连接信息。 - **历史记录配置**：记录流程实例的历史状态对审计和分析至关重要，这部分展示了如何定制历史记录的存储和查询方式。 - **表达式和脚本中的配置**：强调了配置对象如何在业务逻辑中被引用，以实现动态的配置过程。 3.17 **事件处理器** 包括事件监听器的实现、配置和如何在运行时动态添加事件监听器，这是处理流程执行过程中事件触发的关键环节。《Activiti 6.0 用户手册》为开发者提供了丰富的资源，无论是初次接触 Activiti 还是希望优化现有部署的用户，都能从中找到所需的信息。通过阅读和遵循这些指南，用户可以充分利用 Activiti 的功能，实现高效的企业流程自动化。

• Execute the main method of the DbSchemaCreate class

However, often only database administrators can execute DDL statements on a database. On a production system, this is also the

wisest of choices. The SQL DDL statements can be found on the Activiti downloads page or inside the Activiti distribution folder, in the

database subdirectory. The scripts are also in the engine jar (activiti-engine-x.jar), in the package org/activiti/db/create (the drop

folder contains the drop statements). The SQL files are of the form

Where db is any of the supported databases and type is

• 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.

Note for MySQL users: MySQL version lower than 5.6.4 has no support for timestamps or dates with millisecond precision. To make

things even worse, some version will throw an exception when trying to create such a column but other versions don’t. When doing

auto-creation/upgrade, the engine will change the DDL when executing it. When using the DDL file approach, both a regular version

and a special file with mysql55 in it are available (this applies on anything lower than 5.6.4). This latter file will have column types with

no millisecond precision in it.

Concretely, the following applies for MySQL version

• <5.6: No millisecond precision available. DDL files available (look for files containing mysql55). Auto creation/update will work out

of the box.

• 5.6.0 - 5.6.3: No millisecond precision available. Auto creation/update will NOT work. It is advised to upgrade to a newer database

version anyway. DDL files for mysql 5.5 could be used if really needed.

• 5.6.4+: Millisecond precision available. DDL files available (default file containing mysql). Auto creation/update works out of the

box.

Do note that in the case of upgrading the MySQL database later on and the Activiti tables are already created/upgraded, the column

type change will have to be done manually!

3.7. Database table names explained

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.

3.8. Database upgrade

Make sure you make a backup of your database (using your database backup capabilities) before you run an upgrade.

By default, a version check will be performed each time a process engine is created. This typically happens once at boot time of your

application or of the Activiti webapps. If the Activiti library notices a difference between the library version and the version of the Activiti

database tables, then an exception is thrown.

To upgrade, you have to start with putting the following configuration property in your activiti.cfg.xml configuration file:

activiti.{db}.{create|drop}.{type}.sql

</bean>

</beans>

Also, include a suitable database driver for your database to the classpath. Upgrade the Activiti libraries in your application. Or

start up a new version of Activiti and point it to a database that contains an older version. With databaseSchemaUpdate set to true ,

Activiti will automatically upgrade the DB schema to the newer version the first time when it notices that libraries and DB schema are

out of sync.

As an alternative you can also run the upgrade DDL statements. It’s also possible to run the upgrade database scripts, available

on the Activiti downloads page.

3.9. Job Executor (since version 6.0.0)

The async executor of Activiti 5 is the only available job executor in Activiti 6 as it is a more performant and more database friendly

way of executing asynchronous jobs in the Activiti Engine. The old job executor of Activiti 5 is removed. More information can be found

in the advanced section of the user guide.

Moreover, if running under Java EE 7, JSR-236 compliant ManagedAsyncJobExecutor can be used for letting the container manage

the threads. In order to enable them, the thread factory should be passed in the configuration as follows:

The managed implementation fall back to their default counterparts if the thread factory is not specified.

3.10. Job executor activation

The AsyncExecutor is a component that manages a thread pool to fire timers and other asynchronous tasks. Other implementations

are possible (for example using a message queue, see the advanced section of the user guide).

By default, the AsyncExecutor is not activated and not started. With the following configuration the async executor can be started

together with the Activiti Engine.

The property asyncExecutorActivate instructs the Activiti Engine to startup the Async executor at startup.

3.11. Mail server configuration

Configuring a mail server is optional. Activiti supports sending e-mails in business processes. To actually send an e-mail, a valid

SMTP mail server configuration is required. See the e-mail task for the configuration options.

3.12. History configuration

Customizing the configuration of history storage is optional. This allows you to tweak settings that influence the history capabilities of

the engine. See history configuration for more details.

3.13. Exposing configuration beans in expressions and scripts

By default, all beans that you specify in the activiti.cfg.xml configuration or in your own Spring configuration file are available to

expressions and in the scripts. If you want to limit the visibility of beans in your configuration file, you can configure a property called

beans in your process engine configuration. The beans property in ProcessEngineConfiguration is a map. When you specify that

property, only beans specified in that map will be visible to expressions and scripts. The exposed beans will be exposed with the

names as you specify in that map.

3.14. Deployment cache configuration

All process definition are cached (after they’re parsed) to avoid hitting the database every time a process definition is needed and

because process definition data doesn’t change. By default, there is no limit on this cache. To limit the process definition cache, add

following property

</bean>

</bean>

1 <property name="asyncExecutorActivate" value="true" />

1 <property name="history" value="audit" />

1 <property name="processDefinitionCacheLimit" value="10" />

Setting this property will swap the default hashmap cache with a LRU cache that has the provided hard limit. Of course, the best value

of this property depends on the total amount of process definitions stored and the number of process definitions actually used at

runtime by all the runtime process instances.

You can also inject your own cache implementation. This must be a bean that implements the

org.activiti.engine.impl.persistence.deploy.DeploymentCache interface:

There is a similar property called knowledgeBaseCacheLimit and knowledgeBaseCache for configuring the rules cache. This is only

needed when you use the rules task in your processes.

3.15. Logging

All logging (activiti, spring, mybatis, … ) is routed through SLF4J and allows for selecting the logging-implementation of your choice.

By default no SFL4J-binding jar is present in the activiti-engine dependencies, this should be added in your project in order

to use the logging framework of your choice. If no implementation jar is added, SLF4J will use a NOP-logger, not logging anything

at all, other than a warning that nothing will be logged. For more info on these bindings

http://www.slf4j.org/codes.html#StaticLoggerBinder.

With Maven, add for example a dependency like this (here using log4j), note that you still need to add a version:

The activiti-ui and activiti-rest webapps are configured to use Log4j-binding. Log4j is also used when running the tests for all the

activiti-* modules.

Important note when using a container with commons-logging in the classpath: In order to route the spring-logging through

SLF4J, a bridge is used (see http://www.slf4j.org/legacy.html#jclOverSLF4J). If your container provides a commons-logging

implementation, please follow directions on this page: http://www.slf4j.org/codes.html#release to ensure stability.

Example when using Maven (version omitted):

3.16. Mapped Diagnostic Contexts

Activiti supports Mapped Diagnostic Contexts feature of SLF4j. These basic information are passed to the underlying logger along with

what is going to be logged:

• processDefinition Id as mdcProcessDefinitionID

• processInstance Id as mdcProcessInstanceID

• execution Id as mdcExecutionId

None of these information are logged by default. The logger can be configured to show them in desired format, extra to the usual

logged messages. For example in Log4j the following sample layout definition causes the logger to show the above mentioned

information:

This is useful when the logs contain information that needs to checked in real time, by means of a log analyzer for example.

3.17. Event handlers

The event mechanism in the Activiti engine allows you to get notified when various events occur within the engine. Take a look at all

supported event types for an overview of the events available.

It’s possible to register a listener for certain types of events as opposed to getting notified when any type of event is dispatched. You

can either add engine-wide event listeners through the configuration, add engine-wide event listeners at runtime using the API or add

event-listeners to specific process definitions in the BPMN XML.

</property>

</dependency>

</dependency>

log4j.appender.consoleAppender.layout.ConversionPattern=ProcessDefinitionId=%X{mdcProcessDefinitionID}

executionId=%X{mdcExecutionId} mdcProcessInstanceID=%X{mdcProcessInstanceID} mdcBusinessKey=%X{mdcBusinessKey} %m%n

All events dispatched are a subtype of org.activiti.engine.delegate.event.ActivitiEvent . The event exposes (if available)

the type , executionId , processInstanceId and processDefinitionId . Certain events contain additional context related to the

event that occurred, additional information about additional payload can be found in the list of all supported event types.

3.17.1. Event listener implementation

The only requirement an event-listener has, is to implement org.activiti.engine.delegate.event.ActivitiEventListener .

Below is an example implementation of a listener, which outputs all events received to the standard-out, with exception of events

related to job-execution:

The isFailOnException() method determines the behaviour in case the onEvent(..) method throws an exception when an event

is dispatched. In case false is returned, the exception is ignored. When true is returned, the exception is not ignored and bubbles

up, effectively failing the current ongoing command. In case the event was part of an API-call (or any other transactional operation,

e.g. job-execution), the transaction will be rolled back. In case the behaviour in the event-listener is not business-critical, it’s

recommended to return false .

There are a few base implementations provided by Activiti to facilitate common use cases of event-listeners. These can be used as

base-class or as an example listener implementation:

• org.activiti.engine.delegate.event.BaseEntityEventListener: An event-listener base-class that can be used to listen for entity-

related events for a specific type of entity or for all entities. It hides away the type-checking and offers 4 methods that should be

overridden: onCreate(..) , onUpdate(..) and onDelete(..) when an entity is created, updated or deleted. For all other

entity-related events, the onEntityEvent(..) is called.

3.17.2. Configuration and setup

If an event-listener is configured in the process engine configuration, it will be active when the process engine starts and will remain

active after subsequent reboots of the engine.

The property eventListeners expects a list of org.activiti.engine.delegate.event.ActivitiEventListener instances. As

usual, you can either declare an inline bean definition or use a ref to an existing bean instead. The snippet below adds an event-

listener to the configuration that is notified when any event is dispatched, regardless of its type:

To get notified when certain types of events get dispatched, use the typedEventListeners property, which expects a map. The key

of a map-entry is a comma-separated list of event-names (or a single event-name). The value of a map-entry is a list of

org.activiti.engine.delegate.event.ActivitiEventListener instances. The snippet below adds an event-listener to the

configuration, that is notified when a job execution was successful or failed:

public class MyEventListener implements ActivitiEventListener {

@Override

public void onEvent(ActivitiEvent event) {

switch (event.getType()) {

case JOB_EXECUTION_SUCCESS:

System.out.println("A job well done!");

break;

case JOB_EXECUTION_FAILURE:

System.out.println("A job has failed...");

break;

default:

System.out.println("Event received: " + event.getType());

}

@Override

public boolean isFailOnException() {

// The logic in the onEvent method of this listener is not critical, exceptions

// can be ignored if logging fails...

return false;

}

...

<list>

</list>

</property>

</bean>

...

The order of dispatching events is determined on the order the listeners were added. First, all normal event-listeners are called

( eventListeners property) in the order they are defined in the list . After that, all typed event listeners ( typedEventListeners

properties) are called, if an event of the right type is dispatched.

3.17.3. Adding listeners at runtime

It’s possible to add and remove additional event-listeners to the engine by using the API ( RuntimeService ):

Please note that the listeners added at runtime are not retained when the engine is rebooted.

3.17.4. Adding listeners to process definitions

It’s possible to add listeners to a specific process-definition. The listeners will only be called for events related to the process definition

and to all events related to process instances that are started with that specific process definition. The listener implementations can be

defined using a fully qualified classname, an expression that resolves to a bean that implements the listener interface or can be

configured to throw a message/signal/error BPMN event.

Listeners executing user-defined logic

The snippet below adds 2 listeners to a process-definition. The first listener will receive events of any type, with a listener

implementation based on a fully-qualified class name. The second listener is only notified when a job is successfully executed or when

it failed, using a listener that has been defined in the beans property of the process engine configuration.

For events related to entities, it’s also possible to add listeners to a process-definition that get only notified when entity-events occur

for a certain entity type. The snippet below shows how this can be achieved. It can be used along for ALL entity-events (first example)

or for specific event types only (second example).

<map>

<list>

</list>

</entry>

</map>

</property>

</bean>

/**

* Adds an event-listener which will be notified of ALL events by the dispatcher.

* @param listenerToAdd the listener to add

void addEventListener(ActivitiEventListener listenerToAdd);

/**

* Adds an event-listener which will only be notified when an event occurs, which type is in the given types.

* @param listenerToAdd the listener to add

* @param types types of events the listener should be notified for

void addEventListener(ActivitiEventListener listenerToAdd, ActivitiEventType... types);

/**

* Removes the given listener from this dispatcher. The listener will no longer be notified,

* regardless of the type(s) it was registered for in the first place.

* @param listenerToRemove listener to remove

void removeEventListener(ActivitiEventListener listenerToRemove);

<activiti:eventListener class="org.activiti.engine.test.MyEventListener" />

<activiti:eventListener delegateExpression="${testEventListener}" events="JOB_EXECUTION_SUCCESS,JOB_EXECUTION_FAILURE"

</extensionElements>

...

</process>

<activiti:eventListener class="org.activiti.engine.test.MyEventListener" entityType="task" />

<activiti:eventListener delegateExpression="${testEventListener}" events="ENTITY_CREATED" entityType="task" />

</extensionElements>

...

</process>

剩余271页未读，继续阅读

zouhongquan_zz

粉丝: 0
资源: 3

Activiti 6.0 用户指南：快速入门与配置详解

深入学习Activiti6.0工作流引擎开发

Activiti6.0工作流使用详解

深度解析：Activiti 6.0工作流引擎开发全攻略

activiti6.0用户手册，pdf英文版

Activiti6.0 用户手册说明文档1

activiti6.0 用户指南中文版

activiti 6.0

Activiti 6.0

Activiti6.0下载

activiti6.0 最新jar

最新资源