Setting up queries

In addition to the binding queries, which set up a single query bql, neql or ord, you can add additional queries to a Queries folder. The schema turns the queries in this folder into a string.
  1. Create a regular schema.
    Image

    The example above uses the points of a BACnet device. This JSON configuration includes the Queries folder and the root object container for the schema.

    1. Identifies the regular queries that define the source of the data for binding. In this example, the query uses bql to identify the data.
    2. Identifies a query that can become a JSON string. The query result injects the query referenced from the Queries folder into the point in the schema output. You can nest these queries anywhere within your JSON message.

    By default, each schema includes a Queries folder, which comes with two properties: Query Interval (to configure how frequently to execute the query), and Last Query Completed Timestamp.

  2. To configure the Query Interval, right-click the Queries folder, click Views > AX Property Sheet, configure the interval, and click Save.
  3. To add an ad hoc query to the schema, expand the Query node in the palette, drag a Query from the palette to the Queries folder in the schema, double-click the Query, enter the Query Ord, and click Save.
    For simplicity, the example Queries folder contains a single query. It could contain additional queries.
    A above identifies the ord for the single ad hoc query (BacnetQuery): station:|slot:/Drivers/BacnetNetwork/MyName|bql:select name, proxyExt.objectId, out.value AS ‘v’, status from control:ControlPoint

    This query searches a particular BACnet device for the name, object ID, current value and status of all points under the device. The Last Result Size property indicates that the query finds two points.

  4. To create a bound query result, expand the Query node in the palette and drag a BoundQueryResult from the palette to the root object in the schema.
    In the example, the bound query result (identified by the second box) references the query (BacnetQuery) and defines the Output Style to render the query in.
  5. To update the payload message, click the Generate button.
The result of running the example query looks like this:
Figure 17.   Device connectivity JSON payload
Image

The first group of name and value pairs reports the result of the main binding query (under config). The data block at the bottom shows the result of the ad hoc query in the Queries folder. The data block displays as an object array identified by the square brackets. The array contains one object per BACnet point, in this case two objects, each inside a pair of braces.

This example could have used a relative schema. Which one to use depends on your requirements. Does your API need all data in a single JSON message or does it require one message per point? This procedure does not subscribe to the component model. It runs a bql query to populate the BITable and encodes that data. The power of bql to select data feeds into the input to the schema the same as you could feed a series transform into this schema, query the historical alarm data, or query history data.

This type of query configuration does not have to be done with device points. By “query” in this context, we mean anything that returns a BITable so you could use a transform ord, bql on the history space or neql on the component space. Any time you have something you can feed to the ReportService you can encode and output it with a schema.