博客园_webreport

用子流程来分解大流程续

2012-02-03T04:19:00Z

年前写过一篇，用子流程来分解大流程。当业务流程处理环节多，繁杂时，可以用子流程来分解。就像我们程序员最熟悉的子函数一样，把处理同一事项的归纳成一个子函数，子函数可以在多个场景多次调用，也可以在同一场景中反复调用。

用子流程来分解大流程，作用和子函数类似。将功能处理过程比较独立或者单一的归纳成一个子流程。子流程本身是一个完整的处理过程，可以单独启动执行，也可以嵌入到其它流程中使用。

单独启动执行：这种就是常见的业务流程的使用。

嵌入其它流程中被调用：和主流程就会有千丝万缕的关联了。
分析一下，主要体现在，传入传回参数，同步异步的运行。和子函数不同的还有，主流程实例和子流程实例之间的对应关系。

传入参数：主流程送给子流程的参数，和子函数的调用参数一样理解。
传回参数：子流程运行结束，返回给主流程的，和子函数的返回值一样理解。

同步：主流程运行到子流程，启动了子流程了，需要等待子流程运行结束，返回主流程，主流程再接下去执行。和子函数的同步调用一样。
异步：主流程运行到子流程节点，启动了子流程了，不需要等待子流程运行结束，立即就返回了主流程了，接着主流程往下执行。和异步调用子函数类似。

主流程实例和子流程实例，一对多的关系：主流程实例运行到子流程时，启动一个子流程实例。当主流程因为循环，返回，自由跳转等等返回到子流程节点之前，再次运行时，会再次启动子流程实例，这时候是又生成了一个新的子流程实例了。主流程实例只有一个，形成了主子流程实例，一对多的关联关系。

主流程实例和子流程实例，一对一的关联：主流程实例运行到子流程实例时候，启动一个子流程实例。当主流程由于多种原因返回到子流程节点之前，需要再次启动子流程实例时，
当子流程实例未运行结束时候，则不产生新的子流程实例，继续原来的子流程实例的运行。
当子流程实例已经运行结束了，则将子流程实例再次激活，并回退到开始节点，重新运行。

总之，使得主子流程实例始终是一一对应的关系。即当已经产生了一个子流程实例后，就不会再产生新的子流程实例。

子流程的运用场景：
1、将功能单一的业务流程嵌入到大的业务流程中。可以在多个业务流程中被调用，也可以同一个业务流程中多次被调用。
如整个采购系统中的退货流程，退货流程本身是规范的，没有歧义的，按照退货办理顺序流转。可以主动发起退货流程，也可以嵌入到采购流程中，库房管理流程中，销售流程中。。。。。

2、分解大的业务流程：
通常很多企业上工作流系统，是因为业务流程繁杂，环节多，步骤又多变，便于流程化管理和后期的维护，才会选择工作流管理系统。当一个页面都显示不下一个业务处理过程的节点时，很自然的就会考虑用子流程来分解大的业务流程，使得界面更加清晰流畅，而事实上，那么大的业务流程肯定是可以分类的，用子流程来分解是最好的方法。

但是，用子流程只是为了分解大的业务流程的话，主子流程实例就必须是一对一的关联。如主流程实例运行到子流程后，启动了子流程，返回主流程，主流程因为各种原因，返回了，再次运行到子流程时，应该是重做子流程的业务，而不是再次启动一个新的子流程。因此主子流程的衔接需要这样一个开关来决定是一一对应的还是一对多的关联。

本文链接

导入excel文件处理流程节点的解决方案

2012-01-18T03:13:00Z

在没用管理系统的时候，很多企业都会将一些生产或流水线操作的数据保存在excel文件中，按名称或按sheet页形成多份excel的表格数据。

当运用了工作流管理系统后，这些生产或流水线的操作都会记录成流程的节点，过程需要记录的数据，也会应用到管理系统中。通常是建立数据库，建立数据库表来存储这些记录。

