业务流程的监控方法、装置、计算机设备及存储介质

技术领域

本发明涉及软件监控技术领域，特别涉及一种业务流程的监控方法、装置、计算机设备及存储介质。

背景技术

办理金融类业务通常需要多个业务流程，以贷款业务为例，可以包含提交申请、授信出额、额度确认、审批、资方外审、签约、放款等多个业务节点。目前上述业务流程大多由客户通过应用程序自助办理，可以一定程度上减轻客户及业务办理人员的压力，提高业务办理效率。

目前对既有的业务办理应用程序缺乏有效的监督改进机制。当应用程序中某些业务流程存在代码错误或业务逻辑不清等缺陷时，后台运维人员难以及时发现，有可能导致办理业务异常缓慢，严重影响业务办理效率，导致用户体验不佳。

发明内容

本发明的目的是提供一种能够及时监控业务流程中各个业务节点运行状态的技术方案，以解决现有技术中存在的上述问题。

为实现上述目的，本发明提供一种业务流程的监控方法，包括以下步骤：

确定业务流程中包含的业务节点，针对每个业务节点配置切面数据；

根据所述切面数据生成与所述业务节点对应的业务日志，所述业务日志用于记录所述业务节点的执行过程数据；

提取所述业务日志中包含的关键字；

统计在预设时间段内与所述关键字对应的所有业务日志的数据量，并根据所述数据量确定所述业务节点的运行状态。

根据本发明提供的业务流程的监控方法，所述确定业务流程中包含的业务节点，针对每个业务节点配置切面数据的步骤包括：

设置每个业务节点对应的节点编号；

设置每个业务节点对应的切面类和切入点，所述切面类用于表征所述业务节点的扭转状态，所述切入点用于表征在所述业务节点的扭转状态写入所述业务日志。

根据本发明提供的业务流程的监控方法，所述提取所述业务日志中包含的关键字包括提取所述业务日志中的节点编号、开始时间、结束时间和申请状态；其中所述开始时间表征所述业务流程开始执行对应业务节点的时间，所述结束时间表征所述业务流程结束执行对应业务节点的时间，所述申请状态表征所述业务节点申请成功、申请失败或申请异常的状态。

根据本发明提供的业务流程的监控方法，所述统计在预设时间段内与所述关键字对应的所有业务日志的数据量，并根据所述数据量确定所述业务节点的运行状态的步骤包括以下任意一种或几种：

从所述业务日志中提取所述开始时间和所述结束时间，根据所述开始时间和所述结束时间计算所述业务节点的滞留时间；

从所述业务日志中提取所述申请状态，根据所述申请状态统计在预设时间段内处于对应申请状态的业务日志的数量，所述申请状态包括申请成功、申请失败和申请异常；

统计预设时间段内在所述业务节点产生的业务日志的总数量。

根据本发明提供的业务流程的监控方法，所述统计在预设时间段内与所述关键字对应的所有业务日志的数据量，并根据所述数据量确定所述业务节点的运行状态的步骤还包括：

根据所述节点编号将所述业务流程划分为多个组别；

以组别为单位对所述业务节点的滞留时间、所述申请状态的数量和/或所述业务日志的总数量进行分析统计；

以图表形式显示所述分析统计的结果。

根据本发明提供的业务流程的监控方法，根据所述节点编号将所述业务流程划分为多个组别的步骤包括：

根据所述业务节点编号将所述业务流程划分为申请流程、审批流程、签约流程和放款流程。

根据本发明提供的业务流程的监控方法，所述确定业务流程中包含的业务节点的步骤包括：

确定所述业务流程中包含的申请节点、实名认证节点、添加联系人节点、完善信息节点、风控节点、担保出额节点、线上预审节点、远程面谈节点、接收核保结果节点和线上签约节点。

为实现上述目的，本发明还提供一种业务流程的监控装置，包括：

节点确定模块，适用于确定业务流程中包含的业务节点，针对每个业务节点配置切面数据；

