Hierarchy component

Obtained from the hierarchy palette, the Hierarchy component creates the root level of a hierarchy Nav tree structure.

The name of the Hierarchy component becomes the collective name for the root node in the tree. Examples might be a company or department name, a geographic region or the name of a group of devices that are being monitored together.

Figure 1. Hierarchy component property sheet

Hierarchy properties

Property	Value	Description
`Query Context`	Config Facets dialog box	The current location is one item that could be placed in the query context. The facet value is compared with the value of the context tag on a device or point at a lower level in the navigation tree. The query context can hold anything to be used in LevelDef queries. It is comparable to a hierarchy scoped variable. You could create multiple copies of such a hierarchy definition and then customize each copy with the query context of the specific hierarchy.
`Status`	text	Read-only field. Indicates the condition of the component at last polling. {ok} indicates that the component is licensed and polling successfully. {down} indicates that polling is unsuccessful, perhaps because of an incorrect property. {fault} indicates another problem.
Fault Cause	read-only	Indicates the reason why a system object (network, device, component, extension, etc.) is in fault. This property is empty unless a fault exists.
`Scope`	station:	Causes the hierarchy query to search the local station database.
`Scope Ord`	station:\|slot:/...	Causes the hierarchy query to search within a specific location in the station database
Tags		Additional tags may be applied. For example, you can set the display name of the hierarchy definition as you might for any other component. The display name will be used when the hierarchy is displayed under the hierarchy space and the `n:displayName` tag stores this display name. The name of the hierarchy definition and not the display name is used in hierarchy ords so hierarchy ords will continue to work even if the display name of a hierarchy is changed. The display name might be changed to make the hierarchy space more user friendly (display names can accept more than regular component names).
Cache Status	Not Cached (default), Caching, Cached, Caching Failed, Not Cached On Started	Read only value, shows whether or not the hierarchy is cached or the status of a caching operation that is in progress. If “Cached” there is an existing cache of the hierarchy. If “Not Cached” either an existing cache was cleared, or the hierarchy has never been cached. If "Caching", then there is a job running that is creating a cache of the hierarchy. If "Caching Failed", then something went wrong during cache creation and a cache of the hierarchy does not exist. See the caching job log for details regarding the failure. If "Not Cached on Startup", then the hierarchy property Cache On Station Started is true but a caching job was not started when the station started because either the "niagara.hierarchy.caching.disableOnStationStarted" or "niagara.hierarchy.caching.disabled” system property is set to true; a cache of the hierarchy does not exist.
Cache Creation Time	text string	Read only timestamp, shows date/time that the current cache was created or null if a cache of the hierarchy does not exist.
Cache On Station Started	true, false (default)	If the value is true, a job will be started once the station has started that builds a cache of this hierarchy.

Actions

These caching-related actions are applied manually per hierarchy definition via the right-click menu.

Create Cache — builds the hierarchy cache; an existing cache is deleted before the new cache is built
Clear Cache — deletes the existing hierarchy cache

Additionally, you could link the caching action to a trigger schedule so that the cache is recreated on a regular schedule, such as each night at 3:00 a.m.