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.

2) Introducing Postman

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

Integration can of course be accomplished by any tool or programming framework that facilitates HTTP interactions with a web server (e.g. .Net, Java, PHP etc). For testing it is quite common to use a HTTP Post Tool, Utility or Client application. Jube has created a page to support manual testing of HTTP messaging in the application, called Postman.

To navigate to Postman, navigate through the the menus Administration >>> HTTP Post Tools >>> Postman:

1.png

The Postman page will be presented:

2.PNG

There are three input parameters worthy of discussion in this Blog entry, keeping in mind that subsequent Blog entries will set about posting to the pre-configured models. The first parameter is represented as radio buttons and select the format of the message to be posted:

3.PNG

The Format option has no bearing on the message being submitted to the server via HTTP and only serves to tell the page how to format the input in the code editor, which affords certain parsing and formatting in the input box.

The second parameter is the URL that the message is to be posted to, which hard codes the Jube https://api.jube.io endpoint and query string delimiter, then expects only querystring parameters separated by the & character:

4.PNG

The final parameter is the Request body, which accepts ether XML or JSON to be posted to the endpoint alongside the querystring parameters:

5.PNG

An important consideration when deciding to use the embedded utility over another tool is that all requests and responses are logged to a database available to Jube support staff. Should any requests not behave as expected, then Jube support can provide more timely intervention having access to the messages and internal error messages.

As mentioned, there are several pre-configured models which exist for the purposes of training and integration testing and comprise the content of several subsequent Blog entries.

1) HTTP Endpoint Request Payload and Switching

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

The Jube Platform does not have a hard-coded API specification and the HTTP Endpoint is promiscuous in the format of the GET or POST body that it accepts, with that POST body being parsed as per a specification configured in each Symbol or Entity model.

The POST body may be XML or JSON, in any structure, with its precise structure being configured in the Entity or Symbol model definition of Jube. It of course follows that the XML or JSON should pass a parse on receipt of the POST, appropriate to the specification. When the Jube Engine receives a HTTP request, the POST body is not initially inspected or parsed, instead only the Query String of the HTTP request is inspected for the presence of switching keys.

An example of a HTTP request to the Jube Engine is as follows:

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

In the above url the following parameters are implied:

Component

Text

Description

SSL Encryption

http:// or https://

The http SSL designator which is used to encrypt HTTP traffic using SSL.

Endpoint

api.jube.io

The IP address or sub domain name for which HTTP posts are to be made.

Port

:443

The colon designating a nonstandard port to be used, followed by the port.

This is not needed, but is included for completeness.

Query String Delineation

?

The model to be invoked for the purposes of processing the POST body is passed in the query string, everything that follows the ? will be considered model parameters.

Model Type Switch

EntityAnalysisModelGUID=

While there are several parameters available in model recall, such as the ability to process a model asynchronously, for the purposes of this document there is a single parameter of EntityAnalysisModelGUID which, by virtue of its presence, switches to the entity subsystem and will seek a GUID as follows.

GUID

253e427e-4523-40d2-b155-fcd5348e20e9

The GUID of the model, created automatically on model insert.

Switching, depending up the presence of a given Switch key, takes place in the following order:

Switch

Description

Symbol

A switch to be made to the Symbol Subsystem to process a new Symbol (e.g. Stock Price).

ExhaustiveSearchInstanceGUID

A switch to be made to the Exhaustive Subsystem to recall a trained model, bypassing the Entity Model and Symbol Model processing.

EntityAnalysisModelGUID

A switch to be made to the Entity Subsystem to process a new Entity (e.g. Account Transaction).

EntityAnalysisModelGUID and Tag

A switch to be made to process a Tag for a given transaction previously processed through an Entity Model.

Although the endpoint for all requests made to Jube is the same, the processing is very different depending upon the switch.

Jube has several pre-configured models for the purposes of validation, integration testing and confidence building. These pre-configured models will be explored in subsequent Blog entries. The pre-configured models and example switches and formats are contained in the formats document as follows:

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

The formats document provides examples of messages routed by each switch set out above.