Dynamic Component Mapping

This section describes Dynamic Application Mapping, which allows SL1 to collect data from a single management system, such as a VMware ESX server, and then use that data to create multiple device records for the entities managed by that single management system.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

What is Dynamic Component Mapping?

Dynamic Component Mapping allows SL1 to collect data from a single management system, such as a VMware ESX server, and then use that data to create multiple device records for the entities managed by that single management system. For example, the managed entities for a VMware ESX server would be the Guest VMs hosted by that ESX server.

SL1 uses Dynamic Applications to retrieve data from the management device and discover each entity managed by that management device. SL1 then uses that retrieved data to create a device for each managed entity. In some cases, the managed entities are nested.

In SL1, a managed entity is called a component device. A component device is an entity that runs under the control of a management device.
In SL1, the root device is the physical device that manages one or more component devices.
In SL1, a parent device is a device that has associated entities modeled as component devices. A parent device can be either a root device or another component device.
In SL1, a component identifier is a collection object that SL1 uses to populate information about a component device, such as the device name.

For example, in a Cisco UCS system, SL1 might discover a physical server that hosts the UCS manager. SL1 might discover a chassis as a component device. The chassis is a child device to the physical server; the physical server is the root device. SL1 might also discover a blade as a component device that is part of the chassis. The blade is a child device to the chassis. The chassis is the parent device.

Where in SL1 are Component Devices Displayed?

You can view root devices and their associated component devices in the following places in SL1:

The Device Components page (Devices > Device Components) displays a list of all root devices and component devices discovered by SL1. The Device Components page displays all root devices and component devices in an indented view, so you can easily view the hierarchy and relationships between child devices, parent devices, and root devices.
The Component Map page (Classic Maps > Device Maps > Components) allows you to view devices by root node and view the relationships between root nodes, parent components, and child components in a map. This makes it easy to visualize and manage root nodes and their components. SL1 automatically updates the Component Map as new component devices are discovered. SL1 also updates each map with the latest status and event information.

Configuring a Dynamic Application to Create Component Devices

Dynamic Applications that use the following protocols can be configured to create component devices:

SNMP
Snippet
SOAP
WMI
PowerShell
XML
XSLT

For SL1 to create component devices using your Dynamic Application, you must perform the following steps to configure Dynamic Component Mapping:

In the Dynamic Applications Properties Editor page, select a configuration Application Type.
In the Dynamic Applications Properties Editor page, check the Component Mapping checkbox.
In the Dynamic Applications | Collections Objects page, configure a collection object that maps to the Device Name component identifier.
In the Dynamic Applications | Collections Objects page, configure a collection object that maps to the Unique Identifier component identifier.
Create a Device Class with a Device Type of Component to align with the Dynamic Application.

Performance Dynamic Applications cannot be used to create component devices.

If a Dynamic Application is configured to create component devices, SL1 will create a component device when the collection objects that map to the Device Name and Unique Identifier of a component device are successfully collected from a device.

For information on configuring device classes for component devices, see the section on aligning device classes with component devices.

You can also perform the following additional configuration steps for Dynamic Applications that create component devices:

In the Dynamic Applications | Collections Objects page, configure collection objects that map to the following component identifiers:

The availability of the component devices. The values collected using this collection object will be used to generate availability reports and graphs for each component device.
The manufacturer of the component devices.
The model of the component devices.
The names the management system uses to refer to the devices, known as the Distinguished Name.
The globally unique identifier of the component devices. This value is used to determine when a component device should be associated with a different root device.
The MAC Address of the component devices.
The UUID of the component devices.

In the Dynamic Application Component Alignment page, define a list of Dynamic Applications SL1 should automatically align to component devices created using this Dynamic Application.

Configuring Collection Objects as Component Identifiers

To configure a collection object to map to a component identifier:

Go to the Dynamic Applications Manager page (System > Manage > Applications).
Find the Dynamic Application that you want to configure. Select its wrench icon (). The Dynamic Applications Properties Editor page is displayed.
Select the Collections tab. The Dynamic Applications | Collections Objects page is displayed.
Select the wrench icon () for the collection object you want to edit.

