CN109886656A - 一种支持多系统的工作流引擎系统 - Google Patents

Abstract

本发明公开了一种支持多系统的工作流引擎系统，工作流引擎系统通过程序接口与各个业务系统功能模块对接数据，通过统一的地方审核不同系统的业务。本发明有以下优点：1通用性强。本工作流引擎系统能通过http接口接入多个不同业务系统，为不同的业务系统提供审批。不同的业务系统如果实现了回调接口，工作流引擎也可以回调业务系统实现工作流对业务系统的回调。所以通用性很强。2维护成本低。业务系统接入工作流完全通过接口，通过配置即可，无须编代码。3图形化流程绘制。通过图形化拖拽的方式绘制工作流，操作方便，使用简单。

Description

一种支持多系统的工作流引擎系统

技术领域

本发明涉及业务流程处理领域，特别涉及一种支持多系统的工作流引擎系统。

背景技术

很多公司业务审核流程比较多、系统多、各个审批流程的差异性比较大，为了能兼容现有各个系统以及考虑到公司信息化的发展，所以设计了本工作流引擎系统。

现有的工作流引擎系统主要具有以下缺点：

1与业务系统深度耦合，维护成本高；

2只能接入单一的渠道；

3只能支持某一类用户。

发明内容

本发明的目的在于克服现有技术的不足，提供一种支持多系统的工作流引擎系统。

本发明的目的是通过以下技术方案来实现的：

一种支持多系统的工作流引擎系统，工作流引擎系统通过程序接口与各个业务系统功能模块对接数据；业务系统发起流程时调用设定地址创建工作流实例，通过参数“sys_id”表示不同的系统，sys_id＝APP表示本业务由APP渠道发起，sys_id＝PC表示本业务由官方网站发起，sys_id＝WECHAT表示本业务由微信系统发起；

业务系统发起或者在业务系统端审核某个业务流程时，流程的流转由工作流引擎系统控制，业务系统会请求工作流引擎系统执行相应的操作，工作流程引擎系统执行完毕后会调用启动回调操作；

工作流程引擎系统根据“sys_id”的值通过数据库查找对应的业务系统回调的地址来实现回调；

业务系统逻辑执行成功后返回code值给工作流程引擎系统，工作流程引擎系统再返回code值给业务系统。

作为优选方式，通过web界面来操作和访问，这样既实现了各个系统的工作流任务又能在这个系统统一看到各个流程流转情况。

作为优选方式，业务系统通过http接口传递参数到工作流引擎系统，工作流引擎系统创建一个流程实例，然后通过http接口调用业务系统的逻辑，逻辑成功后返回成功标志给工作流，再返回给创建接口。

作为优选方式，程序接口包括流程实例创建接口、流程列表查询接口、流程详情查询接口和流程节点跳转接口。

作为优选方式，流程实例创建包括如下步骤：

1)通过业务系统传来的业务编号(bus_id)获取到对应的流程id；

2)把业务需要用的值存进变量表；

3)调用activity的接口runtimeService.startProcessInstanceById()创建一个新的实例；

4)寻找办理人，在找办理人时调用mongodb，获取人员的姓名等信息，并且将接收人员信息，发送人员信息，流程信息，写入办理人历史表；

5)封装返回的对象。

作为优选方式，流程列表查询包括如下步骤：

1)调用方传来处理人信息，任务id，操作编号，其他参数变量；

2)根据操作编号看执行提交还是退回，如果是提交，调用方法taskService.complete(taskid,dyna_arg)；

如果是退回，则通过删除原来的路径创建新的路径来实现；

退回到哪个节点可以由调用方传过来或者在流程中指定好，直接配置在配置信息里；

如果下一个环节是子流程，还需要将多实例的办理人组装好，放在变量中；

3)寻找办理人，办理人可能是指定的角色，客户经理，指定的人，这些信息都是在monggodb中获取，并且将接收人员信息、发送人员信息、流程信息写入办理人历史表；

4)将重要信息写入变量表；

5)封装返回的对象；

6)回调业务系统的接口，改变业务数据的状态。

作为优选方式，流程列表查询还包括步骤7)如果由节点配置了发送短信的listener，在产生新任务的时候会调用发送短信的listener。

作为优选方式，流程详情查询包括如下步骤：

1)待办、已办、办结是一个接口地址，通过参数querytype判断查询什么数据；

2)待办：把activity的act_ru_task表中的数据、从mongodb中取出的姓名等信息、实例表、按钮配置表四表联合查询所得；

