CN113114493B - 一种网元配置约束检查方法及*** - Google Patents

Abstract

本发明公开了一种网元配置约束检查方法及***，方法包括：加载约束检查管理器和约束规则检查器，不同网元类型对应不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器；接收网元配置的变更消息后确定变更消息类型，并通过分析网元配置数据得到网元类型和网元配置类型；根据网元类型查找对应的约束检查管理器，并根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合；每个约束规则检查器均根据对应的约束类型和变更消息类型进行相应约束检查，并将约束检查结果上报客户端。通过该约束检查方法可以有效地保障网元配置数据的一致性、合法性、正确性。

Description

一种网元配置约束检查方法及***

技术领域

本发明属于网络设备管理技术领域，更具体地，涉及一种网元配置约束检查方法及***。

背景技术

网元配置数据的一致性、合法性和正确性是网络设备管理***的重要指标，也构成了对配置数据的约束要求。首先，在网络设备管理***中，业务和配置在创建或更改过程中需要对网元配置的相关数据进行合法性检查，比如数据字段是否非空、是否处于值域范围、是否超过设备上限要求、是否违背唯一性原则等等，否则会造成业务创建失败或配置激活异常等现象，影响网络设备的功能使用。其次，网络设备管理***中的一些网管操作具有先后顺序要求，不可颠倒；比如业务与配置数据存在一定关联性，在删除或修改配置时需要检查是否承载业务，否则不可随意修改配置，以免影响业务畅通，因此需要对网管操作的先后顺序进行约束检查。第三，网络设备管理***需要支持重建约束，即工程升级或网元业务模型变化时能够对存量配置进行约束关系重建，以保证整个***的数据一致性和正确性。另外，对于用户的一些非法或不当操作，当前***的提示信息往往不够清晰或缺失必要的提示，影响用户体验和快速排查问题。

鉴于此，需要提供一种高效的约束检查方法及***，可实现对网元配置数据合法性、网管操作先后顺序的约束检查，同时在工程升级或网元业务模型变化时可重建约束，保障网元配置数据的一致性、合法性、正确性。另外，需要约束检查结果提示信息清晰准确，以提高用户进行网管操作的效率，改善用户体验、方便排查问题原因。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种网元配置约束检查方法及***，其目的在于有效实现网元配置数据合法性、网管操作先后顺序的约束检查，并在必要时进行重建约束，由此解决传统方案难以保障网元配置数据的一致性、合法性和正确性的技术问题。

为实现上述目的，按照本发明的一个方面，提供了一种网元配置约束检查方法，包括：

加载约束检查管理器和约束规则检查器；其中，不同网元类型对应不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器；

接收网元配置的变更消息后确定变更消息类型，并通过分析网元配置数据得到网元类型和网元配置类型；

根据网元类型查找对应的约束检查管理器，并根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合；

所述约束规则检查器集合中的每个约束规则检查器均根据对应的约束类型和变更消息类型进行相应约束检查，并将约束检查结果上报客户端。

优选地，在所述加载约束检查管理器和约束规则检查器之前，所述方法还包括：

根据功能需求定义不同的约束类型并抽象，所述约束类型包括值域约束、唯一性约束、主外键约束和规格约束中的一项或多项；其中：

所述值域约束用于对当前的网元配置数据合法性进行约束检查；

所述唯一性约束对应的约束关系数据存储在数据库中，用于对网元配置唯一性进行约束检查，且对应约束关系数据以Key-Value格式存储；

所述主外键约束对应的约束关系数据存储在数据库中，用于对网管操作的先后顺序进行约束检查，且对应约束关系数据以Key-Value格式存储；

所述规格约束对应的约束关系数据存储在数据库中，用于对网元配置规格进行约束检查；且对应约束关系数据以Key-Value格式存储。

优选地，在所述加载约束检查管理器和约束规则检查器之前，所述方法还包括：

设置规则定义脚本和约束错误码脚本；其中，所述规则定义脚本用于供用户自定义设置规格约束的上限值、是否屏蔽某种约束规则检查器的检查以及是否开启重建约束功能，所述约束错误码脚本用于定义约束检查错误码信息模板。

优选地，对于所述约束规则检查器集合中的每个约束规则检查器，所述根据对应的约束类型和变更消息类型进行相应约束检查，具体为：

如果约束规则检查器对应的约束类型为值域约束，则根据网元配置的变更消息类型执行相应的约束检查方法，并得到相应的约束检查结果；其中，所述变更消息类型包括增加、删除、修改、激活和去激活中的一项或多项；

如果约束规则检查器对应的约束类型为非值域约束，则根据网元配置数据计算约束Key信息，根据所述约束Key信息从数据库中查找对应的约束关系数据；然后根据网元配置的变更消息类型以及查找到的约束关系数据执行相应的约束检查方法，并得到相应的约束检查结果。

优选地，对于值域约束，在所述根据网元配置的变更消息类型执行相应的约束检查方法过程中，所述方法还包括：