For Dynamic Applications that have the Component Mapping checkbox selected in the Dynamic Applications Properties Editor page, the Component Identifiers field is displayed. In this field, select one or more identifiers that SL1 can use to create and monitor component devices. The values collected for this collection object will populate the selected identifier for the component devices. Collection objects can define the following component identifiers:

Availability. The availability of the component devices. SL1 uses Availability collection objects to generate availability reports and graphs for each component device. For information about how SL1 calculates availability using this component identifier, see the Availability for Component Devices section.

Class Identifier 1. The class type of the component devices, typically the vendor. This field can be used to align a discovered component device with an existing device class.
Class Identifier 2. The class sub-type of the component devices, typically the model. This field can be used to align a discovered component device with an existing device class.
Device Name (%N). The name of the component devices in SL1.
Distinguished Name (%C). The name that the system that monitors the component devices (the root device) uses to identify the component devices. Using this component identifier is optional; this name is not used as a unique identifier by SL1. This component identifier is useful if an additional substitution character is required in your Dynamic Application.
GUID (%G). The globally unique identifier SL1 will use for the component devices. This value must be unique for all component devices in SL1. This value is used to determine when a component device should be associated with a different root device. For information about how SL1 moves component devices using this component identifier, see the Moving Component Devices Between Root Devices section.
MAC Address. The MAC Address of the component device. This value is used to match component devices to devices that are discovered using the discovery tool. If a component device is matched to a physical device, SL1 discovers a component device directly using the discovery tool. For more information, see the Merging Component Devices with Physical Devices section.
Organization. During discovery, if the value of the collection object exactly matches an organization name in SL1, SL1 will align the component device with that organization. During subsequent collections, if the value of this collection object changes and exactly matches an organization name in SL1, SL1 aligns the new organization with the component device. If the value of this collection object does not exactly match any organizations in SL1, SL1 will create an event and align the event with the device aligned with the Dynamic Application.
Unique Identifier (%U). The unique identifier for the component devices. This value must be unique for all component devices associated with the same root device.
UUID. The universally unique identifier for the component devices.
GUID. Globally unique identifier. This value will be unique within SL1. No two component devices can have the same GUID. This component identifier protects the integrity of a component device even if it is aligned with a different root device (for example, with a vmotion event).

Each of these options can be defined by only one collection object in a Dynamic Application. If a component identifier is already defined by a collection object in this Dynamic Application, that component identifier will not be displayed in the list. For example, if you have already assigned a collection object to be the device name, the Device Name (%N) entry will not appear in the Component Identifiers list for other collection objects in the Dynamic Application.

Select the Save button to save your changes.

Duplicate MAC Addresses for Component Devices

SL1 handles duplicate MACs for component devices differently than duplicate MACs for physical devices. When a component device is assigned a MAC address, SL1 does not enforce uniqueness and will allow a component device to be created with the same MAC address as existing physical devices and/or existing component devices.

Unlike how SL1 discovers physical devices, SL1 uses Dynamic Applications to retrieve data from a management device and "discover" each entity managed by that management device as a component device. SL1 then uses that retrieved data to create a device for each managed entity. In some cases, the managed entities are nested. In SL1, physical devices are identified by IP address and MAC address. In SL1, component devices are identified by a device name, a unique identifier, and a device class. A Dynamic Application that creates component devices can assign a MAC address to each component device, but is not required to.

In SL1, a managed entity is called a component device. A component device is an entity that runs under the control of a physical management device.
In SL1, the root device is the physical device that manages one or more component devices.
In SL1, a parent device is a device that has associated entities modeled as component devices. A parent device can be either a root device or another component device.

For example, in a Cisco UCS system, SL1 might discover a physical server that hosts the UCS manager. This physical server is the root device. SL1 might discover a chassis on the root device. The chassis is a component device. The chassis is a child device to the physical server. SL1 might also discover a blade as a component device that is part of the chassis. The blade is a child device to the chassis. The chassis is the parent device.

SL1 does not automatically combine new component devices with any existing device record using the MAC address of the new component device. A component device can be combined with an existing device record under the following conditions:

Dynamic Applications that create component devices can assign a globally unique identifier (GUID) to each component device. When SL1 performs collection for a Dynamic Application, and the Dynamic Application includes a collection object with a GUID component identifier, SL1 compares the collected values for that collection object with all GUID values for all component devices discovered in the system. If a newly collected value matches a GUID value for an existing component device, the device from which SL1 collected the new value will become the parent of the existing component device. The existing component device will no longer be associated with its previous parent device. No new component device will be created.
You can merge a physical device and a component device. You can do this in the Actions menu in the Device Properties page (Devices> Device Manager > wrench icon) for either the physical device or the component device. When you merge a physical device and a component device, the device record for the component device is no longer displayed in the user interface; the device record for the physical device is displayed in user interface pages that previously displayed the component device. For example, the physical device is displayed in lieu of the component device in the Device Components page and the Component Map page. All existing and future data for both devices will be associated with the physical device. You can unmerge a component device from a physical device in the Actions menu in the Device Properties page for the physical device (Devices> Device Manager > wrench icon).

Component Devices, Collector Groups, and Load Balancing

To perform initial discovery, SL1 uses a single, selected Data Collector from the Collector Group. This allows you to troubleshoot discovery if there are any problems.

After each discovered device is modeled (that is, after SL1 assigns a device ID and creates the device in the database), SL1 distributes devices among the Data Collectors in the Collector Group. The newest device is assigned to the Data Collector currently managing the lightest load.

This process is known as Collector load balancing, and it ensures that the work performed by the Dynamic Applications aligned to the devices is evenly distributed across the Data Collectors in the Collector Group.

SL1 performs Collector load balancing in the following circumstances:

A new Data Collector is added to a Collector Group
New devices are discovered
Failover or failback occurs within a Collector Group (if failover is enabled)
A user clicks the lightning bolt icon () for a Collector Group to manually force redistribution
Devices in DCM or DCM-R trees will be loaded on the Data Collector currently assigned to the DCM or DCM-R tree rather than being distributed across the Collector Group. DCM or DCM-R trees will be rebalanced as an aggregate when rebalancing occurs to an available Data Collector with sufficient capacity to sustain the load.

Whenever a device is load-balanced from one Data Collector to another, whether due to failover or regular load balancing, the device state information is not transferred to the new Data Collector.

The lightning bolt icon () appears only for Collector Groups that contain more than one Data Collector. For Collector Groups with only one Data Collector, this icon is grayed out. This icon does not appear for All-In-One Appliances.

When all of the devices in a Collector Group are redistributed, SL1 will assign the devices to Data Collectors so that all Data Collectors in the collector group will spend approximately the same amount of time collecting data from devices.

Collector load balancing uses two metrics:

Device Rating. A device's rating is the total elapsed time consumed by either 1) all of the Dynamic Applications aligned to the device, or 2) collecting metrics from the device's interfaces, whichever is greater. A Collector's load is the sum of the ratings of the devices assigned to the Collector. The balancer tries to evenly divide the work performed by Collectors by assigning devices to Collectors using the device ratings and Collector loads.
Collector Load. The sum of the device ratings for all of the devices assigned to a collector.

SL1 performs the following steps during Collector load balancing:

Searches for all devices that are not yet assigned to a Collector Group.
Determines the load on each Data Collector by calculating the device rating for each device on a Data Collector and then summing the device ratings.
Determines the number of new devices (less than one day old) and old devices on each Data Collector.
On each Data Collector, calculates the average device rating for old devices (sum of the device ratings for all old devices divided by the number of old devices). If there are no old devices, sets the average device rating to "1" (one).
On each Data Collector, assigns the average device rating to all new devices (devices less than one day old).
Assigns each unassigned device (either devices that are not yet assigned or devices on a failed Data Collector) to the Data Collector with the lightest load. Add each newly assigned device rating to the total load for the Data Collector.

Collector Affinity

Collector Affinity specifies the Data Collectors that are allowed to run collection for Dynamic Applications aligned to component devices. You can define Collector Affinity for each Dynamic Application. Choices are:

Default. If the Dynamic Application is auto-aligned to a component device during discovery, then the Data Collector assigned to the root device will collect data for this Dynamic Application as well. For devices that are not component devices, the Data Collector assigned to the device running the Dynamic Application will collect data for the Dynamic Application.
Root Device Collector. The Data Collector assigned to the root device will collect data for the Dynamic Application. This guarantees that Dynamic Applications for an entire DCM tree will be collected by a single Data Collector. You might select this option if:

The Dynamic Application has a cache dependency with one or more other Dynamic Applications.
You are unable to collect data for devices and Dynamic Applications within the same Device Component Map on multiple Data Collectors in a collector group.
If the Dynamic Application will consume cache produced by a Dynamic Application aligned to a non-root device (for instance, a cluster device).

Assigned Collector. The Dynamic Application will use the Data Collector assigned to the device running the Dynamic Application. This allows Dynamic Applications that are auto-aligned to component devices during discovery to run on multiple Data Collectors. This is the default setting. You might select this option if:

The Dynamic Application has no cache dependencies with any other Dynamic Applications.
You want the Dynamic Application to be able to make parallel data requests across multiple Data Collectors in a collector group.
The Dynamic Application can be aligned using mechanisms other than auto-alignment during discovery (for instance, manual alignment or alignment via Device Class Templates or Run Book Actions).

Failover for Collector Groups for Component Devices

If you specified Default or Root Device Collector for Dynamic Applications, and the single Data Collector in the Collector Group for component devices fails, users must create a new Collector Group with a single Data Collector and manually move the devices from the failed Collector Group to the new Collector Group. For details on manually moving devices to a new Collector Group, see the section on Changing the Collector Group for One or More Devices.

Merging Component Devices

SL1 does not automatically combine new component devices with any existing device record. A component device can be combined with an existing device record under the following conditions:

Dynamic Applications that create component devices can assign a globally unique identifier (GUID) to each component device. When SL1 performs collection for a Dynamic Application, and the Dynamic Application includes a collection object with a GUID component identifier, SL1 compares the collected values for that collection object with all GUID values for all component devices discovered in the system. If a newly collected value matches a GUID value for an existing component device, the device from which SL1 collected the new value will become the parent of the existing component device. The existing component device will no longer be associated with its previous parent device. No new component device will be created.

You can merge a physical device and a component device. You can do this two ways:

From the Actions menu in the Device Properties page (Devices> Device Manager > wrench icon) for either the physical device or the component device.
From the Actions menu in the Device Manager page (Devices > Device Manager), select Merge Devices to merge devices in bulk.

When you merge a physical device and a component device, the device record for the component device is no longer displayed in the user interface; the device record for the physical device is displayed in user interface pages that previously displayed the component device. For example, the physical device is displayed in lieu of the component device in the Device Components page and the Component Map page. All existing and future data for both devices will be associated with the physical device.

If you manually merge a component device with a physical device, SL1 allows data for the merged component device and data from the physical device to be collected on different Data Collectors. Data that was aligned with the component device can be collected on the Data Collector for its root device. If necessary, data aligned with the physical device can be collected on a different Data Collector.

NOTE: You can merge a component device with only one physical device.

You can unmerge a component device from a physical device. You can do this in two ways:

From the Actions menu in the Device Properties page (Devices> Device Manager > wrench icon) for either the physical device or the component device.
From the Actions menu in the Device Manager page (Devices > Device Manager), select Unmerge Devices to unmerge devices in bulk.

Availability for Component Devices

For non-component devices, SL1 checks availability every 5 minutes by performing a ping request, SNMP request, or TCP connection to the admin primary IP address for the device. The result of the availability check is either available or unavailable. SL1 uses availability data to generate events when a device is unavailable and to generate availability reports and graphs.

In the Dynamic Applications | Collections Objects page, you can configure a collection object to represent the availability of the component devices created by a Dynamic Application. SL1 processes and stores the availability values returned by the availability collection object in the same way that SL1 processes and stores the values collected by the availability check for physical devices.

When you configure a collection object to represent the availability of component devices:

When SL1 performs collection for this Dynamic Application, if SL1 can collect a value for a component device using the collection object and the value is not 0 (zero) or "false", the component device is considered "available".
When SL1 performs collection for this Dynamic Application, if SL1 cannot collect a value for a component device using the collection object or SL1 collects a value that is 0 (zero) or "false", the component device is considered "unavailable".
If the collection objects aligned with the Device Name and Unique Identifier component identifiers return lists of values, SL1 will create multiple component devices. Each component device will be associated with an index, i.e. a location in the list of values. To monitor the availability of all the component devices in the list, the collection object aligned with the Availability component identifier should return a list of values with a value at each index associated with a component device. SL1 will consider a component device "unavailable" when the list of values returned by the collection object aligned with the Availability component identifier does not include a value, or returns a value of 0 (zero) or false, at the index for that component device. For more information about Dynamic Application indexing, see the Indexing section.
If you align a collection object with the Availability component identifier, SL1 will create a system availability graph in the Device Performance page of each component device created using the Dynamic Application.
If you align a collection object with the Availability component identifier and SL1 determines that a component device is unavailable, SL1 will generate an event and supply the value "Unavailable" in the Collection State column in the Device Components page.

The following rules apply to the availability state for component devices:

Component devices can use a Component Identifier to monitor availability. However, in a tree of component devices, some component devices might have a component identifier for availability and others might not. For example, suppose a component device has a component identifier for availability, and SL1 considers that component device "unavailable". All the descendents of that component device that do not have their own component identifier for availability will be considered unavailable. As soon as SL1 finds a descendent with its own component identifier for availability, SL1 stops checking that descendent and its descendents for availability. Component devices without their own component identifier for availability inherit their availability from their nearest ancestor that has a component identifier for availability.

For trees that include merged devices, i.e. those that include both hardware devices and component devices, SL1 skips over the hardware devices and allows them to use a network-based protocol to determine availability. For example, suppose you have a tree like this:

Grandparent device is a component device with a component identifier for availability. SL1 has determined that the grandparent device is unavailable.
Child device is a hardware device that uses ICMP and ping to determine availability. When SL1 evaluates the grandparent's component identifier, SL1 skips over this device. ICMP and ping determine the availability of this device.
Grandchild device is a component device that does not have its own component identifier for availability. When SL1 evaluates the grandparent's component identifier, SL1 assigns the grandparent's availability state to this grandchild device.

If all the hosts in a cluster are powered off or unavailable, both the hardware-based hosts and the associated component devices will have an availability value of "Unavailable". When at least one host in the cluster becomes available, some or all of the associated component devices will also become available.

For instructions on how to align a collection object to a component identifier, see the Configuring Collection Objects as Component Identifiers section.

Moving Component Devices Between Root Devices

Depending on the type of management system that you want to monitor using Dynamic Component Mapping, it might be possible for a component device to move from one root device to another root device. For example, if a Dynamic Application with Dynamic Component Mapping configured is aligned with multiple VMware ESX servers that are root devices with guest VMs discovered as component devices, a vMotion event might move a guest VM from one VMware ESX server to another VMware ESX server.

If your Dynamic Applications will create component devices that can move from one root device to another root device, you can configure a collection object that maps to a globally unique identifier (GUID) for each component device. The value of the GUID component identifier must be unique for every component device in SL1.

When SL1 performs collection for a Dynamic Application, and the Dynamic Application includes a collection object with a GUID component identifier, SL1 compares the collected values for that collection object with all GUID values for all component devices discovered in the system. If a newly collected value matches a GUID value for an existing component device, the device from which SL1 collected the new value will become the parent of the existing component device. The existing component device will no longer be associated with its previous parent device.

Automatically Aligning Dynamic Applications with Component Devices

In a Dynamic Application that has Dynamic Component Mapping enabled, you can define a list of Dynamic Applications that SL1 will automatically align to the component devices that are discovered by the Dynamic Application. The Dynamic Applications in the list are automatically aligned to a component device when the component device is created. Every time collection is performed for the Dynamic Application that created a component device, any new Dynamic Applications that have been added to the list of Dynamic Applications are aligned to the component device.

This feature is useful when you want to nest component devices, that is, discover additional component devices that have a component device as the parent. To nest component devices, you must specify that SL1 should immediately align Dynamic Applications that discover additional component devices upon creation of a component device.

To define a list of Dynamic Applications that you want SL1 to automatically align to component devices:

Go to the Dynamic Applications Manager page (System > Manage > Dynamic Applications).
Find the Dynamic Application that has Dynamic Component Mapping enabled. Select its wrench icon (). The Dynamic Applications Properties Editor page is displayed.

Select the Component tab. The Dynamic Application Component Alignment page is displayed.

The Component tab and the Dynamic Application Component Alignment page do not appear for Dynamic Applications that do not have component mapping enabled in the Dynamic Applications Properties Editor page.

The Dynamic Application Component Alignment page displays two lists of Dynamic Applications:

Unaligned Dynamic Apps. Displays a list of all Dynamic Applications in SL1 that are not automatically aligned to the component devices discovered by this Dynamic Application.
Aligned Dynamic Apps. Displays a list of Dynamic Applications that SL1 will automatically align to the component devices discovered by this Dynamic Application.

To move a Dynamic Application from the Unaligned Dynamic Apps list to the Aligned Dynamic Apps list, select the Dynamic Application and then select the right-arrow button.

To move a Dynamic Application from the Aligned Dynamic Apps list to the Unaligned Dynamic Apps list, select the Dynamic Application and then select the left-arrow button.

Select the Save button to save your changes.

Automatically Assigning a Device Class to Each Component Device

SL1 can automatically align a device class with each discovered component device. If you do not want to automatically assign all component devices to the same device class, you can use Component Identifiers (variables) to align component devices with device classes. The value of two collection objects will determine the device class for each component device.

To customize the alignment between device classes and component devices, perform the steps in the following two section.

Configuring a Device Class to Match Collected Values

Go to the Device Class Editor page (System > Customize > Device Classes).

When you create or edit a device class for component devices, you must define these three values:

Device Type. Select "Component".
Class Identifier 1. Enter a value collected by one of the collection objects in the Dynamic Application that creates the component devices. Typically, this value is the manufacturer of the device. For a component device to be assigned to a device class based on component identifiers, the value entered in this field must match the value(s) collected by the Class Identifier 1 component identifier in the collection object.
Class Identifier 2. Enter a value collected by one of the collection objects in the Dynamic Application that creates the component devices. Typically, this value is the model of the device. If you want to assign this device class based only on the Class Identifier 1—that is, if you are creating a "fall back" device class for components that do not match specific Class Identifier 1 and Class Identifier 2 combinations—do not enter a value in this field.

NOTE: The combination of the Class Identifier 1 and Class Identifier 2 values should be unique to devices that subscribe to the device class.

Configuring Component Identifiers for the Collection Objects

When you create a Dynamic Application, you can map the value of a collection object to a component identifier. The value collected for the collection object (from each device) will populate the Component Identifier field(for that device).

Two of these component identifiers help SL1 automatically align a device class with each component device.

Class Identifier 1. For a component device to be assigned to a device class based on component identifiers, the value(s) collected by this collection object must match the value you entered in the Class Identifier 1 field for that device class.
Class Identifier 2. For a component device to be assigned to a device class based on component identifiers, either the value(s) collected by this collection object must match the value you entered in the Class Identifier 2 field for that device class or the device class must not include a value for the Class Identifier 2 field.

How Does SL1 Use Component Identifiers to Automatically Assign a Device Class to Each Component Device?

SL1 uses the following procedure to automatically assign a device class to each new component device:

If the values for component identifiers Class Identifier 1 and Class Identifier 2 exactly match the values specified in the device class fields Class Identifier 1 and Class Identifier 2 in an existing component device class, SL1 will align the component device with that device class. During subsequent collections, if the value of the one or both of the collection objects changes and exactly matches a device class name and device class description, SL1 will change the device class to match the values of Class Identifier 1 and Class Identifier 2.
If the value for component identifier Class Identifier 1 exactly matches the device class field Class Identifier 1 in a component device class definition, but the component identifier Class Identifier 2 either does not match a device class description or is not defined, SL1 will assign the component device to the device class with the matching value in the field Class Identifier 1 and no value defined for Class Identifier 2.

NOTE: ScienceLogic recommends that you create such a device class as a "fallback" for the specified Class Identifier 1. SL1 can then use this device class for any component devices that have an unrecognized Class Identifier 2.

