基于图的消息合并方法及装置与流程

文档序号:12178293阅读:165来源:国知局
基于图的消息合并方法及装置与流程

本申请涉及计算机领域,尤其是涉及一种基于图的消息合并方法及装置。



背景技术:

在企业信息系统架构中,业务系统之间是高度解耦的,业务系统之间通过消息系统进行数据交换是较为常见的方式。

虽然业务系统是高度解耦的,但是业务数据是需要耦合的,因而需要解决如何把某些业务系统发出的消息合并到一起投递给其他业务系统使用的问题:

如图1所示,业务系统A发送业务系统消息A,业务系统B发送业务系统消息B,业务系统C则同时需要业务系统消息A和业务系统消息B才可以进行后续的业务处理。如此,需要将进入消息队列的业务系统消息A和业务系统消息B合并后发给业务系统C。



技术实现要素:

本申请的目的在于提供一种基于图的数据合并方法及装置,其可在图的遍历中实现消息的合并。

为实现上述申请目的之一,本申请一实施方式提供了一种基于图的数据合并方法,所述方法包括:

获取业务系统消息;

将需要进行合并处理的业务系统消息存储并设置入消息合并模型中,其中,消息合并模型中包括:由分别与各个业务系统消息对应的多个顶点,以及将具有业务关联关系的顶点互连的标识符所构成的图;

对所述图进行遍历,以将有合并需求且具有关联关系的顶点对应的业务系 统消息合并。

作为本申请一实施方式的进一步改进,所述多个顶点和标识符构成树状结构,所述顶点构成所述树状结构的节点,所述标识符构成所述树状结构的树枝。

作为本申请一实施方式的进一步改进,按照所述图的逻辑对所述图进行遍历的步骤具体包括:

从当前获取到的业务系统消息对应的顶点开始,以深度优先搜索方式对所述图进行遍历。

作为本申请一实施方式的进一步改进,以深度优先搜索方式对所述图进行遍历的步骤具体包括:

以深度优先搜索方式,逐一对当前获取到业务系统消息对应的顶点的下层顶点的业务系统消息进行查询;

当在下层顶点内查询到业务消息时,则递归至该下层顶点对应的上一层顶点并继续查询,当在下层顶点内未查询到业务系统消息时,则终止查询。

作为本申请一实施方式的进一步改进,所述将有合并需求且具有关联关系的顶点对应的业务系统消息合并的步骤具体包括:

判断当前获取到的业务系统消息的顶点的下层顶点的关联业务系统消息是否到达;

若有下层顶点的业务系统消息已到达,则将有合并需求且具有关联关系的业务系统消息合并。

作为本申请一实施方式的进一步改进,在获取业务系统消息步骤后,还包括:

判断业务系统消息是否有与其他业务系统消息具有业务关联关系;

若是则执行后续合并业务系统消息的步骤;若否,则直接发送该业务系统消息。

为实现上述申请目的之一,本申请一实施方式提供了一种基于图的数据合并装置,所述装置包括:

通信模块,用于获取业务系统消息;

消息合并模型,所述消息合并模型中:由分别与各个业务系统消息对应的多个顶点,以及将具有业务关联关系的顶点互连的标识符所构成的图,所述消息合并模型用于:

将需要进行合并处理的业务系统消息存储并设置入消息合并模型中,以及

对所述图进行遍历,以将有合并需求且具有关联关系的顶点对应的业务系统消息合并。

作为本申请一实施方式的进一步改进,所述多个顶点和标识符构成树状结构,所述顶点构成所述树状结构的节点,所述标识符构成所述树状结构的树枝。

作为本申请一实施方式的进一步改进,所述消息合并模型用于:

从当前获取到的业务系统消息对应的顶点开始,以深度优先搜索方式对所述图进行遍历。

作为本申请一实施方式的进一步改进,所述消息合并模型用于:

以深度优先搜索方式,逐一对当前获取到业务系统消息对应的顶点的下层顶点的业务系统消息进行查询;

当在下层顶点内查询到业务消息时,则递归至该下层顶点对应的上一层顶点并继续查询,当在下层顶点内未查询到业务系统消息时,则终止查询。

作为本申请一实施方式的进一步改进,所述消息合并模型用于:

判断当前获取到的业务系统消息的顶点的下层顶点的关联业务系统消息是否到达;

