企业官网建设流程全解析

我最早接触 Activiti 6 时，对官方 Demo 的第一印象是：一个能跑起来的 Web 页面，不至于这么费劲。结果真去部署activiti-app才发现，熟悉它的打开方式很重要，不然很容易陷在“下一步怎么点”“为什么保存失败”“为什么换了数据库起不来”这些环节里。这篇内容没有任何源码分析，主要是把一个可以用于真实开发参考的 Activiti 6 官方应用 demo——activiti-app，从部署、登录、流程设计到外部配置改造，完整走一遍。适合刚接触 Java 工作流引擎、想先看官方实现长什么样的读者，也适合准备用 Activiti 6 做技术调研，但不想一上来就啃 API 的工程人员。

1. activiti-app 在 Activiti 6 体系中的真实地位

1.1 一个 war 包带来的完整工作流环境

先说实话：Activiti 这个项目发展到 6.0 阶段，社区里几乎所有教程都在教“写代码调用引擎 API”。但官方其实默默维护了一套可直接部署的 web 应用集合，这就是activiti-app。它不是一个单纯展示界面的 Demo，而是把流程引擎完整包进去的一站式控制台。数据库、引擎服务、REST 接口、流程建模器、待办任务界面、用户管理、报表展示，都在同一个 war 包里。

这意味着你启动它之后，就相当于拥有了一套带界面的完整工作流平台。平时我们拼一个 Activiti 环境，至少要写配置文件、准备数据库、集成一堆依赖，但在activiti-app里，这些全是现成的。

这和“自己搭一个工程跑流程”是完全不同的两条路。很多人把activiti-app当成一个玩具，觉得它只是给你看看截图。实际部署之后你会发现，它背后包含了流程部署、流程实例、任务分配、代办、权限、历史等完整链路。你做技术选型时看图说话，看这里最直观。

1.2 五个应用入口，不是同一个页面

我第一次进去时确实有点懵，界面上并不只有一个建模器。activiti-app默认是围绕着“工作台”展开的：首页会列出一组入口，分别对应日常操作、流程设计、管理维护、身份权限和快速构建，孤立着看像五个小程序。

这里容易产生一个误解：很多人一启动就点进入“建模器”，想马上画流程，结果发现还要先选应用、先创建模型才能进入编辑器。这个使用习惯和后来很多新版本工作流产品不一样，它要求你先有“要做一个什么业务”的完整想法，才能动手。

五个入口里面，日常用得最多的是应用构建和流程预览。管理后台用来配置数据源、监控引擎运行状态，身份管理用来维护用户和用户组。实际画流程的时候，建模器主要做 BPMN 2.0 设计，说的是图，不是表单。至于快速构建器，走的是“低代码折叠式”的路子，可以快速搭出简单审批流。

1.3 对普通开发者来说，它到底解决什么问题

如果你正打算评估工作流引擎的选型，那activiti-app至少能帮你回答三个问题：

第一，这个引擎到底能做什么样的流程？
第二，表单、任务、审批权限这套东西长什么样、大概怎么配？
第三，如果自己用引擎开发，REST API 大概能提供哪些能力？

因为这三点不需要写业务逻辑，全部通过界面上操作就能感知。尤其对于没接触过 BPMN 的同事，先给他一个能打开、能点击的页面，比扔给他十页文档都好使。

我当时接一个流程平台维护任务，对方把activiti-app直接扔到了 Tomcat，问的第一句话是“这玩意里的数据是怎么落库的”。我当时第一反应是把数据库切到 MySQL 看表结构，下面要讲的部署流程，就是那时实际跑通的。

2. 部署之前先把版本、内存、数据库这三关过了

2.1 环境版本选择背后的原因

要运行官方 Demo，首先要选对基础环境。Activiti 6 官方对 Java 版本的要求偏向 Java 8，我实测用 Java 11 在一些老 Tomcat 上跑，偶尔会遇到类加载的兼容性问题。稳妥起见，直接上 Tomcat 8.5 + Java 8，别为了追逐新版本自找麻烦。

为什么不用 Tomcat 9？其实 Tomcat 9 也能跑起来，但activiti-app内部依赖的不少库来自较老的技术栈，用 Tomcat 9 你就要多留意 servlet API 的兼容差异。作为演示环境，完全是多花时间排查不必要的问题。如果你是初次接触，直接用官方文档默认支持的组合，能少踩很多坑。