如果约束检查存在冲突，则以网元配置数据作为参数格式化约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果；其中，所述约束检查错误码信息模板通过约束错误码脚本来定义。

优选地，对于非值域约束，在所述根据网元配置的变更消息类型以及查找到的约束关系数据执行相应的约束检查方法过程中，所述方法还包括：

如果约束检查存在冲突，则以网元配置数据作为参数格式化约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果；如果约束检查不存在冲突，则更新对应的约束关系数据并存入所述数据库；其中，所述约束检查错误码信息模板通过约束错误码脚本来定义。

优选地，当网络设备管理***中导入新配置或者网元业务模型有更新时，进行重建约束，具体为：清除所述数据库中当前的约束关系数据，重新对当前的网元配置执行一次约束检查，并生成新的约束关系数据存入所述数据库。

优选地，所述清除所述数据库中当前的约束关系数据，重新对当前的网元配置执行一次约束检查，并生成新的约束关系数据存入所述数据库，具体包括：

对于每个网元，根据网元类型从对应的约束检查管理器中查找已注册约束规则检查器的网元配置类型集合，并从所述数据库中清除该网元对应的约束关系数据；

根据所述网元配置类型集合获取该网元的每个网元配置项，并利用该网元所注册的约束规则检查器，依次对每个网元配置项执行变更消息类型为增加配置的约束检查方法；

对于约束类型为非值域约束的约束规则检查器，在执行约束检查方法后更新对应的约束关系数据，并将新的约束关系数据存入所述数据库；

其中，如果约束检查过程中发现存在约束检查冲突，则生成一个约束冲突摘要并存储到所述数据库中。

按照本发明的另一方面，提供了一种网元配置约束检查***，包括约束检查框架、存储器和处理器；其中，所述约束检查框架包括约束检查接口、约束检查管理器、约束规则检查器和数据库；

所述约束检查接口用于接收网元配置的变更消息，触发约束检查；

所述约束检查管理器设置一个或多个，分别对应不同网元类型，且每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个不同的约束规则检查器；

所述约束规则检查器用于根据对应的约束类型和变更消息类型，执行相应的约束检查方法，并将得到的约束检查结果上报客户端；

所述数据库用于保存约束关系数据，并供所述约束规则检查器使用；

所述存储器用于存储可被所述处理器执行的指令，所述指令在被所述处理器执行后，用于通过分析网元配置数据得到网元类型和网元配置类型，并根据网元类型查找对应的约束检查管理器，根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合。

优选地，所述约束检查框架还包括约束脚本仓库和脚本解析器；

所述约束脚本仓库用于存储规则定义脚本和约束错误码脚本；

所述脚本解析器用于对所述约束脚本仓库中存储的规则定义脚本和约束错误码脚本进行解析，并供所述约束检查管理器使用；

其中，所述规则定义脚本用于供用户自定义设置规格约束的上限值、是否屏蔽某种约束规则检查器的检查以及是否开启重建约束功能；所述约束错误码脚本用于定义约束检查错误码信息模板。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有如下有益效果：本发明提供的网元配置约束检查方法及***中，不同网元类型对应不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器；当用户对某个网元配置执行变更操作时可触发根据网元类型查找对应的约束检查管理器，进而根据网元配置类型从对应的约束检查管理器中获取约束规则检查器集合，集合中每个约束规则检查器均可根据对应的约束类型和变更消息类型执行约束检查，并将结果上报客户端。通过该约束检查方法可以有效地保障网元配置数据的一致性、合法性、正确性。

附图说明

图1是本发明实施例提供的一种网元配置约束检查框架的结构示意图；

图2是本发明实施例提供的一种约束检查框架化的方法流程图；

图3是本发明实施例提供的一种ruledefine脚本的设计示例图；

图4是本发明实施例提供的一种错误码信息脚本的设计示例图；

图5是本发明实施例提供的一种网元配置约束检查方法的流程图；

图6是本发明实施例提供的一种每个网元执行重建约束的流程图；

图7是本发明实施例提供的一种网元配置约束检查的完整流程图；

图8是本发明实施例提供的一种网元配置重建约束的完整流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

实施例1

为解决传统方案难以保障网元配置数据的一致性、合法性和正确性的技术问题，本发明提供了一种网元配置约束检查方法，用于对各种网元配置进行约束检查。其中，为更好地实现对网元配置的约束检查，可先将约束检查框架化，形成如图1所示的约束检查框架，则后续可利用该约束检查框架执行约束检查方法。

参考图2，在本发明实施例中，约束检查框架化的过程具体如下：

步骤101，根据功能需求定义不同的约束类型并抽象，所述约束类型包括值域约束、唯一性约束、主外键约束和规格约束中的一项或多项。

网元配置类型有很多，例如环回口配置、以太口配置、VPWS(Virtual PrivateWire Service，即虚拟专线业务)配置、LSP(Label Switching Path，即标记交换路径)配置等。一种网元配置可以对应多个约束规则检查器，而不同的约束规则检查器则根据需求分别继承这些抽象，并可实现增加、删除、修改、激活、去激活等约束检查方法，且每一个约束规则检查器都有唯一的约束规则ID。其中：

