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.

3) Posting XML and JSON in Postman

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

To develop a familiarisation in messaging the Jube platform a number of models are pre-configured in the platform with their messaging formats available in the following document:

http://download.jube.io/formats.pdf

These formats serve to introduce message formats the the different switches that are available to message processing. These formats will also be used regularly in subsequent Blog entries.

In this Blog entry, an Account Financial Transaction will be explored.

Firstly an XML post will be made with the querystring key value pair as follows:

EntityAnalysisModelGUID=253e427e-4523-40d2-b155-fcd5348e20e9

This querystring key value pair would be used in concert with the full endpoint specification if it was called from a programming language or a external HTTP post tool or utility:

https://api.jube.io?EntityAnalysisModelGUID=253e427e-4523-40d2-b155-fcd5348e20e9

To get started with the XML message, navigate to Administration >>> HTTP Post Tools >>> Postman:

1.PNG

In this example, XML is going to be posted. Click the XML radio button to ensure that the XML is formatted in the Postman page properly:

2.PNG

In the Format field, enter the querystring Key Value pair:

EntityAnalysisModelGUID=253e427e-4523-40d2-b155-fcd5348e20e9
3.PNG

Using the formats document, in this example, copy the Sample XML Account Financial Transaction section of the Formats document:

4.PNG

Pasting it into the Request code editor in the Postman page of Jube:

5.PNG

The code editor will parse the XML and give an indication of errors in structure. The message is now ready to be sent to the https://api.jube.io endpoint. Click the POST button:

6.PNG

The Postman page will simply relay the post to the https://api.jube.io endpoint as if it were being called from a programming environment or alternative HTTP post utility. The response will be written out to the response code editor:

7.PNG

The response XML is written out to the Response code editor, formatted as XML. Furthermore the response time is recorded, which is 6 milliseconds in this example, alongside the HTTP response status of 200 (success).

Refresh the page by navigating to Administration >>> HTTP Post Tools >>> Postman then proceed to repeat this process using JSON as follows.

Jube accepts both XML and JSON via the https://api.jube.io endpoint. Sending JSON messages is the same as XML, except the code editor would need to be changed to JSON by clicking on the radio button in the format section of the Postman page:

8.PNG

Although the switch is the same, a different value is used containing instructions on how to parse the JSON. In the formats field enter the querystring key value pair as follows:

EntityAnalysisModelGUID=7e5f96df-5a9b-4e13-a007-e02d79f970b3
9.PNG

This time, use the Sample JSON from the Account Financial Transaction section of the Formats document:

10.PNG

Pasting it into the Request code editor in the Postman page of Jube:

11.PNG

The code editor will parse the JSON and give an indication of errors in structure. The message is now ready to be sent to the https://api.jube.io endpoint. Click the POST button:

12.PNG

The response JSON is written out to the Response code editor, formatted as JSON.

It can be seen that Jube is able to accept both XML and JSON over the https://api.jube.io endpoint. The endpoint is described as being promiscuous in this regard and simply expects the the XML or JSON to be valid, and parse on receipt.

Make note that the structure of both XML and JSON is comprised of elements which can be referenced using XPath or JSON Path respectively.