如果是多实例节点并且是并行执行，还需要把多实例节点上已经办理过的任务剔除；

已办接口、办结接口通过实例表、按钮配置表、历史表查询。

作为优选方式，流程详情查询根据用户id过滤查询个人的数据或者查询所有人的待办，根据allorpart决定(allorpart参数如下：0表示查询所有用户任务；1表示根据用户id查询任务)；

过滤还包括根据系统，业务类型，分站，公司名称等参数进行过滤。

作为优选方式，流程信息调用步骤：

1)调用方传过来一个实例id，通过实例获取流程相关的信息；

2)返回包含流程id、名称、业务编号、业务名称、公司信息，标题信息、创建人、创建时间、业务表id、业务表主键、每个节点操作的历史记录。

本发明的有益效果是：

本发明有以下优点：

1通用性强。本工作流引擎系统能通过http接口接入多个不同业务系统，为不同的业务系统提供审批。不同的业务系统如果实现了回调接口，工作流引擎也可以回调业务系统实现工作流对业务系统的回调。所以通用性很强。

2维护成本低。业务系统接入工作流完全通过接口，通过配置即可，无须编代码。

附图说明

图1为工作流引擎系统与业务系统连接示意图；

图2为本发明工作流程示意图；

图3为变量表结构示意图；

图4为act_ru_task activity任务表示意图(表1)；

图5为wf_run_history办理人历史记录示意图(表2)；

图6为wf_run_instance实例表示意图(表3)；

图7为button_config_table按钮配置表示意图(表4)；

图8为act_hi_actinst activity历史记录表(表5)。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。

如图1和图2所示，一种支持多系统的工作流引擎系统，工作流引擎系统通过程序接口与各个业务系统功能模块对接数据；业务系统发起流程时调用设定地址创建工作流实例，通过参数“sys_id”表示不同的系统，sys_id＝APP表示本业务由APP渠道发起，sys_id＝PC表示本业务由官方网站发起，sys_id＝WECHAT表示本业务由微信系统发起；

业务系统发起或者在业务系统端审核某个业务流程时，流程的流转由工作流引擎系统控制，业务系统会请求工作流引擎系统执行相应的操作，工作流程引擎系统执行完毕后会调用启动回调操作；

工作流程引擎系统根据“sys_id”的值通过数据库(数据库建在工作流系统，一个库，其他系统不能访问数据库，可以通过接口调用获取数据)查找对应的业务系统回调的地址来实现回调；

业务系统逻辑执行成功后返回code值(code＝100，code的值是一个意义定义，目前所有业务系统的接口执行成功返回的值为100；以后开发的新接口可根据需求调整；如不是有什么特殊情况，成功值返回100不变)给工作流程引擎系统，工作流程引擎系统再返回code值(code＝200，code的值是一个意义定义，目前所有的接口执行成功返回的值为200；以后开发的新接口可根据需求调整；如不是有什么特殊情况，成功值返回200不变)给业务系统。

在一个优选实施例中，通过web界面来操作和访问，这样既实现了各个系统的工作流任务又能在这个系统统一看到各个流程流转情况。

在一个优选实施例中，业务系统通过http接口传递参数到工作流引擎系统，工作流引擎系统创建一个流程实例，然后通过http接口调用业务系统的逻辑，逻辑成功后返回成功标志(比如：业务系统改变状态成功给的code＝100)给工作流(工作流引擎系统)，再返回给创建接口。

在一个优选实施例中，程序接口包括流程实例创建接口、流程列表查询接口、流程详情查询接口和流程节点跳转接口。节点跳转、提交、退回同属于流程操作接口(只是具体的操作不同，还可扩展其他的操作)

传统的工作流系统与业务系统的耦合度太高、复用性太低，每开发一个复杂的业务系统都会投入大量的人力和物力去改造工作流引擎。本工作流引擎系统提供了强大的接口功能，支持多个不同的业务系统接入，且接入成本低廉。

表1接口说明

表1中的x表示可以自定义。

在一个优选实施例中，流程实例创建包括如下步骤：

1)通过业务系统传来的业务编号(bus_id)获取到对应的流程id；

2)把业务需要用的值存进变量表

变量表是activity的变量表，也是通过操作activity的runtimeService.startProcessInstanceById(flowid,dyna_arg)和taskService.complete(taskid,dyna_arg)这两个方法的变量；dyna_arg是一个存放变量的Map容器。变量表设置的字段如图3所示。

