External Tag Provider Reference

Important

If you are using the default Tag provider, none of this is applicable. The following information is only valid for new Tag providers that you create using the External Tag Provider type.

The information provided here requires an understanding of Tags and how they work. It is an advanced reference to how the tables of external Tags providers are structured, and an overview of the concepts of Tag execution. If you are a new user, it is suggested that you read the Understanding Tags section first.

SQLT Table Descriptions

Basic Concepts and Data Flow

Tags operate through tables created in the database.

Tag Execution Concepts

Polling – Many operations require polling of the database by either the driver or the provider. To ensure efficiency, all polling operations utilize indexed timestamp fields. This allows the database to do very little work when nothing has changed.

Tag Configuration – Tags are configured by inserting or modifying the appropriate entries in the configuration tables above. Configuration change is signaled to the provider by updating the configchange of sqlt_core to be the current time. Deleting a Tag works by setting its deleted column and then touching config change. This will inform all drivers and providers to remove the Tag from memory. At some point later, a daemon will delete the Tag information from the database.

Tag Execution, drivers – Each Tag has a drivername property that indicates which driver is responsible for executing it. Other drivers and providers with different names will treat the Tag as an external Tag – a Tag driven by a different entity – and will only monitor its value.

Tag Execution, scan classes – Each Tag is assigned to a scan class. The idea is that scan classes will define how often the Tag should execute, as well as provide more advanced options like leased and driven execution. In reality, the Tag driver is free to execute Tags as it desires, but it is important to understand how the scan classes and the sqlt_sci table are expected to work, as that is how the provider will verify that the Tags are being executed.

Tag Monitoring – Both providers and drivers generally monitor Tag value and configuration changes. In general, the entities will monitor Tags whose drivername isn’t equal to their own, which for providers means all Tags, since providers don’t have a driver name. Monitoring occurs by selecting the Tag values (or any information desired) from the appropriate table where one of the indexed timestamp columns is greater than the last checked time. The provider/driver will then store that time in memory as the last check, and will use it in the next poll.

Table Reference

The following is a reference list for the table structures of all the tables listed above. In general, all integer time values are in milliseconds.