Creating a Custom Administration Setting

Introduction

Most of our ISV Partners will need to provide some custom administration settings to allow their customers to configure the partners’ solutions. For example, you may want to store a server name and database name to connect to as part of a workflow and then access that information at the time the workflow runs. As a partner you would want to make it easy for your customers to edit this configuration and do so in a way that is consistent with the rest of the Service Manager product.

The Settings view in the Administration workspace is the “catch all” view for Service Manager administrators to view these kinds of settings. Out of the box, we put things like grooming settings, incident management settings like the Target Time to Resolution settings, and many others in this view.

The question is – “How do I add my own custom settings to this view and provide a user experience for administrators to get/set these settings?”

Starting with the End in Mind

This is what we are trying to achieve:

A row in the Settings view that the user can either select and click Properties for in the task pane or can double click on

When the user clicks Properties or double clicks a custom form pops up to capture the user input in the Service Manager database

The data is stored as properties of an object so that it is easy to access and store

This is what the user experience looks like:

When the user double-clicks or clicks Properties:

Implementation

First we need to create a management pack with our new Admin Setting class in it. If we derive from System.SolutionSettings our item will automatically show up in the Settings view. Further, since we aren’t going to be creating multiple instances of this class we should set it to Singleton=”true”. For this demo, I’m adding a couple of basic properties creatively named Property1 and Property2.

<ClassTypeID=“Microsoft.Demo.AdminSetting.Example“

Accessibility=“Public“

Abstract=“false“

Base=“AdminItem.Library!System.SolutionSettings“

Hosted=“false“

Singleton=“true“

Extension=“false“>

<PropertyID=“Property1“

Type=“string“

AutoIncrement=“false“

Key=“false“

CaseSensitive=“false“

MaxLength=“256“

MinLength=“0“

Required=“false“

/>

<PropertyID=“Property2“

Type=“string“

AutoIncrement=“false“Key=“false“

CaseSensitive=“false“

MaxLength=“256“

MinLength=“0“

Required=“false“

/>

</ClassType>

Then we need to define a console task handler so that when the user clicks the Properties link in the task pane our form will come up. Notice how the task is targeted at our singleton class. It will call the class in the referenced assembly which I’ll show you in a minute.

The first one tells Service Manager that when the singleton class object is selected in the Settings view that the doubleclick task is the one defined in this management pack.

The second one tells Service Manager that this is an MP intended to be used in Service Manager. This is necessary to make sure that the console task shows up in the Service Manager console.

Then of course we add the usaul Language Pack stuff. I won’t go over that again, but remember there is more information on localizing management packs if you need it.

That’s it for the management pack. Now let’s take a look at the form – it’s really easy. All I did was add a new WPF User Control to my project and then changed it to derive from wpfwiz:WizardRegularPageBase.

There is a very small amount of code behind that we need to put into the .cs file that is associated with this .xaml file. You’ll see that this implementation is very similar to the task handler provided in the CSV Connector example. We are using the same concept of a “Wizard” in property page mode to display the UI to get/set the property values.

This code simply binds the WizardData object to the form as part of the constructor. Now let’s look at the task handler code and associated WizardData class. The only tricky/new part of this is highlighted below in the code comments.

Deploying this Solution

In order to deploy this solution you need to import the management pack .xml file and copy the AdminSettingsExample.dll file to the %ProgramFiles%\Microsoft System Center\Service Manager 2010 directoy on all computers that will be accessing this form. That .dll contains the task handler code and the XAML form.

Join the conversation

I dont know that we have a event handler for the Next button click event. Instead we try to proactively validate the form as the user is filling it out. You can hook various other events on the form and perform a validation. When the form meets your business logic, then you can change .IsNextButtonEnabled = true.

Hi German – sorry for the delayed response. I'm on week 4 of a 4 week world tour for SCSM now and it's been hard to keep up. It's probably not necessary to write cod to have a settings dialog, but it is an option. Please send me an email at scsmbeta [at] live [dot] com with some more details on what you are trying to do and I'll try to make a recommendation.

I'm creating a wizard consisting of multiple custom forms which is feasible thanks to your above instruction. When navigating from one form to another within the wizard using built-in Next buttons of the wizard, I'm struggling to find the events when these buttons are clicked so that I can validate the data of previous forms to meet business rules

Please help with details on how I can capture the event when Next/Previous button is clicked