CN115756568A - 业务规则的更新方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开公开了一种业务规则的更新方法、装置、电子设备及存储介质。方法包括：获取第一客户端发送的业务规则更新请求，业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息；利用目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，第一业务规则版本包括业务规则序列以及规则标识关系集，规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系；基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本；将第二业务规则版本进行发布。本公开实现了对业务规则版本的增量更新，提高了规则更新效率，且后续可以直接对比规则标识关系确定版本之间的差异信息。

Description

业务规则的更新方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种业务规则的更新方法、装置、电子设备及存储介质。

背景技术

目前常见的规则引擎有规则集、决策树和策略流等类型，以规则集类型为例，业务规则由组规则组成，规则引擎顺序执行每条规则，产出决策结果；其中规则的顺序决定其优先级，先执行的规则优先级高。现有规则引擎的版本控制方法，是将业务规则进行全文编辑后，整体提交，整体覆盖，不具备增量更新的能力，且更新前与更新后的版本差异通过全文本匹配的方式实现，导致业务规则更新后无法对版本间的差异信息进行精准定位。

例如：用户修改的原始业务规则为版本V1，用户在版本V1增加规则R6后，得到的新的业务规则，即版本V2，然而现有方法只能通过全文对比，得出版本之间的差异信息为新增规则R6。如果用户对版本V2进行更新得到版本V3，更新操作为删除规则R3，增加规则R7，然后互换规则R1和规则R2的顺序。通过现有方法将版本V3和版本V2进行全文匹配的方式，无法准确得到新增或删除的规则以及规则变更顺序。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种业务规则的更新方法、装置、电子设备及存储介质。

根据本公开实施例的一个方面，提供了一种业务规则的更新方法，包括：

获取第一客户端发送的业务规则更新请求，其中，所述业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息；

利用所述目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，所述第一业务规则版本包括业务规则序列以及规则标识关系集，所述规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系；

基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本；

将所述第二业务规则版本进行发布。

根据本公开实施例的再一个方面，还提供了一种业务规则的更新装置，包括：

第一获取模块，用于获取第一客户端发送的业务规则更新请求，其中，所述业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息；

第二获取模块，用于利用所述目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，所述第一业务规则版本包括业务规则序列以及规则标识关系集，所述规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系；

处理模块，用于基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本；

执行模块，用于将所述第二业务规则版本进行发布。

根据本公开实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的计算机程序，程序运行时执行上述的步骤。

根据本公开实施例的另一方面，还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；其中：存储器，用于存放计算机程序；处理器，用于通过运行存储器上所存放的程序来执行上述方法中的步骤。

本公开实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述方法中的步骤。

本公开实施例提供的上述技术方案与现有技术相比具有如下优点：本公开实施例提供的方法通过将业务规则版本设置业务规则序列以及规则标识关系，能够在获取到客户端提交的规格更新信息时直接从业务规则序列确定待更新的业务规则，并对该规则进行更新，同时更新该规则对应的规则标识关系。以此实现了对业务规则版本的增量更新，相比对业务规则进行全量更新，不再需要对业务规则进行全文编辑更新，提高了业务规则的更新效率。且后续可以直接对比规则标识关系确定版本之间的差异信息。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1为本公开实施例提供的一种业务规则的更新方法的流程图；

图2为本公开实施例提供的业务规则版本的示意图；

图3为本公开实施例提供的业务规则更新过程的示意图；

图4为本公开实施例提供的业务规则更新过程的示意图；

图5为本公开实施例提供的业务规则更新过程的示意图；

图6为本公开实施例提供的业务规则更新过程的示意图；

图7为本公开实施例提供的业务规则更新过程的示意图；

图8为本公开另一实施例提供的一种业务规则的更新方法的流程图；

图9为本公开实施例提供的一种业务规则的更新装置的框图；

图10为本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开的一部分实施例，而不是全部的实施例，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个类似的实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本公开实施例提供了一种业务规则的更新方法、装置、电子设备及存储介质。本公开实施例所提供的方法可以应用于任意需要的电子设备，例如，可以为服务器、终端等电子设备，在此不做具体限定，为描述方便，后续简称为电子设备。

