Steps
A Step is a "touch-point" within a website flow - it can be the loading of a page, a form submit, button click etc.
A Step consists of:
- A Trigger - to invoke the Step.
- Request Data Mappings - to optionally inject or extract data to/from the HTTP Request.
- Response Data Mappings - to optionally inject or extract data to/from the HTTP Response.
- A Workflow - to generate Features, execute Models and perform Decisioning on the Step.
Triggers
The Triggers section of a Step is used to specify which HTTP request will invoke the Step. This is typically done by matching the URL or the beginning of the URL (prefix match). Triggers can be very explicit matching only on an exact URL or they can be pattern based, matching multiple URLs. Triggers can be specified with the aid of the Darwinium Journey Assistant.
Invocation of the Step executes the Data Mapping, Workflows and (optionally) the recording of an Event for offline analysis.
Data Mappings
Data Mappings is where data can be injected/modified, processed or extracted. HTTP comprises a Request and a subsequent Response (to the Request).
The Data contained in the Request and the Response is different, so separate Mappings are provided for both.
Multiple standards exist for HTTP Data exchange, such as JSON, XML, URL query parameters etc. As such the Request and Response Data Mappings are very similar in appearance and operation, however the underlying Data is very different.
Request
Request Data Mappings operate on the HTTP Request before it is forwarded to the destination. Request Data Mappings consist of URL Mappings, Header Mappings and Body Mappings. All Request Data Mappings are optional, so only the required Mappings need to be configured.
Request URL Mappings
URL Mappings allow the extraction, injection and modification of URL data such as Host, Port, Path and Query Parameters. Data can be extracted for use in Decisioning or offline Analysis. The URL specifies the resource to be returned in the Response, so URL Data Mapping is specific to the Request.
Request Header Mappings
Header Mappings allow HTTP headers to both be extracted from and modified/injected into the HTTP Request.
Request Body Mappings
Body Mappings provide the ability to extract, modify and inject content from the HTML body within the HTTP Request Body.
Both single body and multipart body types are supported, making it possible to extract multi-part form data directly into Darwinium Attributes for Decisioning and offline analysis.
Data can be mapped from the body using XPATH for HTML/XML or JSONPath for JSON Content Types.
Data can also be injected into the HTTP Request Body using HTML, XPath or JSON Path to inject or modify data elements or inject template content before, after or overwriting the existing Body.
Response
Response Data Mappings operate of the HTTP Response before it is sent to the client (typically a browser). Response Data Mappings consistent of Header Mappings and Body Mappings only. All Response Data Mappings are optional, so only the required Mappings need to be configured.
Response Header Mappings
Header Mappings allow HTTP headers to both be extracted from and modified/injected into the HTTP Response.
Response Body Mappings
Body Mappings provide the ability to extract, modify and inject content from the HTML body within the HTTP Response Body.
Both single body and multipart body types are supported, making it possible to extract multi-part form data directly into Darwinium Attributes for Decisioning and offline analysis.
Data can be mapped from the body using XPATH for HTML/XML or JSONPath for JSON Content Types.
Data can also be injected into the HTTP Response Body using HTML, XPath or JSON Path to inject or modify data elements or inject template content before, after or overwriting the existing Body.
Workflows
Models
Generate Features
Features are numeric values computed on event history over time, that serve as inputs for both Machine Learning models and manually constructed Rule Based Systems. Features are given unique names so that they can be used by Models, other features and the Decision Strategy.
Features of a similar nature are typically grouped together in a single file known as a Feature Set.
Call URL
Call URL allow integration with third-party vendors and internal systems such as case management via RESTful API (HTTP). Attribute data from Darwinium can both be sent in the URL Request Body via injection and extracted from the Response Body.
Call URL supports HTML, XML using XPATH and JSON using JSONPath.
Request bodies can be constructed using static String Injections with variable substitution or templates for more complex scenarios.
Execute Code/Model/Rules
Multiple Rules, Models and Code blocks can be invoked during a Step.
Rules are Rule Based Systems that are constructed using the Darwinium Rule Builder.
Models are Machine Learning models which are are built using off line data analysis.
Code is native Assembly Script code, utilising the Darwinium Assembly Script API bindings.
All of these (Models, Rules and Code) are compiled into Web Assembly (WASM) code for native execution.
The Darwinium Orchestration Engine automatically computes all parts of the Step Workflow in the most efficient way possible by using Dependencies. For example, if a Model requires a certain Feature Set, then the name of the Feature Set is added to the Model as a Dependency.
Decision Strategy
The Decision Strategy is a Rule Based System that takes all of the Scores, Features and Signals and makes the final Decision (Result) as to the disposition of the Event - Pass, Challenge, Reject, Review, Alert etc.
The Decision Strategy also produces a Score and Signals for analytics purposes.
Proxy Actions
Proxy Actions are rules that enable to directly affect the customer journey. By using the conditional logic of the rule you can complete the following action called a proxy terminate:
- Accept
- Return with HTTP status code - Drop down available for all available status codes
- HTTP ReDirect - The URL for the redirect can be specified in the rules
- Silent Drop