3)调用activity的接口(通过bus_id(业务id)获取到了流程id时，就调用activity的创建接口了)runtimeService.startProcessInstanceById()创建一个新的实例；

4)寻找办理人，在找办理人时调用mongodb，获取人员的姓名等信息，并且将接收人员信息，发送人员信息，流程信息，写入办理人历史表；

mongodb中存储了一个大而全的组织架构，在流程上配置的办理人可能是一个具体的id，这是需要调用mongodb获取人员对应的名字，电话等信息(发短信要用)；也可能配置的是一个角色id，需要去monggodb中寻找这个角色下的人员；也可能配置的是某种关系，比如寻找申请用户的客户经理，也需要去mongodb中把用户对应的客户经理找到。

mongodb是一个独立的数据库，工作流只是链接了这个库。

办理人历史表是单独创建的一个表，因为工作流系统无组织架构信息，为了方便后面列表接口取数据，把每个步骤的办理人都存了一份。

5)封装返回的对象。对象内容包含(流程id，流程名字，流程key，当前节点信息，下一个节点的名字(可能多个)，下一个节点的办理人(可能多个)，下一个节点拥有的操作权限(比如提交、退回等)，任务id(可能多个)等)

在一个优选实施例中，流程列表查询包括如下步骤：

1)调用方传来处理人信息，任务id(taskid)，操作编号(表示是提交还是退回)，其他参数变量；

处理人即办理人；人员角色有三类：创建人(这个申请时我发起的，我就是创建人，创建人一旦发起成功，同时也变成了已办人)，处理人(也叫待办人，这个任务当前需要我处理，我就是处理人)，已办人(任务我已经处理完了，此时的身份就变成了已办人)。

其他参数一般是业务逻辑上的数据，用来辅助或者控制流程的走向的，比如业务方传来一个变量是贷款金额。金额大小不同，走的流程路线就不同，这个数据就可以通过变量传过来。只要业务方觉得有价值的数据就可以放在变量中，用于辅助并控制流程走向。

2)根据操作编号看执行提交还是退回，如果是提交，调用方法taskService.complete(taskid,dyna_arg)(activity的接口)；

如果是退回，则通过删除原来的路径创建新的路径来实现；

(如果是在多实例节点执行退回操作，需要把其他还没处理的任务删除，通过设置nrOfInstances变量的值为1来实现)

退回到哪个节点可以由调用方传过来或者在流程中指定好，直接配置在配置信息里；

如果下一个环节是子流程，还需要将多实例的办理人组装好，放在变量中；

办理人可理解为处理人。对于发起子流程而言，可能会需要发起多个子流程，每个人各自负责一个任务，这些互不相干。这个时候就需要把人员组装到一个list集中，绑定到画流程图时指定的变量名上。

3)寻找办理人，办理人可能是指定的角色，客户经理，指定的人，这些信息都是在monggodb中获取，并且将接收人员信息、发送人员信息、流程信息写入办理人历史表；

4)将重要信息写入变量表；

此处写入变量表的中数据一般用来控制流程走向，变量表如图3所示。

5)封装返回的对象，内容包含(流程id，流程名字，流程key，当前节点信息，下一个节点的名字(可能多个)，下一个节点的办理人(可能多个)，下一个节点拥有的操作权限(比如提交、退回等)，任务id(可能多个)等)

6)回调业务系统的接口，改变业务数据的状态

流程流转到某个节点需要改变业务数据的状态，这个节点需要配置一个改变状态的listener，这个lisntener中，通过获取到该流程实例的系统编号，从配置表中获取到这个系统对应的改变状态的url接口，通过调用这个接口改变业务数据。此处涉及到的表名，主键名，id值这些都是存在了activity的变量中的，直接传给调用方就行。

在一个优选实施例中，流程列表查询还包括步骤7)如果由节点配置了发送短信的listener，在产生新任务的时候会调用发送短信的listener。传统的工作流系统一般只适用与PC端或者只适用于APP端，且无其他主动提醒审批人员的方式，或者其他提醒方式不明显。传统的工作流系统一般在PC端进行通知。本工作流整合了PC端、APP端和手机短信。这三个渠道都会有待办通知，且对于同一个工作流节点，不同的渠道可以有不同的功能。

短信功能通过两个配置表实现，即触发场景配置和短信模板配置，每次产生待办任务的时候系统会调用java的interface类从场景配置表查找与该流程和该节点匹配的数据，如果未找到数据则表示不需要发送短信，如果找到数据则再根据配置的短信编号找到短信模板，然后用流程变量替换短信模板的变量来实现短信发送。