根据本公开实施例的一方面，提供了一种业务规则的更新方法的方法实施例。图1为本公开实施例提供的一种业务规则的更新方法的流程图，如图1所示，该方法包括：

步骤S11，获取第一客户端发送的业务规则更新请求，其中，业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息。

本公开实施例提供的方法应用于服务器，服务器中部署有多个业务对应的业务规则版本。具体的，服务器用于接收第一客户端发送的业务规则编辑请求，服务器基于业务规则编辑请求向第一客户端反馈业务规则编辑界面，第一客户端可以基于业务规则编辑界面输入目标业务标识以及至少一个第一规则更新信息，目标业务标识用于从服务器中获取待更新目标业务的业务规则版本。规则更新信息的内容格式如下：

diffUpType:Modify

prevID:R1

nextID:R3

ruleInfo:[

{

ID:R2

RuleInfo

},...

]

其中，第一规则更新信息(diffup)包括：更新类型(diffup Type)、目标规则标识(ID)以及相邻规则标识(prevID以及nextID)更新类型包括：新增类型(1：Add)、删除类型(2：Del)、修改类型(3：Modify)以及移动类型(4：Move)。该规则更新信息表示修改业务规则R1和业务规则R3之间的业务规则R2。另外，目标规则标识用于确定第一客户端当前待更新的目标业务规则，相邻规则标识包括：prev ID以及next ID，用于定位待更新的目标业务规则，二者结合用于校验规则更新信息是否有效。

具体的，校验过程包括：校验第一业务规则版本的规则标识集中是否存在目标规则标识以及相邻规则标识对应的规则标识关系，得到校验结果；在校验结果为存在目标规则标识以及相邻规则标识对应的规则标识关系的情况下，确定业务第一规则更新信息有效，其中，第一规则更新信息有效的情况下，基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本。

作为一个示例，业务规则版本中业务规则的顺序是R1—R2—R3—R4。规则更新信息包括的相邻规则标识为R3和R4，目标规则标识为R2，基于此可以确定R2未处于R3和R4之间，所以确定该规则更新信息无效。或，规则更新信息包括的相邻规则标识为R2和R4，目标规则标识为R3，基于此可以确定R3处于R3和R4之间，所以确定该规则更新信息有效。

步骤S12，利用目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，第一业务规则版本包括业务规则序列以及规则标识关系集，规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系。

在本公开实施例中，服务器首先利用目标业务标识从多个业务中确定目标业务，并从业务规则版本库中获取目标业务在当前时刻对应的第一业务规则版本，第一业务规则版本包括业务规则序列以及业务规则关系集。

图2为本公开实施例提供的业务规则版本的示意图，如图2所示，业务规则序列包括：业务规则R1，业务规则R2，业务规则R3，业务规则R4，业务规则R5。业务规则关系集包括业务规则序列中每个业务规则对应的业务规则关系，其中，业务规则R1对应的业务规则关系为R1.prev＝-1，R1.next＝R2。业务规则R2对应的业务规则关系为R2.prev＝R1，R2.next＝R3。业务规则R3对应的业务规则关系为R3.prev＝R2，R3.next＝R4。业务规则R4对应的业务规则关系为R4.prev＝R3，R4.next＝R5。业务规则R5对应的业务规则关系为R5.prev＝R4，R15next＝-1。例如：R2的相邻规则标识prev ID和next ID分别为R1和R3，即标识为：在业务规则集版本中，R2处于R1和R3之间。队列头部和尾部用-1表示，例如：R1的prev为-1，意为：在规则集版本V1中，R1处于头部和R2之间。

步骤S13，基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本。

在本公开实施例中，服务器首先利用第一规则更新信息中目标规则标识以及相邻规则标识确定待更新的目标业务规则的位置。其次基于更新类型(例如：新增、删除、修改以及移动)以及更新内容对目标业务规则进行更新，即得到第二业务规则版本。

作为一个示例，当前的业务规则版本为V1，采用规则更新信息进行更新时，更新公式可以表示为：V1+diffup[1,2,3,4]得到业务规则版本V5。

步骤S14，将第二业务规则版本进行发布。

在本公开实施例中，服务器在得到基于规则更新信息得到的第二业务规则版本后，将第二业务规则版本进行线上发布。