1)所述值域约束用于对当前的网元配置数据合法性进行约束检查，包括是否非空、是否处于值域范围、是否允许修改等；例如业务名称不能为空、以太口承载L2VPN(Layer2 Virtual Private Network，即二层虚拟专用网络)业务时不能修改MPLS(Multi-Protocol Label Switching，即多协议标签交换)使能等。

2)所述唯一性约束又包括全局唯一性约束和网元内唯一性约束。

所述全局唯一性约束是指配置数据在整个网络设备管理***中唯一；例如，环回口、以太口的IP地址在整个网络设备管理***中不能重复。

所述网元内唯一性约束是指配置数据在整个网元中唯一；例如，MA(MaintenanceAssociation，即维护联盟)、MD(Maintenance Domain，即维护域)的名称在同一网元内不能重复，但在不同网元中允许重复。

所述唯一性约束对应的约束关系数据存储在数据库中，以用于后续对网元配置唯一性进行约束检查。其中，所述唯一性约束对应的约束关系数据在数据库中以Key-Value格式存储，具体可如下：

Key＝约束类型+约束规则ID+约束字段值；

Value＝网元配置数据的关键字；

其中，约束字段值和网元配置数据的关键字可根据功能需求进行定义。

3)所述主外键约束又包括主键约束与外键约束。主键约束与外键约束是一个相对概念，表明一个配置数据引用了另一个配置数据；例如，DS(DiffServ，即区分服务)模板中可以配置DS域，此时就需要针对DS域新建一个主键，针对DS模板创建一个外键，并将这种约束关系数据存储在数据库中，以用于后续对网管操作的先后顺序进行约束检查。例如，当某一个DS模板数据已配置了某一个DS域数据，此时如果用户执行删除该DS域数据，则网络设备管理***就会弹出提示该DS域被引用，不允许删除。

综上，所述主外键约束对应的约束关系数据也存储在数据库中，并用于后续对网管操作的先后顺序进行约束检查。其中，所述主外键约束对应的约束关系数据在数据库中以Key-Value格式存储，具体可如下：

Key＝约束类型+约束规则ID+约束字段值；

Value＝网元配置数据的关键字；

其中，约束字段值和网元配置数据的关键字可根据功能需求进行定义。

4)所述规格约束是指对网络设备的能力约束，表明某种类型的配置数据是否已达到网络设备所支持的上限。配置数据在进行增加、删除操作时会动态计算当前该类配置的总数，并将这种约束关系数据存储在数据库中，以用于后续规格约束检查。例如，某种PTN(Packet Transport Network，即分组传送网)设备的VPWS业务不能超过320条，当用户创建VPWS业务达到上限时，网络设备管理***会弹出提示。

综上，所述规格约束对应的约束关系数据也存储在数据库中，用于对网元配置规格进行约束检查。其中，所述规格约束对应的约束关系数据在数据库中以Key-Value格式存储，具体可如下：

Key＝约束类型+约束规则ID+约束字段值；

Value＝当前数量；

其中，约束字段值可根据功能需求进行定义。

步骤102，设置规则定义脚本和约束错误码脚本，即脚本化设置。其中：

1)所述规则定义脚本又称为ruledefine脚本，也就是将规则定义进行脚本化。所述规则定义脚本的具体功能特征包括但不限于以下几点：1、供用户自定义设置规格约束的上限值；2、设置是否屏蔽某种约束规则检查器的检查；3、设置是否开启重建约束功能的开关状态。具体地，对于规格约束类型的约束规则检查器，通过该脚本用户可以自定义规格约束的上限值；对于所有约束规则检查器，通过该脚本用户可以自定义是否屏蔽某种约束规则检查器的检查；通过该脚本用户还可以决定是否开启重建约束功能。其中，所述规则定义脚本的具体表现形式包括但不限于图3所示的形式。

2)所述约束错误码脚本用于定义约束检查错误码信息模板，也就是将约束检查错误码信息脚本化。所述约束错误码脚本的具体功能特征包括但不限于以下几点：1、定义约束错误码的类型；2、定义约束错误码提示信息的中英文格式化模板；3、定义参数列表，该参数列表将作为约束错误码信息格式化模板的参数输入。通过脚本定义错误码提示信息的格式化模板，可使得界面收到的提示信息更加清晰，且方便扩展。其中，所述约束错误码脚本的具体表现形式包括但不限于图4所示的形式。

步骤103，基于所述不同的约束类型和设置的脚本创建约束检查框架。

基于所述步骤101中定义的4种约束类型以及所述步骤102中设置的规则定义脚本和约束错误码脚本，即可创建约束检查框架，它一个独立的模块，且支持插件式加载。如图1所示，所述约束检查框架包括约束检查接口、约束检查管理器、约束规则检查器、数据库、约束脚本仓库和脚本解析器。具体如下：