原来记录在纸质或excel文件中的数据，就需要通过工作流管理系统，执行流程的节点，打开节点上的表单界面，录入这些数据，并保存到数据库表中。

这样企业用户在操作习惯上会有些变化，原来存excel文件的，现在需要通过表单界面来录入。

用户为了更方便自己，会提出，我们还是按原来的方式，记录在excel文件中，或者说，我们记录了excel文件的，能不能选择excel文件，上传一下，然后再从流程的表单界面中展现出这些数据，并可编辑和维护，然后继续流程的流转。

为了适应这种功能，我们就必须在流程节点的表单中加上上传excel文件的功能。

在我们eform自定义表单中，有上传附件的控件，但是和这种需求稍有区别：eform上传附件的控件，文件会上传到web服务器的目录中，不会打开文件将数据导入到数据库表。其实打开excel文件，将数据导入到数据库表，这个要用自定义代码来实现更方便。

下面是实现这个需求的过程：

在流程节点表单中加上上传附件的功能按钮，点击后模态打开上传附件的选择页面。

选择需要上传的附件，点击上传，上传附件的页面是用的基本的 type=file的标准控件。action指向后台的类，当选择好文件，点击上传后，后台类截获到上传的文件流.
是j2ee的工程，就利用poi包，分析excel文件的行，列，单元格，取出数据，将数据拼成insert into 的sql语句，将数据写入数据库表。
是dotnet的工程，就利用分析excel文件的dll，分析文件的行、列、单元格，将数据拼成insert into 语句，写入数据库表。

上传完成后，关闭上传页面，返回到流程节点表单录入界面，并且刷新页面，页面表格中显示的，就是刚才excel文件中上传的内容。

用户可以编辑修改表格中的内容，点击执行后，再次提交修改后的记录，并执行流程的流转。

因为后台分析excel文件，是取的输入流直接分析的，因此web服务器中没有存直接的文件。

将上传附件按钮功能封装成一个共用的js函数，打开特定的上传附件的页面。在上传附件的页面中接收流程实例id, 标识存入那张业务表的参数。

每个excel文件的格式必须固定，每列需要和数据库表的字段绑定。

这样在流程节点中挂接的业务表单中，需要上传附件功能的，就定义上传附件的按钮，调用封装好的js函数，并按照标识写入数据库表。这样做到在流程节点的表单中快速的集成导入excel文件的功能。

本文链接

用子流程来分解大流程

2012-01-11T04:03:00Z

企业的业务处理过程如果简单，不繁琐，几步就处理完成了的，不会考虑上工作流系统。如果处理过程繁杂，处理步骤很多，涉及到很多工序，而且处理时间很长，就必须用工作流系统了。统一管理，统一运行，无论处理的过程以及路由如何繁杂，这都是工作流系统最擅长的了。并且后续的维护、修改、变更也能快速的相应。这些是用硬编码的方式来实现无法比拟的。

企业选用工作流系统，还有一种情况，当企业的业务处理种类很多，虽然每种业务的处理过程不复杂，但是种类太多，用硬编码的方式来控制流转工作量太大，多一种业务处理过程就需要做技术人员扑上去，开发，测试，发布，部署，试运行一次，而且后续的维护和修改更加无法控制，这样企业也是无法忍受的。

用工作流系统统一建模，将业务处理过程图形化的方式展现出来，一个业务办理的过程用流程中的一个节点表示，有多少个业务办理过程，就有多少个流程节点。

工作流引擎是业务流程的抽象，将业务数据和流程处理过程剥离，流程引擎只负责业务流程的流转，包含节点与节点之间的各种路由方式，条件路由，循环路由，分支，合并，子流程等等。

在工作流软件产品中就表现为，业务流程的流转用流程设计器来建模，将业务的流转办理过程用流程的节点来表示。业务办理过程，在节点上挂接的业务表中处理，包含读写展现业务数据，工作流引擎是不关心业务数据的，就是说节点上办理的是何种业务，工作流引擎是不必要知道的，这样来达到业务数据和流程的流转剥离。但是，工作流引擎在处理业务流程的流转时，有时候需要一些业务数据的参与（如条件路由，就需要取业务数据，如报销金额>10000这样的条件，这个报销金额就是业务数据），这就需要将业务数据做为实时的变量，传递到流程引擎的上下文中，使得流程引擎能读取到。所以我们经常说业务数据和流程数据是交互的，既要分开又要有关联。

