This is a continuation of the ‘The System Center Platform in Service Manager’ series. Previous posts:
The System Center Platform in Service Manager Part 1: Introduction
The System Center Platform in Service Manager Part 2: The Model-Based Database
From time to time in this series, I will post a ‘Try it!’ post where I explain how you can try out some of the platform capabilities I’m describing in this series.
Today I’ll describe how to use a management pack to extend the model-based database in Service Manager and you can try it yourself by creating the management pack XML file and importing it into Service Manager.
First, open your favorite XML editor like Visual Studio or notepad. Either type in or copy/paste this XML and save the file as “Woodgrove.CI.xml”.
<ManagementPack ContentReadable=" true " SchemaVersion=" 1.1 "
xmlns:xsd=" http://www.w3.org/2001/XMLSchema "
xmlns:xsl=" http://www.w3.org/1999/XSL/Transform ">
<Manifest>
<Identity>
<ID> Woodgrove.CI </ID>
<Version> 1.0.0.0 </Version>
</Identity>
<Name> Woodgrove Configuration Items </Name>
<References>
<Reference Alias=" System ">
<ID> System.Library </ID>
<Version> 1.0.3113.0 </Version>
<PublicKeyToken> 31bf3856ad364e35 </PublicKeyToken>
</Reference>
</References>
</Manifest>
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID=" Woodgrove.CI.Projector " Accessibility=" Public " Abstract=" false " Base=" System!System.ConfigItem ">
<Property ID=" SerialNumber " Type=" string " Key=" true " CaseSensitive=" false " MaxLength=" 256 " MinLength=" 0 " Required=" true " />
<Property ID=" Manufacturer " Type=" string " MaxLength=" 256 " MinLength=" 0 " Required=" false " />
<Property ID=" Model " Type=" string " MaxLength=" 256 " MinLength=" 0 " Required=" false " />
<Property ID=" PurchaseDate " Type=" datetime " Required=" true " />
</ClassType>
</ClassTypes>
</EntityTypes>
</TypeDefinitions>
</ManagementPack>
A few notes about the XML above:
· Note that Management Packs that are written for System Center Service Manager can take advantage of the new version of the Management Pack schema (version 1.1) but you can still import older management packs (version 1.0). More info on the additions to the schema from version 1.0 to 1.1 can be found in the product documentation provided with each release of the product including Beta 1.
· The management pack file name must be exactly the same as the /ManagementPack/Manifest/Identity/ID element value (in this example “Woodgrove.CI”)
· A Reference here declares a dependency between management packs. In this case we need to reference the System.Library management pack because it contains the System.ConfigItem class that we are deriving our Woodgrove.CI.Projector class from. If the System Library MP version 1.0.3113.0 (or higher) is not present when you try to import this MP the MP validation will fail. This ensures compatibility between dependent management packs. Note 1.0.3113.0 is the version number for Beta 1.
· When creating a reference to a dependent management pack you can declare an “alias” which is a shortcut way to refer to the management pack. See how the “System” alias is used later on down in the Base attribute on the ClassType element – Base=”System!System.ConfigItem” ? That is the hint to the platform that the System.ConfigItem class is actually declared in the referenced management pack with the alias “System”.
· The PublicKeyToken is always the same for Microsoft produced publicly released signed builds - 31bf3856ad364e35. Anytime you reference a Microsoft publicly released signed build you should use this PublicKeyToken.
Now we get to the interesting part – declaring our new configuration item class. This is done in the TypeDefinitinos/EntityTypes/ClassTypes section of a management pack. To declare a new class you need to provide the following:
· A unique ID for the class – in this case ‘Woodgrove.CI.Projector’
· Accessibility – Public or Internal. This determines whether or not other management packs can derive from your class. Public = Yes, you can derive. Internal = No, you cannot derive.
· Abstract – false or true. This determines whether or not there will be specific instances of this class created in the database or not. False = Yes, there will be instances. True = No, there will not be instances.
· Base defines the class from which you are deriving from. In this case since a Projector is a kind of configuration item we can derive from System.ConfigItem which is located in the System.Library MP (as pointed out earlier)
Next we need to define each property of the class. We need to have at least one “key” property which will be unique for each instance of that class. In this case the serial number property is the key property because it has Key=”true” declared on it. Each property must also have a declared data type such as “string” or “datetime”. You can also declare certain data validation rules such as required or not, min/max length, and min/max value.
Now that you have saved the MP as a .xml file you are ready to import it into the system. Everybody knows how to do this using the console so I’ll show you a cool new way to import MPs.
1. Copy your .xml file to your Service Manager management server (where the SDK service is installed)
2. On the Service Manager management server open a PowerShell window.
3. Enter the command Add-PSSnapin SMCmdletSnapin
4. Enter the command: Import-SCSMManagementPack <path to the file Woodgrove.CI.xml and hit enter>
5. Your MP should validate and import! If you get an mp import error, please put the text of your MP file in a comment and I’ll take a look.
Now if you open the Service Manager console you should see your MP in the Management Packs view.
When your MP was imported, the database schema was automatically extended to support storing and updating instances of your new class. If you were to open SQL Server Management Studio and browse the ‘ServiceManager’ (called ‘SMDB’ in Beta 1) database, you would see that there are two new tables:
The dbo.MT_Woodgrove$CIProjector table is where the instances of the new Projector class will be stored.
The dbo.MT_Woodgrove$CI$Projector_Log table is where this history of changes to properties of the projectors will be stored automatically.
This is what the table looks like:
The GUIDs are appended to each of the properties to ensure uniqueness. Service Manager also automatically creates a view to create, get, and update projectors.
While this may seem pretty simple (I hope!) as I’ve described it here, we will be making this even easier! More details on an MP authoring console will be coming out at the Microsoft Management Summit (end of April ’09).
Now that the database schema has been extended and a database view has automatically been created, you are ready to create new projectors and update them using the user interface or the API layer directly. More on the API layer in the next post ….