CN111435330B - 业务处理流程模拟方法、装置及系统 - Google Patents

Abstract

本申请实施例公开了业务处理流程模拟方法、装置及系统，所述方法包括：引擎子系统，用于通过对所述代理节点子系统进行调用的方式，发起对所述业务子系统中的业务处理流程进行仿真的仿真任务；代理节点子系统，包括多个代理节点对象，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述代理节点对象用于根据所述引擎子系统在所述调用周期内的调用信息，确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；业务子系统，用于提供模拟所需的工单信息并实现在不同的业务节点之间进行流转。通过本申请实施例，能够实现对包含人工作业的业务处理流程进行更准确的模拟。

Description

业务处理流程模拟方法、装置及系统

技术领域

本申请涉及业务处理流程模拟技术领域，特别是涉及业务处理流程模拟方法、装置及系统。

背景技术

在“新零售”的模式下，其核心点在于线上与线下相结合，消费者用户可以在线上下单，线下的实体店铺可以执行拣货，打包，甚至加工制作等一系列的流程，最后再在规定的时间内将具体的商品配送至消费者指定的收货地址。

在这种新零售模式下，能够实现对线下实体店铺的信息化管理，包括具体业务链路上的各个节点之间的流转等，都可以实现自动化处理。但是，在涉及到拣货、加工制作、打包等具体的处理环节时，除了数据层面的信息流转之外，还需要由相应的“人工”配合来实现具体的操作。也就是说，在具体的任务到达某个节点后，需要由对应节点上的拣货员、打包员、厨师等人工执行具体的任务，执行完成进行任务提交后，才会流转到下一节点。而这种新零售场景的特点在于，每一个消费者用户的订单都有严格的时效性，从消费者用户下单支付开始，通常都会经过人工拣货、人工打包及人工配送的过程，人的处理速度是有限度的，和机器完全不是在一个量级上。因此，对于这种业务子系统而言，一个具体的线下实体店铺业务子系统所能够对外提供服务的最大限度，并不仅由系统软件能够达到的最大服务能力来决定，更多的取决于人工操作所能够达到的最大服务能力。

而对于一个业务子系统而言，压力测试通常是很必要的，尤其是在一些业务并发量比较大的情况发生之前，通常需要对系统所能够承受的最大服务能力进行测试。对于上述新零售系统中的业务子系统也是一样，例如，某提供新零售服务的组织机构，可能每年都需要开展一场或两场超大型的促销活动，另外，每个月还可能都会有日常大促活动，等等，频率之高使得这种业务子系统必须有一套自己的压测系统来保障每一次的大促正常开展。

然而，现有的压测系统仅仅是对软件系统层面的压力测试，这样做的效果就是可以检测出软件系统可以达到的最大服务能力，对于人工操作所能够达到的最大服务能力却无能为力。这使得门店的服务能力压测结果及容量评估结果和最终的实际结果是会产生无法预知的偏差。

因此，如何更准确地对包含人工作业的业务处理流程的最大服务能力进行测试或容量评估，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了业务处理流程模拟方法、装置及系统，能够实现对包含人工作业的业务处理流程进行更准确的模拟，从而可以为压力测试等提供更准确的依据。

本申请提供了如下方案：

一种业务处理流程模拟系统，包括：

引擎子系统，代理节点子系统以及业务子系统；其中，

引擎子系统，用于通过对所述代理节点子系统进行调用的方式，发起对所述业务子系统中的业务处理流程进行仿真的仿真任务；其中，所述仿真任务在多个调用周期内发起多次；

代理节点子系统，包括多个代理节点对象，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述代理节点对象用于根据所述引擎子系统在所述调用周期内的调用信息，确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；

业务子系统，用于在所述代理节点对象执行所述动作的过程中，提供模拟所需的工单信息并实现在不同的业务节点之间进行流转。

一种业务处理流程模拟方法，包括：

按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行。

一种业务处理流程模拟方法，包括：

代理节点对象接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转。

一种业务处理流程模拟装置，包括：

仿真任务生成单元，用于按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

仿真任务发起单元，用于通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行。

一种业务处理流程模拟装置，包括：

调用信息接收单元，用于接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

动作执行单元，用于确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，通过该代理节点对象可以模拟业务链路中的具体业务节点，并通过具体代理实例来模拟具体业务节点中配置的作业人员，然后，通过引擎子系统来驱动具体的代理节点对象执行具体动作的方式，对具体的业务处理流程进行模拟。其中，由于同一业务节点上的不同作业人员，在同一时刻执行的具体动作可能是不同的，因此，为了达到这一目的，可以是在不同的调用周期对各个代理节点对象调用多次，执行多次仿真任务，每次调用时，具体代理实例所执行的动作都可能是随机的，以此来达到模拟真实的效果。另外，在进行模拟的过程中，还可以由具体的业务子系统提供具体模拟所需的任务订单的生成以及流转方面的支持。这样，可以实现对包含人工作业的业务处理流程进行更准确的模拟，从而可以为压力测试等提供更准确的依据。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统的示意图；

图2是本申请实施例提供的加速运行的示意图；

