Overview of KNS
From KynetxDocs
Contents |
Rulesets
A Kynetx app consists of one or more rulesets that comprise one or more rules.
Rules
A rule is selected when its select statement is true. Once selected, the rule's prelude is evaluated to declare variables and the rule action is performed. Actions can be conditional in which case the action is only performed if the condition is true.
Rules can declare callbacks which specify certain user actions to watch for and what to do when the user takes those actions.
Rules can also have a postlude that is used to modify persitent variables and log events after the rule has fired.
Other Ruleset Information
In addition to rules, rulesets contain
- Meta Block - The meta block contains information about the ruleset such as:
- Name - The name of the app.
- Description - A short description of the app.
- Author - The author of the app.
- Logging - Whether or not to output verbose logging information.
- Dispatch Block - This block tells the endpoints when to plant the initialization tags for this app.
- Globals Block - This part of the ruleset is global in the sense that all other parts of the rule can access the data which has been declared in this block.
Execution Model
A Kynetx app is fired, or run, by a service call to the Kynetx Rule Engine (KRE). This is typically done through an endpoint, such as a browser extension (BX) or proxy. The following diagram shows the Kynetx Network System (KNS) process.
The endpoint has three distinct phases:
- Preperation - The endpoint makes a call to the dispatch API to get the instances in which to fire this rule.
- Wait - The endpoint then watches for a situation to fire the rule on. When it does see a rule, it then makes a call to the KNE services.
- Finalize - When the endpoint is closed (such as a browser) or shutdown (such as the proxy), cleanup needs to occur. This is done during the finalize phase.
When A Rule Fires
When a Kynetx app is fired, three things happen.
- Initialization - The app data and other such variables are set up and prepared.
- Evaluation - The app is evaluated and ran.
- Callback - Any information that needs to be sent back to KNS is, such as if it was a success, if foo occured, etc.
Initialization
The initialization phase configures and initiates the KRE call.
Configuration is performed by adding a script tag to the page that defines the KOBJ_config object like so:
<script type="text/javascript">
var KOBJ_config ={
"rids" : ["kntx_rulealert","kntx_rulealert_2"],
"init" : {"eval_host" : "cs.kobj.net","callback_host":"log.kobj.net"},
"key_1" : "value_1",
"key_2" : "value_2"
};
</script>
The config object must contain an array names "rids" that contains the RIDs of rulesets applicable to this page. The config object can also contain an optional object named "init" that can override the URLs of the eval and callback host. The "init" object will not be included under most circumstances.
The other components of the config object are parameters that will be passed to the ruleset when it is evaluates. These can be read and tested using the page:env function in KRL (without the namespace designation). Parameter names should be namespaced by prepending RID with a colon (:) separator like so:
var KOBJ_config ={
"rids" : ["ruleset_1","ruleset_2"],
"ruleset_1:ex_param" : "3",
"ruleset_2:ex_param" : "5",
};
Parameters that aren't namespaced will be treated as global and will be seen in all rulesets identified in the "rids" array.
After the config object as been added to the page, the evaluation is initiated by adding this tag to the page:
<script type="text/javascript" src="http://init.kobj.net/js/shared/kobj-static.js"/>
This initializes the calls to the KRE system.
Evaluation
After the script tags are planted by the endpoint, the ruleset is evaluated. This is done by having a Javascript returned which is generated from the Kynetx Rule Language.
Callback
Some app designers want or need information based on what occurred during the evaluation. This is done during callback phase.