业务日志模块，适用于根据所述切面数据生成与所述业务节点对应的业务日志，所述业务日志用于记录所述业务节点的执行过程数据；

关键字提取模块，适用于提取所述业务日志中包含的关键字；

统计分析模块，适用于统计在预设时间段内与所述关键字对应的所有业务日志的数据量，并根据所述数据量确定所述业务节点的运行状态。

为实现上述目的，本发明还提供一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。

为实现上述目的，本发明还提供计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述方法的步骤。

本发明提供的业务流程的监控方法、装置、计算机设备及计算机存储介质，可以获取业务流程中的每个业务节点在状态扭转时的日志，根据日志统计业务节点处产生的数据量，从而监控每个业务节点的处理流程是否顺畅。进一步，本发明还可以根据业务节点的数据量确定业务节点的设置是否合理，并对可能设置不合理的节点计时进行调整，从而提高整个业务流程的处理效率。

附图说明

图1为本发明的业务流程的监控方法实施例一的流程图；

图2示出了根据本发明实施例一中以图标显示统计结果的示意图；

图3示出了本发明的业务流程的监控装置实施例一的程序模块示意图；

图4为本发明的业务流程的监控装置实施例一的硬件结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供的业务流程的监控方法、装置、计算机设备及计算机存储介质，可以获取业务流程中的每个业务节点在状态扭转时的日志，根据日志统计业务节点处产生的进件量、滞留时间等，从而监控每个业务节点的处理流程是否顺畅。本发明通过图表形式显示每个业务节点在不同时间段内的数据量，用户可以直观清晰地掌握业务流程的历史及当前处理状态。进一步，本发明还可以根据业务节点的数据量确定业务节点的设置是否合理，并对可能设置不合理的节点计时进行调整，从而提高整个业务流程的处理效率。

实施例一

请参阅图1，本实施例提出一种业务流程的监控方法，其特征在于，包括以下步骤：

S100:确定业务流程中包含的业务节点，针对每个业务节点配置切面数据。

以抵押贷款业务为例，通常完成该业务的办理需要多个业务节点，例如申请节点101、实名认证节点201、添加联系人节点202、完善信息节点203、风控节点301、担保出额节点302、线上预审节点406、远程面谈节点401、接收核保结果220、线上签约节点218等。上述每一个节点代表抵押贷款业务中的一个环节，其中编号101、201、202、203、301、302、406、401、220、218等表示每个业务节点的编码。

本步骤采用面向切面编程的方式配置日志的产生，其中的切面数据指的是在不影响业务的情况下进行日志生成行为。具体的，切面数据以每一个业务节点的功能作为横切关注点来配置日志文件。通常来说，这些横切关注点从概念上是与应用的业务逻辑分离的。比如，声明式事务、日志、安全、缓存等等，都与业务逻辑无关，可以将这些东西抽象成为模块，采用面向切面编程的方式，通过声明方式定义这些功能用于何处，通过预编译方式和运行期动态代理实现这些模块化横切关注点程序功能进行统一维护，从而将横切关注点与它们所影响的对象之间分离出来，就是实现解耦。

切面类包含通知和切入点，在创建切面类之前,切点表达式定义切点，用于准确的定位应该在什么地方应用切面的通知。在本实施例中，切面类为扭转状态的类,切入点就是在每个业务节点扭转状态的时候,写入一条日志，所以在每个节点通过后,都会写入一条相应的日志。本实施例具体通过设置扭转状态的切面类来监测节点的扭转状态。当业务流程中某个业务节点处于扭转状态时即生成一条日志。本实施例中的扭转状态指的是业务节点从未处理到处理完成的状态切换，例如对于用户A提出的贷款请求，当完成提交申请过程时，对应的申请节点从未申请到申请结束时即处于扭转状态，此时产生一条对应于申请节点的日志，标识用户A已完成申请过程。

