CN107622060A - 订单跟踪分析方法及装置 - Google Patents

Abstract

本公开提供了一种订单跟踪分析方法及装置。该方法包括：建立对应于业务系统的业务处理结果的消息主题；监听所述消息主题，并在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。本公开可以提高解决异常的效率。

Description

订单跟踪分析方法及装置

技术领域

本公开涉及应用软件开发技术领域，具体而言，涉及一种订单跟踪分析方法以及订单跟踪分析装置。

背景技术

随着互联网技术的迅速发展，网上购物已经成为人们生活中不可缺少的一部分，各类网上购物平台的发展十分快速，其订单量、交易额近几年一直保持着较高的增长率。

在普通消费者眼中，网上购物过程只是网上挑选商品、网上支付、商家配送直至客户收货，但对于订单系统而言，多数订单都需要经过复杂的处理过程。以一个订单的为例，其从客户下单到客户收货完成，这个订单可能需要经过几十甚至上百种不同业务系统的处理，这些业务系统之间相互分离但又相互依赖。

目前，一个比较棘手的问题是一旦订单处理过程中出现了异常，使用者通过很难准确的定位到该订单在订单处理系统中的哪个业务系统出现了异常以及很难了解出现异常的原因是什么。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种订单跟踪分析方法以及订单跟踪分析装置，用于至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或多个问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本公开的一个方面，提供一种订单跟踪分析方法，应用包括一或多个业务系统的订单处理系统，所述订单跟踪分析方法包括：

S1.建立对应于所述业务系统的业务处理结果的消息主题；

S2.监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；

S3.在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；

S4.监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；

S5.根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

在本公开的一种示例性实施例中，其中：

所述步骤S1包括，建立第一消息主题以及第二消息主题；所述第一消息主题用于接收各所述业务系统生产的处理成功消息，所述第二消息主题用于接收各所述业务系统生产的处理异常消息。

在本公开的一种示例性实施例中，其中：

所述步骤S2包括，在监听到所述第一消息主题接收到处理成功消息时将接收到的处理成功消息数据组织成上下文对象发送至第一数据包接口，在监听到所述第二消息主题接收到处理异常消息时将接收到的处理异常消息数据组织成上下文对象发送至第二数据包接口。

在本公开的一种示例性实施例中，其中：

所述步骤S3包括，在所述第一数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列；以及，在所述第二数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列。

在本公开的一种示例性实施例中，其中：

所述步骤S4包括，在监听到所述数据存储队列接收到包含处理成功消息的数据包时将接收到的数据包存储至第一表单，以及，在监听到所述数据存储队列接收到包含处理异常消息的数据包时将接收到的数据包存储至第二表单。

在本公开的一种示例性实施例中，所述业务处理结果消息为JSON文本格式；所述步骤S2还包括，将JSON文本格式的所述业务处理结果消息反序列化成类对象，以及所述类对象组织成上下文对象发送至数据包接口。

在本公开的一种示例性实施例中，所述步骤S3包括：

S31.在所述数据包接口接收到上下文对象时通过所述数据包接口将接收到的上下文对象写入当前数据包；

S32.判断所述当前数据包中的上下文对象是否达到预设数量以及所述当前数据包的生命周期是否超过预设时间；

S33.在判断所述当前数据包中的上下文对象达到所述预设数量或者所述当前数据包的生命周期超过预设时间时，锁定所述当前数据包，并将所述当前数据包插入所述数据存储队列；

S34.获取新的数据包作为所述当前数据包，并跳转至步骤S31。

在本公开的一种示例性实施例中，所述步骤S33还包括：

在所述当前数据包被锁定期间，将所述数据包接口接收到的上下文对象放入临时数据集合，并在解除所述当前数据包的锁定后，根据所述临时数据集合中的上下文对象生成数据包且插入到所述数据存储队列。

根据本公开的一个方面，提供一种订单跟踪分析装置，应用包括一或多个业务系统的订单处理系统，所述订单跟踪分析装置包括：

主题建立模块，用于建立对应于所述业务系统的业务处理结果的消息主题；

上下文组织模块，用于监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；

数据包生成模块，用于在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；

队列存储模块，用于监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；