所述约束检查框架提供统一的约束检查接口，即所述约束检查接口。所述约束检查接口与客户端连接，当用户在客户端执行网元配置的增加、删除、修改、激活、去激活等变更操作时，所述约束检查接口可接收网元配置的变更消息，从而触发约束检查。

所述约束检查管理器可设置一个或多个，分别对应不同网元类型的设备。例如OTN(Optical Transport Network，即光传送网)网元、PTN网元、SDH(Synchronous DigitalHierarchy，即同步数字体系)网元，分别对应OTN约束检查管理器、PTN约束检查管理器、SDH约束检查管理器。

其中，每个约束检查管理器会通过相应的约束检查管理器注册接口，根据功能需求对不同网元配置类型分别注册多个不同的约束规则检查器，即一个网元配置可对应多个约束规则检查器。每个约束规则检查器都有唯一的约束规则ID，并对应一种约束类型，支持增加、删除、修改、激活、去激活这5种约束检查方法，即支持CheckAdd、CheckDel、CheckDeploy、CheckModify、CheckUnDeploy。

所述约束规则检查器可根据对应的约束类型(即值域约束、唯一性约束、主外键约束、规格约束)和变更消息类型(即增加、删除、修改、激活、去激活)，执行相应的约束检查方法，并将得到的约束检查结果上报客户端。

所述数据库用于保存所述唯一性约束、所述主外键约束和所述规格约束对应的约束关系数据，并可供所述约束规则检查器调取使用。

所述约束脚本仓库用于存储设置好的规则定义脚本(即ruledefine脚本)和约束错误码脚本。所述脚本解析器则可对所述约束脚本仓库中存储的脚本进行解析，且解析后的脚本可供所述约束检查管理器使用。

基于所述约束检查框架，当用户在客户端执行某种网元配置的增加、删除、修改、激活、去激活等变更操作时，可触发查找该网元配置对应注册的约束规则检查器集合，该集合中的每个约束规则检查器依次执行相应的约束检查方法，并将约束检查结果上报给客户端，完成约束检查。其中，具体的约束检查过程可参考实施例3，在此不做赘述。

实施例2

基于上述实施例1中创建的约束检查框架，本发明实施例进一步提供了一种网元配置约束检查***，可用于执行后续实施例3中的网元配置约束检查方法。具体结构如下：

所述网元配置约束检查***包括约束检查框架、存储器和处理器。

所述约束检查框架如图1所示，是一个独立的模块，且支持插件式加载，主要包括约束检查接口、约束检查管理器、约束规则检查器、数据库、约束脚本仓库和脚本解析器。其中：

所述约束检查接口用于接收网元配置的变更消息，进而触发约束检查。结合图1，当用户在客户端执行网元配置的增加、删除、修改、激活、去激活操作时，所述约束检查接口可接收到网元配置的变更消息。

所述约束检查管理器设置一个或多个，分别对应不同网元类型的设备；例如，网元类型为OTN网元、PTN网元、SDH网元时，分别对应OTN约束检查管理器、PTN约束检查管理器、SDH约束检查管理器。其中，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个不同的约束规则检查器，每个约束规则检查器都有唯一的约束规则ID。

所述约束规则检查器用于根据对应的约束类型和变更消息类型，执行相应的约束检查方法，并将得到的约束检查结果上报客户端。

所述数据库用于保存所述唯一性约束、所述主外键约束和所述规格约束对应的约束关系数据，并可供所述约束规则检查器调取使用。

所述约束脚本仓库用于存储规则定义脚本和约束错误码脚本。

所述脚本解析器用于对所述约束脚本仓库中存储的规则定义脚本和约束错误码脚本进行解析，并供所述约束检查管理器使用。

其中，所述规则定义脚本用于供用户自定义设置规格约束的上限值、是否屏蔽某种约束规则检查器的检查以及是否开启重建约束功能等；所述约束错误码脚本用于定义约束检查错误码信息模板。

所述存储器用于存储可被所述处理器执行的指令，所述指令在被所述处理器执行后，用于通过分析网元配置数据得到网元类型和网元配置类型，并根据网元类型查找对应的约束检查管理器，根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合，以便该集合中的各约束规则检查器分别执行相应约束检查方法，并将约束检查结果上报客户端。

其中，所述处理器与所述约束检查框架的约束检查接口连接，当用户在客户端执行某种网元配置的增加、删除、修改、激活、去激活操作时，所述约束检查接口接收到该网元配置的变更消息，触发所述处理器进行一系列的分析处理操作，以获取该网元配置相关的约束规则检查器集合。

进一步地，所述处理器和所述存储器可以通过总线或者其他方式连接。所述存储器作为一种网元配置约束检查方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。所述处理器通过运行存储在所述存储器中的非易失性软件程序、指令以及模块，从而执行网元配置约束检查***的各种功能应用以及数据处理。

所述存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，所述存储器可选包括相对于所述处理器远程设置的存储器，这些远程存储器可以通过网络连接至所述处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或光盘等。

