Skip to content

Setup

Creating public API

Here we create two analytics to extract raw and bucketed data from the warehouse. To leverage KX Connect for some of the later examples, the Connect conventions will be used. Please refer to the KX Connect documentation for more details. These analytics may be utilised by a variety of clients.

Analytic Rules

Analytics must adhere to the following criteria.

  1. Naming conventions:

    • Analytic Groups should be named API.<groupName>.
    • Analytics should be named <groupName>.<functionName>.
  2. Analytic Group Entity requirements:

    • Must be a public Analytic Group.
    • API Analytics must be in Analytic Group.
    • Analytic Group must be permissioned for the calling user(s).
  3. Parameter requirements:

    • Input parameters must be in dictionary form.
    • Return value should be a table.
  • First, create an analytic group. Right-click on the KxWarehouse package in the Navigation pane and select New > Analytic Group from the context menu.

Screenshot

  • Name the analytic group adhering to the naming conventions.

Screenshot

  • Set the Visibility to public in the Analytic Group Parameters subtab.

  • Add the monPublic analytic group to the kxw_rdb, kxw_ihdb, and kxw_hdb.

Extract memory

This analytic will extract raw, un-aggregated data from the monMem table. It will be written to select data from that table across realtime, intraday and historical databases. It will be parameterised to filter by time and server names.

  • Add a new analytic to the API.monPublic group and name it .monPublic.getMem.
  • Add a description, a unique alias, connection and double check that the analytic is set public.

Screenshot

  • In the Parameters subtab, click Add and set the Parameter Values as type Dict. Click on the Value column to enter each key of the dictionary as below:

Screenshot

  • Set the Return Value as a table and use the schema monMem previously created. Save the configuration and check to see if it looks like this:

Screenshot

In the Content subtab, write the analytics to retrieve data from the monMem table.

The sample code can be found here:

Public API: getMem

Bucketed memory

This analytic will be written to extract bucketed memory data. It can again filter on time and servers but provides an additional parameter for the bucket interval (minutes).

  • Similarly, add a second analytic to the API.monPublic group and name it .monPublic.getMemBucket. The alias shoud be unique. This analytic will retrieve average data from the monMem table in intervals.

Screenshot

  • Set the Parameters to be a dictionary and add the following keys.

Screenshot

  • In the Content subtab, write the analytics to retrieve bucket data from the monMem table.

Public API: getMemBucket

Routed configuration

In order to define an analytic as routed, some configuration needs to be setup. The solution should create an override of the DS_QR_ROUTINGS parameter and add a row for the analytic name.

  • To create customized routing rules, create an override parameter.

  • Right-click the KxWarehouse package in the Navigation pane and select New > Parameter Override from the context menu.

Screenshot

  • Set parameter as DS_QR_ROUTINGS and name the override KxWarehouse. Hit Add.

Screenshot

  • In the editor window, click Add to create a row. This should open a pop-up. Enter .monPublic.getMem to the Analytic column and kxw_rdb; kxw_ihdb; kxw_hdb to Targets.

Screenshot

  • Do the same for .monPublic.getMemBucket and Save. It should look like below

Screenshot

QR gateway

The KX Delta Platform has provides interfaces into the QR framework, however it's not always possible for clients to use these. This is especially true for clients that only support sync communication (the framework is async only). To account for these cases, a QR GW process is provided as an access point.

Multiple of these processes can be deployed on a system for clients to connect directly to. These processes can be customized to use the in-built QR interface and serve data to clients.

The next sections will create a QR GW and some analytics to serve different clients.

Sync Requests

  • Create a service class and name it kxw_qr_gw. Save the service class without any configuration.

Screenshot

Analytics

  • Create a new analytic group and name it monCore.

  • Assign the analytic group to kxw_qr_gw process.

.mon.initGW

The process needs to define some handlers to log and execute WebSocket handlers so an initialization function will be created to do this on startup.

  • Create a new analytic within the monCore group and name it .mon.initGW.

  • Add the following to the Contents subtab. Save.

{[]
  .z.ws:{ value .j.k -9!x;  };
  .z.wo:{ .log.out[.z.h; "WS opened ",string[x]; ()] };
  .z.wc:{ .log.out[.z.h; "WS closed ",string[x]; ()] };  
 }
  • On the Service Params subtab of kxw_qr_gw, attach .mon.initGW to the initialStateFunct parameter. Hit Save.

.mon.getMemAsync

This analytic will be used to serve async clients via the QR.

  • Create a new analytic and name it .mon.getMemAsync.

  • Set the parameters to be id and dict.

Screenshot

Screenshot

  • In the Contents subtab, copy and paste the code below and Save.
{[id;dict]
  .qr.client.sendRequest[(`.monPublic.getMem; dict); `; {[h; id; res] neg[h] (`collectResults; id; res) }[.z.w; id; ]; ()!()];
 }

.mon.getMemSync

This analytic will be used to serve sync clients.

  • Create a new analytic named .mon.getMemSync.

  • Same as above; set the parameters to be dict.

  • Add the following to the Contents subtab and Save.

{[dict]
  .qr.client.sendSyncRequest[(`.monPublic.getMem; dict); `; ()!(); {[res] res }];
 }

.mon.getMemWS

This analytic will be used to serve WebSocket clients.

  • Create a new analytic named .mon.getMemWS.

  • Same as above; set the parameters to be dict.

  • Add the following to the Contents subtab and Save.

{[dict]
  dict:@[dict; `start`end; {"p"$"Z"$x}];
  dict[`syms]:except[; `] `$csv vs dict`syms;
  .qr.client.sendRequest[(`.monPublic.getMem; dict); `; {[h; res] neg[h] -8!.j.j .sd.r:res }[.z.w]; ()]
 }

Starting up server processes

Ensure the following processes are all running before proceeding.

  • ds_qr_a
  • ds_qp_a
  • ds_ms_a
  • kxw_tp
  • kxw_rdb
  • kxw_lr
  • kxw_ihdb
  • kxw_hdb
  • kxw_qr_gw
  • mon_feed
  • mon_agg