若有下层顶点的业务系统消息已到达,则将有合并需求且具有关联关系的业务系统消息合并。

作为本申请一实施方式的进一步改进,所述装置还包括过滤模块,所述过滤模块用于:

判断业务系统消息是否有与其他业务系统消息合并的需要,若是,则通过所述消息合并模型存储所述业务系统消息,并按照所述图的逻辑对所述图进行遍历,以将具有关联关系的顶点对应的业务系统消息合并,若否,则通过所述通信模块直接发送该业务系统消息。

相对于现有技术,本申请的技术效果在于:通过本申请的基于图的消息合并方法及装置,在图的遍历中实现了消息的合并,不但极大的简化了消息的合并过程,而且代码复杂度低,通用性较强,不需要针对不同场景开发不同的代码。

附图说明

图1是现有技术中消息合并的系统架构图。

图2是本申请一实施方式中基于图的消息合并方法的流程图。

图3是本申请一实施方式中消息合并模型中图的示例图;

图4是本申请一实施方式中基于图的消息合并装置的模块图。

具体实施方式

以下将结合附图所示的具体实施方式对本申请进行详细描述。但这些实施方式并不限制本申请,本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本申请的保护范围内。

如图2所示,在本申请一实施方式中,所述基于图的消息合并方法包括:

S1、获取业务系统消息;

S2、将需要进行合并处理的业务系统消息存储并设置入消息合并模型中,其中,消息合并模型中包括:由分别与各个业务系统消息对应的多个顶点,以及将具有业务关联关系的顶点互连的标识符所构成的图;

S3、对所述图进行遍历,以将有合并需求且具有关联关系的顶点对应的业务系统消息合并。

在本申请一实施方式中,对业务系统消息的合并是基于消息合并模型中图的遍历的,例如采用图的深度遍历算法或者图的广度遍历算法。所述消息合并模型包括了多个顶点、将具有关联关系顶点互联的标识符,以及每个顶点对应的属性,例如存储键、查询键、合并键。

进一步地,所述标识符可表现为线条的样式,将具有关联关系的顶点互连, 在本申请中,具有关联关系是指消息具有相同的业务属性,其是有业务关联关系的。如此设置,所述顶点和所述标识符即可构成图的形式。

在一个示例中,假设依下游业务系统需求,需要合并(A、B)(A、C)(C、D)(D、E)四组消息,可参图3所示,顶点A和顶点B、顶点C具有业务关联,顶点C和顶点D、顶点E具有业务关联,它们之间的关联关系由标识符标识,所述多个顶点和标识符构成树状结构,所述顶点构成所述树状结构的节点,所述标识符构成所述树状结构的树枝。

其中,所述存储键可用于标识唯一业务系统消息,并将业务系统消息存储,例如,在收到业务系统消息A时,所述存储键可将所述业务系统消息A存储至其对应的顶点,例如顶点A。

所述查询键可用于查询顶点所对应的业务系统消息是否到达,例如,在存储业务系统消息A后,可通过查询键查询业务系统消息B对应的顶点(例如顶点B)中业务系统消息B是否到达。

所述合并键可用于合并具有关联关系的消息,例如,在获得业务系统消息A和业务系统消息B时,通过对图的遍历,所述合并键可合并业务系统消息A和业务系统消息B。

在本申请一实施方式中,按照所述图的逻辑对所述图进行遍历的步骤具体包括:

从当前获取到的业务系统消息对应的顶点开始,以深度优先搜索方式对所述图进行遍历。

进一步地,以深度优先搜索方式对所述图进行遍历的步骤具体包括:

以深度优先搜索方式,逐一对当前获取到业务系统消息对应的顶点的下层顶点的业务系统消息进行查询;

当在下层顶点内查询到业务消息时,则递归至该下层顶点对应的上一层顶点并继续查询,当在下层顶点内未查询到业务系统消息时,则终止查询。

进一步地,所述将有合并需求且具有关联关系的顶点对应的业务系统消息合并的步骤具体包括:

判断当前获取到的业务系统消息的顶点的下层顶点的关联业务系统消息是否到达;

若有下层顶点的业务系统消息已到达,则将有合并需求且具有关联关系的业务系统消息合并。