S200:根据所述切面数据生成与所述业务节点对应的业务日志，所述业务日志用于记录所述业务节点的执行过程数据。

业务日志文件可以是一行一个JSON，物理上对应一条数据，逻辑上对应一个描述了用户行为的事件，或是描述一个或多个用户属性的Profile操作。业务日志的具体内容可以包含多个字段，由设计人员根据具体需要定义。以下为一条业务日志的部分内容示例：

{"time":1590471408101,"lib":{"$lib_method":"code","$lib_version":"3.1.9","$lib_detail":"com.paic.apsplus.o2o.biz.service.impl.MonitorSdkServiceImpl##getParamsByBean##MonitorSdkServiceImpl.java##47","$lib":"Java"},"distinct_id":"13810105002","event":"WALLE_BUSINESSFLOW","properties":{"measurement_id":"0001","status":"PS","flow_name":"wudiya-o2o","enter_time":"2019-5-19 03:05:38","product":"PH1000100010002","city_code":"150100000000","distinctid":"13810105002","value_qty":1,"channel":"WX","exit_time":"2019-5-1903:05:38"},"type":"track"}

上文中，字段“time”表示事件发生的实际时间戳，字段“distinct_id”表示对应业务流程的申请号，字段“measurement_id”代表节点编号，字段“enter_time”代表对应业务节点的开始时间，字段“exit_time”代表对应业务节点的结束时间，字段“status”代表对应业务节点的申请状态，例如申请成功、申请失败、申请异常等等。

S300:提取所述业务日志中包含的关键字。

需要说明的是，本步骤用于提取关键字的执行主体和步骤S200中生成业务日志的执行主体可以不同。例如，生成业务日志的执行主体可以是现有的任意业务流程的执行软件，例如ASP应用软件；提取关键字的执行主体可以是现有的任意数据管理软件，例如神策系统。本实施例中的业务日志可以通过kafka读取数据并写入数据管理软件。具体的，可以通过kafka连接业务流程的执行软件和数据管理软件，其中业务流程的执行软件可以为ASP应用软件。当ASP应用软件中产生业务日志时，将会通过kafka传送给数据管理软件。其中Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，其采用生产者和消费者模式，常见可以用于web/nginx日志、访问日志，消息服务等等。具体的，生产者将每个业务节点处产生的业务日志发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。消费者可以从broker中读取数据。在本实施例中，将APS应用作为生产者,将消息即业务日志发布到Kafka的topic中,追加到当前用于追加数据的segment文件中。同时将神策系统作为消费者，实时监测动态,消费并反馈数据给到前端。

业务日志中包含的关键字可以是业务日志的上述字段中某具体字段对应的数值。可以通过正则表达式实现对日志中关键则的提取。其中正则表达式是对字符串(包括普通字符(例如，a到z之间的字母)和特殊字符(称为“元字符”))操作的一种逻辑公式，就是用事先定义好的一些特定字符、及这些特定字符的组合，组成一个“规则字符串”，这个“规则字符串”用来表达对字符串的一种过滤逻辑。例如可以提取到字段“measurement_id”对应的节点编号为0001，字段“enter_time”对应的开始时间为“2019-5-19 03:05:38”，字段“exit_time”对应的开始时间为“2019-5-19 03:05:38”。

S400:统计在预设时间段内与所述关键字对应的所有业务日志的数据量，并根据所述数据量确定所述业务节点的运行状态。

本实施例中提取的关键字可以随着统计目的的不同而灵活设置。本步骤对于业务日志的统计分析，包括但不限于以下项目：

