CN101163049A - 一种实现消息跟踪的方法、系统和装置 - Google Patents

Abstract

本发明提供一种实现消息跟踪的方法、系统和装置，应用系统各个子系统执行业务功能程序，第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中；后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。应用本发明方案，由于只需要在第一个跟踪点处对接收到的消息进行解析，并在确定是需要跟踪的消息时，将跟踪标签添加到消息中，后续跟踪点处就可以由跟踪标签来判断是否为需要跟踪的消息，不必再次对消息进行解析，从而有效减少解析消息的次数，提高应用系统的整体性能。

Description

一种实现消息跟踪的方法、系统和装置

技术领域

本发明涉及消息跟踪技术，特别是涉及一种实现消息跟踪的方法、系统和装置。

背景技术

随着计算机应用的发展，一个大的应用系统往往可以由很多子系统组成，应用系统业务功能的实现则由这些子系统共同完成。在共同实现业务功能的过程中，某个子系统接收到外部的消息后，会根据该消息进行业务处理，并将该消息或衍生出的相关消息发送给其它子系统，由其它子系统进行后续处理。比如：应用系统可以是一个大的计费系统，包括在线计费管理点(OCMP，online charge manage point)、在线计费点(OCP，online charge point)和业务运营支撑系统(BOSS，Business Operations Support System)等子系统，这些子系统可以分别实现一部分业务功能，并通过消息交互以实现整个计费业务。

实际应用中，如果发生网络不稳定等情况，就有可能在实现某个业务功能的时候发生故障。但由于该业务功能是由多个子系统共同实现的，如果子系统比较多，或者业务功能本身比较复杂，就很难对故障发生的具体环节进行准确定位。

为此，现有技术提出对业务功能过程中的消息进行跟踪。由于被跟踪的消息可以反映在子系统之间的流向以及业务流程执行情况等，所以，就可以将被跟踪到的消息内容输出，再对所有输出的消息内容进行分析，从而定位出发生故障的具体环节。

现有技术一般采用打点跟踪的方法来实现对消息的跟踪，其大致思想为：在各个子系统的业务功能程序中设置跟踪点，当各个子系统执行到跟踪点时，对接收到的消息进行解析，并根据解析结果以及判断条件确定该消息是否为需要跟踪的消息。这里所说的对消息进行解析是指对消息体本身进行解析，如解析出消息体中的发送方号码，并判断该发送方号码是否是判断条件中的号码，如果是，则确定该消息是需要跟踪的消息。这里，各个子系统各自的业务功能程序就是大的应用系统实现业务功能的程序分布在各个子系统中的部分。当然，各个子系统还可以将跟踪到的消息内容输出给应用系统的网络管理子系统，以便于后续进行分析。至于如何输出消息，如果分析消息内容等情况则属于现有技术，此处不再赘述。

在实现本发明的过程中，发明人发现现有的消息跟踪方法中，由于子系统需要在跟踪点对接收到的消息进行解析，才能够确定该消息是否为需要跟踪的消息，所以，如果子系统比较多，或者设置的跟踪点比较多，消息被解析的次数就会大大增加，从而导致整个应用系统的性能的下降。

发明内容

本发明实施例提供一种实现消息跟踪的方法，可以减少应用系统对接收到的消息进行解析的次数，提高应用系统的整体性能。

为了达到上述目的，本发明实施例提出的技术方案为：

一种实现消息跟踪的方法，该方法包括：

应用系统各个子系统执行业务功能程序，在执行过程中，第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中；后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。

本发明实施例还提供一种实现消息跟踪的系统，可以减少应用系统对接收到的消息进行解析的次数，提高应用系统的整体性能。

为了达到上述目的，本发明实施例提出的技术方案为：

一种实现消息跟踪的系统，该系统包括一个以上用于执行应用系统业务功能程序的子系统，所述业务功能程序中事先设置有跟踪点；

其中，

第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中；

后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。

本发明实施例还提出一种实现消息跟踪的装置，其技术方案为：

一种实现消息跟踪的装置，该装置承载第一个跟踪点所属子系统，包括：

业务功能程序执行模块，用于执行业务功能程序，并在执行到第一个跟踪点时将接收到的消息发送给解析模块；

解析模块，用于对接收到的消息进行解析，并将解析结果发送给第一判别模块；

第一判别模块，用于根据解析结果判断是否为需要跟踪的消息，如果是，则通知标签插入模块；