图3是本申请实施例提供的第一方法的流程图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，为了能够更准确地对包含人工作业的业务处理流程进行准确的压力测试等，提供了一种业务处理流程模拟系统，在该系统中，可以包括引擎子系统，代理节点子系统以及业务子系统。其中，业务子系统具体就可以是实际被模拟的系统，在实际应用中，这种业务子系统能够支持各自业务节点上的任务工单生成以及流转，其中，每个业务节点上的任务工单，可以由对应节点上通过人工作业的方式来完成。因此，本申请实施例中主要就可以创建出代理节点对象(Agent)的方式，来对应这种业务节点，然后通过在具体的代理节点对象下生成具体的代理实例，来对应具体业务节点上的人工，再通过为这种代理节点实现一些执行多种动作的接口，使得引擎子系统能够通过这种接口实现对代理节点对象的调用，通过这种调用的方式来使得代理节点对象中的具体代理实例在执行某些特定的动作，以此来模拟具体业务节点上的人工作业。再通过业务子系统的配合，实现对具体作业过程中的任务工单的生成以及在不同节点之间的流转，以此实现对整个业务处理流程的模拟。

其中，具体的业务子系统可以是用于执行实际业务的系统，具体实现时，可以在原有的业务子系统基础上做一些改造，例如，为了避免对真实的业务流程造成影响，可以对模拟过程中生成的各种任务工单等添加特殊的标记，并与真实的任务工单进行独立保存，等等。

而引擎子系统以及代理节点子系统中的代理节点对象则可以是另行开发的系统。其中，在实际应用中，业务子系统中的业务链路中通常会包括多个业务节点，因此，代理节点子系统中也可以包括多个代理节点对象，分别对象业务链路中的各个不同的业务节点。例如，在某业务链路中，包括拣货，打包，配送等多个业务节点，则可以对应生成四个代理节点对象。另外，具体的代理节点对象内部还可以提供一些具体的实现，例如，可以提供具体的代理实例等，其中，代理实例对应于具体业务节点上的人工，也就是说，通过这种方式可以模拟出拣货、打包等节点上分别配置了多少人工，等等。需要说明的是，引擎子系统以及各个代理节点对象都可以看作是各自独立的应用程序，具体实现时，可以分别独立开发，独立安装部署。但是，为了使得各个应用程序之间能够相互通信，可以各自实现一些接口，这些使得不同的应用程序之间能够通过接口调用的方式实现相互通信。

通过这种对实际业务处理流程的仿真模拟，可以实现对固定人工配置的情况下，最大服务能力的测试，或者，还可以实现在固定任务单量的情况下，最佳人工配置的评估，等等。下面对本申请实施例提供的具体实现方案进行详细介绍。

实施例一

参见图1，本申请实施例首先提供了一种业务处理流程模拟系统，该系统具体可以包括：

引擎子系统101，代理节点子系统102以及业务子系统103；其中，

引擎子系统101，用于通过对所述代理节点子系统进行调用发起对所述业务子系统中的业务处理流程进行仿真的仿真任务；其中，所述仿真任务在多个调用周期内发起多次；

代理节点子系统102，包括多个代理节点对象，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述代理节点对象用于根据所述引擎子系统在所述调用周期内的调用信息，确定该调用周期内需要执行的动作并执行；所述代理节点中包括至少一个代理实例；

业务子系统103，用于在所述代理节点对象执行所述动作的过程中，提供所需的工单信息并实现在不同的业务节点之间进行流转。

首先需要说明的是，在真实的业务处理流程中，具体的业务链路通常会包括多个业务节点，例如，对于针对发货链路，前端的消费者用户等生成了具体的交易订单之后，到达后端的业务处理流程，具体可以经过拣货，打包，配送等多个环节，到达具体的收货地址。在此过程中，具体的业务子系统可以根据前端的交易订单生成拣货单，配送单等，由拣货节点上的拣货员进行完成拣货并提交后，再由打包节点上的打包员完成打包操作，最后由配送节点上的配送员进行配送。在此过程中，需要具体业务节点上的人工作业与业务子系统的工单处理相互配合，最终完成一个具体的业务处理流程。

而在本申请实施例中，具体关于工单的生成、流转等操作，仍然可以由具体的业务子系统来完成，而关于具体业务节点上的人工作业，则可以生成代理节点对象，并由代理节点对象下的具体代理实例来代表对应的作业人员。这样，假设某业务链路上包括三个业务节点，则可以生成三个代理节点对象。另外，还可以分别在代理节点内维护代理实例，例如，每个代理节点对象下还可以创建多个代理实例，代表同一个节点上部署了多个人工同时作业，例如，拣货节点上配了多个拣货员，等等。

而关于具体代理节点子系统中的各个代理节点对象如何进行作业模拟，则需要由引擎子系统进行驱动。也就是说，在引擎子系统的驱动下，代理节点对象执行对应的动作，通过这种动作的执行，来模拟对应业务节点上的人工作业。

其中，由于在实际作业系统中，具体业务节点上的某个人工进行作业的过程中，通常需要首先领取一个任务工单，例如拣货单等，然后，处理该任务工单，包括执行具体的拣货、打包等操作，在完成具体的处理之后，再将处理结果，包括“拣货已完成”、“打包已完成”等提交到业务子系统，使得业务子系统可以将具体的业务流程流转到下游的业务节点。因此，在本申请实施例中，代理节点需要执行的动作，同样可以包括三种，也即，任务工单的领取(getTask)、任务工单的处理(doTask)以及对处理结果(submitTask)的提交。引擎子系统就可以通过向代理节点对象发送上述各种类型的动作调用信息，来驱动代理节点对象执行对应的动作。getTask意思为从引擎子系统处获取需要执行的动作，各个Agent会分别计算，比如说拣货Agent会返回需要拣货的几个捡货单，打包Agent会返回需要打包的几个打包单等。通常这些task都是一个列表，在接下来的doTask和submitTask中，会对这个列表进行遍历执行。doTask意思是处理这些拣货单、打包单等，比如说拣货Agent会根据拣货单上的要求，将所需要的商品一一获取，为了模拟真实人的捡货流程所消耗的时间，当doTask做完之后(假设此时时间为t1)，还可以设定一个提交时间(假设为t2)，只有到了提交时间，才会执行submitTask，就好比现实生活中，拣货就消耗了(t2-t1)这么长的时间(后文对此还会有详细介绍)。submit意思是处理完这些任务工单后，将处理结果提交，如doTask中所说的，doTask就好比是执行一个任务工单的开始时间点，submitTask就好比是这个任务工单的完成时间点。系统的执行速度是很快的，相比于人工操作，系统的执行就模拟了真实执行的开始和结束，来达到模拟消耗一段时间的效果。

