Getting Started with the Service Manager SDK

The Service Manager public API is partitioned into several assemblies all of which can by found either in the GAC after install or in the Program Files folder in "SDK Binaries". The primary assembly is Microsoft.EnterpriseManagement.Core (Core) which replaces Microsoft.EnterpriseManagement.Common from Operations Manager 2007. Core also contains a lot of the functionality from the Microsoft.EnterpriseManagement.OperationsManager (OM) assembly that shipped with Operations Manager 2007. The OM assembly still exists, but contains only Operations Manager specific functionality. Service Manager also has a couple other assemblies with Service Manager and Data Warehouse functionality. The following table describes the relationships between Service Manager and Operations Manager assemblies.

Service Manager Operations Manager 2007
Microsoft.EnterpriseManagement.Core Microsoft.EnterpriseManagement.Common and Microsoft.EnterpriseManagement.OperationsManager
Microsoft.EnterpriseManagement.ServiceManager (SM) None
Microsoft.EnterpriseManagement.OperationsManager Microsoft.EnterpriseManagement.OperationsManager
Microsoft.EnterpriseManagement.DataWarehouse (DW) None

The refractoring of the Operations Manager assemblies was done to enable a better story for sharing functionality across the products. Core is delivered by the Service Manager team and provides the fundamental services that System Center products built on top of the OM CMDB share. Core contains the majority of the instance space functionality, all of the management pack infrastructure and other common features across the products. SM contains functionality on the Service Manager product needs while OM is for Operations Manager only. In Beta 1 Service Manager still uses the OM assembly as we haven't completely refractored everything as necessary. The DW assembly contains new data warehouse specific functionality; this is functionality specific to the new Service Manager based data warehouse and not the old Operations Manager data warehouse functionality, which can still be found in the OM assembly.

In order to get started, you need to link at the very least against the Core assembly. Once you do that, the following code will establish a connection to the locally installed SDK service:

 using System;
using Microsoft.EnterpriseManagement;

namespace Jakub_WorkSamples
{
    partial class Program
    {
        static void Connect()
        {
            // Connect to the local management group
            EnterpriseManagementGroup localManagementGroup = new EnterpriseManagementGroup("localhost");
        }
    }
}

You'll notice this part is almost identical to the Operations Manager. Once the connection is established, you can begin playing around with the various services provided by EnterpriseManagementGroup. Previously most functionality was actually directly on EnterpriseManagementGroup and while it is all still there (on ManagementGroup, derived from EnterpriseManagementGroup) , it is marked as obsolete as we are using a new paradigm for providing access to various features of the API. The new mechanism for accessing various parts of the API is centered around services (namely interfaces) exposed via properties on the EnterpriseManagementGroup object. You'll notice, for example, a property called Instances. This provides access to a variety of methods that deal with instance space access. A quick sample follows:

 using System;
using Microsoft.EnterpriseManagement;
using Microsoft.EnterpriseManagement.Common;

namespace Jakub_WorkSamples
{
    partial class Program
    {
        static void GetInstance()
        {
            // Connect to the local management group
            EnterpriseManagementGroup localManagementGroup = new EnterpriseManagementGroup("localhost");

            // Get an instance by Id (need to replace with valid Id of an instance)
            EnterpriseManagementObject instance = 
                  localManagementGroup.Instances.GetObject<EnterpriseManagementObject>(Guid.NewGuid(), ObjectQueryOptions.Default);
        }
    }
}

Over time I'll be talking about the various interfaces and the specific functionality they provide and be talking much more about the Instances interface which introduces significant new functionality from the equivalent OM objects (MonitoringObject).

This model of partitioning is used in all the assemblies and allows us to better group and share functionality across products. We're definitely still open to feedback on how to better partition our services; our goal is to group common functionality together such that most tasks would be done by using one or two services.

Also, a couple things to note. First, this is Beta 1 and there will be changes moving forward. The Instances API in particular will undergo a significant facelift as we are added buffered read support for instances. We are also cleaning up the interfaces and trying to remove unnecessary overloads as much as possible.