当一个业务流程建模好了，并且业务表单也挂接上了，就可以运行了，运行的顺序按流程建模的节点顺序向前流转。

运行的结果可以在流程的运行轨迹图上面直接查看，当前运行到那里了，走过的轨迹也有图形的方式查看。每个节点上办理的业务，通过双击节点，打开表单，还原当时的业务数据。双击当前正在办理的节点，打开表单，办理这个节点上的业务。提交后，这个节点任务就办理完成，从轨迹图上面又可查询到，当前运行和流转到那里了。

这种的流程运行方式，在常见的生产制作等等行业都是很实用的。通常在审批流中，不是很有用，审批流的流转通常是给下一步的办理人发送一条需要审批的待办事项（待办任务），具有审批权限的人登录到系统后，在我的待办任务中，查看到待办事项，点击进去执行审批。

当一个业务流程的办理节点数很多，或者说一个业务流程实例一启动，办理的过程就是几个月。那么这种类型的流程节点数量一定会很多。用流程建模的工具来查看或者编辑，会显得有些笨拙，节点数量大多，一个界面都放不下，这种情况，我们通常可以有选择性的用子流程的方式来分解，这样使得界面更简洁。

本文链接

流程实例运行轨迹的运用

2011-12-19T03:24:00Z

运用工作流系统之后，流程的每次流转每次执行都会被记录下来，直到流程结束。这些被记录下来的记录就是流程实例的运行轨迹。运行轨迹的每条记录都会有一个主键id，用于唯一标识这条记录，这个主键id，就是流程实例轨迹id。

每个流程实例都有自己的运行轨迹，这个运行轨迹可以用列表也可以用图形的方式来展现。

流程实例的监控，大多是监控这个流程运行的轨迹。通过二次加工和定制开发，或再加上定时器的功能，可以做一些居于图形的实时监控。
如，直接图形化显示监控流程的运行轨迹变化；点击图例，输入一些值（业务数据），作用于流程，并使得流程运行轨迹发生变化等。

流程实例如果执行循环路由，或自由回退等，反复的执行同一个步骤，如验收时，发现问题，返回重做，反复的返回重做（类似项目软件开发，需求总变化，反复的重做）。这样一个步骤就会执行了很多次，每次执行的时候，都会记录一条运行轨迹记录。如果客户希望通过监控流程运行轨迹，能清楚的看到每次重做时，都重新做了那些业务，这样就需要将流程实例轨迹id和业务记录一一关联上，在监控流程实例轨迹时候，通过轨迹id，就能取出业务记录了。这样就能清楚的还原当时的修改。

如果将流程轨迹id和业务记录关联上，业务表也应该是一个类似的日志表，能记录多条业务信息，在eworkflow的通用审核表中，就增加了轨迹id( trace_id)这个字段，当发生一次审核的时候，就往通用审核表中增加一条记录，并记录上trace_id。审核结果查看时，就根据trace_id关联出通用审核表中此审核记录，将审核结果和审核意见取出显示。这种通用审核，不论多级审核，都无需再做表结构等的设计，多一级审核即多一条记录，后期有需求变更或流程流转的修改，要修改流程节点时，多增加一级审核或去掉一级的审核都很方便。

流程引擎在获取每次运行的节点时，都可以将流程轨迹id取出，送到节点上关联的表单中，在业务表单中，可以取到此轨迹id（trace_id），根据业务情节的需要，合理的运用此流程轨迹，实现更多的业务。

本文链接

工作流引擎集成表单之工具条运用

2011-12-07T03:31:00Z