标签插入模块，用于根据来自第一判别模块的通知，将表示需要跟踪的跟踪标签添加到消息中，并返回给业务功能程序执行模块。

本发明实施例还提出一种实现消息跟踪的装置，其技术方案为：

一种实现消息跟踪的装置，该装置承载后续跟踪点所属的子系统，包括：

业务功能程序执行模块，用于执行业务功能程序，并在执行到跟踪点时将接收到的消息发送给第二判别模块；

第二判别模块，用于在跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息，并通知给业务功能程序执行模块。

本发明实施例还提出一种取消消息跟踪的装置，该装置包括：

业务功能程序执行模块，用于执行业务功能程序，并在执行到取消跟踪的跟踪点时将接收到的消息发送给第三判别模块；

第三判别模块，用于在取消跟踪的跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则删除消息中的跟踪标签。

综上所述，本发明实施例提出一种实现消息跟踪的方法、系统和装置，由于只需要在第一个跟踪点处对接收到的消息进行解析，并在确定是需要跟踪的消息时，将跟踪标签添加到消息中，后续跟踪点处就可以由跟踪标签来判断是否为需要跟踪的消息，不必再次对消息进行解析，从而有效减少解析消息的次数，提高应用系统的整体性能。

附图说明

图1是本发明实施例实现消息跟踪方法实施例中应用系统的结构示意图；

图2是本发明实施例实现消息跟踪方法实施例实现消息跟踪的流程图；

图3是本发明实施例第一个跟踪点所属子系统对应装置的内部结构示意图；

图4是本发明实施例后续跟踪点所属子系统对应装置的内部结构示意图；

图5是本发明实施例取消跟踪所对应装置的内部结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施例作进一步地详细描述。

为了避免对消息的解析次数过多，影响系统的整体性能，本发明实施例采用添加跟踪标签的方式来实现对消息的跟踪。也就是说，如果在第一个跟踪点对消息解析后判断出接收到的消息是需要跟踪的消息，就将表示需要跟踪的跟踪标签添加到消息中。这样，在后续跟踪点处就可以不再对消息进行解析，而直接判断消息是否携带有跟踪标签，如果有，则表示该消息是需要跟踪的消息，从而可以减少对消息本身解析的次数。

具体地，本发明实施例实现消息跟踪的方法可以具体为：

应用系统各个子系统执行业务功能程序，在执行过程中，第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中；后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。

这里，虽然各个子系统需要共同实现应用系统的业务功能，但如果应用系统从外界接收到消息，对消息的处理是有先后顺序的。比如：某应用系统包括A、B、C三个子系统，子系统A接收到消息后，先对消息进行处理，再发送给子系统B；子系统B对消息处理后，再发送子系统C；最后由子系统C对消息进行处理。那么，在各个子系统业务功能程序中设置的跟踪点也应该是有先后顺序的。比如：在子系统A设置跟踪点a，在子系统B设置跟踪点b，在子系统C设置跟踪点c，那么，a就是第一个跟踪点，b和c就是后续跟踪点，即第二个跟踪点和第三个跟踪点。

本发明实施例中设置跟踪点的含义与现有技术相同，其实就是在各个子系统的程序中设置判断消息是否需要跟踪的步骤。当然，至于在哪些子系统设置跟踪点，一个子系统中设置几个跟踪点等情况，则可以由应用本实施例方案的用户自行确定，此处不再赘述。

但不管如何设置跟踪点，都可以由第一个跟踪点所属的子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果可以确定是否为需要跟踪的消息，如果是，则将跟踪标签添加到消息中。这样，后续对该消息处理的子系统就可以直接由放置在消息头或消息尾的跟踪标签判断出该消息为需要跟踪的消息，而不必再次对消息本身进行解析。

实际应用中，为了对被跟踪的消息进行分析以确定发生故障的具体环节，各个子系统在确定接收到的消息是需要跟踪的消息时，还可以将消息的内容输出给应用系统的网络管理子系统。这样，网络管理人员就可以从接收到的各个跟踪点输出的消息内容进行分析，从而确定是否发生故障，以及哪个环节发生了故障。至于网络管理子系统如何分析输出的消息内容，或者说如何对整个应用系统进行管理和维护可以采用现有技术来实现，此处不再赘述。