除了 JDK 版本，内存也值得提一下。官方 Demo 虽然界面看起来不大，但我遇到过一次长时间跑流程后卡住，查了下日志是内存偏紧。后来在 Tomcat 的启动脚本里加上了 JVM 参数，稳定很多：

export JAVA_OPTS="-Xms512m -Xmx1024m -Dfile.encoding=UTF-8"

-Dfile.encoding=UTF-8加在这里解决了一个常见隐患：后续创建流程任务时，如果服务器默认编码不是 UTF-8，BPMN 图里的中文名称、表单字段名称都可能出现乱码。这个参数一定要尽早加上。

2.2 第一次启动时最稳的手动路径

直接下载官方发行包，里面会有结构清晰的目录。把activiti-app.war复制到 Tomcat 的webapps目录后，我推荐用前台方式启动 Tomcat，也就是执行bin/catalina.sh run。用前台模式的好处是，启动日志能实时刷在控制台里，第一次部署看日志比看访问页面更有用。

启动之后，浏览器访问下面的地址：

http://localhost:8080/activiti-app

如果 Tomcat 端口被占用，就要先改server.xml里的端口配置。这里有一个很常见的误区：很多人以为进入系统是“双击快捷图标”，其实activiti-app自身没有启动器，它必须跑在容器里。

启动过程中看到类似“DataTables warning”“No database selected”这样的提示先别慌。前者多半是前端静态资源的干扰，后者要确认是不是你提前改了配置导致数据源不可用。第一次部署最好保持默认配置，让 H2 数据库自动初始化，等到能登录进页面再考虑外接数据库。

2.3 默认账号、默认数据与默认行为

启动完成后，登录页用的默认账号是实现演示里最常见的：

用户名：admin 密码：admin

登录进去之后，你会看到系统里已经预置了一些示例应用和数据。很多人会觉得“这些 demo 数据太碍眼”，但我不建议你第一时间删除。观察这些官方预置的流程，能学到不少合理的模式，比如把表单字段定义在 BPMN XML 里、用流程变量区分业务场景，这些都是真实项目中会用到的写法。

另外要注意，activiti-app把引擎表都放在了同一个数据库里。默认 H2 数据库会生成在当前工作目录下。如果你用源码启动，数据文件位置和用 war 包启动时可能不同，这也是后来我发现“数据怎么消失了”的重要原因。切换工作目录跑的同一个 war，看起来像是数据丢了，其实是换了套新的 H2 存储文件。

3. 让一条业务真实跑起来：建表单、画流程、发起并审批

3.1 先用快速构建搭一个“费用报销”应用

正式操作时我建议你一步到位走一遍完整场景：做一个费用报销审批流程。这个场景简单，但能覆盖表单、审批节点、发起审批、待办处理等全部基础功能。

在首页进入应用列表，点击创建应用，填写应用名称和描述。进入编辑器后你会看到左侧是一堆控件，右侧是流程画布，和传统低代码平台的布局很像。把“开始事件”拖进画布，选中开始事件，在右侧配置“启动表单”，给表单添加“申请人”“报销金额”“报销事由”这几个字段。再加一个“用户任务”节点，设置任务名称为“经理审批”，并配置允许的处理人。

这里的处理人可以配成具体的用户，也可以配成流程变量。我实际使用中发现，直接用用户组更贴近项目中的分工方式：建一个“经理”组，把处理人设置为这个组，后续加人减人都不影响流程定义。

配置完成后保存应用，回到应用列表点击发布，这样一个简单的报销流程就部署到了引擎里。

3.2 在建模器里看 BPMN 文件的真实样子

快速构建适合搭简单的线性流程，但你要是想升级一下，比如加一个条件分支、并行会签、子流程，就必须去 Modeler 里看真正的 BPMN 图。

建模器界面比你想象中朴素：左侧是节点面板，中间是画布，右侧是节点属性。把审批驳回场景画出来时，我通常会这样处理：在“经理审批”后面连一个排他网关，网关产生“同意”和“驳回”两个分支，同意指向结束事件，驳回指回“重新提交”任务。

保存模型时，activiti-app会生成一个标准的 BPMN 2.0 XML。我截取一段实际部署用的核心片段，看起来大概是这样：