其中，如前文所述，在本申请实施例中，具体的引擎子系统、代理节点对象都可以看作是独立的应用程序，各自独立开发、部署，因此，为了实现引擎子系统对代理节点对象的驱动，或者，也为了使得代理节点对象、业务子系统等从引擎子系统获得一些相关的信息，还可以预先为引擎子系统、代理节点对象等实现预置的接口。这种接口可以是预先由引擎子系统定义的，例如，引擎子系统具体实现的接口可以包括：根据仿真的环境信息获取仿真任务id的接口，根据仿真任务id获取当前仿真时间的接口等。另外，代理节点对象实现的接口则可以包括：清理数据，初始化Agent(代理节点对象)，获取Task(任务工单)列表，处理Task，提交Task等。这样，如果引擎子系统需要驱动某代理节点对象执行某种动作，则可以通过该代理节点对象预先实现的上述接口，发起对该代理节点对象的调用，相应的，代理节点对象即可收到相应的调用信息，并执行对应的动作。另外，如果代理节点对象在执行具体动作的过程中，需要获取当前的仿真任务id，或者访问时间等信息，则可以通过引擎子系统实现的前述接口，对引擎子系统发起调用，以获得对应的信息，等等。

在具体实现时，由于前端的交易订单通常是在不断产生，而一个订单在进入后端的拣货、打包、配送等处理流程后，需要经过一段时间，因此，通常每个业务节点上的作业人员都会不断收到新的任务，在同一时刻，可能有不同的交易订单分别在不同的业务节点上，由不同的作业人员执行。例如，某时刻，由10个订单在拣货节点处进行拣货处理，20个订单在进行打包处理，20个在执行配送处理，等等。同一个业务节点上的不同作业人员，也可能分别执行不同的动作，例如，有的刚刚领取到一个新的任务工单，有的正在处理某个任务工单，有的已经处理完成一个任务工单，等待接收新的任务工单，等等。因此，同一个代理节点对象处的不同代理实例在同一时刻可能也会需要执行不同的动作，而下一时刻的动作又可能会发生变化。为了能够模拟出上述特点，引擎子系统对代理节点对象的驱动过程可以是在多个不同的调用周期中分别进行调用多次。其中，具体的调用周期会比较短，例如，可以是每一秒钟进行一次调用，等等。其中，在一个调用周期中，一个代理节点对象中的一个代理实例只需要执行一个具体的动作，例如，领取、处理或者提交，下一个调用周期再执行其他的动作，等等。也就是说，每个调用周期，都可以由引擎子系统驱动具体的代理节点对象中的代理实例执行某个动作，其中，每个动作都可能会由不同的代理实例执行，各个动作之间可以是乱序的，可以不是针对同一个前端的交易订单。例如，在某调用周期，可能需要驱动某代理节点对象领取一批任务工单，然后，由具体的代理实例处理上述任务工单，或者，可能会驱动另一些代理实例执行之前的调用周期中已经完成的任务工单的处理结果提交工作(对此，后文中会有详细介绍)，等等。这样，通过这种动作多样、乱序的驱动，可以更真实的模拟出具体业务节点上各个不同的人工的作业情况。这里需要说明的是，当仿真任务确定可以开始执行之后，引擎子系统还可以首先调用各个代理节点对象(Agent)，分别进行数据清理及初始化，只有当所有的Agent都表明可以达到执行状态时，仿真任务才真正开始执行。

其中，关于具体的调用周期，可以有多种方式进行确定，例如，其中一种方式下，可以是预先设定好具体的时间间隔，例如，可以是1秒钟，这样，所述引擎子系统具体可以根据该预置的时间间隔进行多个调用周期的仿真任务调用。也就是说，可以每一秒钟发起一次仿真任务的执行。

或者，在另一种方式下，还可以由所述引擎子系统根据当前周期的仿真任务完成情况，确定下一调用周期的开始时间。之所以这样进行是因为，对于一个调用周期对应的仿真任务而言，其中可能包括多个需要由不同的代理节点对象中的代理实例执行的具体动作。例如，在一次仿真任务中，需要由代理节点对象A下的代理实例执行任务工单列表的领取，然后，由具体的代理实例执行具体的处理，另外还有的代理实例需要执行处理任务的提交等动作。虽然上述动作的执行实际上由计算机程序来执行，并不是真正的人工作业，理论上是可以在非常短的时间内处理完成，但是，在实际应用中，并不排除部分代理实例执行具体动作时存在一定的延迟等现象。这就导致，如果预先设定的时间间隔比较小，则某些代理实例在一个时间周期内可能无法完成被分配执行的动作，但下一个时间周期又已经开始了，此时，会对业务代理对象以及业务子系统造成比较大的系统压力，一旦压力累计，最终可能会产生雪崩效应。因此，为了避免出现上述情况，在本申请实施例中，引擎子系统可以跟实际的仿真任务完成情况来确定下一个调用周期的开始时间。也就是说，只有在一个时间周期内，所有代理节点对象中的具体动作全部做完，才会进入下一个周期，以此来消除前述问题。