在一个优选实施例中，流程详情查询包括如下步骤：

1)待办、已办、办结是一个接口地址，通过参数querytype判断查询什么数据(querytype的参数如下：1表示代办事项，2表示已办事项，3表示办结事项)

2)待办：由表act_ru_task(表1，activity任务表)，wf_run_history(表2，办理人历史记录表)，wf_run_instance(表3，实例表)，button_config_table(表4，按钮配置表)这四张表联合查询所得。表1的PROC_INST_ID_字段与表2的instanceid、表3的instanceid关联；表3的flowkey与表4的FLOWKEY关联。act_ru_task这个表的特点是任务办理了，记录就删除了。

表1(如图4所示，为表1)：从左往右的字段分别是：id，版本号，执行id，实例id，流程id，节点名称，父流程的任务id(子流程才有值)，任务描述，节点名称，所有者，办理人(当节点办理人为具体的人时才有值)；

表2(如图5所示，为表2)：从左往右分别时：流程id，流程名称，实例id，节点id，节点名称，发送人id，发送人名称，处理人id，处理人名称，发送时间，任务id。

表3(如图6所示，为表3)：从左往右分别是：流程id，流程名称，实例id，标题，创建人，创建时间，实例的当前状态，业务id，业务名称，系统编号，业务表主键值，业务系统的表名，申请人的公司名称，流程key。

表4(如图7所示，为表4)从左往右分别是：流程KEY，节点id，待办操作按钮编号(多个分号隔开)，待办操作按钮名称(多个分号隔开)，节点备注(即节点名称)，已办操作按钮编号(多个分号隔开)，已办操作按钮名称(多个分号隔开)。

表1、表2、表3实例id关联，表3的流程key与表4的流程key关联。

表3的状态可以知道该实例是否已经结束，现处于什么状态(14001：未提交；14002：审核中；14003：通过；14004：未通过；14005：取消；14006：驳回；14007：填写基础信息；14008：填写详细信息；14009：终止；14010：暂停；14011：债权评审会评审；14012：债权担保公司审批；14013：债权银行审批；14014：债权金融办审批)。

如果是多实例节点并且是并行执行，还需要把多实例节点上已经办理过的任务剔除；

已办接口、办结接口通过实例表(wf_run_instance)、按钮配置表(button_config_table)、历史记录表查询(表5，activity历史表act_hi_actinst)。wf_run_instance表的instanceid与act_hi_actinst表的PROC_INST_ID关联，wf_run_instance的instanceid与button_config_table的FLOWKEY关联。

表5(如图8所示，为表5)从左往右分别是：流程id，实例id，执行id，节点id，任务id，办理人，办理时长，任务开始时间，任务结束时间。

在一个优选实施例中，流程详情查询根据用户id过滤查询个人的数据或者查询所有人的待办，根据allorpart决定(allorpart参数如下：0表示查询所有用户任务；1表示根据用户id查询任务)；

过滤还包括根据系统，业务类型，分站，公司名称等参数进行过滤。

在一个优选实施例中，流程信息调用步骤：

1)调用方传过来一个实例id，通过实例获取流程相关的信息；

2)返回包含流程id、名称、业务编号、业务名称、公司信息，标题信息、创建人、创建时间、业务表id、业务表主键、每个节点操作的历史记录。

在一个优选实施例中，由于互联网端用户和管理员端用户是两套不同的用户，本工作流引擎系统支持互联网端和管理员端用户一起共同使用。即同一个审批流程可以由互联网端用户发起，后台管理员用户审核。

系统在设计用户模块的时候，从系统的安全性考虑就将前台用户与后台管理员用户的数据进行分开存储即存储在不同的表，且未向公众开放后台的登录地址。从理论上来说前台用户有可能与后台用户名相同，在工作流处理的时候对于前台用户名，工作流引擎模块自动增加前缀“C_”后台用户增加前缀“B_”用于区分。

在一个优选实施例中，对于同一个审批节点，在不同的渠道上需要有不同的权限，如“替换办理人”的按钮，由于候选办理人比较多pc上比较好展示但APP上不好展示，所以APP上就不需要这个按钮。系统通过配置的方式解决了这个问题，达到了APP上展示的按钮与pc上展示的按钮不相同。