本公开实施例提供的方法通过设置业务规则序列以及规则标识关系，能够在获取到客户端提交的规则更新信息时直接从业务规则序列确定待更新的业务规则，并对该规则进行更新，同时更新该规则对应的规则标识关系。以此实现了对业务规则版本的增量更新，相比对业务规则进行全量更新，不再需要对业务规则进行全文编辑更新，提高了业务规则的更新效率。且后续可以直接对比规则标识关系确定版本之间的差异信息。

在本公开实施例中，基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本，包括以下步骤A1-A5：

步骤A1，在更新类型为新增类型的情况下，利用目标规则标识获取新增业务规则。

步骤A2，利用相邻规则标识确定新增业务规则在业务规则序列中的位置信息。

步骤A3，将新增业务规则写入位置信息，得到更新后的业务规则序列。

步骤A4，在规则标识关系集中新增新增业务规则的第一规则标识关系，以及更新相邻规则标识所对应的业务规则的第二规则标识关系，得到更新后的规则标识关系集。

步骤A4，基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

作为一个示例，在更新类型为新增类型的情况下，第一规则更新信息如下：

diffUpType:1

prev:R1

next:R2

ops:[

{

id:R4

ver:1

info:{new info}

}

]

基于上述内容可知，更新类型为新增类型，相邻规则标识为R1以及R2，目标规则标识为R4(目标规则标识即为新增业务规则的标识)。具体更新过程如图3所示，首先根据相邻规则标识R1以及R2确定新增业务规则在业务规则序列的位置信息，其次将新增业务规则R4写入该位置信息，得到更新后的业务规则序列。再者，在规则标识关系集中新增业务规则R4的第一规则标识关系，即R4.prev＝R1，R4.next＝R2，以及更新相邻规则标识所对应的业务规则R1和R2的第二规则标识关系，得到更新后的规则标识关系集，第二规则标识关系即业务规则R1的规则标识关系R1.prev＝-1，R1.next＝R4，业务规则R2的规则标识关系R2.prev＝R4，R2.next＝R3。最终基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

在本公开实施例中，基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本，包括以下步骤B1-B4：

步骤B1，在所述更新类型为删除类型的情况下，利用所述目标规则标识获取待删除业务规则，并确定所述待删除业务规则的规则版本。

步骤B2，在所述规则版本校验通过的情况下，将所述待删除业务规则从所述业务规则序列中删除，得到更新后的业务规则序列。

步骤B3，删除所述待删除业务规则在所述规则标识关系集对应的第三规则标识关系，以及更新所述相邻规则标识对应的业务规则的第四规则标识关系，得到更新后的规则标识关系集。

步骤B4，基于所述更新后的业务规则序列以及所述更新后的规则标识关系集得到第二业务规则版本。

作为一个示例，在更新类型为删除类型的情况下，第一规则更新信息如下：

diffUpType:2

prev:R4

next:R3

ops:[

{

id:R2

ver:1

info:{new info}

}

]

基于上述内容可知，更新类型为删除类型，相邻规则标识为R4以及R3，目标规则标识为R2(目标规则标识即为待删除业务规则的标识)。具体更新过程如图4所示，首先利用目标规则标识获取待删除业务规则对应的规则版本。其次将规则版本与业务规则序列中待删除业务规则对应的实际规则版本进行校验，在二者一致的情况下，将待删除业务规则R2删除，得到更新后的业务规则序列。再者，删除待删除业务规则在规则标识关系集对应的第三规则标识关系，第三规则标识关系即R2.prev＝R4，R2.next＝R3，以及更新相邻规则标识对应的业务规则的第四规则标识关系，得到更新后的规则标识关系集，第四规则标识关系即业务规则R4的规则标识关系R4.prev＝R1，R4.next＝R3，业务规则R3的规则标识关系R3.prev＝R4，R3.next＝-1。最终基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

在本公开实施例中，基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本，包括以下步骤C1-C4：

步骤C1，在更新类型为修改类型的情况下，利用目标规则标识获取待修改业务规则对应的目标规则内容。

步骤C2，从业务规则序列中获取待修改业务规则对应的原始规则内容。

步骤C3，将待修改业务规则的原始规则内容更新为目标规则内容，得到更新后的待修改业务规则，并基于更新后的待修改业务规则得到更新后的业务规则序列。