轨迹生成模块，用于根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

在本公开的一种示例性实施例中，其中：

所述主题建立模块用于，建立第一消息主题以及第二消息主题；所述第一消息主题用于接收各所述业务系统生产的处理成功消息，所述第二消息主题用于接收各所述业务系统生产的处理异常消息。

在本公开的一种示例性实施例中，其中：

所述上下文组织模块用于，在监听到所述第一消息主题接收到处理成功消息时将接收到的处理成功消息数据组织成上下文对象发送至第一数据包接口，在监听到所述第二消息主题接收到处理异常消息时将接收到的处理异常消息数据组织成上下文对象发送至第二数据包接口。

在本公开的一种示例性实施例中，其中：

所述数据包生成模块用于，在所述第一数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列；以及，在所述第二数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列。

在本公开的一种示例性实施例中，其中：

所述队列存储模块用于，在监听到所述数据存储队列接收到包含处理成功消息的数据包时将接收到的数据包存储至第一表单，以及，在监听到所述数据存储队列接收到包含处理异常消息的数据包时将接收到的数据包存储至第二表单。

在本公开的一种示例性实施例中，所述业务处理结果消息为JSON文本格式；所述上下文组织模块还用于，将JSON文本格式的所述业务处理结果消息反序列化成类对象，以及所述类对象组织成上下文对象发送至数据包接口。

根据本公开的一个方面，提供一种订单跟踪分析装置，应用包括一或多个业务系统的订单处理系统，所述订单跟踪分析方法包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中所述处理器配置为经由执行所述可执行指令来执行以下操作：

S1.建立对应于所述业务系统的业务处理结果的消息主题；

S2.监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；

S3.在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；

S4.监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；

S5.根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

本公开一种示例实施方式中的技术方案，通过利用消息平台作为中间平台将订单处理系统中的各业务系统串联在一起，以生产/订阅的方式获取各业务系统的处理结果信息，并且通过数据包以及数据存储队列将处理结果信息批量存入数据库，最后根据数据库中的信息生成订单处理轨迹；一方面，方便使用者跟踪订单在众多业务系统之间流转的状态以及所处的位置，并且当订单在业务系统发生处理异常时可以快速定位排查问题，提高解决异常的效率；另一方面，上述技术方案中的数据写入方式可以提高系统处理数据的能力，从而进一步的提升数据处理效率，节约处理时间。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中一种订单跟踪分析方法流程图。

图2示意性示出本公开示例性实施例中一种订单跟踪分析方法流程图。

图3示意性示出本公开示例性实施例中一种订单跟踪分析装置的框图。

图4示意性示出本公开示例性实施例中一种订单跟踪分析装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本示例实施方式中首先提供了一种订单跟踪分析方法，该订单跟踪分析方法可以应用于订单处理系统。该订单处理系统可以包括一或多个(如几十甚至上百个)分离的业务系统；在用户下单后，订单需要经过上述各业务系统的处理；本示例实施方式中所提供的订单跟踪分析方法即主要用于对于各业务系统对于订单的处理过程进行跟踪分析。参考图1中所示，本示例实施方式中所提供的订单跟踪分析方法可以包括以下步骤：

步骤S1.建立对应于所述业务系统的业务处理结果的消息主题。

本示例实施方式中，可以使用消息平台作为数据的中间交换系统，从而避免各个业务系统之间的数据传递产生强依赖性。消息平台是生产/订阅模式，因此本示例实施方式中的订单跟踪分析方法实质是订阅并消费各个业务系统生产的各种消息。所述消息平台例如可以为JMS(Java Message Service，Java消息服务)平台或者其他消息平台。消息主题包含了消息平台用来路由和识别消息的数据，在消息平台中建立了消息主题后，即可识别以及接收指定的消息。

例如，本示例实施方式中，以所述业务系统的业务处理结果包括处理成功以及处理异常为例，相应的，步骤S1可以包括，建立第一消息主题，所述第一消息主题可以用于接收各所述业务系统生产的处理成功消息；以及，建立第二消息主题，所述第二消息主题可以用于接收各所述业务系统生产的处理异常消息。参考图2中所示，在建立第一消息主题以及第二消息主题之后，各业务系统即可按照预设的数据格式在订单处理完成和订单处理异常时将对应的消息发生至消息平台的对应主题上。