如前文所述，在本申请实施例中，具体需要模拟的动作的执行，都是由计算机程序来完成的，因此，每个动作基本都可以在很短的时间内完成。但是，在实际应用中，对于一个作业人员而言，处理一个具体的任务工单，通常是需要花费一些时间的，例如，从接收到拣货单开始，到完成具体的拣货、称重等操作，可能需要几分钟的时间，等等。因此，在本申请实施例中，为了更有效地模拟实际作业人员的操作，还可以在在完成任务工单的处理与处理结果的提交之间设定强制等待时间信息。也就是说，在同一个调用周期中，如果驱动某代理节点对象领取到了一些任务工单，则可以直接在该调用周期内继续驱动具体的代理节点对象执行具体的“处理”动作。但是，在处理完成后，则需要等待一段时间才能够执行提交动作。因此，对于一个调用周期内的仿真任务而言，在领取并执行“处理”动作的代理实例而言，只要在完成具体的“处理”动作，即可认为完成此次仿真任务。同时，引擎子系统可以记录下具体任务工单的处理完成时间等信息，然后，根据具体需要强制等待的时间，可以确定出需要提交该任务工单处理结果的时间，在后续发起其他仿真任务的过程中，在该时间到来时，再在对应调用周期中，发起对具体的提交动作的调用，等等。

也就是说，所述引擎子系统具体用于，在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息，并在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息，以便所述代理节点对象对所述任务工单进行处理，在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。当然，由于具体的调用周期的时间长度通常远远短于上述需要强制等待的时间长度，因此，对于一个任务工单的处理结果的提交动作，通常是在完成具体任务工单处理动作之后的若干个调用周期中才会被触发执行。具体实现时，引擎子系统中保存的任务工单信息表具体可以如表1所示：

表1

其中，上述表1中记录的需要提交处理结果的时间是未来的某个时间点，后续在具体某个任务工单对应的需要提交处理结果的时间到来时，就可以驱动对应的代理节点对象执行对该任务工单的处理结果的提交动作，在完成该提交动作后，则可以将对应的条目从上述表1中删除。

正是因为存在上述强制等待时间信息，因此，具体的引擎子系统还可以用于，在同一调用周期内，判断所述任务工单信息表中是否存在强制等待时间到期的目标任务工单，如果存在，则向该目标任务工单对应的代理对象节点发送对所述任务工单对应的任务处理结果进行提交的第三动作调用信息。此时，所述任务对象节点具体用于，根据所述第三动作调用信息，触发具体的代理实例对对应的任务工单的处理结果提交到所述业务子系统，并向所述引擎子系统返回响应消息。其中，强制等待时间到期的目标任务工单包括在当前调用周期之前的某个调用周期内完成处理动作的任务工单。一个仿真任务有一个开始时间和一个结束时间，在这段时间内，根据时间间隔，这个仿真任务在不停的重复执行，并且对于一个任务工单而言，会在第一个周期的get时获取到，并进行了一次do(处理)，但是，直到第三个周期才去submit(提交)。这就使得每一个周期内，都会有随机的动作进来，这样就达到了模拟真实的效果。

需要说明的是，对于具体代理节点对象下的代理实例而言，在完成具体关于某个任务工单的处理动作后，在若干个调用周期后提交具体的处理结果之前的这段时间内，该代理实例可以处于“作业中”状态。对于具体的代理实例而言，还可以预先设定具体的饱和条件等信息，例如，同一时刻最多只能执行一个任务工单，或者N个任务工单，等等，这样，在某个代理实例执行了对某个任务工单的处理动作后，可以将其已经被分配的单量进行加一操作，并可以根据该代理实例同时可承受的最大单量，确定该代理实例的任务是否已达到饱和。如果某代理实例已经达到饱和，则不能再处理新的任务工单。而一个代理节点对象下的代理实例数量又是有限的，因此，在具体实现时，所述代理节点对象具体用于，在接收到所述领取任务工单的第一动作调用信息后，可以首先根据该代理节点对象内部的代理实例数量及状态，确定处于任务未饱和状态的代理实例的数量，然后，根据该数量向所述业务子系统领取对应数量的任务工单，并向所述引擎子系统返回响应信息。如果上述处于任务未饱和状态的代理实例的数量为0，则可以拒绝执行该领取动作，如果大于0，则可以从业务子系统中领取对应数量的任务工单。然后，在同一调用周期内接收到所述第二动作调用信息后，可以将所领取到的任务工单分发到该代理节点对象下任务未饱和的代理实例进行任务工单的处理，并在处理完成后通知给所述引擎子系统。这里需要指出的是，在一个代理节点对象下处于任务未饱和状态的代理实例的数量大于0时，实际从业务子系统中领取到的任务工单数量可能会小于该数量。这是因为，具体的任务工单是在多个不同的业务节点之间流转并逐渐产生的，在模拟初始阶段等情况下，对于处于下游位置的业务节点而言，上游节点的处理结果尚未提交的情况下，下游节点上的任务工单可能尚未生成，因此，对于下游的代理节点对象而言，即使当前有多个代理实例都处于可以接受新的任务工单的状态，可也无法领取到对应数量的需要处理的任务工单。此时，对于一个代理节点对象而言，将实际领取到的任务工单列表如实返回给引擎子系统即可，即使部分时刻该任务工单列表中的任务工单数量可能为0。