步骤C4，基于更新后的业务规则序列以及规则标识关系集得到第二业务规则版本。

作为一个示例，在更新类型为修改类型的情况下，第一规则更新信息如下：

diffUpType:3

prev:R1

next:R3

ops:[

{

id:R4

ver:1

info:{new info}

}

]

基于上述内容可知，更新类型为修改类型，相邻规则标识为R1以及R3，目标规则标识为R4(目标规则标识即为待修改业务规则的标识)。具体更新过程如图5所示，首先，利用目标规则标识获取目标规则内容。其次，利用目标规则标识从业务规则序列中获取目标业务规则，以及目标业务规则对应的原始规则内容，得到更新后的目标业务规则，更新后的目标业务规则R4的规则版本由Ver：1更新为Ver：2。再者，基于目标业务规则得到更新后的业务规则序列，由于只是修改规则内容，业务规则的顺序并不发生变化，所以不对规则标识关系集进行更新，最终，可直接基于更新后的业务规则序列得到第二业务规则版本。

在本公开实施例中，基于第一规则更新信息对业务规则序列以及规则标识关系进行更新，得到第二业务规则版本，包括以下步骤D1-D4：

步骤D1，在更新类型为移动类型的情况下，获取目标规则标识对应的原始相邻规则标识以及目标相邻规则标识；

步骤D2，基于原始相邻规则标识以及目标相邻规则标识，分别确定目标规则标识对应待移动业务规则在业务规则序列的原始位置信息以及目标位置信息；

步骤D3，将待移动业务规则由原始位置信息移动至目标位置信息，得到更新后的业务规则序列，并在规则标识关系集中更新更新后的待移动业务规则对应的第五规则标识关系，以及更新目标相邻规则标识对应的业务规则的第六规则标识关系，得到更新后的规则标识关系集；

步骤D4，基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

作为一个示例，在更新类型为移动类型的情况下，第一规则更新信息如下：

diffUpType:4

prev:R1

next:R3

newPrev:R3

newNext:-1

ops:[

{

id:R4

ver:1

info:{new info}

}

]

基于上述内容可知，更新类型为移动类型，原始相邻规则标识为R1以及R3，目标相邻规则标识为R3和-1。目标规则标识为R4(目标规则标识即为待移动业务规则的标识)。具体更新过程如图6所示，首先基于原始相邻规则标识(R1以及R3)以及目标相邻规则标识(R3以及-1)，分别确定目标规则标识对应待移动业务规则在业务规则序列的原始位置信息(业务规则R1和业务规则R3之间)以及目标位置信息(业务规则R3和业务规则序列的尾部之间)。其次，将待移动业务规则由原始位置信息移动至目标位置信息，得到更新后的业务规则序列。再者，在规则标识关系集中更新更新后的待移动业务规则对应的第五规则标识关系(业务规则R4的规则标识关系R4.prev＝R3，R4.next＝-1)，以及更新目标相邻规则标识对应的业务规则的第六规则标识关系(业务规则R3的规则标识关系R3.prev＝R1，R3.next＝R4和业务规则R1的规则标识关系R1.prev＝-1，R1.next＝R3)，得到更新后的规则标识关系集；最终基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

在实现本公开的过程中还发现：当客户端A和客户端B在同一时间段需要修改同一业务规则时，如图7所示，客户端A和客户端B未感知对方同时修改版本V1，客户端A首先提交更新内容，服务器根据客户端A提交的更新内容修改规则R2，得到版本V2。客户端B随后提交更新内容，服务器根据客户端B提交的更新内容修改规则R3，因无感知客户端A已经发布了V2，所以此时更新后同样得到版本V2，由于全量更新，版本V2中规则R2的内容仍然为版本V1中规则R2的内容，也就是说客户端B对应的版本V2将会覆盖掉客户端A的版本V2，导致客户端A所对应的版本V2最终没有生效。

为了解决该问题，本公开实施例提供的一种业务规则的更新方法，图8为本公开另一实施例提供的一种业务规则的更新方法的流程图，如图8所示，该方法可以包括以下步骤：

步骤S21，检测在第二业务规则版本发布时刻之后是否存在目标业务对应的第三业务规则版本，其中，第三业务规则版本是基于第二客户端发送的第二规则更新信息得到的，第二客户端是与第一客户端在同一时间段内对目标业务的第一业务规则版本发起编辑的客户端。