此外，在订单处理系统中，上述各个业务系统的服务器硬件CPU通常使用率都不高，大部分的性能都是使用在磁盘I/O方面。基于此，本示例实施方式中可以将各个业务系统中发送业务处理结果消息的处理程序做成子线程异步发送，这样对业务系统的原有性能影响不大，又可以利用空闲的硬件CPU实现发送业务处理结果消息的目的，因此可以在很大程度上实现成本节约。

步骤S2.监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口。

本示例实施方式中，上下文对象(Context)是一个类对象，该类对象封装了业务处理结果消息、消息生产者、消息消费者以及请求等方面的信息。举例而言，可以通过MessageListener等消息监听器监听所述消息主题，当消息到达之后，系统自动调用监听器的onMessage。参考图2中所示，以所述业务系统的业务处理结果包括处理成功以及处理异常为例，在监听到所述第一消息主题接收到处理成功消息时，将接收到的处理成功消息设置成处理成功状态，并且将处理成功消息数据组织成上下文对象发送至第一数据包接口；类似的，在监听到所述第二消息主题接收到处理异常消息时，将接收到的处理异常消息设置成处理异常状态，并且将处理异常消息数据组织成上下文对象发送至第二数据包接口。

此外，根据各业务系统发送消息的格式的不同，本示例实施方式中还需要对于消息主题接收到的消息进行预处理。例如，上述预设的数据格式可以为JSON文本格式，即各所述业务系统发送的消息以及消息主题接收到的消息为JSON文本格式；则相应的，所述步骤S2还可以包括，将JSON文本格式的所述业务处理结果消息反序列化成类对象，进而将所述类对象组织成上下文对象发送至数据包接口。此外，为了减少耗时，本示例实施方式中，在对多条消息数据(例如大于3条)进行反序列化时，可以使用多线程并行工作，从而进一步提供处理效率。相比于XML等其他文本数据格式，JSON格式所占用的空间更小，因此可以降低降低本示例实施方式中方法所需的带宽；但本示例实施方式中并不以此为限。此外，本示例实施方式中对接收的消息数据进行统一化的反序列化，可以避免多个接口使用同一个原始消息数据时重复反序列化而增加耗时。

步骤S3.在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列。

继续参考图2中所示，以所述业务系统的业务处理结果包括处理成功以及处理异常为例，所述步骤S3可以包括，在所述第一数据包接口接收到上下文对象时，将所述第一数据包接口接收到的上下文对象组织成数据包并存入所述数据存储队列；以及，在所述第二数据包接口接收到上下文对象时，将所述第二数据包接口接收到的上下文对象组织成数据包并存入所述数据存储队列。下面以所述第一数据包接口的处理过程为例进行说明。举例而言，所述步骤S3的流程可以包括：

步骤S31.在所述第一数据包接口接收到上下文对象时，第一数据包接口将接收到的上下文对象暂存于内存中并写入当前数据包。本示例实施方式中，所述当前数据包为线程安全的，即所述当前数据包的数据不受到其他不相关线程的影响，进而避免出现偏差。

步骤S32.由于数据包空间有限，同时为了避免内存长期无法释放，本示例实施方式中可以判断所述当前数据包中的上下文对象是否达到预设数量以及所述当前数据包的生命周期是否超过预设时间；其中，所述预设数量以及预设时间可以由用户根据需求或者相关规范设定，本示例性实施例中对此不做特殊限定。

步骤S33.在判断所述当前数据包中的上下文对象未达到所述预设数量并且所述当前数据包的生命周期未超过所述预设时间时，返回至上述步骤S31。而在判断所述当前数据包中的上下文对象达到所述预设数量或者所述当前数据包的生命周期未超过所述预设时间时，则可以锁定所述当前数据包，然后调用所述数据存储队列接口，将所述当前数据包插入所述数据存储队列。