工作流引擎只负责业务流程的抽象模型的建立，解释和运转，业务模块还是在业务模块中完成。
当一个成型的流程引擎在和业务模块集成时，需要做如下几点的集成：

1、业务模块中业务数据保存的同时，要调用流程引擎的执行流程流转的api函数，如，未初始化得到流程实例id的，就需要初始化流程，已经初始化的需要执行流程的流转。并且业务模块的保存和流程的流转在同一个事务中。

2、业务模块中录入控件的操作权限设置，通常是只读，隐藏等。使得表单挂接在流程的各个节点上对各个控件的操作权限不一样。

3、业务关键数据需要传递到流程引擎中，使得流程上下文能读取，作用于流程。

通常需要做这三方面的集成。

为了更方便集成业务模块或表单，通常会将启动流程，执行流程的流转等行为api再次封装成通用函数。在表单或者模块中调用，只需要传递流程名称，流程版本等参数，就能达到执行流程流转。

如果用表单工具的话，这些封装就显得更重要了。

自定义表单工具，可视化的设计录入界面。将和工作流引擎相关联的api函数，再次封装成通用函数，在表单的设计界面中就可以选择。并进一步将这些函数封装成可配置的工具条按钮，在自定义表单页面中引入。

如这样一些表单按钮功能，都是工作流引擎集成自定义表单必备的：

暂存：只提交业务数据
提交：提交业务数据并执行流程
执行：只执行流程
轨迹：查看流程实例的运行轨迹
挂起：挂起流程实例，挂起后的流程实例不能执行，需要恢复后才能执行。
终止：直接结束流程实例，终止后的流程不能再恢复运行。

其中，提交和执行两个功能，又有很多种的组合变化，主要体现在，提交和执行之后的提示信息显示上面。
1、提交和执行之后，继续下面的步骤，检查当前用户是否有权限，有权限的话，继续执行下一步，将下一步可执行的表单页面打开，等待操作者执行。
这种情况最复杂，但是可以使得流程运行很连贯，一气呵成，有运用的场景的。如用户有整个流程所有步骤的操作权限时，就不希望每次都切换界面，从任务链接中继续下一步，而是每执行完一个步骤，就自动往下执行。打开下一步的界面。

2、提交和执行之后，链接到新的页面，页面显示下一步信息，操作者等等。

3、提交和执行之后，提示下一步的信息，操作者。确认后，关闭当前页面。

4、提交和执行之后，不提示也不关闭窗口。(这种运用场景可能比较少。)

将这么多的功能按钮的功能封装在自定义工具条的功能中，让用户去配置自己的工具条。或者自定义功能按钮时，选择这些执行函数。
如下面：

在表单中选择自定义工具条

设置自定义的按钮和下拉项：

这些按钮还可以设置操作权限。

充分利用这些自定义工具条的功能，使得流程引擎和自定义表单集成后功能更强大，操作更灵活，适应更广泛。

本文链接

工作流系统的一些常见名称解释

2011-11-30T03:08:00Z

第一次接触工作流系统，可能会对一些基本的术语和名词有误解。如流程实例，流程模版，流程版本等，以及这些名词之间的关系，需要有一个学习和理解的过程。这些名词和术语也是工作流系统中的通用名词，通过学习和理解后，会对这些术语和名词有一个共同的认识和理解。

如下面的词语

工作流引擎：抽象的业务流程设计模型，负责业务流程的定义，解释和运转。

工作流模版：用工作流引擎的基本概念和路由过程表示出一个业务办理过程，这个过程通常是用xml格式的文件来记录的，这个xml文件，就是工作流模版，也可以说是流程模版。

工作流名称：就是工作流模版文件的名称。也可以叫流程名称。

工作流版本：工作流模版的版本，也可以叫流程版本。在工作流系统中，对工作流模版有个版本管理，新建一个工作流模版时候，它的工作流模版是.1。当再次做修改的时候，可以选择创建新的版本，如.2。
因为一旦业务流程模版投入使用了，有了运行的流程实例了，再次对业务流程做的修改，就需要更新到新的版本中，原来的流程版本还需要存在，原来的流程定义信息，按版本仍然能查询到。新的修改在新的版本中。
流程名称＋流程版本是唯一标识一个业务流程的。