在本发明实施例提供的上述网元配置约束检查***中，不同网元类型对应不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器；当用户对某个网元配置执行变更操作时可触发获取该网元配置对应的约束规则检查器集合，集合中每个约束规则检查器执行约束检查，并将结果上报客户端。通过该约束检查方法可以有效地保障网元配置数据的一致性、合法性、正确性；而且脚本化地管理约束规则检查器的开启、自定义规格约束的上限值以及错误码格式化信息，维护方便、扩展灵活。

实施例3

基于上述实施例2提供的网元配置约束检查***，本发明实施例进一步提供了一种网元配置约束检查方法，如图5所示，具体包括：

步骤201，加载约束检查管理器和约束规则检查器；其中，不同网元类型对应不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器。

结合图1和实施例1、2可知，所述网元配置约束检查***中包括多个约束检查管理器和多个约束规则检查器，这里需要加载所有的约束检查管理器和所有的约束规则检查器，以便后续使用。

步骤202，接收网元配置的变更消息后确定变更消息类型，并通过分析网元配置数据得到网元类型和网元配置类型。

结合实施例1、2可知，所述变更消息类型主要是指增加、删除、修改、激活和去激活，所述网元类型主要包括OTN网元、PTN网元、SDH网元等；所述网元配置类型是按照设备功能进行划分的，例如环回口配置、以太口配置、VPWS配置、LSP配置等。当用户在客户端执行某种网元配置的增加、删除、修改、激活、去激活操作时，所述约束检查接口会接收到该网元配置的变更消息，所述处理器通过分析网元配置数据得到网元类型和网元配置类型。

步骤203，根据网元类型查找对应的约束检查管理器，并根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合。

所述处理器先根据网元类型查找对应的约束规则管理；例如，当网元类型为OTN网元时则对应查找OTN约束检查管理器，当网元类型为PTN网元时则对应查找PTN约束检查管理器，当网元类型为SDH网元时则对应查找SDH约束检查管理器。

不同的网元配置类型注册了很多不同的约束规则检查器，所述处理器查找到对应的约束规则管理后，继续根据网元配置类型从所述对应的约束检查管理器中获取相关的约束规则检查器集合。

步骤204，所述约束规则检查器集合中的每个约束规则检查器均根据对应的约束类型和变更消息类型进行相应约束检查，并将约束检查结果上报客户端。

依次从所述约束规则检查器集合取出约束规则检查器，根据当前该约束规则检查器对应的约束类型和变更消息类型进行相应约束检查。其中：

1)如果约束规则检查器对应的约束类型为值域约束，则直接根据网元配置的变更消息类型执行相应约束检查方法，并得到相应的约束检查结果。特殊地，如果约束检查存在冲突，则以网元配置数据作为参数格式化所述约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果。其中，所述错误码信息中包含有约束检查错误的具体原因详情，可使得界面收到的提示信息更加清晰，从而提高用户进行网管操作的效率，改善用户体验、方便排查问题原因。

2)如果约束规则检查器对应的约束类型为非值域约束(即唯一性约束、主外键约束或规格约束)，则根据网元配置数据计算约束Key信息，根据所述约束Key信息从数据库中查找对应的约束关系数据；然后根据网元配置的变更消息类型以及查找到的约束关系数据执行相应的约束检查方法，并得到相应的约束检查结果。

特殊地，如果约束检查存在冲突，则以网元配置数据作为参数格式化约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果，其中，所述错误码信息中包含有约束检查错误的具体原因详情；如果约束检查不存在冲突，则更新对应的约束关系数据并存入所述数据库。

由上可知，值域约束与非值域约束的处理逻辑不一样，值域约束只需要对当前网元配置的内容做检查，而非值域约束涉及到对历史数据的检查，需要借助存储在数据库中的约束关系数据来进行逻辑处理。

进一步地，当网络设备管理***中导入新配置或者网元业务模型有更新时，可通过增量式约束检查的方式进行重建约束，即清除所述数据库中当前的约束关系数据，重新对当前***中的网元配置执行一次约束检查，并生成新的约束关系数据存入所述数据库；同时还可将约束检查过程中违背现有约束检查规则的网元配置生成约束冲突摘要供用户查看。

在重建约束时需要对所有网元依次执行重建约束，对于每个网元，重建过程可参考图6，具体如下：

步骤301，根据网元类型从对应的约束检查管理器中查找已注册约束规则检查器的网元配置类型集合，并从所述数据库中清除该网元对应的约束关系数据。例如，如果当前网元为OTN网元，则所述处理器从OTN约束检查管理器中找到OTN网元所有注册了约束规则检查器的网元配置，进而形成网元配置类型集合。

步骤302，根据所述网元配置类型集合获取该网元的每个网元配置项，并利用该网元所注册的约束规则检查器，依次对每个网元配置项执行变更消息类型为增加配置的约束检查方法。

