Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Operations Manager i10.62

Administer > RTSM > RTSM Modeling > Modeling > CI Type Manager > CI Type Attributes

CI Type Attributes

Every CI type has attributes which define it, such as name, description, and default value. The CITs grouped under other CITs in the CI Type tree inherit attributes from the higher-level CITs.

When you define a new CI type, you first select a Base Configuration Item Type from a list of existing CITs. Your new CIT inherits the attributes of the existing CIT. You can then set the attributes for the new CIT. You edit the attributes of an existing CIT by selecting a CIT from the tree in the CI Types pane and selecting the Attributes tab of the topology map. For details on CIT attributes, see Attributes Page.

CI Type Identification Methods

Every CI created is given an automatically generated global ID, which is used to distinguish different instances of the same CI type. RTSM provides identification methods which enable you to set conditions under which two CI instances are defined as identical, and are consequently merged into a single instance. For example, the By key attributes method involves defining CIs with certain matching attributes to be identical. You can also select additional identification methods as described in Details Page.

If you select the By key attributes option, you can designate one or more of the CIT's attributes as key attributes, which are used as identifiers of the CIT. When you define an instance of a CIT, the CIT's key attributes are mandatory fields for CIs of that type. You can assign as many key attributes as you want to a given CIT. If you do not assign a key attribute when defining a new CIT or changing the identification method of an existing CIT to By key attributes, you must select the ABSTRACT_CLASS qualifier on the Qualifier page of the wizard.

You can change or remove the key attributes of an existing CIT if the key attribute values for all instances of that CIT are unique. Similarly, you can change the identification method to By key attributes only if the key attribute values for all instances of that CIT are unique. If the selected changes result in multiple instances of a CIT with identical key attribute values, an error message indicates that the action is not permitted, as the CIT instances would be merged.

If you select other identification methods, you cannot define key attributes for the CIT, but it retains the key attributes of its parent CIT. These key attributes are mandatory fields for CIs of that type and they should not be removed. For those identification methods, there are no restrictions on the qualifiers selected.

Note If the child classes should not use the key attributes defined by the parent classes, this can be achieved by overriding the attribute for the child class.

Here is an example:

Suppose for class Load Balancing Cluster a new key attribute (ID_ATTRIBUTE) with attribute name description is added. Then, for class Load Balancing Cluster the following attribute override is added. This can be seen in JMX console, listResources and enter CM_CLASS, and then select loadbalancecluster.

<Attribute-Override is-partially-override="true" name="description " is-factory="false">
    <Attribute-Qualifiers>
        <Attribute-Qualifier name="ID_ATTRIBUTE" is-factory="false">
            <Data-Items/>
        </Attribute-Qualifier>
        <Attribute-Qualifier name="INDEX" is-factory="false">
            <Data-Items/>
        </Attribute-Qualifier>
    </Attribute-Qualifiers>
</Attribute-Override>

Class MS NLB Cluster is a subclass of Load Balancing Cluster and will inherit description attribute as being a key attribute.

If the identification rule for class MS NLB Cluster should not contain the description attribute, then a new override should be done (but not partially).

To achieve this, the class definition of MS NLB Cluster should be open from JMX console:

On the UCMDB Server, go to JMX Console > UCMDB:service=URM Services > listResources.
Enter customer ID. (Default: 1)
In the value field, enter CM_CLASS and click Invoke.
On the returned result page, locate and select ms_nlb_cluster.

In the Resource XML text box, locate the <Attribute-Overrides> section and enter the following:

<Attribute-Override name="description " is-factory="false">
    <Attribute-Qualifiers>
        <Attribute-Qualifier name="INDEX" is-factory="false">
            <Data-Items/>
        </Attribute-Qualifier>
    </Attribute-Qualifiers>
</Attribute-Override>

Click the Save resource button.

Then after server restart, class MS NLB Cluster will not have description attribute as being a key attribute. This can be seen from the CI Type Manager module on the Details tab for the MS NLB Cluster class. In a similar way this can be achieved for other classes where the key attribute qualifier should not be inherited.

Identification is also relevant for CIs of sibling CI types, if at least one of the CI types inherits its identification method from the common ancestor CIT. For example, the CI types Router and Switch Router are sibling CI types, descendants of the ancestor CIT Node. If at least one of them has Inherited from parent as the identification method, then CIs of the two types could be merged if the identification criteria are met. In such a case, the CI type of the merged CI is that of the sibling that was most recently updated. If one of the CIs had attributes that do not exist in the CI type of the merged CI, they are filtered out of the merged CI.

CI Type Naming

Entity names in HPE Business Service Management for RTSM-based applications follow the conventions described below:

CIT attributes values. All primitive types are supported: long, double, float, string, and so on.
CIT attributes values-type string. All special characters are supported. The maximum length is 4000 characters.
CIT name. Only the following characters are permitted: a-z, A-Z, 0-9 and underscore (_). Note also:
- The first character must not be a number.
- The name field is case sensitive, but you cannot use the same name with different cases for different CITs.
- The maximum length is 200 characters.
CIT attribute name. Only the following characters are permitted: a-z, A-Z, 0-9 and underscore (_). Note also:
- The first character may be a number.
- The attribute name field is not case sensitive.
- The maximum length is 200 characters.
CIT attribute length. The total length of all the attribute values in one CIT cannot exceed 8K bytes due to a Microsoft SQL Server limitation. This limitation is relaxed under certain circumstances. For details, see http://msdn.microsoft.com/en-us/library/ms186981.aspx.

Related Information

Send Help Center feedback