工作流建模：利用流程设计器将业务处理过程用工作流的节点方式表示出来，就是工作流建模，也可以说是流程建模。

工作流节点：是工作流引擎的设计基本节点，一个节点表示一个业务处理过程，在流程设计器中，会有相应的表示方式。

流程实例：按照工作流模版定义的处理过程启动运行的业务处理过程，即流程实例。利用建立好的业务流程模版，可以多次启动流程实例，一个流程实例即一个业务处理过程。如请假审批的流程，张三填写他的请假单，启动一个审批流程实例。李四也填写一个自己的清单单，也是启动了一条流程实例。

流程实例id：每条启动的流程实例，在工作流引擎中，都会对应一个流程实例id，来唯一标识这条流程实例。

轨迹id：轨迹id通常是指流程节点的运行轨迹id，当一个节点在流程实例中被反复运行的时候（如循环路由，自由流），每次到达这个节点的时候，都会产生一个轨迹 id，trace_id, 唯一标识这次的运行轨迹。

业务数据：流程中每个节点上处理的业务记录等。通常流程数据和业务数据是有关联的。

流程设计器：利用工作流引擎的设计基本节点和概念给业务流程建模的可视化编辑工具，就是流程设计器。

当前步骤：流程实例未结束前，正运行到的当前节点，为当前步骤。

历史步骤：流程实例运行完成的节点，都认为是历史步骤。

流程实例运行轨迹：每条流程实例在工作流模版的节点上运行的轨迹。

流程实例监控：监控每个流程实例在各个节点的运行情况。

任务：每条流程实例在运行到流程的各个节点时，会产生一些待执行的任务信息。有任务名称，描述，和参与人，完成人等任务的基本信息。通过任务链接到待处理的业务过程。

任务参与人：任务信息的参与人，能够查看到任务的相关人。

任务执行人：可执行任务的操作人。

任务工单：任务派发下来的工单。

串行路由：业务建模中，节点按顺序一个一个的往后串联的方式。

并行路由：业务建模中，节点并行的方式往后链接。

条件路由：业务建模中，按设置的条件为真，链接一个路由方式，条件为false，往后链接一个路由方式。在流程实例运行时，只会执行一条路由，即条件要么＝true，要么=false.

分支：业务建模中，平行分支的节点路由方式。

合并：业务建模中，将平行分支的节点路由再合并起来的路由方式。

子流程：为一个独立的业务流程，嵌入到主流程中。

循环路由：在节点间或同一个节点上循环执行的路由方式。

自由流：流程实例不按照流程模版中预定义好的节点顺序往下执行，而是可以自由的跳转。

回退流：流程实例不按照流程模版中预定义好的节点顺序往下执行，而是回退到曾经运行过的任意节点上。

业务补偿类：在流程发生自由跳转的时候，需要辅助执行一些业务处理过程来对业务数据进行修改。

这里只是列出一些常用的工作流系统中的术语，不体现流程引擎的设计基本概念。

特别是流程模版，流程实例，业务数据这之间的关联和区别：

流程模版，是将业务处理过程用工作流引擎的支持的方式表示出来的一个模版文件。
流程实例，按照工作流模版定义的处理过程启动并运行的业务处理过程，通常对应一条主业务数据。一条流程实例在流程引擎中会有一个唯一的流程实例id，通常命名为wf_id，在业务数据的主业务表中，也需要建立一个wf_id字段，来和流程实例关联上。

例如请假审批的流程，请假单，就是业务主表。报销单，报销单的主表，就是业务主表。

根据需要，可能在业务表中，还可能会增加轨迹id字段，来进一步控制业务数据与工作流数据的关联。

本文链接

aspx页面集成工作流引擎api

2011-11-03T02:33:00Z

最近用户在做工作流系统的集成时，总会要求快速的集成到用户的应用系统。