另外需要说明的是，关于一个具体的任务工单从完成处理到提交处理结果之间的强制等待时间也可以通过多种方式进行确定。例如，在其中一种方式下，可以根据所述代理节点对象对应的业务节点所对应工种对一个任务工单的平均作业时间信息，确定所述强制等待时间信息。也就是说，对于同一代理节点而言，由于对应的业务节点的工种相同，因此，处理一个任务工单所需的时间通常比较接近，这样，可以直接根据具体的工种对一个任务工单的平均作业时间信息，来确定上述强制等待时间。

或者，由于同一个业务节点上的不同作业人员，由于经验、能力等不同，具体处理任务的时间长度也可能不同，因此，为了更准确的进行模拟，还可以使得同一代理节点对象中的多个不同代理实例，对应不同的强制等待时间，以用于模拟对应的人工操作过程中，由于不同工人之间不同的业务能力所导致的作业时间之间的差异。

以上所述对具体的业务流程的模拟方式进行进了介绍，而在具体实现时，为了不影响具体业务子系统中的真实业务，具体用于模拟的任务工单可以是虚拟生成的。为此，在具体实现时，还可以提供一种特殊的代理节点对象，该代理节点对象具体可以用于生成链路入口处的任务工单。也就是说，具体用于仿真模拟的过程中所需要用到的链路入口处的任务工单，可以是由该代理节点“创造”的，而不是真正根据具体消费者用户的交易订单等进行真实创建的，因此，也可以将这种代理节点对象称为“造单”代理，在本申请实施例中称为第一代理节点对象。此时，所述引擎子系统还可以用于，根据待模拟的目标单量，目标时间段，以及所述时间段内的单量分布信息，向所述第一代理节点对象发送生成链路入口处的任务工单的调用信息。例如，需要对某个大促活动内预计可能产生的单量进行测试，该大促活动的起始时间到结束时间就是上述目标时间段，而关于单量分布信息，则可以根据具体的经验、活动中设置的一些特殊时间节点等，确定出大致可能出现的下单高峰期，稳定期，低谷期等，然后根据上述情况，确定出具体单量的分布情况。例如，大促活动刚刚开始时刻可能会出现下单高峰，午餐、晚餐时段可能出现下单高峰，等等，在这些高峰期可以加大单量的分布，等等。引擎子系统可以根据具体的单量分布情况，向第一代理节点对象发起生成具体链路入口处的任务工单的调用信息。相应的，第一代理节点对象可以向具体的业务子系统发送生成具体任务工单的请求，所述业务子系统则可以用于，对所述第一代理节点对象生成的任务工单信息进行保存，并在收到具体业务节点对应的代理节点提交的处理结果信息后，生成需要流转到业务链路中下游节点的任务工单。也就是说，第一代理节点对象只需要创造出链路入口处的任务工单，后续下游节点中的任务工单则可以由业务子系统根据具体的业务处理逻辑来自动生成。其中，在具体实现时，所述业务子系统还用于为所述仿真任务中生成的任务工单添加预置标识，并与实际任务中生成的任务工单进行单独保存。

另外，在具体实现时，由于需要使用真实的业务子系统来对仿真过程中的工单流转等提供支持，因此，为了避免对真实的业务处理造成影响，通常可以在一些凌晨时间等系统相对较空闲的时间进行上述仿真过程。另外，除了以上的核心流程外，本申请实施例提供的仿真系统还可以提供加速运行的功能。所述引擎子系统具体用于，将具体大促活动等对应的目标时间段确定为第一时间段，但是，是在第二时间段内对，通过在多个调用周期内调用代理节点子系统执行多次仿真任务进行业务模拟，其中，所述第二时间段的长度小于所述第一时间段的长度。

为了便于理解上述加速运行方案，首先介绍一下仿真压测系统内的时间概念：仿真系统内的时间称为“仿真时间”，而现实生活中的时间可以称之为“真实时间”，如图2所示，一个仿真任务的开始和结束时间可以对应到现实生活中的两个时间点上，但是，这两组时间点(仿真时间开始结束、真实时间开始结束)之间并没有任何关系，仿真时间在真实时间之后，就是对以往的结果进行再次验证优化，试图找到更好的解决方案，仿真时间在真实时间之前，就是对未来的预测。在仿真系统中，开始和结束两个时间点可以相差了2个小时，但是这个时间是由仿真引擎告诉各个Agent的，实际上，真实时间可能只有1个小时的时间差，但是在仿真系统中，大家都认为会有2个小时，所以在这样的情况下，系统运行结束之后，就相当于使用2倍速跑完了真实2个小时的任务量。仿真压测系统之所以需要有时间加速的特性，是因为通常大促活动都会持续1天或者超过1天，如果系统也要运行1天或者超过1天，那么这样的效率是不能接受的，所以可以增加加速运行这样的特性。有了这个特性之后，对于任何预测任务，都可以快速完成，进行验证。例如，在大促活动的时间是从某天的00：00到23：59，模拟所需的目标单量在这24小时之间都会有分布，也就是说，按照实际时间，应该是从00：00开始，执行与第一个任务工单相关的动作，但是，在1：00时执行该时刻产生的任务工单对应的动作，等等。但是，如果按此时间进行模拟，则需要24小时才能完成模拟的过程。而在加速运行的方式下，则可以00：30时，就告诉Agent现在已经是1：00了，在1：00时告诉Agent现在已经是2：00，则Agent就会按照引擎子系统提供的时间信息对执行具体的任务工单对应的动作，以此来加快测试的效率。

