Automatically creating group hierarchies

Infrastructure Management lets you create and define group hierarchies. You can automatically create groups and group membership based on attributes present in the BMC_ComputerSystem configuration item (CI) published from BMC Atrium CMDB. This enables you to dynamically respond to changes in the foundational data in BMC Atrium CMDB and eliminates the need to maintain groups and group memberships manually in Infrastructure Management. 

You can view the new group hierarchy in the operator console (Global > Groups). The groups that are automatically created using the blueprint file are visible to all users, but access to devices is controlled by the CI-based access control mechanism.

You can decide the type of device for which groups must be automatically created from the bppm.dynamicgroup.include.devicetype entry in the pw/pronto/conf/pronet.conf file. At present, the the bppm.dynamicgroup.include.devicetype entry supports the following values:

  • CMDB - CMDB is the default value. When set to CMDB, only those devices synchronized from BMC Atrium CMDB are considered for the automatic group creation.
  • ALL - When set to ALL, all devices whose information is available to the cell from device discovery, are considered for automatic group creation.
  • NONE - When set to NONE, no device is considered and groups are not created automatically.

You must restart the BMC TrueSight Infrastructure Management Server after changing the bppm.dynamicgroup.include.devicetype property.

You can also create groups manually using the administrator console.

Creating groups using a blueprint

You can create and define groups by using an XML-based blueprint file. A sample blueprint file is located in the pw/pronto/conf directory. You can use this sample file to create your own XML file. You must first create the blueprint file, save it in your system, and then import it into your Infrastructure Management environment through CLI commands.

Use case 1

The following figure depicts the grouping hierarchy for the BMC Software Global group, and within the group shows the devices discovered for the Boston Support Center group. BMC Software Global is an entity that supports three locales: Americas, Asia Pacific, Europe. Each locale has different countries under it, and each country in turn has support centers operating in various cities.

Sample blueprint file

The following is a sample of the blueprint file that must be created to achieve the grouping structure shown in the preceding figure.

<?xml version="1.0" ?> 

<blueprint name="BMC Software Global" type="dynamic-group" version="1">

 <group group-name-policy="use-slot-val" slot-name="Region">

   <group group-name-policy="use-slot-val" slot-name="SiteGroup">

     <group group-name-policy="use-slot-val" slot-name="CityName">

        <group group-name-policy="use-slot-val" slot-name="Site" /> 

         </group>

      </group>

     </group>

   </group>

 </blueprint>

Use case 2

Mix Technologies wants to create groups based on domains, administrators, location, and operating systems. Mix Technologies has two administrators (John and Tom), three domains, two locations, and three types of operating systems. The following is a tabular representation of the USight business structure. Mix Technologies wants to John and Tom to be able to support any domain from any location on any OS.

CI
Domain
Location
OS
Function
CI1mixenterprise.comDallasLinuxOracle
CI2mixenterprise.comDallasWindowsOracle
CI3mixsupply.comHoustonLinuxOracle
CI4mixsupply.comHoustonWindowsOracle
CI5mixsupply.comHoustonSolarisOracle
CI6mixservice.comDallasWindowsOracle

Sample blueprint file

The following is a sample of the blueprint file that Mix Technologies needs to modify to create groups based on domains, administrators, location, and operating systems. Creating this file will enable Mix Technologies to support the tabular structure depicted in the preceding section.

<?xml version="1.0" ?> 

<blueprint name="Mix Technologies" type="dynamic-group" version="1">
 
  <group group-name-policy="map-slot-val" slot-name="Domain">
 
    <slot-val-group-name-map use-slot-val-if-not-found="true">
 
       <map slot-val="mixenterprise.com" group-name="USight1"/>
 
       <map slot-val="mixsupply.com" group-name="USight2"/>
 
    </slot-val-group-name-map>
 
    <group group-name-policy="use-slot-val" slot-name="Location">

      <group  group-name-policy="use-slot-val" slot-name="Function">

         <group group-name-policy="map-slot-val" slot-name="OS">   
 
            <slot-val-group-name-map use-slot-val-if-not-found="false" create-others-group="true">
                                            
               <map slot-val="Windows" group-name="Win-Group"/>
                                                
               <map slot-val="Linux" group-name="Linux-Group"/>
                                         
            </slot-val-group-name-map>
 
         </group>
 
       </group>   
 
      </group>
      
  </group>
 
<group group-name-policy="use-slot-val" slot-name="Department">
 
            ........
 
            ........
</group>
 
</blueprint >

Output of the sample blueprint file

The following figure depicts the output of the how the groups are organized based on the groupings defined in the sample blueprint file for Mix Technologies.

Mix Technologies (The blueprint name itself is used to create the root node for the group to avoid issues with conflicting blueprint definitions)
   | 
   |---  John
   |        |
   |        |---------  Mix Technologies 1 (Mapped value for mixenterprise.com) 
   |        |                       |---------- Dallas
   |        |                                               |---------  Oracle
   |        |                                                                       |---------  Linux-Group   (CI1)
   |        |                                                                       |---------  Win-Group     (CI2)
   |        |---------- Mix Technologies 2 (Mapped value for mixsupply.com)
   |                                |-----------Texas
   |                                                       |-----------Oracle
   |                                                                                |---------  Linux-Group (Mapped value for Linux) (CI3)
   |                                                                                |---------  Win-Group (Mapped value for Windows) (CI4)
   |                                                                                |---------  Others    (When slot value mapping not found and use-slot-val-if-not-found != true, device is added to "Others" group  ) (CI5)
   |---  Tom
          |
          |---------  Mix Technologies 1 (Mapped value for mixenterprise.com)
          |                       |---------- Dallas 
          |                                               |---------  Oracle 
          |                                                                       |---------  Linux-Group  (CI1)
          |
          |--------- mixservice.com  (No mapped value found, but as use-slot-val-if-not-found=true, the group is created using the slot value )
                                 |---------- Dallas 
                                                         |---------  Oracle 
                                                                                |---------  Linux-Group  (CI6)