一般一个成熟的工作流软件产品，会有流程设计器，流程引擎，表单设计器，流程管理中心。在流程管理中心能可视化给业务流程建模，并发起流程实例，执行流程的流转，监控和管理流程实例的运行情况。这些功能是在工作流软件产品中已经完成的功能模块，流程建模，执行流程实例的过程其实也是一个调用流程引擎api的集成过程，只是这些调用过程都封装好了，不需要用户再去关心那些代码是如何实现的。

在工作流系统集成到应用系统时，集成方案，分二种，一种是直接调用流程管理中心的可视化模块，将这些可视化模块的url链接挂接到应用系统的菜单上，使得点击应用系统的菜单，就执行这些流程的管理模块。这样就只需要在应用系统的菜单管理中多定义一些关于流程管理的菜单，就可以了。如流程设计器，表单设计器，流程模版管理，启动流程实例，监控流程实例，我的待办任务。

但往往是事与愿违的，流程管理中心的那些可视化功能，有的用户会觉得不够用，或者是不能完全满足最终客户的需要。总是需要重新编写一些模块，如流程模版列表，用户需要增加一下查询条件。我的待办任务列表，用户希望能增加一些业务列的显示。这样的话，就必需要重新改写这些模块。这样就需要用到集成方案的第二种，调用流程引擎的api来做了。

利用工作流引擎的api来做集成，就需要了解都提供有那些api接口和函数，就不如第一种直接的模块集成那么方便了，需要编写代码来实现。不过，流程引擎提供的api接口和函数总归是简单的，不会太复杂，而且已经有了实现的方案（流程管理中心的实现过程就是示例），照着示例去做就ok了。

例如，在aspx页面中，需要做流程模版的列表。流程模版通常有存文件和存database两种，流程引擎的api函数中，有这样的函数，可以屏蔽掉是存文件中还是存database中的区别，只需要获取得到模版列表的arraylist，就ok了。

如果应用系统确定了流程模版只存在于database中，那还可以用sql从表中直接取出流程模版列表的方案，可能用这种对用户来说更方便了，但是就不能屏蔽流程模版保存场所的变化。

我的待办任务列表，这种是用户在集成的时候，经常需要调用api来做集成的。
在流程管理中心，我的待办任务列表的显示列，只能从流程的角度来列，有流程模版名，描述，版本，任务描述，最大再加一列业务显示列。但是如果用户需要更多的业务显示列，就只能关联到用户的具体业务表去取。

在集成待办任务列表的时候，也有两种方法，利用流程引擎的api和执行sql直接从任务表中获取。
下面以我们公司的eworkflow自定义工作流系统为例，在aspx页面中，如何调用eworkflow的流程引擎获得待办任务列表：

string userid = (System.String) Session["userid"];
       Environment env = new Environment(Session);
       Workflow wf = new BasicWorkflow(userid,env);
     ArrayList tasks = wf.getCurrentTasks("2",condition);//2待办任务，3已办

   这个tasks中，就包含有任务信息了，每一行，是一个IDictionary, 根据关键字的不同，能获取到，任务id，wfid, actionid,traceid,....等等，执行任务必需的参数。

      string flowname = wf.getWorkflowName(wfid);
       int flowversion = wf.getWorkflowVersion(wfid);
       WorkflowDescriptor wd = wf.getWorkflowDescriptor(flowname, flowversion);
       ActionDescriptor action = wd.getAction(actionId);

     action.View就是这个任务关联的业务表单，打开这个表单，执行业务过程。

     在这里就不把所有的代码都列出来了，在eworkflow中，有aspx页面集成流程引擎得到待办任务列表的示例。

在应用系统集成工作流系统时，直接利用流程管理中心的现有功能的url，是最快速的集成。有些模块也可以利用流程引擎的api来做，按照现有的调用示例，也能很快的达到集成，甚至可以通过执行sql来达到。如我的待办任务列表，就可以直接用这样的sql来做列表。

