Use the following guidelines and best practices when customizing classes.

Naming Conventions for Type Definitions

The Service Manager schema model naming convention is based on Operations Manager 2007 R2 guidance and on .Net namespaces naming convention.

Basic Naming Conventions

The basic naming convention is: CompanyName.TechnologyArea.ProductName.FunctionalityArea.Name where:

  • “Product Name” is optional, use it if the definition is independent of any specific product.

  • “FunctionalityArea” is optional, use it if the definition can apply to different areas.

  • “Name” reflects on the meaning of the class, not on the inheritance hierarchy.

Examples: Microsoft.AD.Printer, Microsoft.Windows.Computer, System.Knowledge.Article, System.WorkItem.Incident, and System.StarRating.Average.

The System Namespace

The “System” namespace refers to definitions that are independent of Microsoft and Windows. This usually applies to the base definitions that either Windows applications or Unix applications need to depend on. These base definitions should be company independent.

Use the following guidelines for the “System” prefix:

  • System.Computer represents any type of computer, and it is not vendor specific.

  • Use the System prefix if you expect others to define schemas on top of that namespace.

  • Note that Microsoft.Windows.Computer does not start with System although most Windows applications (regardless of the vendor that defines it) need to rely on this definition.

Best Practices for Naming Classes

Use the following best practices when naming classes:

  • Do not create two separate classes (even if they are in two different management packs) which would result in identical key values being stored for different objects of the two classes.

  • When extending a class, always ensure that the class extension names are unique across management packs. If possible, use meaningful class extension names.

  • When extending a class, do not define a property with an ID that is already in use in that class.

  • Do not use periods in names of properties of a custom class.

Do Not Create Too Many Classes

Creating too many classes can result in needless complexity with minimal value. A good rule is to use the least number of classes to achieve the desired results. Other than abstract classes, if a class is not going to be the target of any workflow or be used to store data, it probably should not be created. Also, if two classes are similar, consider using a single class for both of them, possibly by using a property that can hold the values for any differences.

Properties that Update Too Frequently

Property values should change rarely after they are first populated. A possible cause for frequent property value changes is a custom connector, or any other customization that programmatically updates the Service Manager database. These scenarios can potentially cause property values to update too frequently, such as every 10-15 minutes or less for a large number of objects.

Such frequent changes to property values might slightly impact performance of workflows, and have other performance impact. This is because the system keeps track of those changes in history and also, depending on the property being changed, it can add a significant amount of data to be processed and stored by the data warehouse.

Do Not Extend an Abstract Class

In System Center Service Manager 2010 you cannot extend an abstract class. If you need to extend an abstract class you can do either of the following:

  • Create a new class with the properties you want to add, and then create a relationship between the new class and the abstract class.

  • Extend each of the relevant concrete classes that derive from the abstract class.

Improve Simple Search for Work Item Classes

When you define a custom class that is derived from the “System.WorkItem” class, it is recommended that you store the “DisplayName” property of that class in the following format: "WorkItem.ID<SPACE>WorkItem.Title".

This improves simple search. Simple search searches only the “DisplayName” property, and by explicitly including the “Title” property value and the “ID” property value in the “DisplayName” property value, the results of simple search are improved. This is because the user can search either by a word in the title or by ID.