参图3所示示例,假设当前获取到的业务系统消息为消息A,其对应的顶点为A,此时,顶点B、顶点C、顶点D、顶点E都属于顶点A的下层顶点,且顶点D和顶点E属于顶点C的下层顶点。所述顶点A对应业务系统消息A,顶点B对应业务系统消息B,顶点C对应业务系统消息C,顶点D对应业务系统消息D,顶点E对应业务系统消息E。

在对图进行遍历的过程中,因是深度优先搜索方式,故在查询完某一顶点后,需先查询该顶点的下层顶点,而非同一层顶点,具体可参示例:

在顶点A的业务系统消息已到达的情况下,查询顶点B,看业务系统消息B是否到达,若没有到达,则终止查询;若到达,且业务系统消息A和业务系统消息B有合并需求,则可合并业务系统消息A和业务系统消息B,并递归至顶点A继续查询;因顶点A已经处理过,这时接着查询顶点C,看业务系统消息C是否到达,,若未到达,则终止查询;若到达,且业务系统消息A和业务系统消息C有合并需求,则合并业务系统消息A和业务系统消息C,并递归至顶点A;因顶点A已经处理过,这时将查询顶点D,看业务系统消息D是否到达,若未到达,则终止查询;若到达,且业务系统消息C和业务系统消息D有合并需求,则合并业务系统消息C和业务系统消息D,并递归至顶点C;因顶点C已经处理过,此时将查询顶点E,看业务系统消息E是否到达,若未到达,则终止查询;若到达,且业务系统消息C和业务系统消息E有合并需求,则合并业务系统消息C和业务系统消息E。

当然,也可在对图片遍历全部结束后,再合并具有关联关系的业务系统消息。

进一步地,在本申请一实施方式中,在获取业务系统消息步骤后,还包括:

判断业务系统消息是否有与其他业务系统消息具有业务关联关系;

若是则执行后续合并业务系统消息的步骤;若否,则直接发送该业务系统消息。

在本实施方式中,可过滤掉不需要参与合并(与其他业务系统消息没有业务关联关系)的业务系统消息,以满足多样化的业务需求,例如,当获取到的业务系统消息不需要参与合并时,可不存储该业务系统消息,直接发送至需要该业务系统消息的业务系统中;当获取到的业务系统消息需要参与合并时,则根据上述技术方案将所述业务系统消息通过消息合并模型进行存储及合并。

如图4所示,在本申请一实施方式中,所述基于图的消息合并装置包括:

通信模块100,用于获取业务系统消息;

消息合并模型200,所述消息合并模型中包括:由分别与各个业务系统消息对应的多个顶点,以及将具有业务关联关系的顶点互连的标识符所构成的图,所述消息合并模型200用于:

将需要进行合并处理的业务系统消息存储并设置入消息合并模型中,以及

对所述图进行遍历,以将有合并需求且具有关联关系的顶点对应的业务系统消息合并。

在本申请一实施方式中,对业务系统消息的合并是基于消息合并模型中图的遍历的,例如采用图的深度遍历算法或者图的广度遍历算法。所述消息合并模型包括了多个顶点、将具有关联关系顶点互联的标识符,以及每个顶点对应的属性,例如存储键、查询键、合并键。

进一步地,所述标识符可表现为线条的样式,将具有关联关系的顶点互连,在本申请中,具有关联关系是指消息具有相同的业务属性,其是有业务关联关系的。如此设置,所述顶点和所述标识符即可构成图的形式。

在一个示例中,假设依下游业务系统需求,需要合并(A、B)(A、C)(C、D)(D、E)四组消息,可参图3所示,顶点A和顶点B、顶点C具有业务关联,顶点C和顶点D、顶点E具有业务关联,它们之间的关联关系由标识符标识,所述多个顶点和标识符构成树状结构,所述顶点构成所述树状结构的节点,所述标识符构成所述树状结构的树枝。

其中,所述存储键可用于标识唯一业务系统消息,并将业务系统消息存储,例如,在收到业务系统消息A时,所述存储键可将所述业务系统消息A存储至其对应的顶点,例如顶点A。

所述查询键可用于查询顶点所对应的业务系统消息是否到达,例如,在存储业务系统消息A后,可通过查询键查询业务系统消息B对应的顶点(例如顶点B)中业务系统消息B是否到达。