需要增加业务显示列的话，就在上面的sql中增加关联业务表，关联关系，就是任务表.wf_id=业务表.wf_id。这样就可获取到业务的任意信息做显示用了。

本文链接

应用系统切换到mysql应注意的

2011-10-28T03:16:00Z

mysql数据库简单，易用，现在越来越多的小的应用系统选择mysql数据库，也更因为mysql是免费的，不用付费。
mysql安装：以for window的为例：
将安装文件展开，执行安装：
展开mysql-5.1.6-alpha-win32(utf-8).zip后执行install.bat

安装完成后，在windows，控制面板，服务中，启动mysql的服务。

再安装mysql的客户端，类似plsqldev，但比plsqldev还是差很多。
用SQLyog604.exe这个客户端；
Navicat_for_MySQL_10.0.5.0_XiaZaiBa.exe这个记录的导入导出汉字会有问题。

然后将应用系统的表结构的建表sql转换成mysql的，常见常用的那些字段类型都支持
以eworkflow自定义工作流系统＋eform自定义表单系统为例
表结构的转换：用sqlserver的表结构，转换到mysql
int,char,varchar,datetime等均不用变化
唯有ntext 需要转换成longtext类型

转换完的建表sql如下面格式：

表主键的定义语法，和其它的有些区别.

转换完成的表结构，在mysql中建立库，执行。

当应用系统作为产品来开发的时候，在设计之初就应该考虑好对多种数据源的支持。使得切换数据库的成本最低，甚至达到，会管理和使用一种数据库了，切换的工作也就完成了。
在eworkflow工作流＋eform表单中，都预留好了接口，数据库链接的配置文件fcconfig.xml文件中，配置好ds数据库链接，如

将mysql的驱动包copy到系统的相应目录中。

fcworkflow.xml中配置好mysql的实现factory类。对每种数据库都可以有自己的实现类，因为mysql都是标准的sql，特殊性很少，所以就用JDBCWorkflowFactory做为实现类。
日期的实现函数很多数据库都不一样，mysql的获取系统日期的函数为now()，注意要将此函数替换掉原来的。

fcuser.xml中配置用户系统的Provider实现类，使得key="mysql"的类型和fcconfig.xml文件中第一个ds的dbType设置的值一致。

配置做好后，就可以开始做测试运行了。

本文链接

工作流软件产品集成struts2框架

2011-10-25T06:59:00Z

工作流软件产品只负责业务流程的流转，流程节点上业务模块的办理，以及监控业务流程的执行。通常一套工作流管理系统，会包含流程引擎，流程设计器，流程管理中心，表单设计器，自定义表单系统，表单引擎等等。表单模块可以是可选的。一套自定义表单系统也会包含一个mvc的框架，能实现前后台的数据提交和展现，并实现了分层的管理。

当客户的应用系统集成工作流软件时，客户的应用系统本身也包含一个mvc的框架，能实现代码级别的前后台数据提交和页面功能展现。利用此mvc框架，应用系统应该完成登录，菜单，用户管理，权限管理，组织机构管理等等模块。在此基础上，再集成工作流软件产品来实现业务流。

利用工作流软件产品中的电子表单系统，也能完成登录，菜单，用户管理，权限管理，组织机构等模块。因为电子表单系统如eform自定义表单系统，本身也是一个mvc的框架，能实现前后台通讯和定制界面展现，比传统的mvc框架更方便的是，eform有可视化编辑界面功能，无需编码，通过设置属性就能快速的完成业务模块的功能。

工作流软件产品集成到struts2框架中的时候，分几个步骤来做，先将工作流软件产品的后台jar包，xml配置文件，前台的ebsys目录一起copy到struts2框架的相应目录中，先做到目录结构的集成。
如下面的struts2的一个示例工程。加上eworkflow工作流软件产品后的，目录结构：

集成后，在登录模块，登录成功后，给工作流的session变量赋值。

fcuser.xml文件映射到应用系统的用户，角色等表

做完上面的准备工作后，登录到eworkflow工作流管理中心，这些可视化的功能，可以直接将url链接挂接到应用系统中做功能模块的集成。

