The Software Management model stems from the Software Resource Model, or the SRM. The SRM is used by the Platform and many Solutions, tying together the sometimes disparate frameworks different Solutions use to manage or otherwise track Software. This article covers how the base Resource Model works, and how the SRM sits on top of that.
To understand how the Software Resource Model works, first it is important to understand the underlining Resource Model used by the Symantec Management Platform for all Resource types.
NOTE: At the time of this publication, the information contained here was known to be valid, however minor changes during the course of Product development might have changed schema. Please test any query or other data inspection with the understanding that these references might be stale based on a recent update.
Introduction
The Resource Model is a mechanism that enables the storage of large amounts of data for several entities. On key difference between items and tables is that data stored by resources can be stored in one or more tables. Items however store data in a state column.
The Resource Model provides a common solution development environment by allowing common pieces of the framework to be used. The Resource Model is a framework designed to be extended and customized by other solutions. Examples of this include the Data Loader, resource security, and Notification Server data forwarding.
The Resource Model also provides a common experience for end users. Examples of this common functionality include: Query Builder, Resource Manager, and Data Entry pages.
What is a Resource?
Resources represent the physical objects that the Symantec Management Platform manages. The term resource is often used synonymously with a tangible object, such as a user's computer, a user's phone, or the user themselves. When discussing resources in conversations, this definition is typically sufficient; however, from a design perspective, this definition is incomplete. Programmatically, resources are composed of three things: a Resource Type, Data Classes and Associations.
Resource types are arranged in a hierarchy. Data classes, association types and resource type keys are inherited from the base resource type.
Figure 1. - Resource design diagram
Resource types extend the Item Object Model. Because resource types are based on items, the base resource type class is called ResourceItem. Examples of resource types are Computers, Users, Printers, Routers, Contracts and Software Packages. Since resource types extend Items, all resources are items; however, there is an important distinction between a resource and an item. That distinction is the data classes and associations that comprise resources. Therefore we typically refer to resources and items (or standard items) separately.
Resource associations are relationships between resource types. Conceptually, a parent type is associated with a child type in the form of a relationship. A well named association indicates what the relationship is. Associations also define a cardinality which determines how many parents can/must be related to how many children (0 to 1, exactly 1, 0 to many, etc). A resource type may have multiple associations. Examples of resource associations are Users Company (connects a user type to a company type), Users Manager (connects a user type to a user type) and Incident To Resource (connects an incident type to any resource type).
Like the Item Object Model, the Resource Model is extensible, supporting customizable types, data classes and associations. New resources can be built on top of existing resources thereby inheriting the features of that existing resource, including its dataclasses and associations. For example, a Software Company may be extended from Company, which in turn extends from Resource.
Resource Model Components
- Resource
- Resource Type
- Data class (Resource Data Class)
- Resource Association
- Resource Association Type
- Resource Type Key
Resource Type
A Resource Type contains the definition of a type of entity in Notification Server (NS).
Examples of entities are: computer, user, and software
Resource Association
A Resource Association is a individual link between two resources. The link describes the relationship between two resources. This relationship describes the parent and child resources and the cardinality that is allowed. A Resource Association's data is forwarded between Notification Servers.
Figure 1-3 display the relationship/associations between resource types.
Figure 2. - Relationships between Resource Types
The Contract Resource Type is also derived from the base Resource type. Below is a chart of the Contract Resource.
Figure 3. - Contract Resource Type Model
Resource Type Key
The Resource Type Key is the mechanism for identifying a resource instance. Different solutions need to identify a resource by different lookup values.
An example of is of the Computer Resource Type. Inventory Solution identifies a computer by Name and Domain whereas Asset Management Solution uses the serial number to identify a computer. The standard core implementation of a resource Type key provides resource lookups for data class attribute values.
Resource Type Views
vResource, vResourceItem, and vResourceEx are views on [vitem] joined to [ItemResource].
- vResource - This view includes all resources.
- vResourceItem - This view includes all resources joined with [vItem]
- vResourceEx - This view extends vResource to include the Name, Description and IsLocal flag.
- vResourceType - This view shows all Resource types and is a view on [ResourceType]
What is a Data Class?
A data class is essentially a database table that contains custom data relevant to a given resource type. When standard items are extended, their extended data is stored in the Item table as an xml blob. This is not the case with resources which use a separate table for each data class. This is done for performance reasons. Separate tables allow for easy querying and reporting about the resource. A resource type may have multiple data classes. Examples of data classes are User General Details, Company Details and Software Delivery Package Summary. A common naming scheme is used to for Resources, namely: RM_Resource...
Data Class (Resource Data Classes)
Data Classes store actual data for a resource instance. Groups of similar properties are typically placed into a single data class. A data class can be assigned and used by many different resource types. Existing Resource types can be extended to include additional data classes. Data Classes are categorized as inventory or event data classes.
Inventory data classes can be set to record a 1 or multiple rows of information. The data contained in a Inventory Data Class can be forwarded between Notification Servers. The Inventory Data Class is designed to store the current state of the data. Inventory style data class tables are prefixed with "Inv_" in the CMDB.
Data Classes may contain foreign keys. The Data Class foreign key specifies that a given field in a given Data Class is a link to another item. Data Class foreign key items are linked to another Data Class using an Item Reference. The core includes these two standard implementations for foreign keys:
- Data Class foreign key - This specifies that the value in the Data Class is the GUID of a specified class.
- Data Class resource foreign key - This specifies that the value is the GUID of a resource item of a specified resource type.
Event Data Classes are designed to store a history of the data. Event style data class tables are prefixed with "Evt_" in the CMDB. A summary of all Data Classes in the CMDB can be found in the "DataClass" table. The Data lasses are filtered by style with the vInventoryClass and vEventClass views.
The following diagram in Figure 4 displays the Software Resource Model. This diagram shows the relationship between resources and data classes. Blue boxes are resource types and orange boxes are data classes.
Figure 4. - The Software Resource Model
The following diagram (Figure 5) provides a more detailed look at the Software Resource Model.
Figure 5. - The Software Resource Model, greater detail
Software Resource Model Navigation
The data classes in the resource data model ( yellow boxes ) are named by their correct name, and the table can be discerned by the data class name. Columns are also supplied via the box below the data class names. They do not list those columns that are created for any data class automatically ( _id, _ResourceGuid).
Figure 6 - Example of a data class, its name, and columns
The actually dataclass table name contains the Inv_ prefix and all the spaces are replaced with _ i.e. in the given example the table name is Inv_Windows_File.
The software resources (blue) boxes only list Name and Description column as essentially all software resource tables have the same number of columns
The exact table name contains the RM_Resource prefix and all the spaces are replaced with _ i.e. for the for the resource above it is RM_ResourceSoftware_Installation_File
The software resource tables are joined to resource data classes (solid purple arrows) by GUID column in the software resource and _ResourceGuid column in the data class
For example:
SELECT * FROM RM_ResourceFile rf JOIN Inv_File_Details fd ON rf.Guid = fd._ResourceGuid
The foreign key relationship to resource instance (dashed gray arrows) are joined on the column that essentially has the foreign software resource in its name.
For example:
SELECT * FROM Inv_Installed_File_Details f JOIN RM_ResourceFile fr ON f.FileResourceGuid = fr.Guid
Some explanation: as you can see on the model the Installed File Details data class is associated with the Computer resource, not the File Resource. But it does have connection to the file resource ( dashed gray arrow ) via the FileResourceGuid column.
Also, for each resource NS Resource Management framework also creates a view and updates it automatically. The view combines resources of the given type and all the types derived from it. The view name contains the vRM_Resource prefix, then the software resource name with the spaces replaced with _ and then _Item postfix.
Conclusion
This information is provided to aide in understanding how Resources within the Symantec Management Platform are represented and associated. At the time of this publication, the information contained here was known to be valid, however minor changes during the course of Product development might have changed schema. Please test any query or other data inspection with the understanding that these references might be stale based on a recent update.