If the Dynamic Application does not include component identifiers Class Identifier 1 and Class Identifier 2 OR the values for Class Identifier 1 and Class Identifier 2 do not match the fields in an existing component device class, SL1 aligns the component device with the device class associated with the Dynamic Application. You can define this device class in the Device Class Editor (System > Customize > Device Classes > edit a device class > Dynamic App Alignment field) or in the Dynamic Application Editor window, in the Components tab (System > Manage > Applications > edit a Dynamic Application > Components tab).
If the Dynamic Application does not include component identifiers Class Identifier 1 and Class Identifier 2 OR the values for Class Identifier 1 and Class Identifier 2 do not match the fields in an existing device class, AND the Dynamic Application is not aligned with a device class (either in the Device Class Editor page or in the Components tab), SL1 automatically assigns the component device to the device class "Generic: Component".

Aligning a Default Device Class with a Dynamic Application

You can align a device class with a Dynamic Application that creates component devices. If you choose not to use the component identifiers Class Identifier 1 and Class Identifier 2 in your Dynamic Application to match a device class, SL1 will automatically align each newly discovered component device with the default device class that you aligned with the Dynamic Application.

There are two ways to align a default device class with a Dynamic Application:

In the Device Class Editor page (System > Customize > Device Classes), in the Dynamic app Alignment field.
In the Dynamic Application Editor window, in the Components tab (System > Manage > Applications > Edit a Dynamic Application > Components tab).

Defining a Default Device Class in the Device Class Editor

To define a default device class for a Dynamic Application from the Device Class Editor page:

Go to the Device Class Editor page (System > Customize > Device Classes).
Create or edit the device class you want to align with the Dynamic Application.

In the field Dynamic App Alignment, select a Dynamic Application.
Select the Save button.

Defining a Default Device Class in the Dynamic Application

To define a default device class for a Dynamic Application from the Dynamic Application Editor window:

Go to the Dynamic Applications Manager page (System > Manage > Dynamic Applications).

Find the Dynamic Application that you want to associate a device class with. Select its wrench icon (). The Dynamic Applications Properties Editor page is displayed.

Select the Component tab. The Dynamic Application Component Alignment page is displayed.

NOTE: The Component tab does not appear for Dynamic Applications that do not have dynamic component mapping enabled.

In the Device Class Alignment field, select a device class.
Select the Save button.

Variables in Dynamic Applications for Component Devices

If Dynamic Applications are aligned to component devices, SL1 uses the following rules when performing collection:

If the %D substitution is used in the credential aligned with the Dynamic Application, SL1 substitutes the IP address of the root device.
If the Dynamic Application uses cached responses from other Dynamic Applications, the Dynamic Application that caches the response can be aligned to either the component device or the root device.

In SOAP and XSLT Dynamic Applications that are aligned to component devices, you can include the following substitution characters in the SOAP Request Code, XSLT Request Code, and XSLT Parser Code fields:

%N. SL1 will substitute the value of the Device Name component identifier for the component device for which collection is being performed.
%U. SL1 will substitute the value of the Unique Identifier component identifier for the component device for which collection is being performed.
%C. SL1 will substitute the value of the Distinguished Name component identifier for the component device for which collection is being performed.
%G. SL1 will substitute the value of the GUID component identifier for the component device for which collection is being performed.

Caching and Component Mapping

Although the caching and dynamic component mapping features can be used separately, the caching feature is useful to collect performance and configuration data for component devices. For example, the following set of Dynamic Applications might be used to discover and monitor component devices:

A Dynamic Application that requests all the information needed for all other Dynamic Applications in this set. This Dynamic Application caches the responses and is aligned to the root device.
A Dynamic Application that creates component devices. This Dynamic Application consumes cache and is aligned to the root device.
One or more Dynamic Applications that collect performance and/or configuration data for each component device. These Dynamic Applications consume the cached responses from the first Dynamic Application and are aligned to each component device.

To associate performance or configuration data with only the appropriate component device (that is, the component device that generated the performance or configuration data), you would use substitution characters in your requests. When the request is executed, SL1 replaces the substitution character with a component identifier for the component device for which collection is currently being performed.