仍以当前网元为OTN网元为例，则所述处理器从对应的网元配置类型集合中获取OTN网元的每个网元配置项，并查找每个网元配置项对应的约束规则检查器。由于是重新执行约束检查，因此可根据查找到的对应关系，由约束规则检查器对对应的网元配置项执行增加约束检查方法。

步骤303，对于约束类型为非值域约束的约束规则检查器，在执行约束检查方法后更新对应的约束关系数据，并将新的约束关系数据存入所述数据库。

考虑到值域约束与非值域约束的处理逻辑不一样，值域约束只需要对当前网元配置的内容做检查，而非值域约束涉及到对历史数据的检查，需要借助存储在数据库中的约束关系数据来进行逻辑处理，因此在重新执行约束检查后，对于非值域约束需要根据约束检查结果更新约束关系数据，值域约束则无需处理。如果约束检查过程中发现存在约束检查冲突，则生成一个约束冲突摘要并存储到所述数据库中，以方便用户后续查看。

在本发明实施例提供的上述网元配置约束检查方法中，当用户对某个网元配置执行变更操作时，可触发获取该网元配置对应注册的约束规则检查器集合，由集合中每个约束规则检查器执行约束检查，并将结果上报客户端。通过该约束检查方法可以有效地保障网元配置数据的一致性、合法性、正确性；而且脚本化地管理约束规则检查器的开启、自定义规格约束的上限值以及错误码格式化信息，维护方便、扩展灵活；同时可重建约束的特性，使得约束检查可以增量式进行，工程升级更便捷。

实施例4

在上述实施例3的基础上，本发明实施例进一步对网元配置约束检查方法的完整流程作详细说明，结合图7，具体包括以下步骤：

步骤401，加载约束检查管理器和约束规则检查器。

所述网元配置约束检查***中包括多个约束检查管理器和多个约束规则检查器，不同网元类型的设备对应着不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器，这里需要加载所有的约束检查管理器和所有的约束规则检查器。

步骤402，接收网元配置的变更消息，确定变更消息类型。其中，所述变更消息类型包括增加、删除、修改、激活和去激活等。

步骤403，通过分析网元配置数据，得到网元类型和网元配置类型。其中，所述网元类型主要包括OTN网元、PTN网元、SDH网元等；所述网元配置类型是按照设备功能进行划分的，例如环回口配置、以太口配置、VPWS配置、LSP配置等。

步骤404，根据网元类型查找对应的约束规则管理。例如，当网元类型为OTN网元时则对应查找OTN约束检查管理器，当网元类型为PTN网元时则对应查找PTN约束检查管理器。

步骤405，根据网元配置类型从所述对应的约束检查管理器中获取相关的约束规则检查器集合。不同的网元配置类型注册了很多不同的约束规则检查器，根据网元配置类型即可确定对应的各约束规则检查器。

步骤406，从所述约束规则检查器集合中取出一个约束规则检查器。

步骤407，判断该约束规则检查器的约束类型是否为值域约束；如果是则跳转至步骤408，否则跳转至步骤412。

步骤408，约束规则检查器根据网元配置的变更消息类型执行相应约束检查方法，并得到相应的约束检查结果。

步骤409，如果约束检查存在冲突，则以网元配置数据作为参数格式化所述约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果。其中，所述错误码信息中包含有约束检查错误的具体原因详情。

步骤410，判断所述约束规则检查器集合中的所有约束规则检查器是否处理完毕；如果处理完毕则跳转至步骤411；否则跳转至步骤406。

步骤411，返回所有约束规则检查器的约束检查结果给客户端。至此整个约束检查流程执行完毕。

步骤412，约束规则检查器根据网元配置数据计算约束Key信息。

结合实施例1可知，约束Key信息＝约束类型+约束规则ID+约束字段值。不同约束规则检查器的约束字段值可按照功能要求进行定义，例如，环回口IP全局唯一性约束的约束字段值就是IP地址。

步骤413，约束规则检查器根据约束Key信息从数据库中查找对应的约束关系数据。

结合实施例1可知，所述唯一性约束和所述主外键约束在所述数据库中的存储格式如下：

Key＝约束类型+约束规则ID+约束字段值；

Value＝网元配置数据的关键字；

所述规格约束在所述数据库中的存储格式如下：

Key＝约束类型+约束规则ID+约束字段值；

Value＝当前数量；

因此，由约束Key信息即可从所述数据库中找到对应的约束关系数据。

步骤414，约束规则检查器根据网元配置的变更消息类型以及查找到的约束关系数据执行相应的约束检查方法，并得到相应的约束检查结果。

步骤415，如果约束检查存在冲突，则以网元配置数据作为参数格式化约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果；其中，所述错误码信息中包含有约束检查错误的具体原因详情。

如果约束检查不存在冲突，则更新对应的约束关系数据并存入所述数据库，这是因为非值域约束涉及到对历史数据的检查，需要借助存储在数据库中的约束关系数据来进行逻辑处理。

然后跳转至步骤410，直至所述约束规则检查器集合中的所有约束规则检查器都处理完毕。

实施例5