此外，在所述当前数据包被锁定期间，如果所述第一数据包接口接收到的上下文对象，则可以将所述第一数据包接口接收到的上下文对象放入临时数据集合中，并在解除所述当前数据包的锁定后，即当前数据包可用时，检查所述临时数据集合中是否有上下文对象；在检查到所述临时数据集合中有上下文对象时，可以根据所述临时数据集合中的上下文对象的数量生成一个或者多个数据包，然后调用所述数据存储队列接口，将生成的数据包插入到所述数据存储队列。

步骤S34.从数据包工厂中获取一个可重复利用的数据包作为新的所述当前数据包，并跳转至步骤S31，重复上述过程。所述第二数据包接口的处理过程与第一数据包接口类似，因此不再重复描述。此外，需要说明的是，虽然本示例实施方式中提供了上述步骤S3的一种实现方式，但在本公开的其他示例性实施例中，也可以通过其他方式实现上述步骤S3，这同样属于本公开的保护范围。

步骤S4.监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单。

本示例实施方式中，所述数据存储队列同样是线程安全的，可以通过一个子线程实时监听所述数据存储队列是否接收到数据包，并且判断数据包中包含的消息种类。继续参考图2中所示，以所述业务系统的业务处理结果包括处理成功以及处理异常为例，所述步骤S4可以包括，在监听到所述数据存储队列接收到包含处理异常消息的数据包时，将数据包从数据存储队列中取出，并且调用数据库接口，将接收到的数据包存储至数据库中的第一表单，所述第一表单可以存储订单的基本信息以及各业务系统处理成功的信息。类似的，在监听到所述数据存储队列接收到包含处理异常消息的数据包时，将数据包从数据存储队列中取出，并且调用数据库接口，将接收到的数据包存储至数据库中的第二表单，所述第二表单可以存储订单的基本信息以及各业务系统处理异常的信息。

步骤S5.根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

通过上述步骤S1至步骤S4，在第一表单以及第二表单中已经分别存储了各业务系统的处理成功信息以及处理失败信息。基于此，可以以各业务系统为处理节点生成订单处理轨迹，通过订单处理轨迹显示订单在经过各个业务系统时的处理轨迹。为了便于直观观察，使使用者对于订单处理过程一目了然，本示例实施方式中订单处理轨迹可以是可视化的。举例而言，本示例实施方式中可以在一可视化界面中呈现所述订单处理轨迹以及其他相关信息：

例如，可视化界面可以分为两部分，第一部分可以包括订单查询区和订单信息区等；第二部分可以为订单处理轨迹区。以订单处理轨迹是流程图为例，流程图中的每个处理节点可以代表一个业务系统并且标识业务系统的名称，每个处理节点可以通过颜色标识等方式标识出订单在该业务系统的处理状态；例如，可以使用绿色代表处理成功，使用红色代表处理异常，使用黄色代表正在处理，使用灰色代表尚未经过该业务系统等；用户将鼠标移动至某一处理节点上时，处理节点则会根据其代表的业务系统的处理状态展示出不同的颜色以及相关信息；例如，当处理节点为绿色时同时展示订单的基本信息，为红色时同时展示订单在该业务系统发生的异常信息；为黄色时同时显示该订单的一些基本信息；为灰色时同时显示订单尚未经过该系统等。

此外，本领域技术人员容易理解的是，在本公开的其他示例性实施例中，也可以通过其他方式实现上述订单处理轨迹，本示例性实施例中对此不做特殊限定。

综上所述，本示例实施方式中的技术方案，通过利用消息平台作为中间平台将订单处理系统中的各业务系统串联在一起，以生产/订阅的方式获取各业务系统的处理结果信息，并且通过数据包以及数据存储队列将处理结果信息批量存入数据库，最后根据数据库中的信息生成订单处理轨迹；一方面，方便使用者跟踪订单在众多业务系统之间流转的状态以及所处的位置，并且当订单在业务系统发生处理异常时可以快速定位排查问题，提高解决异常的效率；另一方面，上述技术方案中的数据写入方式可以提高系统处理数据的能力，从而进一步的提升数据处理效率，节约处理时间。

本领域技术人员可以理解实现上述实施方式的全部或部分步骤被实现为由CPU执行的计算机程序。在该计算机程序被CPU执行时，执行本发明提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理步骤并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