另外，由于对消息进行解析后获得的解析结果通常包括若干消息项，如果事先设置针对消息项的跟踪条件，就可以判断解析结果中是否包括与跟踪条件相同的消息项，如果有，则可以确定该消息是需要跟踪的消息；否则，确定该消息不是需要跟踪的消息。比如：消息中包含订阅号(subscriberno)这个消息项，该消息项的内容为用户的手机号码。那么，如果需要对手机号码为13812345678的用户实现该业务功能时的消息进行跟踪，就可以将跟踪条件设置为“subscriberno＝13812345678”。这样，第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，如果解析结果中包含“subscriberno＝13812345678”这个消息项，就可以确定该消息为被跟踪的消息。

实际应用中，还可以将某个子系统中的某跟踪点设置为取消跟踪的跟踪点，当该子系统在该跟踪点确定接收到的消息是需要跟踪的消息，可以将消息中的跟踪标签删除。这样，后续子系统就无法根据跟踪标签确定接收到的消息是否为需要跟踪的消息，也就不会将消息内容输出，有利于对是否输出消息内容的情况进行灵活处理。

为了更好地说明本实施例方案，下面用方法实施例二进行详细描述。

本实施例中，应用系统包括A～D共四个实现业务功能的子系统，还包括一个网络管理子系统，其系统结构如图1所示。

本实施例中，假设在子系统A～子系统D的业务功能程序中分别设置一个跟踪点，即：跟踪点a～跟踪点d；各个子系统在执行业务功能程序中处理消息的顺序是从子系统A到子系统D顺次进行；跟踪点a为第一个跟踪点，跟踪点b为第二个跟踪点，并以此类推。另外，本实施例还将子系统C中的跟踪点c作为取消跟踪的跟踪点。

本实施例列举的各个子系统是逻辑上的，是抽象的，实际应用中，各个子系统与具体的应用系统相关。比如：如果应用系统为一个大型计费系统，子系统A就可以为业务运营支撑系统(BOSS，Business Operations SupportSystem)；子系统B可以为在线计费管理点(OCMP，online charge managepoint)；子系统C可以为在线计费点(OCP，online charge point)；子系统D可以为归属位置寄存器(HLR，Home Location Register)。这些子系统各自实现一部分业务，共同完成整个计费系统的功能。

当然，实际应用中，应用系统也可以是其它的系统或设备，不仅仅限于计费系统，只要各个子系统共同完成一个大的应用系统功能即可。

图2是本实施例实现消息跟踪方法的流程图。如图2所示，在各个子系统执行业务功能程序的过程中，本实施例可以包括：

步骤201：子系统A在跟踪点a对接收到的消息进行解析。

步骤202～步骤203：子系统A判断解析结果中是否存在与跟踪条件相同的消息项，如果存在，则执行步骤204；否则，继续执行业务功能程序，直到将消息发送给子系统B，再执行步骤205。

步骤204：子系统A确定接收到的消息为需要跟踪的消息，将跟踪标签添加到消息中，并将消息内容输出给网络管理子系统后继续执行业务功能程序，直到将消息发送给子系统B，再执行步骤205。

这里所述的跟踪标签可以为某个标志位，并按照消息定义的格式添加到消息的消息头或消息尾。当然，实际应用中，跟踪标签的形式以及如何添加到消息中等情况可以由应用本实施例方案的用户自行确定，此处不再赘述。

步骤205～207：子系统B在跟踪点b判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息为需要跟踪的消息，并将消息内容输出给网络管理子系统后继续执行业务功能程序；否则，继续执行业务功能程序，直到将消息发送给子系统C，再执行步骤208。

步骤208～步骤210：子系统C在跟踪点c判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息为需要跟踪的消息，将消息内容输出给网络管理子系统，再将消息中的跟踪标签删除并继续执行业务功能程序；否则，直接继续执行业务功能程序，直到将消息发送给子系统D，再执行步骤211。

步骤211～步骤213：子系统D在跟踪点d判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息为需要跟踪的消息，将消息内容输出给网络管理子系统，再继续执行业务功能程序直到结束；否则，直接继续执行业务功能程序直到结束。

应用本实施例方案以后，如果某消息为需要被跟踪的消息，则将在子系统A的跟踪点a处添加跟踪标签，并输出消息内容；在子系统B的跟踪点b处输出消息内容；在子系统C的跟踪点c处输出消息内容，并删除消息中的跟踪标签；在子系统D的跟踪点d处不输出消息内容。