所述合并键可用于合并具有关联关系的消息,例如,在获得业务系统消息A和业务系统消息B时,通过对图的遍历,所述合并键可合并业务系统消息A和业务系统消息B。

在本申请一实施方式中,所述消息合并模型200用于:

从当前获取到的业务系统消息对应的顶点开始,以深度优先搜索方式对所述图进行遍历。

进一步地,所述消息合并模型200用于:

以深度优先搜索方式,逐一对当前获取到业务系统消息对应的顶点的下层顶点的业务系统消息进行查询;

当在下层顶点内查询到业务消息时,则递归至该下层顶点对应的上一层顶点并继续查询,当在下层顶点内未查询到业务系统消息时,则终止查询。

进一步地,所述消息合并模型200用于:

判断当前获取到的业务系统消息的顶点的下层顶点的关联业务系统消息是否到达;

若有下层顶点的业务系统消息已到达,则将有合并需求且具有关联关系的业务系统消息合并。

参图3所示示例,假设当前获取到的业务系统消息为消息A,其对应的顶点为A,此时,顶点B、顶点C、顶点D、顶点E都属于顶点A的下层顶点,且顶点D和顶点E属于顶点C的下层顶点。所述顶点A对应业务系统消息A,顶点B对应业务系统消息B,顶点C对应业务系统消息C,顶点D对应业务系统消息D,顶点E对应业务系统消息E。

在对图进行遍历的过程中,因是深度优先搜索方式,故在查询完某一顶点后,需先查询该顶点的下层顶点,而非同一层顶点,具体可参示例:

在顶点A的业务系统消息已到达的情况下,查询顶点B,看业务系统消息B是否到达,若没有到达,则终止查询;若到达,且业务系统消息A和业务系统消息B有合并需求,则可合并业务系统消息A和业务系统消息B,并递归至顶点A继续查询;因顶点A已经处理过,这时接着查询顶点C,看业务系统消息C是否到达,,若未到达,则终止查询;若到达,且业务系统消息A和业务系统消息C有合并需求,则合并业务系统消息A和业务系统消息C,并递归至顶点A;因顶点A已经处理过,这时将查询顶点D,看业务系统消息D是否到达,若未到达,则终止查询;若到达,且业务系统消息C和业务系统消息D有合并需求,则合并业务系统消息C和业务系统消息D,并递归至顶点C;因顶点C已经处理过,此时将查询顶点E,看业务系统消息E是否到达,若未到达,则终止查询;若到达,且业务系统消息C和业务系统消息E有合并需求,则合并业务系统消息C和业务系统消息E。

当然,也可在对图片遍历全部结束后,再合并具有关联关系的业务系统消息。

进一步地,在本申请一实施方式中,所述装置还包括过滤模块300,所述过滤模块300用于:

判断业务系统消息是否有与其他业务系统消息具有业务关联关系,若是,则通过所述消息合并模型200存储所述业务系统消息,并按照所述图的逻辑对所述图进行遍历,以将具有关联关系的顶点对应的业务系统消息合并,若否,则通过所述通信模块100直接发送该业务系统消息。

在本实施方式中,可过滤掉不需要参与合并的业务系统消息,以满足多样化的业务需求,例如,当获取到的业务系统消息不需要参与合并时,可不存储该业务系统消息,直接发送至需要该业务系统消息的业务系统中;当获取到的业务系统消息需要参与合并时,则根据上述技术方案将所述业务系统小题通过消息合并模型进行存储及合并。

综上所述,通过本申请的基于图的消息合并方法及装置,在图的遍历中实现了消息的合并,不但极大的简化了消息的合并过程,而且代码复杂度低,通用性较强,不需要针对不同场景开发不同的代码。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置,装置和模块的具体工作过程,可以参考前述方法实施方式中的对应过程,在此不再赘述。

在本申请所提供的几个实施方式中,应该理解到,所揭露的装置,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施方式仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个模块或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或模块的间接耦合或通信连接,可以是电性,机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。

另外,在本申请各个实施方式中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以2个或2个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用硬件加软件功能模块的形式实现。

上述以软件功能模块的形式实现的集成的模块,可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)或处理器(processor)执行本申请各个实施方式所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可 以存储程序代码的介质。

最后应说明的是:以上实施方式仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施方式对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施方式所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施方式技术方案的精神和范围。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1