<process id="expenseProcess" name="费用报销流程" isExecutable="true"> <startEvent id="startEvent" activiti:initiator="initiator" name="开始"/> <userTask id="approveTask" name="经理审批" activiti:candidateGroups="manager"/> <exclusiveGateway id="approveGateway" name="审批结果"/> <sequenceFlow id="flow1" sourceRef="startEvent" targetRef="approveTask"/> <sequenceFlow id="flow2" sourceRef="approveTask" targetRef="approveGateway"/> <sequenceFlow id="flowApprove" name="通过" sourceRef="approveGateway" targetRef="endEvent"/> </process>

你会发现，流程的边界事件、表单定义，最终也都是落到这个 XML 里的。理解这一点，后面你想用代码自定义流程定义时，就有了一个非常具体的蓝底。

3.3 部署、发起实例，然后以另一个账号参与审批

流程发布之后，回到首页的应用列表，进去就能看到“发起新流程”的按钮。点击发起，填掉启动表单，一个人的报销单就变成了一条待办任务。

这时候如果你用 admin 账号批掉它，其实只验证了“顺路跑通”。我建议你这样操作：先到用户管理里创建两个新用户，比如user1和user2，把user2加入“经理”组。用user1发起报销流程之后，退出登录，再用user2登录。这样你能完整看到“我待办里出现一条任务”的完整链路，和实际项目里的用户隔离是一样的。

处理任务时，界面会有“查看详情”“审批通过”之类的操作。通过之后，再去流程实例列表查看状态，能看到该流程的当前节点、历史节点、耗时这些信息。跑一次这个闭环，你对 Activiti 的核心概念基本就有数了。

3.4 表单到底存在哪里

在activiti-app里编辑表单时，你会觉得它很像一个表单设计器，但其实表单定义是和流程模型绑定在一起的。快速构建器做的表单，会转成引擎能识别的表单配置；Modeler 里的自定义表单，也需要在流程节点的属性里挂载表单 key。

这个点很多人搞反了：以为页面表单是前端画出来的，实际上真正做事的是引擎端的表单定义。后续如果你想做自己的前端，可以通过引擎暴露的 REST 接口获取任务表单，再自行渲染。官方 Demo 里你能看到的表单渲染能力，很多是建立在沙箱环境里的“自动生成”机制上。

4. 按实际环境改造：账号体系、外部数据库与中文编码

4.1 管理员账号不能一直是 admin

官方 Demo 默认用admin/admin跑，真实项目绝对不能这样。在 IDM 管理页面里，你可以维护用户、用户组、角色关系。很多人一上来只创建用户，组却不建，导致后面候选人配置时根本找不到人。

正确做法是，先把组织结构梳理出来。比如行政部、财务部、审批组，每个组件配若干个用户，再在流程节点里引用组。这样流程定义里不写死具体人，权限调整全在管理页面里操作。我见过一些项目把候选人直接写死成 admin，流程上线后想改人，得改流程定义重新发布，低级错误但很常见。

另外业务数据和身份数据尽量别混用。如果项目已经有一套账号体系，后续要做对接，你可以通过引擎的事件监听机制做外部用户同步，而不是直接在演示环境里加几百个用户。这是演示环境过渡到真实项目时一定要想清楚的一点。

4.2 换掉 H2 换成 MySQL，哪些位置容易卡壳

默认 H2 数据库适合“看到效果”，但它毕竟不是企业级落地选择。换成 MySQL 时，主要改配置文件里数据源相关的位置。我的经验是先建好数据库，再改配置，再重启应用，顺序不能颠倒。

建库时注意 MySQL 版本和引擎驱动版本的匹配。Activiti 6 对应老版本的 MySQL 驱动即可，不要拿新版驱动的行为硬套。数据库字符集和排序规则，我建议直接设置成utf8mb4，否则中文字段在极少数场景下可能有潜在隐患。

修改配置后，把 MySQL JDBC 驱动 jar 放到你部署的WEB-INF/lib目录下。如果驱动放错位置，你在日志里会看到找不到驱动类的报错，这类问题经常和“配置没生效”搅在一起，浪费不少时间。

切换完成后，你会发现系统创建了一堆以ACT_开头的表，我列一下常见分类：

看到这些表，后面的业务开发心里就有底了：查询任务列表可以直接查运行库，报表统计走历史库，用户和组是独立的身份区。这比把什么都塞进一张大日志表要清晰得多。