如果这些可视化的模块不能满足用户的需要，如我的待办任务列表，客户需要任务列表中加入更多的业务信息的显示（在流程管理中心不能先关联出应用系统的业务表），则只能应用eworkflow流程引擎对外提供的api来实现。

在struts2的dao层建立eworkflow工作流对象，得到当前登录用的待办任务列表

Environment env = new Environment("eworkflow");
Workflow wf = new BasicWorkflow(userid,env);
List tasks = wf.getCurrentTasks("2",condition);//2待办任务;3已办
......

然后对tasks列表循环，根据wfid和业务表的关联，插入业务表的列。

最后，将最后得到的tasks走struts2的框架返回到页面上，显示给最终用户。

也可以利用工作流引擎中的任务表和业务表的关联，直接得到我的待办任务表
在struts2的dao层执行sql：得到任务列表返回到页面显示给最终用户
待办任务列表的sql:

本文链接

工作流集成第三方aspx页面

2011-10-21T03:19:00Z

通常工作流软件系统都会有自己的表单工具，能方便的可视化的设置出业务表单。但是很多客户在做工作流软件产品调研时，都会很关心工作流系统是否能方便的集成第三方的表单。大概是对自定义表单工具的能力不信任，也或者是对表单工具的不熟悉，抱着万一自定义表单工具不能实现自己的要求哦，还可以自己写代码来实现。

当然工作流软件产品中包含的表单工具，是能应付所有的要实现的需求的。可视化的设置功能达不到，还可以通过编程的方法来达到，因为表单工具本身也是一个开发工具，用传统的dotnet或java能实现的，表单工具也一样能实现。

如果达不到那就是表单工具的问题了，象我们的eform是完全可以达到的，eform封装了很多业务模块实现的通用功能和控件，常见的录入方式，都可以通过界面配置来完成，当需求特殊，不具通用性，eform没有提供时，可以通过代码来实现。eform本身也是一个类似jquery的工具，大量运用了ajax，并封装了大量的函数，代码实现的时候也很得心应手。就象jquery一样，如果要自定义代码，需要熟悉一下框架的一些基本函数，熟悉了，就很快了。但毕竟需要自定义代码的地方不多。

eform表单设计器

当客户觉得自己的应用还是够复杂，需要自己写实现模块的时候，工作流系统也需要提供集成第三方页面的方法。集成第三方的页面，可以是htm,jsp，aspx等。用dotnet的通常就是aspx页面了。

在流程设计器中，需要能将aspx页面挂接到流程的节点上，当流程运行到此节点时，能打开关联的aspx页面。这是最基本的要求。

挂接到流程中的aspx页面，要实现两个方面的基本功能，首先要做好自己份内的事，实现业务录入，界面编辑，保存用户录入的数据。另一方面需要执行流程的节点，使得流程得到递进。

业务信息的录入，保存按应用系统的mvc方式来实现。执行流程的递进，就需要调用流程引擎对外提供的api接口了。

如下面这样一个请假的流程：

在集成aspx页面的时候，需要按照如下过程进行：
在流程定义的时候，节点上挂接aspx页面，同时，加上?1=1 ，在流程引擎打开这个页面时，会将流程的相关信息按&关键字＝值这样的方式拼接到url后面。在aspx页面中按关键字获取这些流程相关的信息，为表单提交时，执行流程递进做好准备。

启动流程，运行的url如下：
../aspx_dj/leave_init.aspx?wfName=wf_leave_init_aspx&wfVersion=1&initActionId=4960&actionId=4926

打开leave_init.aspx页面，后面的参数标明业务流程名称，版本。初始化动作id，和第一个动作节点id

aspx业务表单在提交的时候，做好了业务数据的提交之后，再调用流程引擎的api执行流程节点的动作，使得流程得以递进。
集成的api接口函数调用代码如下：

业务数据的提交，和流程的动作执行，应该在一个事务中，保证整个流程的事务一致。

本文链接