在本公开实施例中，业务规则版本支持多个客户端进行并发编辑，因此会存在至少一个第二客户端与第一客户端在同一时间段对目标业务的第一业务规则进行编辑的情况，由于各个客户端之间进行编辑时互不影响，因此在第二业务规则版本创建之后，检测是否存在利用第二客户端发送的第二规则更新信息对第一业务规则版本进行更新得到的第三业务规则版本，以此避免出现版本被覆盖的情况。

步骤S22，在存在第三业务规则版本的情况下，利用第一业务规则更新信息对第三业务规则版本进行更新，得到第四业务规则版本，其中，第三业务规则版本是第二客户端利用第二规则更新信息对第一业务规则版本进行更新得到的。

在本公开实施例中，服务器检测到存在第三业务规则版本的情况下，利用第一业务规则更新信息对第三业务规则版本进行更新，即实现了第二业务规则版本与第三业务规则版本进行合并，最终得到第四业务规则版本。

需要说明的是，由于本公开实施例采用的是增量更新的方式，因此服务器可以直接获取第二客户端上传的第二规则更新信息，第二规则更新信息即为第三业务规则版本与第一业务规则版本之间的差异信息。因此，服务器可以直接从第一规则更新信息确定更新类型、规则标识、相邻规则标识，更新类型包括：新增类型、删除类型、修改类型以及移动类型。然后在第三业务规则版本获取与该规则标识相匹配的业务规则，并按照更新类型对该业务规则执行更新操作，得到第四业务规则版本。

步骤S23，将所述第四业务规则版本进行发布。

作为一个示例，目标业务X对应的业务规则版本V1包括：R1、R2、R3以及R4。客户端P和客户端Q在同一时间段内对业务规则版本V1发起编辑更新，其中客户端P对应规则更新信息diffup1，客户端Q对应规则更新信息为diffup2。客户端P在T1时刻向服务器发送规则更新信息diffup1，服务器基于规则更新信息diffup1对业务规则版本V1进行更新，得到业务规则版本V2，并发布。客户端Q在T2时刻(T2大于T1)向服务器发送规则更新信息diffup2，服务器基于规则更新信息diffup2对业务规则版本V1进行更新，得到业务规则版本V3并发布，此时由于此时已经发布业务规则版本V2，所以需要将业务规则版本V2和业务规则版本V3进行合并，得到业务规则版本V4，合并过程可以是：V1+diffup1+diffup2＝V4。

本公开实施例提供的方法在发布第一客户端对应的更新后的业务版本后，如果存在与第一客户端在同一时间段对同一业务规则版本进行更新的第二客户端，以及第二客户端所要更新的业务版本是否已经发布，如果已经发布，则将第一客户端和第二客户端分别对应的版本进行合并，作为最终版本。以此通过合并版本的方式，解决了同时对同一业务规则版本进行更新的至少两个客户端，因发布时间不同导致后发布的版本对前发布的版本无感知的问题。

图9为本公开实施例提供的一种业务规则的更新装置的框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图9所示，该装置包括：

第一获取模块91，用于获取第一客户端发送的业务规则更新请求，其中，业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息；

第二获取模块92，用于利用目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，第一业务规则版本包括业务规则序列以及规则标识关系集，规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系；

处理模块93，用于基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本；

执行模块94，用于将第二业务规则版本进行发布。

在本公开实施例中，第一规则更新信息包括：更新类型、目标规则标识以及相邻规则标识，更新类型包括：新增类型、删除类型、修改类型以及移动类型；

业务规则的更新装置还包括：校验模块，用于校验第一业务规则版本的规则标识集中是否存在目标规则标识以及相邻规则标识对应的规则标识关系，得到校验结果；在校验结果为存在目标规则标识以及相邻规则标识对应的规则标识关系的情况下，确定业务第一规则更新信息有效，其中，第一规则更新信息有效的情况下，基于第一规则更新信息对业务规则序列以及规则标识关系集进行更新，得到目标业务对应的第二业务规则版本。

