7) Code Construction Widget

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

Several pages in the platform rely on the construction of code and in all cases this is facilitated by a point and click construction tool or direct freehand code (yet heavily restricted with only certain language functions being allowed). In most cases the code is of vb.net dialect, unless it is used for reporting or Adaptation training in which case it is an SQL fragment.

The following example is taken from the Entity Models Activation Rules page, which can be navigated to via Entity Models >>> Activation >>> Activation Rules, then selecting any child:

1.PNG

The default is Builder which uses a point and click interface to build up the vb.net code.

The Rule Constructor takes the form of Object, Field, Comparison and Value. Depending upon the Rule that is being constructed, different Objects will be available. Hovering over the Data Object, there are a large amount of fields available for selection:

2.png

Upon selecting an Object field, the Comparison operator can be specified. The operators differ depending the area of the platform and how the model is configured:

3.png

Finally, the Value can be specified for comparison:

4.png

Upon each update made to the Rule and Code Constructor, the code fragment is written out to the code window:

5.PNG

Having the code written out in this manner is rather easier to review and also helps to identify if there are any obvious issues that would leads to compilation issues. Toggling to Coder, using the radio buttons towards the top of the the Code Construction Widget, it becomes possible to create code by hand:

6.PNG

When typing in code, every second and on change, the code is sent to the server to be parsed, returning any errors that may exist at that point of code construction:

7.PNG

It is incumbent on the user to continue constructing and correcting the code, until it is declared to be ‘Parsed and Compiled’:

8.PNG

Only a small number of tokens from the vb.net language are allowed in the Coder for security reasons.

As aforementioned, the Code Constriction Widget mostly creates vb.net dialect code, with the exception of the Adaptation page, which can be navigated to via Entity Models >>> Adaptation and Prescription, with an arbitrary child selected as follows:

9.PNG

In the case of Adaptation, the code is an SQL fragment which helps build a data set that is intended for machine learning:

10.PNG

It is not possible to update the Adaptation with hand crafted code.

6) Response Payload

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

All children have the option to specify if it should be specified as being a Response Payload. A Response Payload means that the content or value created by the object will be returned to the HTTP response stream, otherwise excluded. It is a means to reduce the amount of bandwidth that is used for extremely large models and thus speed up transport of the response message:

1.PNG

Irrespective of the Response Payload being selected, the value will still be stored in the archive database.

5) Name and Description

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

Each parent and child object entry will have a Name field, which is a character string accepting a maximum of 50 characters. A description field appears on a more irregular basis and is a character string accepting a large number of characters.

1.PNG

The Names for the object should always be unique for that object, for example each Abstraction Rule should have a unique name, whereas the description is of freehand.

4) Locked and Active

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

For every parent and for every child there exists an Active and Locked flag:

1.PNG

Both the Active and the Locked flags form part of the record and are updated in the same manner as the rest of its properties.

The Active flag provides a means to deactivate an object without having to delete it. In most cases deactivating a child object has a very similar behavior to deleting it, insofar as the entry will be unavailable for processing.

The Locked flag may be toggled in just one direction, Locking a record. If a record is Locked it means that all subsequent editing of that record is completely barred and the records is presented a read only. Locking records is useful to avoid the inadvertent update or deletion of important records. An example of objects that once created should not be deleted are Abstraction Rules which are in use my an Adaptation, as the alteration of these Abstraction Rules would render the results of the Adaptation inaccurate. Another example is ensuring that the Request XPath configuration, once created, remains unchanged such is the importance of these values in maintaining real time interfaces into the Jube Platform:

2.PNG

In the above example, note how the Update and Delete buttons are no longer available.

3) Child Versioning

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

For children there is a version system in place. When a record is created for a child object, it is always accompanied by version data:

1.PNG

The fields that relate to version of children are descried in the table as follows:

Name

Description

Version

The version in a sequential number that indicates the extent to which this record has been updated. Upon a record being created, it is allocated version 1, then for each update (i.e. click of the update button) the version will increment by one.

User Created

The name of the user that last created or updated this child record.

Created Date

The date and time this record was last created or updated.

For children all update and deletes are done on a logical basis, which means that they are marked as deleted in the database but still remain there for the purposes of audit. When a child record is updated, in actuality the record being updated is logically deleted and a new record with the incremented version number is created. It follows that there is record for each update maintained in the database.

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.

2) Menu Navigation

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

Navigation in the Jube platform is performed by a Menu, where each Menu item will redirect the user to a specific page to administer a specific part of the Platform:

menu-items-in-jube.png

In the above example, navigating to the Request XPath screen would be refereed to as Navigate to Entity Modes > References > Request XPath, navigating firstly to the Entity Models menu item:

the-entity-models-menu-item-in-jube.PNG

Then, the References sub menu item:

the-references-menu-item-in-jube.PNG

Then, the Request XPath sub menu item (in fact, this is both JSONPath and XPath):

the-menu-item-to-navigate-to-xpath-in-jube.PNG

Upon clicking on the menu item, in this case Request XPath, the whole page will be redirected away from the Activation Watcher to the Entity Models Request XPath page:

5.PNG

1) Logging into Jube.

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

If you have not already done so, create an account in Jube using the simple registration form. An account will be created straight away, although it may require a security check to be activated. You can check the status of your account using the support page or chat application.

Navigate to the login screen in Jube from the home page by clicking on the link, towards the left hand side:

Login

the-jube-home-page-showing-the-link-to-login.png

If you are using a local installation of Jube, your link will be different and you will need to contact your system administrator.

Once navigated to the login screen, which can also be access directly from https://ui.jube.io/Login/Login the following screen will be displayed:

2.PNG

The login page needs to authenticate the user via a User Name and password. Insert the User Name and Password, in this case Example and a correct password:

the-jube-login-page-with-an-example-username-and-password.PNG

Clicking on Login or pressing the Enter key will submit the form and attempt to authenticate the user, keeping in mind that in this case, the password is incorrect:

a-bad-username-and-password-in-jube.PNG

In the event that there is a problem with authentication and it fails, an error message will be returned in red below the login controls. In this example, repeat the process albeit with valid credentials:

5.PNG

A successful login will navigate to the Activation Watcher page as default.