Export markers

Export marker: selecting control points

You select control points to export using:

Absolute ord bindings in a standard schema
Bql or neql in a relative schema
by adding an export marker to a component.

JSON export markers offer several benefits beyond just marking points to include in a relative schema. For example, you can use it to limit the export of alarm or history data related only to points with an export marker present. It can also store a unique identifier supplied by a third party platform. This can allow you to differentiate among registered points with an ID and unregistered points without an ID. An example use case is sending different payloads prior to registration including more detailed information (units, min/max, descriptive tags) than should be sent upon every change of value. When applied to a numeric point an export marker introduces a CovTolerance property to reduce unwanted updates from the station if a value changes only slightly. You can also use an export marker with incoming JSON payloads.

Here are some examples of relative schema configuration.

Base Query: station:|slot:/|bql:select * from jsonToolkit:JsonExportMarker
Example bound property binding ord: slot:.. (References the parent of the JsonExportMarker base)

Export marker filters

Both filters below have a Send Since action, which allows alarms or histories since a given date to be exported. This feature might be useful following network disruption or during initial commissioning of a system.

The Send Since action allows you to specify a start time. The linked schema considers only records stored on or since this time for output.

Two common filter properties are:

Current Export Id includes a description of the export marker if it is linked to a fixed string in the schema.
Count reports how many export-marked points were processed in the last invocation. It resets when the station restarts.

Alarm export marker filter

This filter selects specific alarms a station generates before the station passes them to a recipient. Typically, the recipient would be a JSON alarm recipient, but it could be SNMP, BACnet, etc. with the source alarm class linked to the In slot of the filter.

In the context of alarming the filtering occurs normally on alarms passed from the alarm class as they are generated.

Figure 15. Wire Sheet showing the use of an export marker filter

Filter mode	Outputs alarms
Marked With Id	If the source has an export marker present, with Id set
Marked	If the source has an export marker present
Pass All	All alarms
Block All	No alarms

In the context of alarming, the filtering occurs normally on alarms passed from the alarm class as they are generated.

The Send Since action queries the alarm database and passes existing records in to this filter (inclusive of the supplied timestamp) so that they can be checked for a suitable export marker and then passed to the receiving schema as required to create a new record for each alarm. The timestamp, being in the past, should help identify when this mode is active.

NOTE: To prevent an accidental data deluge, Send Since does not function if the filter is in Pass All mode. A bql query on the alarm database could be used if this is a requirement.

History export marker filter

This filter exports history data for points with an export marker.

The filter overlaps somewhat with the relative history query, which can select history for points using many different selection criteria, or an appropriate base query may also be used to generate history for each export marked point. The HistoryExportMarkerFilter allows updating of the timestamp stored on each export marker so that only recent history records are sent to the remote system (typically, records added since the last export).

The schema nested under the filter determines the payload format. To complete the export, link the output from that schema to a target transport point.

If one does not exist already, the HistoryExportMarkerFilter adds a new query to the Queries folder of the schema. This query needs to be referenced by a BoundQueryResult.

In the event that an export-marked point has more than one history extension beneath it, the schema exports each extension in turn.

In most cases, it is likely the Current Export Id property needs to be linked into the schema output to provide identifying information, or even the query used to select data may be included if the target system could infer useful data from it.

NOTE: Because the export marker relies on being added to a local control point in the station, it is not possible to match histories imported over BACnet or NiagaraNetwork using this method. Use a relative schema instead.

Use the Send Since Last Export action to send only unsent history data using the timestamp stored on each export marker.

These are some important filter properties:

History Export Filter is the schema that produces the output.
Current Query identifies the query fed into the schema below. The first query in the Queries folder is linked on start, does not have to be the only query, and is output first by the schema.
Columns sets up comma-separated values, for example, timestamp, value, status.
Update Send Since Time determines if the schema updates most recent send time when the schema generates data and enables sending only changed records on the next run. If true, every time the schema exports history it updates the timestamp stored on each export marker.