通过前述方式可以实现对包含有人工作业的业务处理流程的仿真模拟，在这种模拟的基础上，所述引擎子系统还可以根据所述代理节点子系统对所述目标单量的完成情况，获得压力测试结果。其中，根据压力测试的目的不同，具体获得的结果也可以不同。例如，一种情况，所述引擎子系统具体用于，在代理节点子系统中的代理实例配置信息不变的情况下，通过调整所述目标单量，获得所述代理节点子系统在当前的代理实例配置下可提供的最大服务能力。也就是说，可以针对某个具体的实体店铺中各个业务节点上的作业人员配置情况，来配置具体代理节点对象下的代理实例数量，然后，通过调整目标单量的方式，测试出该实体店铺现有的作业人员配置条件下，能够提供的最大服务能力。

或者，所述引擎子系统具体还可以用于，在所述目标单量不变的情况下，通过调整所述代理节点子系统中的代理实例配置信息，获得为完成所述目标单量，所述代理节点子系统的代理实例最佳配置信息。也就是说，假设为即将开展的大促活动估计出的目标单量是大致准确的，则还可以通过多次模拟，来不断调整具体业务节点上的作业人员配置情况的方式，来确定出为了完成该单量所需的最佳配置信息。这样，具体的实体店铺可以根据该最佳配置信息，提前准备好各个业务节点上的人员配置，以应对具体大促期间大量产生的单量。

总之，通过本申请实施例，通过该代理节点对象可以模拟业务链路中的具体业务节点，并通过具体代理实例来模拟具体业务节点中配置的作业人员，然后，通过引擎子系统来驱动具体的代理节点对象执行具体动作的方式，对具体的业务处理流程进行模拟。其中，由于同一业务节点上的不同作业人员，在同一时刻执行的具体动作可能是不同的，因此，为了达到这一目的，可以是在不同的调用周期对各个代理节点对象调用多次，执行多次仿真任务，每次调用时，具体代理实例所执行的动作都可能是随机的，以此来达到达到模拟真实的效果。另外，在进行模拟的过程中，还可以由具体的业务子系统提供具体模拟所需的任务订单的生成以及流转方面的支持。这样，可以实现对包含人工作业的业务处理流程进行更准确的模拟，从而可以为压力测试等提供更准确的依据。

实施例二

该实施例二是与实施例一相对应的，从引擎子系统的角度，提供了一种业务处理流程模拟方法，参见图3，该方法具体可以包括：

S301：按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

S302：通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行。

其中，具体实现时，可以通过所述代理实例执行所述动作的方式来模拟对应业务节点上的人工操作，并通过业务子系统提供模拟所需的工单信息并实现在不同的业务节点之间进行流转。

具体实现时，可以根据预置的时间间隔确定所述调用周期。

或者，根据当前周期的仿真任务完成情况，确定下一调用周期的开始时间。

其中，可以在同一调用周期中，调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交，其中，同一代理实例在同一调用周期中对同一动作仅执行一次。

另外，还可以在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，同一任务工单的处理动作与处理结果的提交动作在不同的调用周期中完成。

此时，具体可以在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息，以便所述代理节点对象对所述任务工单进行处理；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

另外，还可以在同一调用周期内，判断所述任务工单信息表中是否存在强制等待时间到期的目标任务工单，如果存在，则向该目标任务工单对应的代理对象节点发送对所述任务工单对应的任务处理结果进行提交的第三动作调用信息。

其中，具体可以根据所述代理节点对象对应的业务节点所对应工种对一个任务工单的平均作业时间信息，确定所述强制等待时间信息。

或者，同一代理节点对象中的多个不同代理实例，对应不同的强制等待时间，以用于模拟对应的人工操作过程中，由于不同工人之间不同的业务能力所导致的作业时间之间的差异。

另外，在具体实现时，还可以根据待模拟的目标单量，目标时间段，以及所述时间段内的单量分布信息，向第一代理节点对象发送生成链路入口处的任务工单的调用信息，所述第一代理节点对象为用于生成链路入口处的任务工单的代理节点对象，以便通过所述业务子系统生成所述链路入口处的任务工单。

为了能够进行加速运行，还可以将所述目标时间段确定为第一时间段，并在第二时间段内对，通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述第二时间段的长度小于所述第一时间段的长度。

另外，还可以根据所述代理节点子系统对所述目标单量的完成情况，获得压力测试结果。

其中，具体可以在代理节点子系统中的代理实例配置信息不变的情况下，通过调整所述目标单量，获得所述代理节点子系统在当前的代理实例配置下可提供的最大服务能力信息。

或者，在所述目标单量不变的情况下，通过调整所述代理节点子系统中的代理实例配置信息，获得为完成所述目标单量，所述代理节点子系统的代理实例最佳配置信息。

实施例三

该实施例三是从代理节点对象的角度，提供了一种业务处理流程模拟方法，参见图4，该方法具体可以包括：

S401：接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

S402：确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转。

具体的，可以在接收到所述引擎子系统关于领取任务工单的第一动作调用信息后，根据该代理节点对象内部的代理实例数量及状态，确定处于任务未饱和状态的代理实例的数量，并根据该数量向所述所述目标业务子系统领取对应数量的任务工单；在领取到任务工单后，向所述引擎子系统返回响应信息；在同一调用周期内接收到用于处理所述任务工单的第二动作调用信息后，将所领取到的任务工单分发到该代理节点对象下任务未饱和的代理实例进行任务工单的处理，并在处理完成后通知给所述引擎子系统。

另外，还可以在接收到所述引擎子系统关于提交任务工单处理结果的第三动作调用信息后，将任务处理结果提交到所述目标业务子系统，并向所述引擎子系统返回响应消息。

其中，关于前述实施例二以及实施例三中的未详述部分，可参照实施例中的记载，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种业务处理流程模拟装置，具体的，参见图5，该装置具体可以包括：