在本公开实施例中，处理模块93，用于在更新类型为新增类型的情况下，利用目标规则标识获取新增业务规则；利用相邻规则标识确定新增业务规则在业务规则序列中的位置信息；将新增业务规则写入位置信息，得到更新后的业务规则序列；在规则标识关系集中新增新增业务规则的第一规则标识关系，以及更新相邻规则标识所对应的业务规则的第二规则标识关系，得到更新后的规则标识关系集；基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

在本公开实施例中，处理模块93，用于在更新类型为删除类型的情况下，利用目标规则标识获取待删除业务规则，并确定待删除业务规则的规则版本；在规则版本校验通过的情况下，将待删除业务规则从业务规则序列中删除，得到更新后的业务规则序列；删除待删除业务规则在规则标识关系集对应的第三规则标识关系，以及更新相邻规则标识对应的业务规则的第四规则标识关系，得到更新后的规则标识关系集；基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

在本公开实施例中，处理模块93，用于在更新类型为修改类型的情况下，利用目标规则标识获取待修改业务规则对应的目标规则内容；从业务规则序列中获取待修改业务规则对应的原始规则内容；将待修改业务规则的原始规则内容更新为目标规则内容，得到更新后的待修改业务规则，并基于更新后的待修改业务规则得到更新后的业务规则序列；基于更新后的业务规则序列以及规则标识关系集得到第二业务规则版本。

在本公开实施例中，处理模块93，用于在更新类型为移动类型的情况下，获取目标规则标识对应的原始相邻规则标识以及目标相邻规则标识；基于原始相邻规则标识以及目标相邻规则标识，分别确定目标规则标识对应待移动业务规则在业务规则序列的原始位置信息以及目标位置信息；将待移动业务规则由原始位置信息移动至目标位置信息，得到更新后的业务规则序列，并在规则标识关系集中更新更新后的待移动业务规则对应的第五规则标识关系，以及更新目标相邻规则标识对应的业务规则的第六规则标识关系，得到更新后的规则标识关系集；基于更新后的业务规则序列以及更新后的规则标识关系集得到第二业务规则版本。

在本公开实施例中，业务规则的更新装置还包括：合并模块，用于检测在第二业务规则版本发布时刻之前是否存在目标业务对应的第三业务规则版本，其中，第三业务规则版本是基于第二客户端发送的第二规则更新信息得到的，第二客户端是与第一客户端在同一时间段内对目标业务的第一业务规则版本发起编辑的客户端；在存在第三业务规则版本的情况下，利用第一业务规则更新信息对第二业务规则版本进行更新，得到第四业务规则版本，其中，第二业务规则版本是第二客户端利用第二规则更新信息对第一业务规则版本进行更新得到的；将第四业务规则版本进行发布。

本公开实施例还提供一种电子设备，如图10所示，电子设备可以包括：处理器1501、通信接口1502、存储器1503。存储器1503，用于存放计算机程序；处理器1501，用于执行存储器1503上所存放的计算机程序时，实现上述实施例的步骤。

存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本公开提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的业务规则的更新方法。

在本公开提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的业务规则的更新方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘SolidState Disk)等。

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

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种业务规则的更新方法，其特征在于，包括：

获取第一客户端发送的业务规则更新请求，其中，所述业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息；

利用所述目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，所述第一业务规则版本包括业务规则序列以及规则标识关系集，所述规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系；

基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本；

将所述第二业务规则版本进行发布。

2.根据权利要求1所述的方法，其特征在于，所述第一规则更新信息包括：更新类型、目标规则标识以及相邻规则标识，所述更新类型包括：新增类型、删除类型、修改类型以及移动类型；

在基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新之前，所述方法还包括：

校验所述第一业务规则版本的规则标识集中是否存在所述目标规则标识以及所述相邻规则标识对应的规则标识关系，得到校验结果；

在所述校验结果为存在所述目标规则标识以及所述相邻规则标识对应的规则标识关系的情况下，确定所述业务第一规则更新信息有效，其中，所述第一规则更新信息有效的情况下，基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本。

3.根据权利要求2所述的方法，其特征在于，所述基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本，包括：

在所述更新类型为新增类型的情况下，利用所述目标规则标识获取新增业务规则；

利用所述相邻规则标识确定所述新增业务规则在所述业务规则序列中的位置信息；