(1)从所述业务日志中提取开始时间和结束时间，根据所述开始时间和所述结束时间计算所述业务节点的滞留时间。这里从日志中提取的关键字为上述开始时间和结束时间，滞留时间用于表征在某个业务节点处执行时消耗的时长，可以理解，滞留时间越短，说明该业务节点的处理速度越快，处理效率越高；滞留时间越长，说明该业务节点的处理速度越慢，这种情况有可能是由于业务逻辑涉及不当造成的，或者是由于软件内部代码错误造成的，或者仅仅是由于数据并发量过大引起的当滞留时间超出一定阈值，就可以发出相应提醒信息，以便负责人员可以及时发现问题解决问题。仍以上文中的业务日志为例，其中字段“enter_time”对应的开始时间为“2019-5-19 03:05:38”，字段“exit_time”对应的结束时间为“2019-5-19 03:05:38”。本示例中开始时间和结束时间相同，意味着该业务节点的滞留时间小于1秒，处理效率很高，业务运行良好。在其它的示例中，例如“exit_time”对应的结束时间为“2019-5-19 03:15:38”，此时用结束时间减去开始时间，可以得到滞留时间为10分钟，处理事件相对较长，此时就可以发出提醒信息，提醒工作人员对该业务节点予以关注。

(2)从所述业务日志中提取申请状态，根据所述申请状态统计在预设时间段内处于对应申请状态的业务日志的数量，所述申请状态包括申请成功、申请失败和申请异常。此时将申请状态作为本步骤中要提取的关键字。上述预设时间段可以根据实际需要进行设置，例如1小时、4小时、12小时、24小时等，预设时间段设置的越短，相当于统计的频率越快。仍以上文中的业务日志为例，其中字段“status”对应的申请状态为“PS”，即申请成功。在其它的示例中，字段“status”对应的申请状态也可能是申请失败或者申请异常。通过从接收到的每一条业务日志中提取申请状态，根据一段时间内所有业务日志中的申请状态进行统计，就可以得到对应申请状态的业务日志的数量。可以理解，业务日志的数量是随着时间而持续增长的，通过统计预设时间段内的对应申请状态的业务日志的数量，可以清楚了解在不同的时间段对应的申请状态如何。例如，当一段时间内申请失败的数量超过预设阈值，或者申请成功和申请失败/申请异常的比例超过预设阈值，说明该业务节点在处理的过程中可能存在问题，从而可以发出提醒信息，提醒工作人员对该业务节点予以关注。

(3)统计预设时间段内在所述业务节点产生的业务日志的总数量。可以提取日志中的关键字段“measurement_id”，对节点编号相同的所有日志的数量进行统计，例如统计包含编号201的所有业务日志的数量。当该数量过多或者过少时，可以考虑对应业务节点的处理逻辑是否不前当，从而提醒相关人员进行维护或更改。

综上所述，本发明将业务节点的制定方和数据监控方整合在一起，给予了数据分析更多的可能，例如实时数据采集、建模、分析，驱动市场营销、产品优化、用户运营、管理监控。本发明一方面用于更加详细的日志数据，另一方面赋予了对自身系统相容的结合性，给用户在业务视觉上更加直观的感受，有利于及时发现业务节点中的异常情况，从而进行更加适合的调整或更改。本发明支持现有业务系统平台的二次开发，可通过BI、大数据平台、CRM、ERP等内部IT系统，构建用户数据体系，让用户行为数据发挥深远的价值。

如前所述，每个业务节点具有各自对应的节点编号。对于某些业务流程而言，其中包含了较多的业务节点，如果对每个业务节点分开统计，可能会得到大量琐碎的统计结果，但是对于直观反映节点运行状态意义并不是很大。为了更加突出阶段性的数据量变化，在一个实施例中，本发明可以将多个业务节点划分到同一个组别中，以组别为单位对所述业务节点的滞留时间、所述申请状态的数量或所述业务日志的总数量进行分析统计。例如，将预约申请节点101、实名认证节点201、添加联系人节点202、完善信息节点203等统一归纳为申请阶段，对整个申请阶段对应的滞留时间、申请状态、日志总数量等进行计算统计，并可以通过图标的形式展示出来。