进一步的，本示例实施方式中还提供了一种订单跟踪分析装置，该订单跟踪分析装置可以应用于包括一或多个业务系统的订单处理系统。参考图3中所示，所述订单跟踪分析装置可以包括：主题建立模块10、上下文组织模块20、数据包生成模块30、队列存储模块40以及轨迹生成模块50。其中：

主题建立模块10可以用于建立对应于所述业务系统的业务处理结果的消息主题。

上下文组织模块20可以用于监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口。

数据包生成模块30可以用于在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列。

队列存储模块40可以用于监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单。

轨迹生成模块50可以用于根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

本示例实施方式中，其中：所述主题建立模块10可以用于，建立第一消息主题以及第二消息主题。所述第一消息主题用于接收各所述业务系统生产的处理成功消息，所述第二消息主题用于接收各所述业务系统生产的处理异常消息。

本示例实施方式中，其中：所述上下文组织模块20可以用于，在监听到所述第一消息主题接收到处理成功消息时将接收到的处理成功消息数据组织成上下文对象发送至第一数据包接口，在监听到所述第二消息主题接收到处理异常消息时将接收到的处理异常消息数据组织成上下文对象发送至第二数据包接口。

本示例实施方式中，其中：所述数据包生成模块30可以用于，在所述第一数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列。以及，在所述第二数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列。

本示例实施方式中，其中：所述队列存储模块40可以用于，在监听到所述数据存储队列接收到包含处理成功消息的数据包时将接收到的数据包存储至第一表单，以及，在监听到所述数据存储队列接收到包含处理异常消息的数据包时将接收到的数据包存储至第二表单。

本示例实施方式中，所述业务处理结果消息为JSON文本格式。所述上下文组织模块20还可以用于，将JSON文本格式的所述业务处理结果消息反序列化成类对象，以及所述类对象组织成上下文对象发送至数据包接口。

上述订单跟踪分析装置中各模块/单元的具体细节已经在对应的订单跟踪分析方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

图4示出根据本公开示例实施方式中一种订单跟踪分析装置400的示意图。例如，订单跟踪分析装置400可以被提供为一服务器。参照图4，订单跟踪分析装置400包括处理组件422，其进一步包括一个或多个处理器，以及由存储器432所代表的存储器资源，用于存储可由处理组件422的执行的指令，例如应用程序。存储器432中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件422被配置为执行指令，以执行上述方法。

订单跟踪分析装置400还可以包括一个电源组件426被配置为执行订单跟踪分析装置400的电源管理，一个有线或无线网络接口450被配置为将订单跟踪分析装置400连接到网络，和一个输入输出(I/O)接口458。订单跟踪分析装置400可以操作基于存储在存储器432的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM或类似。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、电子设备、或者网络设备等)执行根据本发明实施方式的方法。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (15)

1.一种订单跟踪分析方法，应用包括一或多个业务系统的订单处理系统；其特征在于，所述订单跟踪分析方法包括：

S1.建立对应于所述业务系统的业务处理结果的消息主题；

S2.监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；

S3.在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；

S4.监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；

S5.根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

2.根据权利要求1所述的订单跟踪分析方法，其特征在于，其中：

所述步骤S1包括，建立第一消息主题以及第二消息主题；所述第一消息主题用于接收各所述业务系统生产的处理成功消息，所述第二消息主题用于接收各所述业务系统生产的处理异常消息。

3.根据权利要求2所述的订单跟踪分析方法，其特征在于，其中：

所述步骤S2包括，在监听到所述第一消息主题接收到处理成功消息时将接收到的处理成功消息数据组织成上下文对象发送至第一数据包接口，在监听到所述第二消息主题接收到处理异常消息时将接收到的处理异常消息数据组织成上下文对象发送至第二数据包接口。

4.根据权利要求3所述的订单跟踪分析方法，其特征在于，其中：

所述步骤S3包括，在所述第一数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列；以及，在所述第二数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列。

5.根据权利要求4所述的订单跟踪分析方法，其特征在于，其中：

所述步骤S4包括，在监听到所述数据存储队列接收到包含处理成功消息的数据包时将接收到的数据包存储至第一表单，以及，在监听到所述数据存储队列接收到包含处理异常消息的数据包时将接收到的数据包存储至第二表单。