在上述实施例4的基础上，本发明实施例以从客户端修改某种PTN设备的某个单盘的以太口配置的MPLS使能为关、IP设置为10.26.2.89为例，即网元类型为PTN网元、网元配置类型为以太口配置、变更消息类型为修改，则整个网元配置约束检查过程具体如下：

1)加载所有的约束检查管理器和约束规则检查器。

2)约束检查接口接收到以太口配置的修改消息。

3)通过分析以太口配置数据，得到网元类型为PTN网元，网元配置类型为以太口配置。

4)根据PTN网元类型查找到PTN约束检查管理器。

5)根据网元配置类型为以太口配置，从PTN约束检查管理器中获取相关的所有约束规则检查器。假设查找到PTN约束检查管理器对以太口配置注册了两个约束规则检查器：以太口配置值域约束检查器、以太口IP全局唯一约束检查器，即对应的约束类型分别为值域约束和唯一性约束。

6)执行所述以太口配置值域约束检查器的修改约束检查方法，假设约束检查过程中发现当前以太口上已承载L2VPN业务，则约束检查方法返回存在冲突，生成错误信息“当前以太口已承载L2VPN业务，不允许修改MPLS使能”。

7)执行所述以太口IP全局唯一约束检查器的修改约束检查方法，根据以太口配置数据计算出约束Key信息＝“01100110.26.2.89”，根据约束Key信息从数据库中查找是否存在关联的约束关系数据。假设约束检查过程中未发现冲突，则更新约束关系数据并存入所述数据库。

8)两个约束规则检查器都已处理完毕，则返回最终的约束检查结果“当前以太口已承载L2VPN业务，不允许修改MPLS使能”给客户端。至此整个约束检查流程结束。

实施例6

在上述实施例3的基础上，本发明实施例进一步对网元配置重建约束的完整流程作详细说明，结合图8，具体包括以下步骤：

步骤501，解析规则定义脚本，获取重建约束的开关状态。具体由所述脚本解析器解析ruledefine脚本。

步骤502，判断是否启用重建约束功能且重建约束的开关状态为开。如果当前已启用重建约束功能且重建约束的开关为开，则执行重建约束操作，跳转至步骤503，否则流程结束。

步骤503，获取当前网络中的所有网元信息。

步骤504，取出一个网元，并根据网元类型从对应的约束检查管理器中查找已注册约束规则检查器的网元配置类型集合。例如，当前取出的网元为OTN网元时，则从OTN约束检查管理器中找到OTN网元注册了约束规则检查器的所有网元配置，得到网元配置类型集合。

步骤505，从所述数据库中清除该网元对应的所有约束关系数据。

步骤506，根据所述网元配置类型集合，获取该网元的所有网元配置项。

步骤507，依次遍历该网元所注册的约束规则检查器，利用约束规则检查器对每个网元配置项执行变更消息类型为增加配置的约束检查方法。

步骤508，对于非值域约束类型的约束规则检查器，执行约束检查方法后在所述数据库中更新相关的约束关系数据。

步骤509，如果约束检查过程中发现存在约束检查冲突，则生成一个约束冲突摘要并存储到所述数据库中，以供用户后续查看。

步骤510，判断所有网元是否执行重建约束完毕；如果全部执行完毕，则至此流程结束，否则跳转至步骤504继续执行，直至所有网元均执行重建约束。

通过本发明实施例提供的上述方法，当网络设备管理***中导入新配置或者网元业务模型有更新时，可通过增量式约束检查的方式进行重建约束，使得约束检查可以增量式进行，工程升级更便捷。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种网元配置约束检查方法，其特征在于，包括：

加载约束检查管理器和约束规则检查器；其中，不同网元类型对应不同的约束检查管理器，每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个约束规则检查器；

接收网元配置的变更消息后确定变更消息类型，并通过分析网元配置数据得到网元类型和网元配置类型；

根据网元类型查找对应的约束检查管理器，并根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合；

所述约束规则检查器集合中的每个约束规则检查器均根据对应的约束类型和变更消息类型进行相应约束检查，并将约束检查结果上报客户端，其中，所述约束类型包括主外键约束，主外键约束用于对网管操作的先后顺序进行约束检查，其中，如果约束规则检查器对应的约束类型为值域约束，则根据网元配置的变更消息类型执行相应的约束检查方法，并得到相应的约束检查结果，以便于判断数据是否符合取值范围或检查操作是否被允许，所述变更消息类型包括增加、删除、修改、激活和去激活中的一项或多项，如果约束规则检查器对应的约束类型为非值域约束，则根据网元配置数据计算约束Key信息，根据所述约束Key信息从数据库中查找对应的约束关系数据，然后根据网元配置的变更消息类型以及查找到的约束关系数据执行相应的约束检查方法，并得到相应的约束检查结果，其中，配置数据在进行增加、删除操作时会动态计算当前该类配置的总数，并将这种约束关系数据存储在数据库中，以用于后续规格约束检查。

