前面一篇文章说到为了省事，而且在Authoring guide中的workflow composite 里就说，为了让效率更高，最好让脚本支持Cookdown.然后我的脚本就返回多个Property bags.
为了支持cookdown,我设计了一个自定义datasource,定义如下，简单的来说就是定期执行前面文章中说到的powershell 脚本，这个脚本输出多个Property bags ，为了复用module,我加了一个conditionDetection,使用正则表达式对property bag 进行过滤，这样只需要简单的过滤特定属性，就可以监控不同的属性值。
直接上图吧。DS定义
下面是Monitor配置，鉴于以上DS的设计，我可以使用VSAE中的Snippet Template 很快生成多个Monitor
我的Monitor type 定义
Snippet Data
生成的Monitor 的XML代码之一。
其实以上的DS设计时使用MatchedWildCard可以使用通配符匹配有另外一个私心的。因为我了解到System.Performance.DataGenericMapper支持把多个Property Bags 一次性转换成多个Performance data,所以我的这个Datasource 如果在对属性进行比较时，输入*，那么返回的就是所有监控的属性的值，然后通过一个System.Performance.DataGenericMapper 全部转成perf data,然后一个rule 就可以直接写入DB，DWDB。想法是好的，代码能编译，导入MP后也不出错。
但是当我使用performance widget 时，只看到一个性能计数器的选项。我可是有8个计数器的。
查了下搜索引擎，说perf Widget 使用的数据是DWDB里面的，我看看有没有数据。
性能数据写入DWDB时，CounterName全变成一样了，但是Value正确。我以Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData batching 为关键字进行搜索，找到下面这么一个链接。
多年巨坑依旧。
SCOM Console里的perf view数据使用的是OperationMangerDB中的数据，而Perf Widget 使用的OperationmangerDWDB中的数据，而Microsoft.SystemCenter.CollectPerformanceData写入OperationMangerDB的时候支持一次性写入多个perf data,而Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData写入OperationmangerDWDB却不支持。
我原来的rule 写成这样，看来要拆成多个了。
好在DS当时设计的比较好，拆不是问题。使用snippet template 很快可以搞定。
这样很快就生成8个Rule。