4.3 中文字符编码：不显眼但总在关键时刻捣乱

用activiti-app时，最隐晦的问题就是乱码。表单名称、流程名称、审批意见，哪一段都可能遇到。根因大多是两个：容器没按 UTF-8 解码请求，或者数据库连接串没带上字符集参数。

所以对接 MySQL 时，连接地址一定要写清楚编码参数。除了启动参数-Dfile.encoding=UTF-8，我在 Tomcat 的server.xml里也会检查连接器配置是否支持 UTF-8 编码。你新建流程跑中文内容时，如果出现保存后内容变成问号，八成就是这一层出了问题。

排查编码问题时，有一个取巧的方法：点击流程实例详情，看历史数据里存储的中文是否正常。如果历史记录正常而列表页乱码，问题大概率在浏览器渲染；如果历史记录本身就乱码，那就要回查 Tomcat 和数据库连接配置。

5. 可复用的踩坑手记与越用越值的功能盘点

5.1 三个最容易“卡壳”的现象，以及背后的真实原因

我自己在折腾activiti-app时踩过不少坑，这里挑三个最有代表性的，给后来的朋友们一个警示。

第一个是“编辑后保存没反应”。这通常不是网络问题，而是浏览器对老版前端框架支持不好。activiti-app的建模器基于比较老的 AngularJS 技术栈，新版 Chrome 上偶尔会出现点击按钮没反应的诡异现象。切到 Firefox 基本能稳定复现，这里我建议你用 Firefox 操作建模器更稳。

第二个是“同一个流程定义发版失效”。很多人改完流程以后重新部署，发现新发起的实例还是旧的。这是因为 Activiti 的流程定义缓存机制默认会优先使用版本编号更大的定义，如果你用同一个 key 发版，必须确认版本号已经递增。某些情况下，你可能需要先在管理后台做流程定义下线，再部署新版本。

第三个是“重启后任务不见了”。这正是上面提到的 H2 数据文件位置问题。使用 war 包部署时，H2 默认数据文件可能存放在 Tomcat 启动目录下，而不是 webapps 目录里。重启 Tomcat 前先确认当前工作目录，或者干脆尽早切到 MySQL，省得每次怀疑数据丢没丢。

5.2 一批值得实际借鉴的设计思路

除了跑通流程，activiti-app里还藏着不少可以抄进自己项目的设计。它的首页应用市场模式，本质是把引擎能力封装成一个个可发布的应用，这对做系统集成很有参考价值。你在设计自己的流程中心时，完全可以借鉴这个思路：一个流程中心不应该是孤立的流程列表，而应该是业务应用挂载流程的统一入口。

表单自动生成机制也算一个亮点。流程定义里挂表单定义，前端根据渲染配置动态生成表单，这个设计在目前很多低代码平台里依然常见。如果你要自己实现流程表单方案，这套“引擎定义 + 前端渲染”的思路可以直接沿用。

最后是报表和监控。官方 Demo 里自带报表板块，可以看流程平均耗时、任务处理情况。很多项目都忽略了这一块，到上线后想要数据，还得重新开发。我建议一开始就用它的历史表做基础看板，Activiti 的表结构对统计场景支持得不错，只要你会写基础 SQL，就能做出不错的报表雏形。

5.3 别急着删掉 demo，留着做回归测试用例

最后说一个习惯：我接手类似项目时，从来不会第一时间清空官方 Demo 里的数据。那些预置流程实例、用户组、应用模型，恰好可以当回归测试的基线。改动引擎配置、升级版本之后，跑一遍预置流程，能快速确认系统关键链路是否还正常。

等到业务模型逐渐丰富，完全取代了这些测试模型，再清理干净也不迟。我自己就是从这套 demo 开始把流程引擎的运行规律摸清楚的，后来再做自己的流程平台时，很多设计决策都源于当时反复折腾activiti-app获得的直觉。

所以我的建议很直接：如果你手头恰好有 Activiti 6 相关的升级、维护或技术调研任务，花半天时间把这个官方 Demo 完整跑透，比看十篇讲解都管用。它虽然不是现代 Web 产品的样子，但流程引擎的核心路径全在里面，能玩明白这一套，再面对真实项目里的各种拍脑袋需求，都不会觉得摸不着头脑。