本实施例中各个子系统输出的消息内容可以相同，也可以不相同。比如：某消息X在子系统A的跟踪点a输出后，消息X将传输给子系统B。如果在子系统A的跟踪点a和子系统B的跟踪点b之间，子系统A和子系统B都没有对消息X有任何改变，那么，子系统B就将输出完全相同的消息内容。相应地，如果在子系统A的跟踪点a和子系统B的跟踪点b之间，子系统A或子系统B对消息X进行了改变，如改变为消息X′或衍生为消息Y，那么，只要消息X′或消息Y中携带有跟踪标签，子系统B在跟踪点b就可以输出消息X′或消息Y的内容。

针对上述方法，本发明还提出一种实现消息跟踪的系统的实施例。该系统可以包括一个以上用于执行应用系统业务功能程序的子系统，所述业务功能程序中事先设置有跟踪点。

其中，第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中。后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。

这里，实现消息跟踪的设备中包括多少子系统，哪些子系统中设置有跟踪点等情况可以根据实际情况由应用本实施例方案的用户自行确定。

在实现消息跟踪的系统中，各个子系统的实施都可以由某个设备或装置来执行，对于第一个跟踪点所属子系统对应的装置，其内部结构示意图可以如图3所示，包括：

业务功能程序执行模块301，用于执行业务功能程序。

解析模块302，用于在第一个跟踪点对接收到的消息进行解析，并将解析结果发送给第一判别模块303。

第一判别模块303，用于根据解析结果判断是否为需要跟踪的消息，如果是，则通知标签插入模块。

标签插入模块304，用于根据来自第一判别模块303的通知，将表示需要跟踪的跟踪标签添加到消息中，并返回给业务功能程序执行模块301。

也就是说，业务功能程序执行模块301负责执行业务功能程序，并在执行到第一个跟踪点时将接收到的消息发送给解析模块302；解析模块302对接收到的消息进行解析，并将解析结果发送给第一判别模块303；第一判别模块303根据解析结果判断是否为需要跟踪的消息，如果是，则通知标签插入模块303；最后，由标签插入模块303将表示需要跟踪的跟踪标签添加到消息中，并返回给业务功能程序执行模块301。此后，业务功能程序执行模块301将继续执行业务功能程序，还可能将消息发送给其他后续跟踪点所属的子系统。

相应地，对于后续跟踪点所属子系统所对应的装置内部结构示意图可以如图4所示，包括：

业务功能程序执行模块401，用于执行业务功能程序，并在执行到跟踪点时将接收到的消息发送给第二判别模块402。

第二判别模块402，用于判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息，并通知给业务功能程序执行模块401。

也就是说，后续跟踪点所属子系统中的业务功能程序执行模块401负责执行业务功能程序，并在执行到跟踪点时将接收到的消息发送给第二判别模块402；第二判别模块402直接判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息，并通知给业务功能程序执行模块401。此后，业务功能程序执行模块401仍然可以继续执行业务功能程序，还可能将消息发送给其它子系统。

另外，后续跟踪点所属子系统中还可以包括取消跟踪的跟踪点，其对应的装置内部结构示意图可以如图5所示，包括：

业务功能程序执行模块501，用于执行业务功能程序，并在执行到取消跟踪的跟踪点时将消息发送给第三判别模块502；

第三判别模块502，用于在取消跟踪的跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则删除消息中的跟踪标签，并通知给业务功能程序执行模块501。

也就是说，后续跟踪点所属子系统中的业务功能程序执行模块501负责执行业务功能程序，并在执行到取消跟踪的跟踪点时将消息发送给第三判别模块502；第三判别模块502判断消息是否携带有跟踪标签，如果有，则删除跟踪标签，并通知给业务功能程序执行模块501。此后，业务功能程序执行模块501仍然可以继续执行业务功能程序，还可能将消息发送给其他子系统。

本实施例中，实现消息跟踪的系统中应该包括多少个子系统是由具体的业务决定的，在哪些子系统中设置跟踪点则可以由需要对消息进行跟踪的用户自行确定。但不管实际情况如何，设置第一个跟踪点的子系统可以作为第一个跟踪点所属子系统，设置有其它跟踪点的子系统则可以作为后续跟踪点所属子系统。其中，第一个跟踪点所属子系统只有一个，而后续跟踪点所属子系统则可能有多个，而且最后一个跟踪点所属子系统将执行业务功能程序到结束，并不再将消息发送给其它的子系统。