仿真任务生成单元501，用于按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

仿真任务发起单元502，用于通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行。

具体实现时，可以根据预置的时间间隔确定所述调用周期。

或者，根据当前周期的仿真任务完成情况，确定下一调用周期的开始时间。

其中，仿真任务发起单元具体可以用于：在同一调用周期中，调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交，其中，同一代理实例在同一调用周期中对同一动作仅执行一次。

另外，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，同一任务工单的处理动作与处理结果的提交动作可以在不同的调用周期中完成。

此时，仿真任务发起单元具体可以包括：

第一发起子单元，用于在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；

第二发起子单元，用于在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息，以便所述代理节点对象对所述任务工单进行处理；

记录子单元，用于在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

另外，仿真任务发起单元具体还可以包括：

第三发起子单元，用于在同一调用周期内，判断所述任务工单信息表中是否存在强制等待时间到期的目标任务工单，如果存在，则向该目标任务工单对应的代理对象节点发送对所述任务工单对应的任务处理结果进行提交的第三动作调用信息。

其中，该装置还可以包括：

第一等待时间确定单元，用于具体可以根据所述代理节点对象对应的业务节点所对应工种对一个任务工单的平均作业时间信息，确定所述强制等待时间信息。

或者，同一代理节点对象中的多个不同代理实例，对应不同的强制等待时间，以用于模拟对应的人工操作过程中，由于不同工人之间不同的业务能力所导致的作业时间之间的差异。

另外，在具体实现时，该装置还可以包括：

入口任务工单生成单元，用于根据待模拟的目标单量，目标时间段，以及所述时间段内的单量分布信息，向第一代理节点对象发送生成链路入口处的任务工单的调用信息，所述第一代理节点对象为用于生成链路入口处的任务工单的代理节点对象，以便通过所述业务子系统生成所述链路入口处的任务工单。

为了能够进行加速运行，还可以包括：

加速运行单元，用于将所述目标时间段确定为第一时间段，并在第二时间段内对，通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述第二时间段的长度小于所述第一时间段的长度。

另外，还可以包括：

测试结果获得单元，用于根据所述代理节点子系统对所述目标单量的完成情况，获得压力测试结果。

其中，测试结果获得单元具体可以用于：在代理节点子系统中的代理实例配置信息不变的情况下，通过调整所述目标单量，获得所述代理节点子系统在当前的代理实例配置下可提供的最大服务能力信息。

或者，测试结果获得单元具体可以用于：在所述目标单量不变的情况下，通过调整所述代理节点子系统中的代理实例配置信息，获得为完成所述目标单量，所述代理节点子系统的代理实例最佳配置信息。

与实施例三相对应，本申请实施例还提供了一种业务处理流程模拟装置，参见图6，该装置具体可以包括：

调用信息接收单元601，用于接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

动作执行单元602，用于确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转。

其中，动作执行单元具体可以包括：

第一执行子单元，用于在接收到所述引擎子系统关于领取任务工单的第一动作调用信息后，根据该代理节点对象内部的代理实例数量及状态，确定处于任务未饱和状态的代理实例的数量，并根据该数量向所述所述目标业务子系统领取对应数量的任务工单；在领取到任务工单后，向所述引擎子系统返回响应信息；

第二执行子单元，用于在同一调用周期内接收到用于处理所述任务工单的第二动作调用信息后，将所领取到的任务工单分发到该代理节点对象下任务未饱和的代理实例进行任务工单的处理，并在处理完成后通知给所述引擎子系统。

另外还可以包括：

第三执行子单元，用于在接收到所述引擎子系统关于提交任务工单处理结果的第三动作调用信息后，将任务处理结果提交到所述目标业务子系统，并向所述引擎子系统返回响应消息。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行。

以及另一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转。

其中，图7示例性的展示出了电子设备的架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。

其中，处理器710可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器720可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制电子设备700运行的操作系统721，用于控制电子设备700的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及仿真处理系统725等等。上述仿真处理系统725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。

输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。

另外，该电子设备700还可以从虚拟资源对象领取条件信息数据库741中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (21)

1.一种业务处理流程模拟系统，其特征在于，包括：

引擎子系统，代理节点子系统以及业务子系统；其中，

引擎子系统，用于通过对所述代理节点子系统进行调用的方式，发起对所述业务子系统中的业务处理流程进行仿真的仿真任务；其中，所述仿真任务在多个调用周期内发起多次；

代理节点子系统，包括多个代理节点对象，分别对应所述业务子系统中目标应业务链路中的多个业务节点，所述代理节点对象用于根据所述引擎子系统在所述调用周期内的调用信息，确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；

业务子系统，用于在所述代理节点对象执行所述动作的过程中，提供模拟所需的工单信息并实现在不同的业务节点之间进行流转；

其中，在同一调用周期中，调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

2.一种业务处理流程模拟方法，其特征在于，包括：

按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行；

其中，在同一调用周期中，调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

3.根据权利要求2所述的方法，其特征在于，还包括：

根据预置的时间间隔确定所述调用周期。

4.根据权利要求2所述的方法，其特征在于，还包括：

根据当前周期的仿真任务完成情况，确定下一调用周期的开始时间。

5.根据权利要求2所述的方法，其特征在于，

同一代理实例在同一调用周期中对同一动作仅执行一次。

6.根据权利要求5所述的方法，其特征在于，

同一任务工单的处理动作与处理结果的提交动作在不同的调用周期中完成。

7.根据权利要求2所述的方法，其特征在于，

所述调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，还包括：

