一种自定义业务流程审批流生成方法及装置与流程

1.本发明涉及互联网技术领域，具体涉及一种自定义业务流程审批流生成方法及装置。


背景技术：

2.工作流“workflow”，指业务过程的部分或整体在计算机应用环境下的自动化，是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。审批流是工作流的一种应用。
3.被定义了审批流程的单据将按照定义的审批流程被传递和审批。这一完整的过程就称为审批流。审批流的实现可以全面提升企业的办公效率，实现企业在整个审批过程中的高效、透明、及时性。
4.现有审批功能通常嵌入在单个模块或功能的实现逻辑当中，单个系统由多个不同模块，而每个模块又可能由不同的功能组成，嵌入式的审批功能不仅会带来大量重复的编码工作，同时也会增加系统逻辑的复杂度,使系统维护困难。并且审批规则散布在系统的不同位置，很难直观的对审批逻辑进行展示。同时由于逻辑都内嵌在代码内部，非编程人员难以对逻辑进行编辑修改，审批规则的变动需要制定者先与开发人员进行需求沟通后才能进行修改。同时也由于审批逻辑的分散性,难以对审批数据进行集中统计。


技术实现要素：

5.本技术实施例提供一种自定义业务流程审批流生成方法，用于降低审批流生成的难度，基于具体的业务场景确定合适的审批流，本技术实施例采用的技术方案如下：
6.第一方面，本实施例提供一种自定义业务流程审批流生成方法，包括：
7.接受请求方发送的事件触发请求，基于触发规则确定事件是否进行并反馈至请求方；
8.接受请求方发送的审批规则新建请求，配制审批规则表单；
9.基于所述审批规则表单确定审批节点；
10.基于所述审批节点，生成审批规则对应的审批流；
11.检测基于所述审批流形成的审批流程，确定审批进度；
12.基于所述审批进度，完成业务状态的变更并反馈给请求方。
13.针对于第二种实现可能，结合第一方面，所述接受请求方发送的事件触发请求，基于触发规则确定事件是否进行并反馈至请求方，包括：
14.根据所述事件请求中的携带的字段与预设触发字段进行匹配，通过匹配结果确定行为是否进行并反馈至请求方。
15.针对于第三种实现可能，结合第一方面，所述接受请求方发送的审批规则新建请求，配制审批规则表单，包括：
16.预设所述审批规则表单模板，并将所述审批规则表单模板发送至所述请求方端，触发请求方在信息输入界面进行审批规则表单填写。
17.针对于第四种实现可能，结合第三种可能，接受请求方发送的审批规则新建请求，配制审批规则表单，还包括：
18.接收所述请求方发送的在所述信息输入界面录入的信息，基于所述信息生成审批规则表单。
19.针对于第五种实现可能，结合第四中可能，基于所述审批规则表单确定审批节点，包括：
20.基于所述审批规则表单确定每一阶段的审批人员信息以及审批触发条件。
21.针对于第六种实现可能，结合第五种可能，所述审批规则表单包括判断类型，以及与所述判断类型对应的判断参数和与所述判断参数对应的审批人员信息。
22.针对于第七种实现可能，结合第六种可能，所述基于所述审批规则表单确定每一阶段的审批人员信息以及审批触发条件，包括：
23.接收在信息输入界面输入的审批人员名单、多种判断参数以及多种判断类型；接收所述请求方发送的从所述审批人员名单中选取的每个阶段的审批人员信息，以及从所述多种判断参数中选取的指定判断参数、所述多种判断类型中选取的指定判断类型；根据每个阶段的指定判断参数、指定判断类型以及所述请求方发送的所述阶段的触发值，获得每个阶段的触发条件。
24.针对于第八种实现可能，结合第七种可能，所述基于所述审批节点，生成审批规则对应的审批流，包括：
25.根据每一阶段审批人员信息、审批触发条件以及每一阶段请求人完成的状态值，生成所述的审批流。
26.针对于第九种实现可能，结合第八种可能，所述检测基于所述审批流形成的审批流程，确定审批进度，包括：
27.接受审批完成通知，修改当前审批状态。
28.这对于第二个方面，本实施例还提供一种自定义业务流程审批流生成装置，包括：
29.事件确定模块，用于接受请求方发送的事件触发请求，基于触发规则确定事件是否进行并反馈至请求方；
30.审批规则表单配制模块，用于接受请求方发送的审批规则新建请求，配制审批规则表单；
31.审批节点确定模块，用于基于所述审批规则表单确定审批节点；
32.审批流生成模块，用于基于所述审批节点，生成审批规则对应的审批流；
33.审批进度生成模块，用于检测基于所述审批流形成的审批流程，确定审批进度；
34.结果反馈模块，用于基于所述审批进度，完成业务状态的变更并反馈给请求方。
35.本技术实施例提供的一种自定义业务流程审批流生成及装置，通过制定审批规则能够实现在线根据不同的业务类型、不同的业务流程自定义进行审批流的生成以及审批过程的处理。大大提高审批流逻辑的清晰度，减少代码的重复率，提升开发效率。
附图说明
36.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于
本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
37.附图中的方法、系统和/或程序将根据示例性实施例进一步描述。这些示例性实施例将参照图纸进行详细描述。这些示例性实施例是非限制的示例性实施例，其中示例数字在附图的各个视图中代表相似的机构。
38.图1是根据本技术的一些实施例所示审批流的生成方法的应用场景示意图；
39.图2是根据本技术的一些实施例所示电子设备的结构示意图；
40.图3是根据本技术的一种实施例所示的审批流的生成方法流程示意图；
41.图4是根据本技术的一些实施例所示的审批流生成方法详细流程示意图；
42.图5是根据本技术的一些实施例所示的审批流生成装置结构框图。
具体实施方式
43.为了更好的理解上述技术方案，下面通过附图以及具体实施例对本技术技术方案做详细的说明，应当理解本技术实施例以及实施例中的具体特征是对本技术技术方案的详细的说明，而不是对本技术技术方案的限定，在不冲突的情况下，本技术实施例以及实施例中的技术特征可以相互组合。
44.在下面的详细描述中，通过实例阐述了许多具体细节，以便提供对相关指导的全面了解。然而，对于本领域的技术人员来说，显然可以在没有这些细节的情况下实施本技术。在其他情况下，公知的方法、程序、系统、组成和/或电路已经在一个相对较高水平上被描述，没有细节，以避免不必要的模糊本技术的方面。
45.本技术中使用流程图说明根据本技术的实施例的系统所执行的执行过程。应当明确理解的是，流程图的执行过程可以不按顺序执行。相反，这些执行过程可以以相反的顺序或同时执行。另外，可以将至少一个其他执行过程添加到流程图。一个或多个执行过程可以从流程图中删除。
46.相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
47.为了更好的理解本实施例提供的自定义业务流程审批流生成方法，需要对本方法的使用场景进行一定的说明。
48.本实施立体弄的自定义业务流程审批流生成方法，主要应用于crm管理系统。crm统主要提供给客户、邮件、客户订单、报价单、采购单等模块，其中涉及很多模型对象。例如邮件、订单、客户。业务变动其实就是对应模型及关联模型的属性变动，比如，订单由草稿状态修改成已下单，则是订单的属性由1
→
2的过程。所以系统存在很多模型对象，业务的推动映射到对象就是对象属性的变化。
49.以下是对本实施例涉及到的名词做一定的解释：
50.申请单，在本实施例中是指用户业务行为触发时提交的单据。
51.审批单，根据触发条件生成的发送至审批人的单据。
52.审批节点：每一个审批阶段为一个审批节点。
53.审批流程开始，满足审批规则并触发。
54.审批流结束，设定的审批流程全部执行完毕，申请单处于最终状态。
55.最终状态，包含以下状态中的任意一种：拒绝、同意、撤销。
56.图1为本技术实施例提供的审批流的生成方法的应用场景示意图。该方法包括：服务端110以及客户端120，服务端110与客户端120之间通过无线网络通信。客户端120可以是智能手机、平板电脑、台式电脑。服务端110可以是服务器或服务器集群。服务端110可以执行本技术实施例提供的审批流的生成方法。
57.图2是本技术实施例提供的电子设备的结构示意图。该电子设备可以作为上述服务端，该电子设备200可以用于执行本技术实施例提供的自定义业务流程审批流生成方法。如图2所示，该电子设备200包括：一个或多个处理器210、一个或多个存储处理器可执行指令的存储器220。其中，所述处理器210被配置为执行本技术下述实施例提供的自定义业务流程审批流的生成方法。
58.所述处理器210可以是包含中央处理单元(cpu)、图像处理单元(gpu)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元的设备，可以对所述电子设备200中的其它组件的数据进行处理，还可以控制所述电子设备200中的其它组件以执行期望的功能。
59.所述存储器220可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器210可以运行所述程序指令，以实现下文所述的审批流的生成方法。在所述计算机可读存储介质中还可以存储各种应用程序和各种数据，例如所述应用程序使用和/或产生的各种数据等。
60.在一实施例中，图2所示电子设备200还可以包括输入装置230、输出装置240以及数据采集装置250，这些组件通过总线系统260和/或其它形式的连接机构(未示出)互连。应当注意，图2所示的电子设备200的组件和结构只是示例性的，而非限制性的，根据需要，所述电子设备200也可以具有其他组件和结构。
61.所述输入装置230可以是用户用来输入指令的装置，并且可以包括键盘、鼠标、麦克风和触摸屏等中的一个或多个。所述输出装置240可以向外部(例如，用户)输出各种信息(例如，图像或声音)，并且可以包括显示器、扬声器等中的一个或多个。所述数据采集装置250可以采集对象的图像，并且将所采集的图像存储在所述存储器220中以供其它组件使用。示例性地，该数据采集装置250可以为摄像头。
62.在一实施例中，用于实现本技术实施例的审批流的生成方法的示例电子设备中的各器件可以集成设置，也可以分散设置，诸如将处理器210、存储器220、输入装置230和输出装置240集成设置于一体，而将数据采集装置250分离设置。
63.在一实施例中，用于实现本技术实施例的审批流的生成方法的示例电子设备200可以被实现为诸如计算机、服务器等智能设备。
64.图3是本技术实施例提供的一种自定义业务流程审批流生成方法的流程示意图。该方法可以由上述服务端执行，如图3所示，该方法可以包括以下s310-s360。
65.s310：接受请求方发送的事件触发请求，基于触发规则确定事件是否进行并反馈
至请求方。
66.具体为根据事件请求中携带的字段与预设触发字段进行匹配，通过匹配结果确定行为是否进行并反馈至请求方。
67.在本实施例中，事件为请求方即使用方针对于具体的业务场景进行的订单状态改变，包括但不限于订单的编辑、订单编辑后的保存、订单编辑保存后的修改等。
68.在本实施例中，当用户在改变订单状态的时候，会产生一个订单状态被修改的事件，通过订单状态的改变确定当前对象及事件判断是否触发审批。对于每一个订单的确定基于其独立的订单id进行，可以针对id进行赋值，赋值的范围可以根据订单赋值规则以进行。例如订单id＝100，则代表一个id＝100的独立的订单。
69.基于本过程，订单id＝100这个订单由用户从草稿状态修改为已下单，即为订单状态的改变。当订单状态改变时，就会产生一个对应类型的事件，用户在后台配置了订单的触发规则并开启当前规则之后，判断审批流引擎的配置是否能匹配，通过确定具体编号的审批流引擎的配置的触发条件就是对象是订单且订单由草稿变更为已下单。
70.在本实施例中，事件请求中携带的字段为基于触发规则制定的目标字段中的任意一种，可以是名称、编号等。通过对于字段的判断，确定是否被包含在触发条件之下，如果与触发条件下的字段相符合，则进行订单状态的改变，如果与触发条件下的字段不符合，则不进行订单状态的改变即不进行至下一处理环节，并将处理后的信息反馈至请求方。
71.本过程基于业务处理过程，即在进行审批之前，需要对待审批事件的状态进行确定。
72.s320：接收请求方发送的审批规则新建请求，配置审批规则表单。
73.具体为预设审批规则表单模板，并将审批规则表单模板，触发请求方在信息输入界面进行审批规则表单填写。
74.接收请求方发送的在信息输入界面录入的信息，基于录入的信息生成规则审批表单。
75.审批规则新建请求可以由客户端发送到服务端。审批规则表单模板为表单状结构，其内包含了用于审批所使用的标识，用于区分不同的审批规则。具体来说，标识可以是审批行为的名称，还可以是通过编号化的审批行为的名称。
76.在一实施例中，响应于审批规则新建请求，根据审批规则新建请求中携带的规则名称，生成对应的审批规则表单。
77.非编程人员可以在客户端的交互界面针对于审批规则表单模板进行输入处理，具体为输入规则名称。例如合同审批、用章审批、客户录入等。客户端将携带规则名称的审批规则新建请求发送到服务端，服务端基于规则名称生成审批规则表单。
78.s330.基于审批规则表单确定审批节点。
79.具体为，基于审批规则表单确定每一阶段的审批人员信息以及审批触发条件。
80.在本实施例中，针对于每一阶段的审批人员信息以及对应的审批触发条件的确认包括以下过程：
81.接收在信息输入界面输入的审批人员名单、多种判断参数以及多种判断类型。
82.请求人在审批人员名单中选取的每个阶段的审批人员信息。
83.请求人在多种判断参数中选取指定判断参数。
84.请求人在多种判断类型中选取指定判断类型。
85.根据每个阶段的指定判断参数、制定判断类型以及请求方设定且发送的每个阶段的触发值，获得每个阶段的触发条件。
86.在本实施例中，审批人员信息以及触发条件可以由非编程人员在客户端的交互界面输入。由客户端发送到服务端，从而服务端获得审批人员信息以及触发条件。
87.一个审批流可以包括多个阶段，例如，一个请款申请的审批流，可以包括部门经理审批阶段、总经理审批阶段等。
88.一个阶段的审批人员可以是一个或多个，在多个审批人员均审批通过时，才进入下一个阶段。故审批人员信息可以是一个或多个审批人员对应的人员信息，人员信息可以包括姓名、职位名称、邮箱地址、用户id等。
89.触发条件是指触发该阶段的审批人员进行审批的判断条件。例如请款金额大于100，例如部门经理已完成审批。
90.在一实施例中，服务端生成审批规则表单之后，可以将审批规则表单返回审批规则新建请求的请求方，触发请求方显示信息输入界面；之后接收请求方发送的用户在所述信息输入界面录入的每个阶段的审批人员信息以及触发条件。
91.请求方可以是上文发送审批规则新建请求的客户端。客户端可以显示信息输入界面，用户可以在信息输入界面按序指定每个阶段的审批人员和触发条件。之后由客户端将审批人员信息和触发条件发送到客户端。请求方提供图形化操作界面，非开发人员经学习后也可自由制定修改审批规则，摆脱需要与开发频繁沟通对接需求的过程。审批逻辑可图形化展示,不必审阅代码规则一目了然。
92.s340.基于审批节点，生成审批规则对应的审批流。
93.一个审批规则表单对应唯一一个审批流。根据审批规则表单，通过相应的调用接口可以调用对应的审批流。审批流包括按序的每个阶段的审批人员信息和触发该阶段的审批人员进行审批的触发条件。
94.s350.检测基于审批流形成的审批流程，确定审批进度。
95.具体为，根据每一阶段请求人完成的状态值，确定审批流程；基于审批流程，接受审批完成通知，修改当前审批状态。
96.同一个阶段可以多个审批人同时进行审批操作。在实际应用时，当所有并联审批人完成审批时,如果存在拒绝状态的审批则向审批所属应用返回申请单被拒绝的状态,如果所有人都同意,则向审批所属应用返回进入下一阶段的状态。
97.在一实施例中，服务端可以接收请求方配置的每个阶段完成时的状态值。状态值是指在该阶段完成时，位于每一阶段审批人对于申请的确定状态。客户端可以基于返回的状态值，可以修改主申请表的申请状态。例如，比如一次请款申请,状态值可以是请款申请的状态，假设将一次请款申请划分为业务审批人审批-》部门经理确认-》总经理确认-》申请返原四个阶段。那么对应的当业务审批人审批完成后,向审批所属应用(客户端)返回此合同应当进入待部门经理确认的阶段,以此类推,不断更新此请款申请的状态,直到完成所有流程。
98.s360.基于审批进度，完成业务状态的变更并反馈给请求方。
99.图4是本实施例提供的自定义业务流程审批流生成方法详细流程图示意图，包括
以下步骤：
100.1.用户业务流程驱动业务对象变更生成触发器,触发器绑定了事件类型，事件源业务对象,对象变更。
101.2.审批流引擎监听到触发器生成，适配器检测是否满足上述定义的审批规则，如果没有匹配上则当前用户行为不会触发审批，匹配上则将触发器及匹配的结果输出到调度器。
102.3.调度器获取到输入的规则调用解析器解析出规则定义的审批节点，生成申请单，审批节点，审批单，节点中的每一个审批人都会产生一个审批单，同时锁定对象。
103.4.审批人收到审批单之后输入审批结果同意或者拒绝，调度器会依据当前的输入判定当前节点的是否到达最终状态。
104.5.每一个节点状态结束之后调度器依次处理规则定义的下一个步骤，如果没有满足条件的步骤则调度器执行阶段结束，释放锁定对象。
105.6.根据审批人输入的审批结果，执行对应的审批逻辑，拒绝则标记申请单为拒绝状态，同意则通过唤醒器根据触发器绑定的修改对象数据。
106.7.最后执行用户定义的配置，消息通知中心发送审批结果到申请人，整个流程执行结束。
107.图为一种自定义业务流程审批流生成装置的框图。该自定义业务流程审批生成装置700包括：
108.事件确定模块710，用于接受请求方发送的事件触发请求，基于触发规则确定事件是否进行并反馈至请求方；
109.审批规则表单配制模块720，用于接受请求方发送的审批规则新建请求，配制审批规则表单；
110.审批节点确定模块730，用于基于所述审批规则表单确定审批节点；
111.审批流生成模块740，用于基于所述审批节点，生成审批规则对应的审批流；
112.审批进度生成模块750，用于检测基于所述审批流形成的审批流程，确定审批进度；
113.结果反馈模块760，用于基于所述审批进度，完成业务状态的变更并反馈给请求方。
114.在一个或多个实施方式中，公开了一种终端设备，包括服务器，所述服务器包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现实施例一种基于稀疏重构的信号重构方法。为了简洁，在此不再赘述。
115.应理解，本实施例中，模块”可包括以硬件、软件或固件形式实施的单元，且可与例如“逻辑”、“逻辑区块”“部件”及“电路”等其他用语互换使用。模块可为适以执行一种或多种功能的单个集成组件或所述单个集成组件的最小单元或部件。举例来说，根据实施例，模块可实施为应用专用集成电路(application-specific integrated circuit，asic)的形式。
116.计算机可读信号介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等等、或合适的组合形式。计算机可读信号介质可以是除计算机可读存储介质之外的任何计
算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读信号介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤缆线、rf、或类似介质、或任何上述介质的组合。
117.本技术各方面执行所需的计算机程序码可以用一种或多种程序语言的任意组合编写，包括面向对象程序设计，如java、scala、smalltalk、eiffel、jade、emerald、c 、c#、vb.net，python等，或类似的常规程序编程语言，如"c"编程语言，visual basic，fortran 2003，perl，cobol 2002，php，abap，动态编程语言如python，ruby和groovy或其它编程语言。所述程式设计编码可以完全在用户计算机上执行、或作为独立的软体包在用户计算机上执行、或部分在用户计算机上执行部分在远程计算机执行、或完全在远程计算机或服务器上执行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网络(lan)或广域网(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。
118.同样应当理解的是，为了简化本技术揭示的表述，从而帮助对至少一个发明实施例的理解，前文对本技术实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法幷不意味着本技术对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。