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.

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.

Type	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 per device the maximum number of concurrent threads that can be processing system index requests from different sources in parallel.
Retry Trigger	additional properties	See following section.

Retry Trigger properties

Type	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 its trigger. When this trigger fires, it causes a system indexer (either the `LocalSystemIndexer` or `GlobalNiagaraNetworkIndexer`) to execute its index operation. Provides the standard trigger mode options, with a default setting of `Daily` at 2:00 AM, all days of the week. Other selections include `Manual` or `Interval`. For Daily or Interval modes, you can choose the desired execution parameters (Time of Date, Randomization, Days of Week) for the specific mode. Interval fires a trigger each time the specified interval has elapsed. Intended for use when firing the trigger several times per day (e.g. every 5 minutes). Daily allows the trigger to be fired at a specific time on selected days of the week. Also, provides randomization interval so that the trigger is not fired at exactly the same time every day, useful when handling large volumes of data. Manual requires human interaction to fire a trigger. NOTE: Indexing a database is a memory- and CPU-intensive operation that affects the availability of your SystemDb and remote stations. When configuring a re-index time, be sure it does not occur too often so your SystemDb and remote stations can maintain better availability throughout the day. If your SystemDb is indexed too often, query performance will degrade.
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.