对于原来的云管理业务，离线配置涉及三张数据表t_campus_offlinecfg_offlinemsg(以下简称增量表)、t_campus_offlinecfg_offlinecfg(以下简称全量表)、

t_campus_offlinecfg_devicestate(以下简称状态表)。

增量表中存储的是设备离线配置的时候配置记录（edit-config即带操作符的报文），每一条配置都会存储。

全量表中存储的是每台设备对应的全表报文数据（copy-config即不带操作符的报文），每次配置都会去刷新对应的设备的报文数据，总之一台设备只有一条数据。

状态表记录的是每次设备离线的时候配置的顺序，用于设备上线的时候按照此顺序下发增量表中的报文。

设备第一次上线或者设备重启的时候会将全量表中的报文覆盖设备上的配置。

进入离线配置之后会有一个对于设备是否在线的判断：

无论设备是否在线都会执行saveConfigToDB的方法，区别在于设备离线的时候会另外再去存储一下增量表和状态表。

saveConfigToDB方法的第一步就是将业务传输过来的edit-config报文处理然后存储到全量表中，即执行edit-config操作，执行edit-config的时候，会先从内存中查询是否存在该设备配置，如果不存在那么，就返回一个空的报文结构用于下面的处理流程，如果存在那么需要将原来的报文获取出来进行合并。

[if !supportLists]1. [endif]合并报文操作按照editDom中报文的操作符类型来执行，代码中的规定的顺序是先执行默认replace操作、再执行delete、再执行remove、然后执行replace、接着执行create、再然后执行merge、最后再执行默认的merge操作。

以merge操作为例，如下图，会先找到带merge操作符的节点，按照顺序，首先执行的是qos这个节点，它的父节点是interface，那么就会在srcDom中去寻找是否寻在interface节点，如果存在那么，再判断是否存在qos这个节点，如果存在，那么合入报文失败，抛出异常“Edit-config run failed when merge

config.”,因为如果已经下发了这个配置，业务再次下发还是使用merge操作这就违反了netconf协议；另外一种情况如果interface存在而且qos不存在，那么将这个节点从editDom中合并到srcDom中,同时删除eidtDom中对应的节点。

此处还有一个特殊处理对于嵌套报文，如果说当前这个包含merge操作符的节点在edit-config中如果查找不到父节点和本节点，那么我们就跳过这个节点的合并操作，原因是类似于下图中双层嵌套merge报文，我们先执行qos节点的merge操作，执行完之后，那么在editDom中已经删除了这个节点包括其包含的priority节点，那么当我们执行这个priority节点的时候如果再去执行很显然会报错，导致整个业务报文合并失败，所以我们跳过这个节点的执行，而且不会影响业务，因为在执行qos的时候已经将priority节点成功合入了。

[if !supportLists]1.  [endif] 成功合入报文之后，我们还会将报文中的敏感信息加密，然后再压缩存储到全量表中。然后就是根据设备是否在线来判断是否需要去存储增量表和全量表。有一点需要说明一下，当前离线配置对于设备离线再上线之后，前面也说到了会去下发增量表中的配置数据，所有配置数据都下发完之后，无论下发成功与否，都会去删除增量表中对应的该设备的数据。

[if !supportLists]2.  [endif]  另外离线配置也会接受设备管理组件的通知，一旦设备从控制器删除，离线配置会将这三张表中对应设备的所有数据清空。