另外，上述图3、图4和图5是按照某个子系统在跟踪点或取消跟踪点所采取的实施方式来描述其逻辑功能结构的。但实际应用中，图3～图5的内部功能结构也可以根据实际情况进行组合或合并。比如，某个后续跟踪点所属子系统对应的装置可能既包括业务功能程序执行模块，也可能包括第二判别模块和第三判别模块。也就是说，该子系统的业务功能程序执行模块执行业务功能程序，在执行到跟踪点时将消息发送给第二判别模块；第二判别模块根据跟踪标签判断出消息为需要跟踪的消息，可以将消息内容输出给网络管理系统；业务功能程序执行模块继续执行业务功能程序，在执行到取消跟踪点时将消息发送给第三判别模块；第三判别模块将跟踪标签删除，再由业务功能程序执行模块继续执行业务功能程序。

总之，如何设置跟踪点或取消跟踪的跟踪点可以由应用本发明实施例的用户自行确定，此处不再一一列举。

应用本发明实施例方案，由于只需要在第一个跟踪点处对接收到的消息进行解析，并在确定是需要跟踪的消息时，将跟踪标签添加到消息中，后续跟踪点处就可以由跟踪标签来判断是否为需要跟踪的消息，不必再次对消息进行解析，从而有效减少解析消息的次数，提高应用系统的整体性能。

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

Claims (9)

1.一种实现消息跟踪的方法，其特征在于，该方法包括：

应用系统的各个子系统执行业务功能程序，在执行过程中，第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中；

后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。

2.根据权利要求1所述的方法，其特征在于，所述根据解析结果判断是否为需要跟踪的消息方法为：判断解析结果中是否包括与事先设置的跟踪条件相同的消息项，如果有，则确定接收到的消息是需要跟踪的消息；否则，确定接收到的消息不是需要跟踪的消息。

3.根据权利要求1或2所述的方法，其特征在于，当确定接收到的消息是需要跟踪的消息时，该方法进一步包括：将消息内容输出给应用系统的网络管理子系统。

4.根据权利要求1或2所述的方法，其特征在于，所述将表示需要跟踪的跟踪标签添加到消息中的步骤包括：

将表示需要跟踪的跟踪标签添加到消息的消息头或消息尾。

5.根据权利要求1或2所述的方法，其特征在于，所述后续跟踪点中包括取消跟踪的跟踪点，当取消跟踪的跟踪点所属子系统确定接收到的消息是需要跟踪的消息时，该方法进一步包括：

所述取消跟踪的跟踪点所属子系统将消息中的跟踪标签删除。

6.一种实现消息跟踪的系统，其特征在于，该系统包括一个以上用于执行应用系统业务功能程序的子系统，所述业务功能程序中事先设置有跟踪点；

其中，

第一个跟踪点所属子系统在第一个跟踪点对接收到的消息进行解析，根据解析结果判断是否为需要跟踪的消息，如果是，则将表示需要跟踪的跟踪标签添加到消息中；

后续跟踪点所属的子系统在后续跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息。

7.一种实现消息跟踪的装置，其特征在于，该装置包括：

业务功能程序执行模块，用于执行业务功能程序，并在执行到第一个跟踪点时将消息发送给解析模块；

解析模块，用于对接收到的消息进行解析，并将解析结果发送给第一判别模块；

第一判别模块，用于根据解析结果判断是否为需要跟踪的消息，如果是，则通知标签插入模块；

标签插入模块，用于根据来自第一判别模块的通知，将表示需要跟踪的跟踪标签添加到消息中，并返回给业务功能程序执行模块。

8.一种实现消息跟踪的装置，其特征在于，该装置包括：

业务功能程序执行模块，用于执行业务功能程序，并在执行到跟踪点时将消息发送给第二判别模块；

第二判别模块，用于在跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则确定接收到的消息是需要跟踪的消息，并通知给业务功能程序执行模块。

9.一种取消消息跟踪的装置，其特征在于，该装置包括：

业务功能程序执行模块，用于执行业务功能程序，并在执行到取消跟踪的跟踪点时将接收到的消息发送给第三判别模块；

第三判别模块，用于在取消跟踪的跟踪点判断接收到的消息是否携带有跟踪标签，如果有，则删除消息中的跟踪标签。

Images