6.根据权利要求1所述的订单跟踪分析方法，其特征在于，所述业务处理结果消息为JSON文本格式；所述步骤S2还包括，将JSON文本格式的所述业务处理结果消息反序列化成类对象，以及所述类对象组织成上下文对象发送至数据包接口。

7.根据权利要求1～6任意一项所述的订单跟踪分析方法，其特征在于，所述步骤S3包括：

S31.在所述数据包接口接收到上下文对象时通过所述数据包接口将接收到的上下文对象写入当前数据包；

S32.判断所述当前数据包中的上下文对象是否达到预设数量以及所述当前数据包的生命周期是否超过预设时间；

S33.在判断所述当前数据包中的上下文对象达到所述预设数量或者所述当前数据包的生命周期超过预设时间时，锁定所述当前数据包，并将所述当前数据包插入所述数据存储队列；

S34.获取新的数据包作为所述当前数据包，并跳转至步骤S31。

8.根据权利要求7所述的订单跟踪分析方法，其特征在于，所述步骤S33还包括：

在所述当前数据包被锁定期间，将所述数据包接口接收到的上下文对象放入临时数据集合，并在解除所述当前数据包的锁定后，根据所述临时数据集合中的上下文对象生成数据包且插入到所述数据存储队列。

9.一种订单跟踪分析装置，应用包括一或多个业务系统的订单处理系统；其特征在于，所述订单跟踪分析装置包括：

主题建立模块，用于建立对应于所述业务系统的业务处理结果的消息主题；

上下文组织模块，用于监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；

数据包生成模块，用于在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；

队列存储模块，用于监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；

轨迹生成模块，用于根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。

10.根据权利要求9所述的订单跟踪分析装置，其特征在于，其中：

所述主题建立模块用于，建立第一消息主题以及第二消息主题；所述第一消息主题用于接收各所述业务系统生产的处理成功消息，所述第二消息主题用于接收各所述业务系统生产的处理异常消息。

11.根据权利要求10所述的订单跟踪分析装置，其特征在于，其中：

所述上下文组织模块用于，在监听到所述第一消息主题接收到处理成功消息时将接收到的处理成功消息数据组织成上下文对象发送至第一数据包接口，在监听到所述第二消息主题接收到处理异常消息时将接收到的处理异常消息数据组织成上下文对象发送至第二数据包接口。

12.根据权利要求11所述的订单跟踪分析装置，其特征在于，其中：

所述数据包生成模块用于，在所述第一数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列；以及，在所述第二数据包接口接收到上下文对象时将接收到的上下文对象组织成数据包并存入所述数据存储队列。

13.根据权利要求12所述的订单跟踪分析装置，其特征在于，其中：

所述队列存储模块用于，在监听到所述数据存储队列接收到包含处理成功消息的数据包时将接收到的数据包存储至第一表单，以及，在监听到所述数据存储队列接收到包含处理异常消息的数据包时将接收到的数据包存储至第二表单。

14.根据权利要求9～13任意一项所述的订单跟踪分析装置，其特征在于，所述业务处理结果消息为JSON文本格式；所述上下文组织模块还用于，将JSON文本格式的所述业务处理结果消息反序列化成类对象，以及所述类对象组织成上下文对象发送至数据包接口。

15.一种订单跟踪分析装置，应用包括一或多个业务系统的订单处理系统；其特征在于，所述订单跟踪分析方法包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中所述处理器配置为经由执行所述可执行指令来执行以下操作：

S1.建立对应于所述业务系统的业务处理结果的消息主题；

S2.监听所述消息主题，并且，在监听到所述消息主题接收到业务处理结果消息时，将接收到的所述业务处理结果消息数据组织成上下文对象发送至数据包接口；

S3.在所述数据包接口接收到上下文对象时，通过所述数据包接口利用接收到的上下文对象生成数据包并插入至数据存储队列；

S4.监听所述数据存储队列，并且在监听到所述数据存储队列接收到数据包时，将所述数据存储队列接收到的数据包存储至预设表单；

S5.根据所述预设表单中记录的信息生成订单处理轨迹，并且对所述订单处理轨迹中的处理节点按照处理结果进行标识。