Description

The Sky Event API is used to raise events to the Kinetic Rules Engine (KRE). Because the Sky API has the concept of unique entity identity built into the API, each event raised using the Sky API is raised on behalf of a particular entity. This concept enables personal event networks. The Sky API follows the Evented API specification. The API implements event signal URLs (ESLs). 

Event Schema

The event schema includes the following components:

• channel identifier (<eci>) - a token that is used by the system to identify the entity and channel for whom the event is being raised. To work within KRE, the eci must be associated with a valid Kinetic Entity Number (KEN).  See Event Channels for details. 
• event domain - the namespace for any given event
• event type - the individual events within the namespace. The word name is often used interchangably with type in this documentation and elsewhere. 
• attributes - any given event may include attributes that further define the event
• event ID  (<eid>) - a unique number assigned by the endpoint raising events to the event for correlation purposes. The endpoint is free to make the <eid> any value so long as it is URL encoded. 

Event Signal URL (ESL)

The components of the event are encoded in an event signal URL as follows:

The schema is either http or https.

The domain name depends on the server processing the events. For Kynetx, the domain name is cs.kobj.net. 

The path is encoded as follows:

  /sky/event/<eci>/<eid>

If <eid> is not given, the engine will generate a random EID. 

Signaling Events

Endpoints raise events to KRE by making an HTTP call to the ESL. The HTTP call may be either a POST or a GET. POST is preferred. 

The following key-value pairs are used:

Keys with a leading underscore are reserved. Attributes are encoded a key-value pairs in the usual way. 

When sent as the body of an HTTP POST the attributes must be encoded using one of the methods shown in the following table. Note that the Content-Type header must be set to the appropriate mime-type for the event consumer to understand the message.

If the body is JSON-encoded, the encoding should be a JSON object containing the keys and values as follows:

{“_domain” : “web”,

 “_name” : “pageview”,

 “urls” : [“http://www.exampley.com/foo/bar.html”,

           “http://www.google.com/search”]

}

The key-value pairs are encoded as query string parameters if a GET is used. 

Asynchronous vs Synchronous Event Processing

When the _async attribute is present and has the value 1, the event generator is signaling the event engine that events may be processed asynchronously and that no response is expected. 

When events are processed synchronously, the results of the processing, either a JSON-encoded directive document or a JavaScript program is returned to the generator. Actions in KRL are responsible for creating the response. 

If the generator (which may be another KRL rule) does not require a response, it can add the _aync attribute to indicate that the rules engine can process the event asynchronously. The rules engine will return immediately and process the event in a separate thread. This is most useful when the end goal of the event processing is a side-effect, either to a persistent variable or some other Web API. The event:send() action raises asynchronous events by default. 

Alternate Encoding

To make it possible to use the Sky API in systems that use generalized Webhooks to perform callbacks, an alternate encoding is available. In the alternate encoding, the event domain and type may be put in the path of the ELS as following:

  /sky/event/<eci>/<eid>/<domain>/<type>

If an ESL is encoded this way, and also specified the domain and type in the attributes (i.e. in the body of the POST), the attribute specification will override the path specification. 

If you choose to not provide an <eid> in this form, you can supply none as the EID to force the engine to generate a unique EID for the event.  

  /sky/event/<eci>/none/<domain>/<type>

Status 

Active