3.9. Custom data fields

 

IRM comes with “built-in” support for all of the kinds of managed objects listed in the Managed Objects section.  This built-in support includes various data fields that are critical to the operation of the software.  For example, in order to be able to draw a rack-mounted switch properly in the Rack Elevation dialog, the software needs to know the length, width, and height of the switch.  Also, in order to know whether a given cable can connect to a given piece of equipment, IRM must know what kind of ports/jacks the equipment has and what kind of plug is at the end of the cable.  These kinds of fields can be called built-in fields or semantic fields because the software has special built-in knowledge of them. 

 

There are other fields that might be considered critical for IRM users, such as the product number or serial number, but IRM itself doesn’t need these fields for any purpose other than directly displaying their values to the IRM user.  We refer to these fields as custom fields or non-semantic fields because they can be added or removed by IRM users and IRM doesn’t have any special knowledge about them, other than basic information such as their data type and how to properly format them for output in the UI or in reports.

 

A “bare bones” installation of IRM could in principle work without any custom data fields, but such an installation wouldn’t be very useful.  In order to reduce the workload on IRM customers, Planet Associates includes a standard set of custom fields as part of the IRM Library.  In this way, non-semantic fields like “Model Number” and “Street address” can appear to be “built in”, even if they really aren’t.

 

In summary, there are three types of fields in IRM:

 

One interesting and extremely useful property of custom data fields is that they can be applied to Category and Type objects, not just instance objects.  In fact, it is usually much more convenient to apply these fields to a Category or Type, because you can cover large numbers of objects at one time.  For example, consider the field “Model Number”.  Ask yourself, “what kinds of equipment objects could use a model number field”.  The answer, of course, is “all of them”.  In that case, you can simply apply the Model Number field to the topmost equipment Category (which is called “All Equipment” in the screen capture below).  This field is then “inherited” by everything below the object where it was applied (this behavior is sometimes referred to as pseudo-inheritance).  Child Categories inherit from their parent Categories, Types inherit from their parent Categories, and instance objects inherit from their parent Categories and/or Types.  Therefore, by adding this field in just one place (the All Equipment Category), you have affected all the equipment that IRM knows about, from faceplates to blade chassis to desktop monitors.  Now that’s powerful!  Of course, this particular field (Model Number) is so useful that it is included in the IRM Library, so IRM users wouldn’t actually have to add it, but you get the idea.

If you are following the Model Number example carefully, you might think that it’s all well and good to define the Model Number field in the All Equipment Category, but that doesn’t solve the whole problem -- each individual Type of equipment has to have a different value for that field -- and you would be exactly correct.  IRM allows for this situation by providing the field value override feature.  This feature allows for a field to be given a different value at any point in the Categories and Types tree.  Everything below that point sees the overridden value.  So, for the Model Number example, it is possible to define a unique model number for each equipment type object without having to keep re-assigning the user defined field itself.

 

This ability allows each customer to customize IRM to only manage the data they require to effectively manage their assets without having an overload of data fields which are never used; effectively giving them a bespoke application within an out-of-the-box framework.