图2示出了根据本发明实施例一中以图标显示统计结果的示意图。从图2可以看出，无抵押O2O贷款流程被划分为四个组别，分别包括申请流程、审批流程、签约流程和放款流程。图2中显示的是每个组别中统计的日志总数量，横坐标为时间，纵坐标为日志数量也即业务量。这样，可以清楚地反映出不同组别地业务量随时间变化的情况。

总之，本发明能够应用于任何业务流程系统的监控管理中，通过对大数据的监控实时反映系统运行情况。一方面，本发明可以很好地统计出每个业务节点对应的滞留时间、通过时间或拒绝时间等，通过每个节点的时间数据判断这个节点的逻辑是否有问题，从而提前发现问题，增强代码的健壮性。另一方面，本发明可以通过每个节点的数据量判断客户在哪个节点进件的时候遇到的业务问题最多，进而帮助产品经理优化产品逻辑，最终提高用户体验，提升产能。

请继续参阅图3，示出了一种业务流程的监控装置，在本实施例中，监控装置30可以包括或被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本发明，并可实现上述业务流程的监控方法。本发明所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，比程序本身更适合于描述业务流程的监控装置30在存储介质中的执行过程。以下描述将具体介绍本实施例各程序模块的功能：

节点确定模块31，适用于确定业务流程中包含的业务节点，针对每个业务节点配置切面数据；

业务日志模块32，适用于根据所述切面数据生成与所述业务节点对应的业务日志，所述业务日志用于记录所述业务节点的执行过程数据；

关键字提取模块33，适用于提取所述业务日志中包含的关键字；

统计分析模块34，适用于统计在预设时间段内与所述关键字对应的所有业务日志的数据量，并根据所述数据量确定所述业务节点的运行状态。

根据本发明提供的业务流程的监控装置，所述提取所述业务日志中包含的关键字包括提取所述业务日志中的节点编号、开始时间、结束时间和申请状态；其中所述开始时间表征所述业务流程开始执行对应业务节点的时间，所述结束时间表征所述业务流程结束执行对应业务节点的时间，所述申请状态表征所述业务节点申请成功、申请失败或申请异常的状态。

根据本发明提供的业务流程的监控装置，所述统计分析模块34包括：

滞留时间模块341，适用于从所述业务日志中提取开始时间和结束时间，根据所述开始时间和所述结束时间计算所述业务节点的滞留时间；

申请状态模块342，适用于从所述业务日志中提取申请状态，根据所述申请状态统计预设时间段内在所述业务节点申请状态的数量，所述申请状态的数量包括申请成功的数量、申请失败的数量和申请异常的数量；

日志总数量模块343，适用于统计预设时间段内在所述业务节点产生的业务日志的总数量。

本实施例还提供一种计算机设备，如可以执行程序的智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。本实施例的计算机设备40至少包括但不限于：可通过系统总线相互通信连接的存储器41、处理器42，如图3所示。需要指出的是，图4仅示出了具有组件41-42的计算机设备40，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

本实施例中，存储器41(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器41可以是计算机设备40的内部存储单元，例如该计算机设备40的硬盘或内存。在另一些实施例中，存储器41也可以是计算机设备40的外部存储设备，例如该计算机设备40上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，存储器41还可以既包括计算机设备40的内部存储单元也包括其外部存储设备。本实施例中，存储器41通常用于存储安装于计算机设备40的操作系统和各类应用软件，例如实施例一的业务流程的监控装置30的程序代码等。此外，存储器41还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器42在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器42通常用于控制计算机设备40的总体操作。本实施例中，处理器42用于运行存储器41中存储的程序代码或者处理数据，例如运行业务流程的监控装置30，以实现实施例一的业务流程的监控方法。

本实施例还提供一种计算机可读存储介质，如闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘、服务器、App应用商城等等，其上存储有计算机程序，程序被处理器执行时实现相应功能。本实施例的计算机可读存储介质用于存储业务流程的监控装置30，被处理器执行时实现实施例一的业务流程的监控方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

流程图中或在此以其它方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

本技术领域的普通技术人员可以理解，实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。