Attribute Merging During the Portal Upgrade
Version 10.x.xx introduced several enhancements to attribute management.
• A new attribute type, a multi-object attribute, replaces the way that attributes functioned in previous releases. This mult-object attribute enables creation of a single attribute that will be available for all objects, such as hosts, arrays, and switches.
• Prior to Version 10.x.xx, object-specific attributes were required. For example, if you wanted a Location attribute for both host and array objects, you needed to create a separate Location attribute for each object. Now, with multi-object attributes, a single attribute can be used for all objects (for example, arrays, hosts, LUNs and switches).
• System Attributes are new to Version 10.x.xx. System attributes provide a set of popular attributes that you can populate with your own enterprise-specific values. These new system attributes are multi-object attributes with the following names: Application, Business_Unit, Data_Center, Department, Environment, Location, Organization, Owner, and Region. These system attributes cannot be deleted.
• The naming convention for attributes also has been changed in Version 10.x.xx. Attribute names must begin with an alpha character. Use only alpha, numeric, or underscore characters in the name. Spaces and special characters are not allowed. This may mean that you will need to modify attribute names after you upgrade so that you can modify and save the list of values.
Attribute Management During the Portal Upgrade
Because you may already have attributes in your database that have names that duplicate the system names introduced in Version 10.x.xx, the upgrade process must apply logic to prevent duplicate attribute names. During the Portal upgrade, the following logic is used:
• In the top-level domain, if the upgrader finds an existing attribute that has a name that is the same as a new system attribute (for example, Location) it creates the system attribute and populates it with the list of values from the existing attribute.
• For multi-tenancy environments where there are multiple domains, if an attribute is found in both a parent and child domain, the child domain will not inherit the values but instead, the values of the attribute in the child domain will remain intact. See also, Attribute Inheritance Overrides in the online technical documentation.
• If multiple attributes with the same name are encountered in the same domain (for example, a host Location attribute and an array Location attribute), the values from all the attributes with the same name (for all objects) are merged into the system attribute.
• The upgrader will list the attributes with the list of values that will be merged into the new System Attributes. You can choose to let the upgrader merge the attributes or you can stop the upgrade and use the steps provided to rename existing attributes. See
Steps to Rename Duplicate Attributes.
• Merging of values ensures that all objects that have been assigned the attribute will retain this attribute with its values and therefore, reports that use the attributes will continue to work as expected.
Example of a Merge of Attribute Values
Before the upgrade:
• Location attribute exists for Hosts, with a list of values: San Diego, New York, Seattle.
• Location attribute exists for Arrays, with a list of values: Paris, London, Singapore.
After the upgrade:
• Location system attribute has been created to replace the object-specific attributes. This system attribute will contain a merged list of values (LOV): San Diego, New York, Seattle, Paris, London, Singapore.
• This list of values applies to all objects.
• Once the upgrade is successful, you may want to modify the merged list of values via the Portal: Select Admin > Advanced > Attributes.
Steps to Rename Duplicate Attributes
1. Log in to the Portal server.
2. At the command line:
su - aptare
3. At the command line, launch sqlplus:
sqlplus <pwd>/<pwd>
• Example: sqlplus portal/portal
4. To rename an attribute, execute the following SQL statements, substituting <variables> with values listed in the upgrade messages:
UPDATE apt_attribute
SET attribute_name = <attributeName>
WHERE attribute_id = <AttributeID>;
Commit;
Example:
This example renames the Location attribute so that it is not merged with the system attribute named Location.
UPDATE apt_attribute
SET attribute_name = 'Location1'
WHERE attribute_id = 100001;
Commit;
Best Practice for Attributes in Multi-Tenancy Environments
• Maintain attributes at the top-level domain so that the attributes are available to all client/child domains.
• During the Portal upgrade to Version 10.x.xx, newly introduced System Attributes will be added to the top-level domain.