2.如权利要求1所述的网元配置约束检查方法，其特征在于，在所述加载约束检查管理器和约束规则检查器之前，所述方法还包括：

根据功能需求定义不同的约束类型并抽象，所述约束类型包括值域约束、唯一性约束、主外键约束和规格约束中的一项或多项；其中：

所述值域约束用于对当前的网元配置数据合法性进行约束检查；

所述唯一性约束对应的约束关系数据存储在数据库中，用于对网元配置唯一性进行约束检查，且对应约束关系数据以Key-Value格式存储；

所述主外键约束对应的约束关系数据存储在数据库中，用于对网管操作的先后顺序进行约束检查，且对应约束关系数据以Key-Value格式存储；

所述规格约束对应的约束关系数据存储在数据库中，用于对网元配置规格进行约束检查；且对应约束关系数据以Key-Value格式存储。

3.如权利要求1所述的网元配置约束检查方法，其特征在于，在所述加载约束检查管理器和约束规则检查器之前，所述方法还包括：

设置规则定义脚本和约束错误码脚本；其中，所述规则定义脚本用于供用户自定义设置规格约束的上限值、是否屏蔽某种约束规则检查器的检查以及是否开启重建约束功能，所述约束错误码脚本用于定义约束检查错误码信息模板。

4.如权利要求1所述的网元配置约束检查方法，其特征在于，对于值域约束，在所述根据网元配置的变更消息类型执行相应的约束检查方法过程中，所述方法还包括：

如果约束检查存在冲突，则以网元配置数据作为参数格式化约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果；其中，所述约束检查错误码信息模板通过约束错误码脚本来定义。

5.如权利要求1所述的网元配置约束检查方法，其特征在于，对于非值域约束，在所述根据网元配置的变更消息类型以及查找到的约束关系数据执行相应的约束检查方法过程中，所述方法还包括：

如果约束检查存在冲突，则以网元配置数据作为参数格式化约束检查错误码信息模板，并将格式化后的错误码信息保存下来作为约束检查结果；如果约束检查不存在冲突，则更新对应的约束关系数据并存入所述数据库；其中，所述约束检查错误码信息模板通过约束错误码脚本来定义。

6.如权利要求2所述的网元配置约束检查方法，其特征在于，当网络设备管理***中导入新配置或者网元业务模型有更新时，进行重建约束，具体为：清除所述数据库中当前的约束关系数据，重新对当前的网元配置执行一次约束检查，并生成新的约束关系数据存入所述数据库。

7.如权利要求6所述的网元配置约束检查方法，其特征在于，所述清除所述数据库中当前的约束关系数据，重新对当前的网元配置执行一次约束检查，并生成新的约束关系数据存入所述数据库，具体包括：

对于每个网元，根据网元类型从对应的约束检查管理器中查找已注册约束规则检查器的网元配置类型集合，并从所述数据库中清除该网元对应的约束关系数据；

根据所述网元配置类型集合获取该网元的每个网元配置项，并利用该网元所注册的约束规则检查器，依次对每个网元配置项执行变更消息类型为增加配置的约束检查方法；

对于约束类型为非值域约束的约束规则检查器，在执行约束检查方法后更新对应的约束关系数据，并将新的约束关系数据存入所述数据库；

其中，如果约束检查过程中发现存在约束检查冲突，则生成一个约束冲突摘要并存储到所述数据库中。

8.一种网元配置约束检查***，其特征在于，包括约束检查框架、存储器和处理器；其中，所述约束检查框架包括约束检查接口、约束检查管理器、约束规则检查器和数据库；

所述约束检查接口用于接收网元配置的变更消息，触发约束检查；

所述约束检查管理器设置一个或多个，分别对应不同网元类型，且每个约束检查管理器根据功能需求对不同网元配置类型分别注册多个不同的约束规则检查器；

所述约束规则检查器用于根据对应的约束类型和变更消息类型，执行相应的约束检查方法，并将得到的约束检查结果上报客户端；

所述数据库用于保存约束关系数据，并供所述约束规则检查器使用；

所述存储器用于存储可被所述处理器执行的指令，所述指令在被所述处理器执行后，用于通过分析网元配置数据得到网元类型和网元配置类型，并根据网元类型查找对应的约束检查管理器，根据网元配置类型从对应的约束检查管理器中获取相关的约束规则检查器集合，完成权利要求1-7中任一项提供的网元配置约束检查方法。

9.如权利要求8所述的网元配置约束检查***，其特征在于，所述约束检查框架还包括约束脚本仓库和脚本解析器；

所述约束脚本仓库用于存储规则定义脚本和约束错误码脚本；

所述脚本解析器用于对所述约束脚本仓库中存储的规则定义脚本和约束错误码脚本进行解析，并供所述约束检查管理器使用；

其中，所述规则定义脚本用于供用户自定义设置规格约束的上限值、是否屏蔽某种约束规则检查器的检查以及是否开启重建约束功能；所述约束错误码脚本用于定义约束检查错误码信息模板。

Images