First published on TECHNET on Apr 23, 2008
Most MPs have one or more scripts which are used for a variety of things, discovery state monitoring, perf data creation, etc… In a lot of cases the majority of the script code is common to all the scripts in the MP, logging, connecting to a particular service (i.e. WMI), Error handling, etc… Typically this code is simply copied and pasted into every script in the MP, this means that it has to be maintained separately for every script in the MP, so if a bug is found in common script code it must be fixed in all places. This also makes the relatively simple functionality of the script much harder to read as the common script code usually dwarves the implementation.
Given this it would obviously be advantageous to have a repository of common script functions and simply call those functions from the implementation script. OpsMgr 2007 has a built in solution in Composite Module types which can be used to do exactly this with some limitations. A composite module is a new module type which is composed of one or more other modules. The composition has the ability to directly implement some of the configuration of the module or modules it is composed of and combine that with other configuration provided to the module on use. In other words it is sort of built for this purpose.
To use a composite module to contain common script functions you must make two choices. First which type of output your script will create, this will determine which ‘base’ module type to use in your composite (see below). This also means that if you wanted to use a script for both PropertyBag and DiscoveryData then you need to create two base composites.
PropertyBag -> Microsoft.Windows.ScriptPropertyBagProbe
DiscoveryData -> Microsoft.Windows.ScriptDiscoveryProbe
CommandOutput -> Microsoft.Windows.ScriptProbeAction
Then you must choose which language your want to use for your scripts: vbscript, jscript, etc… This obviously determines which script language your common functions should be written in. After you make these choices you can create a base composite module in your MP which implements all of your common script functions (also see attached mp for a working example):
<ProbeActionModuleType ID="ScriptBase" Accessibility="Public">
…
<ModuleImplementation>
<Composite>
<MemberModules>
<ProbeAction TypeID="<Base Script Composite Type goes here>" ID="SPA">
…
<ScriptBody>
<![CDATA[
' -----------------------------------------
' Common Script Header stuff (const, etc…)
' -----------------------------------------
' ----------------------------------------------------------------------------------------
' The script implementation will be placed here, this implementation is provided
' by each script composite module built on the ScriptBase module. This implementation
' can safely use the utility functions provided below without implmenting them.
' ----------------------------------------------------------------------------------------
$Config/ScriptBody$
' -------------------------
' Utility functions go here
' -------------------------
]]>
</ScriptBody>
…
</ProbeAction>
</MemberModules>
<Composition>
<Node ID="SPA" />
</Composition>
</Composite>
</ModuleImplementation>
…
</ProbeActionModuleType>
This allows a ‘child’ composite module to specialize the Main block of script code (see attached mp for a working example).
<ProbeActionModuleType ID="ScriptImpl" Accessibility="Public">
…
<ModuleImplementation>
<Composite>
<MemberModules>
<ProbeAction TypeID="ScriptBase" ID="SPA">
…
<ScriptBody>
<![CDATA[
' ---------------------------------------
' Main script block here
' ---------------------------------------
]]>
</ScriptBody>
…
</ProbeAction>
</MemberModules>
<Composition>
<Node ID="SPA" />
</Composition>
</Composite>
</ModuleImplementation>
…
</ProbeActionModuleType>
Script.Composite.Functions.xml
