configitem

普通配置的维护，可通过配置文件和数据库的初始化脚本配置完成，具体做法见案例。

A.     列表配置

列表配置的维护及优化，已在5.5版本实现。

与普通配置项的差异在于在page_template.xml中添加标示

 

再新建对应的jsp文件，对点击添加按钮时，根据page_template.xml中配置列表的数据动态生成列表在页面展示，并且控制列表个数，添加、删除等操作。

B.     双机浮动IP的修改(连接的外部地址)

请先完成自动配置()

--

双机浮动IP配置的修改，如：ES的双机浮动IP及DP的双机浮动IP的维护。

 

这两组配置的维护是特殊处理，通过硬性的jsp绘制页面包含在通用的jsp中实现。所属的主机需获取对应ES或DP所在主机的槽位号，再通过判断组网类型获取双机的判别标准判断所有进程是否为双机，双机IP展示在一起，配置的修改需要同时同步给双机。

配置生效时，需要修改对应的配置文件，netmask不存在真实的配置项，需要通过HMA绑定到网卡并重启。

C.    同一个配置,存在于多组中

需要SE下发规格的时候，将同一个配置，需要在不同的所属页面的，标识出来，开发人员在开发的时候，通过技术手段(重命名)规避

 

 

难点在于：1.一个配置的修改未生效，页面需要置灰的控制。2.已修改的配置进行生效，生效失败，修改为未生效，只针对其中一组的配置。

D.    容灾配置

容灾的生效在通用方法的头部就独立调用方法处理了，在通用方法中，只是需要把返回的结果List<T>与普通配置项放在同一个集合，用于页面结果展示。

重构方法：把容灾的业务逻辑通过一个单独的类来处理，处理结果在统一展示的时候，将返回的list添加到统一的集合对象中。

在ATAE2.0组网中

1. 容灾配置的整组配置项是否重启，需要判断开关是否变化，有变化才需要重启MPU mng。
2. 需要下发MPU消息，将容灾开关和容灾率下发给MPU，并解析。
3. 需要下发bakuidb的服务地址给MPU并解析响应。

E.     话单配置

页面逻辑需要控制，后台业务逻辑需要控制

话单配置中，需要获取billwriter和spu的合设情况，根据spu的个数展示可以同步的billwriter的个数，同一个spu的计费和统计不能同步给同一个billwriter；一个BillProcess提供服务的IP地址和端口不能同步给不同的billwriter；不同的BillProcess提供服务的IP地址和端口不能同步给同一个spu的统计或计费话单。

 

生效时不能按照普通配置获取整组，而需要根据页面的选择组建HMA的消息下发给统计话单还是计费话单。

 

F.     BakUIDB容灾配置

页面的绘制需要新增jsp文件，所属主机也需要判断双机部署情况，修改配置后生效只需要修改对应的配置文件，并重启bakuidb进程即可。

G.    关联配置

 

页面展示OCS/BRT计费系统还是Rating计费系统取决于计费系统类型的选择，这能生效一种计费模式下的计费配置。

H.    根据进程的维护情况来确定是否同步配置

ES的双机浮动IP的修改和Rating计费系统配置中，需要根据是否存在于ES合设的Monitor来判别是否同步给Monitor的配置

I.       MPU/LC的AP配置

需要根据MPU和LC的个数来绘制页面的展示，当用户修改AP信息时，需要先删除对应组的AP信息在下发消息添加AP信息，需要直接通过UDP消息直接与MPU交互。

J.      L2Vas配置

可通过列表形式配置配置主用LC的Ap信息，同一组的VLAN不能下发相同的AP信息给LC。

通过UDP消息下发给MPU刷给主用LC，获取响应并解析。

可通过页面点击核查，核查OMC记录的AP信息与已下发生效的AP信息是否有差异，有差异以OMC记录的数据为准，可选择重新下发给LC。

转载于:https://www.cnblogs.com/foxnnn/p/3147127.html