将所述新增业务规则写入所述位置信息，得到更新后的业务规则序列；

在所述规则标识关系集中新增所述新增业务规则的第一规则标识关系，以及更新所述相邻规则标识所对应的业务规则的第二规则标识关系，得到更新后的规则标识关系集；

基于所述更新后的业务规则序列以及所述更新后的规则标识关系集得到第二业务规则版本。

4.根据权利要求2所述的方法，其特征在于，所述基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本，包括：

在所述更新类型为删除类型的情况下，利用所述目标规则标识获取待删除业务规则，并确定所述待删除业务规则的规则版本；

在所述规则版本校验通过的情况下，将所述待删除业务规则从所述业务规则序列中删除，得到更新后的业务规则序列；

删除所述待删除业务规则在所述规则标识关系集对应的第三规则标识关系，以及更新所述相邻规则标识对应的业务规则的第四规则标识关系，得到更新后的规则标识关系集；

基于所述更新后的业务规则序列以及所述更新后的规则标识关系集得到第二业务规则版本。

5.根据权利要求2所述的方法，其特征在于，所述基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本，包括：

在所述更新类型为修改类型的情况下，利用所述目标规则标识获取待修改业务规则对应的目标规则内容；

从所述业务规则序列中获取所述待修改业务规则对应的原始规则内容；

将所述待修改业务规则的原始规则内容更新为所述目标规则内容，得到更新后的待修改业务规则，并基于所述更新后的待修改业务规则得到更新后的业务规则序列；

基于所述更新后的业务规则序列以及所述规则标识关系集得到第二业务规则版本。

6.根据权利要求2所述的方法，其特征在于，所述基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系进行更新，得到第二业务规则版本，包括：

在所述更新类型为移动类型的情况下，获取所述目标规则标识对应的原始相邻规则标识以及目标相邻规则标识；

基于所述原始相邻规则标识以及所述目标相邻规则标识，分别确定所述目标规则标识对应待移动业务规则在业务规则序列的原始位置信息以及目标位置信息；

将所述待移动业务规则由所述原始位置信息移动至所述目标位置信息，得到更新后的业务规则序列，并在所述规则标识关系集中更新所述更新后的待移动业务规则对应的第五规则标识关系，以及更新所述目标相邻规则标识对应的业务规则的第六规则标识关系，得到更新后的规则标识关系集；

基于所述更新后的业务规则序列以及所述更新后的规则标识关系集得到第二业务规则版本。

7.根据权利要求1所述的方法，其特征在于，在将所述第二业务规则版本进行发布之后，所述方法还包括：

检测在所述第二业务规则版本发布时刻之前是否存在所述目标业务对应的第三业务规则版本，其中，所述第三业务规则版本是基于第二客户端发送的第二规则更新信息得到的，所述第二客户端是与所述第一客户端在同一时间段内对所述目标业务的第一业务规则版本发起编辑的客户端；

在存在所述第三业务规则版本的情况下，利用所述第一业务规则更新信息对所述第二业务规则版本进行更新，得到第四业务规则版本，其中，所述第二业务规则版本是所述第二客户端利用第二规则更新信息对所述第一业务规则版本进行更新得到的；

将所述第四业务规则版本进行发布。

8.一种业务规则的更新装置，其特征在于，包括：

第一获取模块，用于获取第一客户端发送的业务规则更新请求，其中，所述业务规则更新请求包括：目标业务标识以及至少一个第一规则更新信息；

第二获取模块，用于利用所述目标业务标识获取待更新目标业务当前对应的第一业务规则版本，其中，所述第一业务规则版本包括业务规则序列以及规则标识关系集，所述规则标识关系集包括业务规则序列中每个业务规则对应的规则标识关系；

处理模块，用于基于所述第一规则更新信息对所述业务规则序列以及所述规则标识关系集进行更新，得到所述目标业务对应的第二业务规则版本；

执行模块，用于将所述第二业务规则版本进行发布。

9.一种存储介质，其特征在于，所述存储介质包括存储的计算机程序，其中，所述程序运行时执行上述权利要求1至7中任一项所述的方法步骤。

10.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；其中：

存储器，用于存放计算机程序；

处理器，用于通过运行存储器上所存放的程序来执行权利要求1至7中任一项所述的方法步骤。

Images