Elements and attributes in the blueprint file

The following table describes the various elements and the attributes of each element in the blueprint file.

ElementDescriptionAttribute 1Attribute 2Attribute 3 
blueprintRoot element of  the blueprint definition



name: Blueprint name. Must be unique for each blueprint. Required attribute.



type: Blueprint type. The only supported value is "dynamic-group". This type lets you add different type of blueprints in future releases of Infrastructure Management. Required attribute.

version: Blueprint version. You can create multiple versions of a blueprint with the same name, but only one will be active at a time. Use the pw blueprint <enable|disable> command to activate or deactivate a version. Required attribute. 
groupRepresents a group blueprint definition. You can use nested groups to define group hierarchyslot-name: Defines the CI slot to be used to create dynamic groups. If the slot value is of the type "string" (single value), only one group corresponding to the slot is created. If the slot value is of the type "list of strings", multiple groups corresponding to the string values are created at the same level. Required attribute.group-name-policy: Defines the policy to be used to identify the group name. The values of this attribute can be “map-slot-val” and “use-slot-val”. If the value is “use-slot-val”, the group name is the same as the slot value. If the value is “map-slot-val”, the group name is derived from the value defined in the "slot-val-group-name-map" attribute. The default value of this attribute is “use-slot-val”. Optional attribute.
  
slot-val-group-name-map

Defines the list of mappings from the slot value to the group name

use-slot-val-if-not-found: If this attribute is set to true, the slot value is used if the slot value to group name mapping is not defined. If this attribute is set to false or not defined and the mapping is not found, then the group will not be created.The default value of this attribute is “false”. Optional attribute.

create-others-group: If this attribute is set to true, and if the slot value to group name mapping is not defined and if use-slot-val-if-not-found is set to false, the “Others” group is automatically created and unmapped values are stored in the "Others" group. The default value of this attribute is “false”. Optional attribute.  
map

Defines the slot value to group name mapping for a particular slot value

slot-val: Value of the CI slot. Required attributegroup-name: Group name to be used for the corresponding slot value. Required attribute.  

Note

Mapping of slot values is case-sensitive. For every combination of possible slot values, you must configure a mapping value. For example:

<group group-name-policy="map-slot-val" slot-name="Domain">
   <slot-val-group-name-map use-slot-val-if-not-found="true">
      <map slot-val="mixenterprise.com" group-name="USight1"/>
      <map slot-val="MixEnterprise.com" group-name="USight1"/>

Managing blueprints using CLI commands

After creating the blueprint file, you can import it into your Infrastructure Management environment by using CLI commands. When you import the blueprint file, Infrastructure Management evaluates the file and creates the hierarchy as defined by the groupings in the file.

The following table lists the CLI commands used to manage blueprint files.

CLI commandSyntaxDescription
pw blueprint import pw blueprint import -f <blueprint filename> [-e true  -s true ] Loads the blueprint definition into the system. If "-e true" is given, the pw blueprint enable command is automatically executed on that blueprint version, the blueprint is evaluated immediately, and dynamic groups are created. By default, a blueprint will be in the disabled state after import. "-s true" is for executing command silently.
pw blueprint exportpw blueprint export -n <blueprint name> -v <version> -o <out filename> [ -s true] Exports to an output file, a blueprint file that has already been imported . You can use this file to create new versions of blueprints. "-s true" is for executing command silently.
pw blueprint listpw blueprint listLists all the available blueprint files in the system. This command displays the name, version, type, and status (enabled or disabled) of the blueprint file.
pw blueprint <enable|disable|remove>
  • pw blueprint enable -n <blueprint name> -v <blueprint version>
  • pw blueprint disable -n <blueprint name> [-v <blueprint version>]
  • pw blueprint remove -n <blueprint name> [-v <blueprint version> -s true]
  • Enable is used to enable a particular version of a blueprint and disable all other versions of the same blueprint. The blueprint is evaluated immediately after enabling, and based on the elements in the blueprint file, dynamic group hierarchies are created or modified.
  • Disable is used to disable the specified version of the blueprint. If no version is mentioned, all versions of the specified blueprint are disabled. When this command is executed, the dynamic group hierarchy created using this blueprint is immediately removed from the system.

  • Remove is used to delete a blueprint version from the system. If a version is not mentioned, all versions of the specified blueprint are deleted, and the dynamic group hierarchy created using this blueprint is immediately removed from the system. "-s true" is for executing command silently.  

pw blueprint validatepw blueprint validate –f <blueprint file name>Checks the validity of the blueprint XML file and prints the results.

Recommendations

The following is a list of best practices to be maintained while creating group hierarchies:

  • Append the pronet.jserver.componentSlotsToRetain property in the the pronet.conf file to add all the slots and attributes used in the blueprint XML file. For example, if the blueprint XML file includes domain, city name, operating system, region, site, and so on, add these attributes to the pronet.jserver.componentSlotsToRetain property. For example,
    pronet.jserver.componentSlotsToRetain=Domain,OSType,Region,CityName,Site,SiteGroup,AppNames,SystemEnvironment
Was this page helpful? Yes No Submitting... Thank you

Comments