挖掘过去
过去经常需要使用的功能之一是能够在设备发现期间将通知配置文件与设备相关联。由于配置文件和条件选项是分开的,因此即使知道它会增加很多价值,我们也无法实现。在旧客户端中,当我们编辑管理-->通知配置文件时,不会看到以前选择的条件选项。仅仅当在设备页面中对其进行编辑时,您才能看到该设备的选定条件选项。
引入API客户端后,我们将配置文件和条件选项结合在一起,但是当用户在设备内部更改条件选项时,它们也具有相同的配置文件名称。即,一个配置文件名称具有多个条件选项。该设计没有帮助实现所需的功能“在发现过程中自动将通知配置文件分配给设备”,因为同一配置文件有多个标准选项集。
因此,唯一的选择是将通知配置文件绑定到一组条件选项。我们在11600版本中的一个合并API客户端修复补丁中引入了这一点。那些在设备级别对标准选项做了许多更改的用户开始在管理页面中看到数百个配置文件。这是因为每个集合(配置文件名称标准选项)都被视为一个单独的概要文件,导致他们很难管理。因此我们在12200版本中对此进行了不同的处理,它不会在设置页面中列出数百个配置文件。
12200版本的新设计:
1)如果将具有一组标准选项的全局通知配置文件分配给一个或多个设备,则升级后在“全局配置文件”下将只有一个条目。
2)在11600或更早的版本中,分配了通知配置文件后,如果用户对单个设备的标准选项进行了更改,则将其视为单独的配置文件。由于该条件选项特定于该设备,因此将在“设备特定的配置文件”下列出。
3)在11600或更早版本中,如果配置文件被编辑并应用到具有不同条件选项的多组设备,则每个组将具有一个单独的配置文件名称,并将它们列在全局配置文件下。通过点击“编辑名称”选项,只能手动更改这些配置文件的名称。
之后使用发现规则引擎,用户可以在发现过程中将通知配置文件自动关联到设备。