按钮级权限配置，通过一个数据库配置表将同一个流程不同的节点在不同的角色和不同的渠道上调用的时候，返回不同的按钮权限。图形化流程绘制。通过图形化拖拽的方式绘制工作流，操作方便，使用简单。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，应当指出的是，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种支持多系统的工作流引擎系统，其特征在于：工作流引擎系统通过程序接口与各个业务系统功能模块对接数据；业务系统发起流程时调用设定地址创建工作流实例，通过参数“sys_id”表示不同的系统，sys_id＝APP表示本业务由APP渠道发起，sys_id＝PC表示本业务由官方网站发起，sys_id＝WECHAT表示本业务由微信系统发起；

业务系统发起或者在业务系统端审核某个业务流程时，流程的流转由工作流引擎系统控制，业务系统会请求工作流引擎系统执行相应的操作，工作流程引擎系统执行完毕后会调用启动回调操作；

工作流程引擎系统根据“sys_id”的值通过数据库查找对应的业务系统回调的地址来实现回调；

业务系统逻辑执行成功后返回code值给工作流程引擎系统，工作流程引擎系统再返回code值给业务系统。

2.根据权利要求1所述的一种支持多系统的工作流引擎系统，其特征在于：通过web界面来操作和访问，这样既实现了各个系统的工作流任务又能在这个系统统一看到各个流程流转情况。

3.根据权利要求1或2所述的一种支持多系统的工作流引擎系统，其特征在于：业务系统通过http接口传递参数到工作流引擎系统，工作流引擎系统创建一个流程实例，然后通过http接口调用业务系统的逻辑，逻辑成功后返回成功标志给工作流，再返回给创建接口。

4.根据权利要求1或2所述的一种支持多系统的工作流引擎系统，其特征在于：程序接口包括流程实例创建接口、流程列表查询接口、流程详情查询接口和流程节点跳转接口。

5.根据权利要求4所述的一种支持多系统的工作流引擎系统，其特征在于，流程实例创建包括如下步骤：

1)通过业务系统传来的业务编号(bus_id)获取到对应的流程id；

2)把业务需要用的值存进变量表；

3)调用activity的接口runtimeService.startProcessInstanceById()创建一个新的实例；

4)寻找办理人，在找办理人时调用mongodb，获取人员的姓名等信息，并且将接收人员信息，发送人员信息，流程信息，写入办理人历史表；

5)封装返回的对象。

6.根据权利要求4所述的一种支持多系统的工作流引擎系统，其特征在于，流程列表查询包括如下步骤：

1)调用方传来处理人信息，任务id，操作编号，其他参数变量；

2)根据操作编号看执行提交还是退回，如果是提交，调用方法taskService.complete(taskid,dyna_arg)；

如果是退回，则通过删除原来的路径创建新的路径来实现；

退回到哪个节点可以由调用方传过来或者在流程中指定好，直接配置在配置信息里；

如果下一个环节是子流程，还需要将多实例的办理人组装好，放在变量中；

3)寻找办理人，办理人可能是指定的角色，客户经理，指定的人，这些信息都是在monggodb中获取，并且将接收人员信息、发送人员信息、流程信息写入办理人历史表；

4)将重要信息写入变量表；

5)封装返回的对象；

6)回调业务系统的接口，改变业务数据的状态。

7.根据权利要求6所述的一种支持多系统的工作流引擎系统，其特征在于，流程列表查询还包括步骤7)如果由节点配置了发送短信的listener，在产生新任务的时候会调用发送短信的listener。

8.根据权利要求4所述的一种支持多系统的工作流引擎系统，其特征在于，流程详情查询包括如下步骤：

1)待办、已办、办结是一个接口地址，通过参数querytype判断查询什么数据；

2)待办：把activity的act_ru_task表中的数据、从mongodb中取出的姓名等信息、实例表、按钮配置表四表联合查询所得；

如果是多实例节点并且是并行执行，还需要把多实例节点上已经办理过的任务剔除；

已办接口、办结接口通过实例表、按钮配置表、历史表查询。

9.根据权利要求8所述的一种支持多系统的工作流引擎系统，其特征在于，流程详情查询根据用户id过滤查询个人的数据或者查询所有人的待办，根据allorpart决定；

过滤还包括根据系统，业务类型，分站，公司名称等参数进行过滤。

10.根据权利要求1所述的一种支持多系统的工作流引擎系统，其特征在于，流程信息调用步骤：

1)调用方传过来一个实例id，通过实例获取流程相关的信息；

2)返回包含流程id、名称、业务编号、业务名称、公司信息，标题信息、创建人、创建时间、业务表id、业务表主键、每个节点操作的历史记录。