2) Request XPath for Fraud Prevention using Account Financial Transactions.

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

In previous Blog Entries and Entity Model was configured to consume XML and extract some important parameters from the XML body (but it could also be JSON).

When a request is received from a HTTP Endpoint for a model it will have data contained within either the Querystring or more likely the POST body of the request. Depending on whether the Message Type has been configured to be XML or JSON will determine the parsing algorithm to be applied to it. Once parsed data can be extracted from using either XPath or JSON Path. The Request XPath page is where model fields are specified alongside their position in the POST Body or the Querystring. Various other parameters specifying how this field should be processed by the model are included also.

The page is available by navigating through the menu as Entity Models > References > Request XPath. 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 section of this Blog, with the fields as defined follows:

Name

Description

This Example

Priority

The processing priority of the Request XPath which is useful if there are two fields of the same name, but looking at different elements in the payload.

0

Hash Entity Key Composite

A flag that specifies the field to be used in composite with other fields flagged in the same way. During transaction processing all fields which are flagged as such will be concatenated together before being hashed using MD5. This hashed value will become, hence overwrite, the value extracted as per the model definition. It is useful in the absence of a guaranteed unique value in the transaction yet also where storage of the data (i.e. PII) has regulatory restriction.

False

Hash Entry Key Composite

A flag that specifies the field to be used in composite with other fields flagged in the same way. During transaction processing all fields which are flagged as such will be concatenated together before being hashed using MD5. This hashed value will become, hence overwrite, the value extracted as per the model definition. It is useful in the absence of a guaranteed unique value in the transaction yet also where storage of the data (i.e. PII) has regulatory restriction.

False

Hash Entry Key Composite Sequence

Reserved for future use.

False

Hash Entity Key Composite Sequence

Reserved for future use.

False

Payload Location

A switch that specifies the location of the data for this field. If Body is specified then the Xpath field will be targeted at the parsed POST body whereas if Querystring is specified the XPath field will expect only the name of the Querystring value.

Body

XPath

Depending upon whether the Querystring of Body is targeted, the location of the data to be extracted. In the event that Querystring is specified as the Payload Location then it will require the name of that Querystring value. In the event that Body is specified as the Payload location then it will require XPath or JSON Path depending upon the Message Type.

//IP

XPath Expression

An expression has special meaning in the XPath language and allows for calculations to be performed in XPath (for example creating an average of several fields). This flag specifies if the XPath is an expression rather than a selector, allowing it to deal with the slightly different return type.

False

Search Key

If the field is flagged as a search key it allows the value extracted to be used to query the cache in the Abstraction Rule processing. For example, if a count of all transactions having taken place on an IP address are required, this would be flagged as a Search Key which would mean that during execution the value extracted in this process will be used as a predicate in a select from the Cache (i.e.All from Cache where Cache IP = This IP).

False

Cache

For a Search Key to retrieve data for each transaction it can place significant load on the Mongo Database and Engine and is quite impractical if there might be extremely large amounts of data available for that Search Key (e.g. consider a Merchant with millions of transactions a day). A Search Key Cache defers the processing of these Search Keys to a background engine to process each of the possible Search Keys, saving the calculations off to a Cache, with that Cache being referenced real-time rather than the raw data.

NA

Cache Key Interval Type

The Cache Key Interval Type is the date interval taken together with the Cache Key Interval Value which specifies how frequently the Cache Keys should be recalculated (but even then, it is only done on new data).

NA

Cache Key Interval Value

The Cache Key Interval Value is the date interval taken together with the Cache Key Interval Type which specifies how frequently the Cache Keys should be recalculated (but even then, it is only done on new data).

NA

Cache Key Sample

In order to reduce processing demand in the calculation of Search Keys, a representative sample can be specified to reduce the number of records brought back for each possible search key. All distinct search keys will be processed but only a sample of data for that search key value will be returned. In most cases a sizeable representative sample is perfectly adequate.

NA

Fetch Limit

For each distinct search key value, the maximum number of transactions that can be returned from the Mongo Database for calculations to be performed.

NA

Cache Key TTL Interval Type

The Cache Key TTL Interval Type is the date interval taken together with Cache Key TTL Interval Value and is how long a distinct Search Key, once calculated, should live before being purged from the Cache.

NA

Cache Key TTL Interval Value

The Cache Key TTL Interval Value is the date interval taken together with Cache Key TTL Interval Type and is how long a distinct Search Key, once calculated, should live before being purged from the Cache.

NA

Data Type

The data type of the data being extracted from the HTTP Request. The data type specified is important as it effects the types of predication that can take place in the rules. Possible values are:

String: Text and General Data

Integer: Numbers without any decimal places

Float: Numbers with decimal places.

Date: Date and Time.

Boolean: True or False

String

Encrypt At Rest

If the encrypt at rest flag is specified it means that the data for this field will be encrypted using an AES key stored in the Engines configuration file just prior to it being committed to the database. Upon retrieval of the data, the field will be decrypted such that its contents are available in memory.

Please check with support that this option is enabled.

False

To add a new Request XPath, click on the Entity Model recently created in the top of the tree to the left hand side:

2.PNG

Complete the fields with the value as set forth in the table above, being certain to set the Response Payload flag to ensure that the extract value is returned for testing:

3.PNG

Clicking Add to create the first version of the Request XPath for this Entity Model:

4.PNG

Allow the platform a few moments to syncronise the new Request XPath across all of the nodes, then repeat the HTTP Post as described in previous Blog Entries using Account Financial Transactions.

5.PNG

Notice how the IP is present in the response payload which would indicate that the IP was extracted from the request, processed and then included in the response payload.

This Blog entry should be repeated for each element required in processing and available in the XML POST.

In the event that the request payload if of JSON format, the approach would be the same except in place of XPath, JSON path would be used.