在同一调用周期内，判断所述任务工单信息表中是否存在强制等待时间到期的目标任务工单，如果存在，则向该目标任务工单对应的代理对象节点发送对所述任务工单对应的任务处理结果进行提交的第三动作调用信息。

8.根据权利要求2所述的方法，其特征在于，还包括：

根据所述代理节点对象对应的业务节点所对应工种对一个任务工单的平均作业时间信息，确定所述强制等待时间信息。

9.根据权利要求2所述的方法，其特征在于，

同一代理节点对象中的多个不同代理实例，对应不同的强制等待时间，以用于模拟对应的人工操作过程中，由于不同工人之间不同的业务能力所导致的作业时间之间的差异。

10.根据权利要求2所述的方法，其特征在于，还包括：

根据待模拟的目标单量，目标时间段，以及所述时间段内的单量分布信息，向第一代理节点对象发送生成链路入口处的任务工单的调用信息，所述第一代理节点对象为用于生成链路入口处的任务工单的代理节点对象，以便通过所述业务子系统生成所述链路入口处的任务工单。

11.根据权利要求10所述的方法，其特征在于，

所述通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，包括：

将所述目标时间段确定为第一时间段，并在第二时间段内对，通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述第二时间段的长度小于所述第一时间段的长度。

12.根据权利要求10所述的方法，其特征在于，还包括：

根据所述代理节点子系统对所述目标单量的完成情况，获得压力测试结果。

13.根据权利要求12所述的方法，其特征在于，

所述获得压力测试结果包括：

在代理节点子系统中的代理实例配置信息不变的情况下，通过调整所述目标单量，获得所述代理节点子系统在当前的代理实例配置下可提供的最大服务能力信息。

14.根据权利要求12所述的方法，其特征在于，

所述获得压力测试结果包括：

在所述目标单量不变的情况下，通过调整所述代理节点子系统中的代理实例配置信息，获得为完成所述目标单量，所述代理节点子系统的代理实例最佳配置信息。

15.一种业务处理流程模拟方法，其特征在于，包括：

代理节点对象接收引擎子系统在当前调用周期中的调用信息，其中，所述代理节点对象为多个，分别对应业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转；

其中，在同一调用周期中，调用代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

16.根据权利要求15所述的方法，其特征在于，

所述确定该调用周期内需要执行的动作并分配给代理实例执行，包括：

在接收到所述引擎子系统关于领取任务工单的第一动作调用信息后，根据该代理节点对象内部的代理实例数量及状态，确定处于任务未饱和状态的代理实例的数量，并根据该数量向所述所述目标业务子系统领取对应数量的任务工单；在领取到任务工单后，向所述引擎子系统返回响应信息；

在同一调用周期内接收到用于处理所述任务工单的第二动作调用信息后，将所领取到的任务工单分发到该代理节点对象下任务未饱和的代理实例进行任务工单的处理，并在处理完成后通知给所述引擎子系统。

17.根据权利要求15所述的方法，其特征在于，

所述确定该调用周期内需要执行的动作并分配给代理实例执行，包括：

在接收到所述引擎子系统关于提交任务工单处理结果的第三动作调用信息后，将任务处理结果提交到所述目标业务子系统，并向所述引擎子系统返回响应消息。

18.一种业务处理流程模拟装置，其特征在于，包括：

仿真任务生成单元，用于按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

仿真任务发起单元，用于通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行；

其中，在同一调用周期中，调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

19.一种业务处理流程模拟装置，其特征在于，包括：

调用信息接收单元，用于接收引擎子系统在当前调用周期中的调用信息，其中，代理节点对象为多个，分别对应业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

动作执行单元，用于确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转；

其中，在同一调用周期中，调用代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

20.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

按照调用周期生成用于对目标业务子系统中的业务处理流程进行仿真的仿真任务；

通过对代理节点子系统中包括的多个代理节点对象进行调用的方式发起对所述仿真任务的执行，其中，所述代理节点对象为多个，分别对应所述业务子系统中目标应业务链路中的多个业务节点，用于确定所述调用周期内需要执行的动作并分配给代理实例执行；

其中，在同一调用周期中，调用所述代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

21.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收引擎子系统在当前调用周期中的调用信息，其中，代理节点对象为多个，分别对应业务子系统中目标应业务链路中的多个业务节点，所述引擎子系统用于在多个调用周期内发起多次仿真任务，每次仿真任务中，通过对所述代理节点对象进行调用的方式发起对所述仿真任务的执行；

确定该调用周期内需要执行的动作并分配给代理实例执行；所述代理节点对象中包括至少一个代理实例；其中，所述代理实例在执行所述动作的过程中，通过目标业务子系统获得所需的任务工单信息，向所述目标业务子系统提交处理结果，所述目标业务子系统用于实现任务工单在不同业务节点之间的流转；

其中，在同一调用周期中，调用代理节点子系统中的多个代理节点对象执行多种不同的动作，所述动作包括对任务工单的领取、处理以及处理结果的提交；

其中，在完成任务工单的处理与处理结果的提交之间具有强制等待时间信息，以便在所述调用周期内，向所述代理节点子系统中的多个代理节点对象发送对任务工单进行领取的第一动作调用信息；在所述代理节点对象领取到目标任务工单后，向所述代理节点对象发送对所领取到的任务工单进行处理的第二动作调用信息；在接收到所述代理节点对象完成任务工单处理的响应消息后，确定该代理节点对象完成该调用周期内的仿真任务，并通过任务工单信息表记录所述任务工单对应的处理完成时间信息，以用于根据所述强制等待时间信息确定该任务工单对应的处理结果的提交时间。

Images