8) Cross Model Abstraction Reference

This Blog entry is from the Getting Started in Jube section in Learn Jube.

The Cross Model Abstraction Page allows for the retrieval of Abstraction Rule values from other Entity Models. Cross Model Abstractions are a useful means of cross model communication alongside TTL Counters, which can also be incremented across models. A Cross Model Abstraction Value fetch is the process of retrieving the most current execution of a transaction in another model for that entity value. For example, if there are two models which share the same entity (e.g. an Account Identifier) yet they process inherently different data, the values created in Abstraction Rules in one model can be referenced in another model. Cross Model Abstraction Rules are one means of communicating between models with another possible means being TTL counters.

The page is available by navigating through the menu as Entity Models >>> Abstraction and Fitting > Cross Model Abstraction Reference. The page is presented as a tree objects for the purposes of administering a model child objects:

1.PNG

The general administration of this tree is as documented in the child object section of this documents, with the fields as defined follows:

Name

Description

This Example

Model

The name of the model that the required Cross Model Abstraction belongs to. The model will be integrated for the most recent Abstraction Rule values for the last transaction for the Entity Key.

Traffic

Abstraction

The Abstraction Rule to be returned from the most recent Abstraction for the Entity Key.

Is_Windows

If following the Blog entries step by step, there exists only one Entity Model at this time, hence there would not be a Entity Model available. For the purposes of demonstration, a second model titled Account Non Monetary Events has been created. The second model processes audit events from customer accounts, such as change of address:

2.PNG

With the following Request XPath configuration example:

3.PNG

The IP is specified as a Search Key. A simple Abstraction Rule has been created in the new model, which counts up all events on an IP:

4.PNG

For completeness, a some events have been processed through the new Entity Model, but that is outside the scope of this Blog Entry however, the AccountID element as the same value as contained in the Account Financial Transaction messages taken from the formats document (Rich16).

5.PNG

Return to the Cross Model Abstraction Reference and create an entry as per the parameters set out in the table above and the following:

6.PNG

Click the Add button to create a version of this Cross Model Abstraction Rule:

7.PNG

On recalling the Account Financial Transactions XML Post, it can be see that an entry has been created reaching into the value created in the new model:

8.PNG

It can be seen that the Abstraction Rule has been returned and merged as if it were originating from the same entity model.

7) Abstraction for Fraud Prevention using Account Financial Transactions.

This Blog entry is from the Getting Started in Jube section in Learn Jube.

The In Model Abstraction Rules page is where rules are created for the aggregation of data available in the Cache. The Abstractions Rules functionality is one of the most intrinsic processes in the Entity Model processing being responsible for the creations of aggregate statistics based on the content of the cache of data retained for that model. The abstraction rules are grouped together by their search keys.

A search key is a value that will be used as a predicate in retrieval of data for the subsequent execution of Abstraction rules that use that search key. For example, if a transaction is being processed through a model, if an account identifier is configured to be a search key, a selection of all records in the model cache will be returned where that account identifier matches (put simply it will return all transactions for that customer account). Search keys are defined in the Request XPath definition and there can be many search keys - thus cache database queries - per transaction being executed through the model. The process is different when a Search Key is defined to be retrieved from a cache, as these values are pre-calculated by the Search Key Cache thread, documented extensively in its own right.

Firstly, Search Keys need to be set up, in this example IP, by revisiting the Request XPath page via Entity Models >>> References >>> Request XPath:

20.PNG

Expand on the mode tree on the left hand side to expose all Request XPath for this model, then click on IP:

2.PNG

For the Request XPath, click the checkbox titled Search Key:

3.PNG

With Search Key having been checked, click on the Update button towards the base of the page:

4.PNG

With a search key now being available, navigate through the menu as Entity Models >>> Abstraction and Fitting >>> In Model Abstraction. The page is presented as a tree objects for the purposes of administering a model child objects:

5.PNG

Click on the model towards the left hand side to add an Abstraction Rule:

6.PNG

The Page exists to create Abstraction Rules which are code fragments will will be compiled into the Jube Engine. Abstraction Rules accept data and TTL Counter objects and tests the code fragment for equality, returning a boolean flag to that effect. The Rule and Code Constructor Comprises the following:

Name

Description

Data

The fields created in the Request XPath page and Inline Scripts (if allocated).

TTL Counters

The TLL Counter and their current incremented values.

The page accepts the following parameters in the construction of Abstraction Rules:

Name

Description

This Example

Scope

The scope whether the rule is to be executed on a list of records having been returned from the Cache or only upon the transaction currently being processed through the model. None would imply that the scope of the Abstraction Rule is only the current transaction being processed and if it matches, then a 1 will be returned, otherwise zero (keeping in mind that Neural Networks will seek to weight it, hence the numeric values). If Entity Search would imply that a retrieval from the Mongo Datbase need be taken place and the Abstraction Rule is going to be tested against each transaction returned.

Entity Search

Search Key

The Search Key is the basis for several data retrievals to be made of the Mongo Database. For example, if a Search Key is specified to be an IP, then it would imply that a select is going to be made of the Mongo Database for all transaction matching on the IP of the current transaction thereafter applying the Abstraction Rule on each of the records to test for a match.

IP

Search Interval

The Search Interval is the time threshold reaching back from the Reference Date for the transaction being processed whereby only transactions exceeding this threshold are eligible for matching. For example, if a Search Interval is configured for 1 Day (taking the Search Interval and Search Value together) then this would imply that only records greater than the Reference Date minus One Day is eligible. It is worthy of note that the Search Interval and Search Value are not used in the recall from the Mongo Database, that will still return everything matching on the key up to the fetch limit specified in the model definition. The Search Interval is taken together with the Search Value.

d

Search Value

As Search Interval, with the Search value being comprising the length of time to reach back from the Reference Date.

1

Offset Type

All data matching on a search key is retrieved from the cache. The Offset type helps to select data from a subset of these records. This can be helpful if analysis need be done only on the last x records, for example. In most cases it will be set to none.

None

Offset Interval

The number of intervals to be offset by, for example the last x number of records returned from the cache.

3

Function Type

The process of aggregating the matches is different from the process of testing and matching the Abstraction Rules itself. The process of aggregation takes place after all matching has take place and the transaction matches for the rule have been set aside. The Function Type is the aggregation type to take place and is extensively documented in the Abstraction Function Definitions of this document. For example, if a Sum function is specified, then the function will look to count up records using the Function Key field (e.g. Transaction Amount).

Sum

Function Key

The Function Key is available only on certain Function Types and represents the fields inside the transaction that are to be used for aggregation. For example, if the Sum Function Type is specified and the Function Key is specified as the Transaction Amount, the aggregation will seek to create a Sum for all of the Transaction Amounts. In the case of a Count, no Function Key would be available, as the Function Type would seek to count up the matches only.

CurrencyAmount

Complete the page with the parameters as prescribed above, setting a rule to match on everything:

7.PNG

Click the Add button to create a version of this Abstraction Rule:

8.PNG

Allow the platform a couple of moments to syncronise then post an Account Financial Transaction:

9.PNG

It can be seen that the sum of all events in the last day has been aggregated, and this will increase on each event. This value is available for subsequent rules.