systemIndex-SystemIndexService

The purpose of System Indexing is to schedule indexing (and re-indexing) of tagged data (entities) from the local station or any subordinate stations under the NiagaraNetwork. The SystemIndexService can be configured to crawl the entire system (local and remote stations) by querying for entities that match certain criteria (networks, devices, points) and storing those indexed entities in the Supervisor station's system database.

IMPORTANT: In Niagara 4.14, the back-end graph database used by the System Database (OrientDb) has been upgraded from v3.0.X to v3.2.X. As a result, if you have an existing N4Supervisor station already using the System Database that you upgrade to Niagara 4.14, the upgrade erases the contents of the Supervisor station's existing System Database. Until the next scheduled full re-index of your Niagara system, this will temporarily cause queries against the System Database and return no results. A subsequent full system re-index repopulates the data in the System Database. Re-indexing typically occurs on a triggered basis, but to repopulate the data quicker, you can manually invoke a full system index immediately after upgrading by invoking the Execute action on any System Indexer in use.

NOTE: The tagdictionary palette includes two smart tag dictionaries that support the System Database and System Indexing features. The dictionaries allow you to easily exclude portions of a NiagaraStation from indexing operations, which you might want to do for licensing reasons. The SystemIndex dictionary has a smart tag, the scoped tag. If you add this dictionary to your station, you can drop a systemIndex:excluded marker tag on a component and any descendants will have this same tag implied on them. To prevent implying this tag on all descendants you can apply a systemIndex:included marker tag where necessary. The SystemIndex dictionary has a scoped tag rule that can be configured to imply the systemIndex:excluded tag on portions of the station as specified in one or more Ord scopes.

The SystemIndexService is typically installed under the SystemDbService (although it can be placed anywhere under the Services Container). It must be enabled for any child indexers to function. All child indexers have their own configurable execution triggers, but the service also provides a retry trigger that can re-execute any failed indexers at a faster rate.

Properties

In addition to standard properties (for example, Status, Enabled, Fault Cause), this component provides the following configuration properties.

Property	Value	Description
Max Concurrent Index Executions	5–max (defaults 50)	Defines the maximum number of concurrent threads that can be processing system index requests from different sources in parallel.
Max Concurrent Index Executions Per Device	1–max (defaults 1)	Defines the maximum number of concurrent index executions per device ( Niagara station). This includes index executions for reachable stations that route through a particular Niagara station. This can be important to throttle back concurrent index requests for downstream reachable stations that all route through the same starting Niagara station device. NOTE: This value should never be set equal or larger than the `Max Concurrent Index Executions` value.
Retry Trigger	additional properties	See following section.

Retry Trigger properties

Property	Value	Description
Retry Trigger	1 hour (all days of the week) (default)	Retries any System Indexer components that had a failure on their last execution (so that they will be retried at a quicker interval than the normal execution time).
Trigger Mode	interval, daily (default), manual	Determines when a TimeTrigger fires. `Daily` fires the trigger at a specific time on selected days of the week, and includes a randomized interval so that the trigger does not fire at exactly the same time every day. Randomized firing is useful when handling large volumes of data. `Interval` fires a trigger each time the specified interval elapses. You would use it to fire the trigger several times per day (for example, every 5 minutes). `Manual` requires a human to fire a trigger. When this trigger fires for a station database, a system indexer (`LocalSystemIndexer` or `GlobalNiagaraNetworkIndexer`) executes its index operation. CAUTION: Indexing a database is a memory- and CPU-intensive operation that affects the availability of your SystemDb and remote stations. Do not configure a re-index to occur too often so your SystemDb and remote stations can maintain availability throughout the day. If your SystemDb is indexed frequently, query performance degrades.
Last Trigger	read-only	Records the timestamp of when last retry occurred.
Next Trigger	read-only	Reports when the trigger is scheduled to fire again.