web工作流管理系统开发41-43.doc

四十一 流程的单起点和多起点工作流软件产品在建模的时候，通常都是从开始节点开始，经过一序列的节点，最后到结束。因为有些业务的特殊性，可能会需要有多个起点，也可能会在流程的某个节点就结束了，这里就涉及到流程的多起点，和多结束点的问题。通常工作流引擎都需要支持流程的多起点。多结束点倒是很简单，可以通过条件跳转等等来达到流程的某个节点就转向结束。流程的多起点表现方式有很多种，例如有的需要定时启动一个流程实例；同样一个业务流程，不同的人启动时，所走的步骤不一样。单起点模式：多起点模式：注：图中的开始节点是个虚拟的节点，流程实例都是从初始化动作开始的。流程在和业务表单的集成时，流程实例的启动，又分为两种情况：从业务模块中启动固定的业务流程，在业务表数据提交时，再启动一个流程实例，并将流程实例id绑定到业务表记录。先启动业务流程实例，再运行业务流程第一个节点上关联的业务表单，填写业务表单数据，将流程实例id和业务表记录关联上。单起点的模式，适合在业务模块中绑定业务流程，当业务表记录提交时，保存业务数据的同时，启动一个流程实例，并执行单点的初始化动作，得到 流程实例id，并将流程实例id写入业务表的同一条记录。(如果业务流程的第一个节点为处理此业务表单，则业务流程还需要执行完第一个节点，使得流程实例 流转到第二个节点)这种类型的集成，有些不够灵活，需要在业务模块中固定启动那个业务流程，并且业务流程是单点启动的模式。如下图：在业务模块表单中，绑定固定的请假流程，业务表提交后，启动固定的流程。多起点的模式，流程实例在启动时，需要选择起点，所以不太适合在业务模块中绑定流程的启动方式。当然，如果取出多个起点，列在业务模块中，供用户选择，也是可以的。这样做会使得业务模块比较复杂。因此，多起点的模式，通常是先确定好起点，获得了流程实例id，再执行流程的第一个节点，打开第一个节点上关联的业务模块，执行业务模块的提交，并将流程实例id写入业务表记录中。单起点和多起点的模式，都适合先启动一个流程实例，再按照流程的节点往下运行，打开第一个节点上关联的业务模块，执行业务模块的提交。这样会有一个 缺点，流程实例启动后，操作者不执行第一个节点，那么流程实例就停在还没有和业务表记录关联上的状态，需要通过任务提醒等功能督促此流程实例继续运行。四十二 业务规则和业务过程在工作流软件产品中，产品的扩展性和易用性是衡量软件产品的重要指标。大家都知道，工作流软件系统会包含流程引擎，流程管理中心，流程设计器，任务调度，定时器管理等等.，其中流程引擎是核心，流程引擎完成 对所有业务流程的抽象，建模，以及抽象的业务流程节点的定义、流转。但是流程引擎完成的是抽象的业务流程节点的流转，当给一个具体的业务流程建模后，启动 这个业务流程，才开始一个具体的应用。在具体业务流程中，常常会伴随有一些具体的业务规则和业务过程的实现，这些是流程引擎中不包含的，流程引擎只负责通 用的抽象的节点的流转和实现，具体的业务规则和过程，是和具体的应用系统紧密关联的。例如，审核月终报销的时候，要引入一些相应的规则来做判断，如部门经 理引入部门经理级别的每月通讯费报销范围，餐费报销范围，交通费报销范围，等等，通过这些数据来判断报销申请是否审批通过。这个判断过程是和具体的应用紧 密关联的。在工作流引擎在设计之初，就应该考虑好如何方便的引入具体的业务规则和业务过程，当然这些业务规则和过程是需要有具体的实现的，不是流程引擎能做到的。如何引入这些具体的业务规则和业务过程，常用的处理方案有3种。1、在流程节点中挂接的业务模块中实现2、在流程节点的前置后置事件和规则判断中引入3、利用流程的变量表达式来实现下面详解每种处理过程：1、在流程节点中挂接的业务模块中实现 工作流引擎给业务流程建模后，业务流程就按照定义的流程节点来流转，到达节点后，节点上挂接有业务模块，业务的办理就在业务模块中实现，工作流引擎是不负 责具体的业务模块的实现。业务模块我们通常会利用开发工具做成一个页面或者是一个业务表单来实现，在业务表单中实现业务数据的录入，修改，甚至是和其它数 据的关联交互等等。这种的业务表单，可以是利用开发工具定制的表单，如具体开发的jsp页面，aspx页面；也可以是利用表单工具可视化的画出的业务表 单，如eform自定义表单通过拖拉的方式建立的htm页面。 在业务表单中，可以方便的引入一些业务过程或者业务规则判断，如在提交产品入库单之后，更新产品库存表的库存数量，就可以在保存入库单的数据之后，再更新一下库存数据。 在业务模块业务表单中实现的业务过程和业务规则，通常都是和流程上下文关联不是很紧密的，只是业务处理过程。这种的就可以直接在业务模块中实现。 2、在流程节点的前置后置事件和规则判断中引入 工作流引擎抽象的节点，一般都会提供有前置后置事件函数，便于流程做业务过程的扩展。当流程运行到此节点的时候，会触发前置函数，离开此节点会执行后置函数，至于函数的内容，就是具体的业务过程了。 在前置后置函数中，只需要实现固定的函数接口，如FunctionProvider，FunctionProvider接口有一个execute()方 法，方法中包含3个参数（当函数运行时，通过execute()函数的3个参数，可以获得流程的相关信息，数据库链接，事务等等），业务过程就可以在此方 法中实现。.net的FunctionProvider接口：void execute(System.Collections.IDictionary transientVars, System.Collections.IDictionary args, PropertySet ps);java的FunctionProvider接口：public void execute(Map transientVars, Map args, PropertySet ps) throws WorkflowException; 业务规则的引入通常是在流程节点的条件判断中引入，例如审核加班单，需要引入加班当天的指纹打卡考勤记录，加班的时间段，是否在指纹打卡考勤记录的时间段 中，是则审核通过。这个过程判断，就可以实现一个规则判断接口，如Condition接口，提供一个passesCondition()函数，返回 true，或false. 在passesCondition()函数中写具体的规则判断，流程的相关信息，等等都通过passesCondition()函数的三个参数来获取。.net的Condition接口： bool passesCondition(System.Collections.IDictionary transientVars, System.Collections.IDictionary args, PropertySet ps);java的Condition接口： public boolean passesCondition(Map transientVars, Map args, PropertySet ps) throws WorkflowException;3、利用流程的变量表达式来实现有些业务规则和过程常常会每个流程实例都不一样，这通常就需要在流程建模时引入变量或表达式，当流程实例运行时，给变量赋值。每流程实例赋的值可能不一样，这样来达到每个流程实例的不一样。例 如；费用报销单的一审人，需要是报销单填写人的直接上级。而可以填写费用报销单人，可能是各个部门或所有员工都能填写。这样的话，就可以给一审的审核人定 义一个变量，例如$xx_leader，当费用报销单填写完成后，就通过前置函数的业务过程，查找到当前申请人的直接上级，将上级的用户id，存到变 量xx_leader中，当到达一审节点时，这个变量就有值了。变量又分为临时变量和持久化变量，临时变量仅存在于流程的一次流转当中，前面过程中给变量赋值，后面的过程就能获取到值了。持久化变量，只要保存了值了，后面的所有过程就都能使用了。利用流程的变量表达式的过程来实现业务规则和过程，常常还是需要辅助1,2两种方法来实现。在 工作流软件产品中不需要包含具体的业务规则和业务过程的实现，但是一定要能方便的引入业务规则和业务过程，便于扩展。而通常工作流软件产品中，变量表达 式，节点的前置后置事件等等都是为了方便做业务规则的扩展，合理的利用这些使得工作流软件系统和应用系统结合的更完美。四十三 集成应用系统工作流软件系统做为一个开发组件，只实现了工作流引擎，工作流的建模，流程实例的创建，流转等等。不包含整体的业务系统，当集成到用户的应用系统时候，需要作为组件的方式集成。集成的方式有多种，一般来说，用户系统是首先要集成的，应用系统的一般都会有自己的用户系统，包含，用户，角色，权限等。这些不包含在工作流软件系 统中，但是在工作流软件系统中又一定会用到，流程节点的执行权限等，都离开用户角色权限等的设置。因此用户系统的集成是必须要做的。1.用户系统的集成采用映射表的方式，在 工作流系统之三十四 集成用户系统2.工作流软件系统功能的集成工作流软件系统的可视化可操作的功能模块一般都会包含：业务流程设计器，业务流程建模管理，业务流程版本管理，业务表单(电子表单)管理，业务流程实例的发起，跟踪，监控. 任务管理，我的待办任务，我的已办任务，我的抄送任务，我的流程实例.这些都会提供可视化的可操作的功能，和用户的应用系统集成，可以将这些可视化的功能模块直接集成。可视化的功能模块，直接将url挂接到应用系统中。例如，业务流程设计器，将打开业务流程设计器的url作为菜单，定义到应用系统中，在应用系统中就可以直接使用。（当然流程设计器的前后台代码类等都需要集成到应用系统中）3.调用工作流引擎的接口api方式的集成利用流程引擎对外提供的接口api函数来驱动流程。例如，启动指定的流程实例，执行指定的动作，获取当前用户的待办任务列表等等。工作流引擎内部实现抽象的业务流程建模，以及抽象的业务流程节点的流转，对外以接口api函数等的方式提供调用。流程管理中心的可视化模块也是利用这些接口函数来实现的。当流程管理中心提供的可视化操作模块，不能完全满足用户的需要时，可以通过调用流程引擎的api的方式，定制适合自己的业务模块。例如启动一个业务流程实例就有两种方式：1.先启动流程实例，得到流程实例id，再进入流程的第一个节点，运行第一个节点关联的表单。当表单提交时，将wf_id一起写入业务表。2.先打开流程第一个节点的业务表单，当表单提交时，再启动流程实例，获得流程实例id，和业务表单数据一起提交。然后再运行完流程的第一个节点，使得流转到第二个节点。这两种方式的启动，在流程管理中心都会有直接的模块对应。但是当这两种方式还是不能满足具体的需要时，可以结合自己的实际调用流程引擎api的方式，定制实现。我的待办任务，已办任务，任务管理等信息，等等可视化的模块，列表项，更多的是反应流程管理，业务数据项很少，在集成的时候，用户也是经常需要列出更多的业务数据。这个也可以通过调用流程api的方式来达到。业务表单的提交流程的动作执行：当工作流软件系统集成定制业务表单的时候，需要将表单业务数据的提交和流程的流转放在同一个事务中。