PreEmptive Analytics Workbench User Guide

Portal Architecture

The Workbench includes an easy-to-use website for viewing data, called the Portal. The Portal is backed by a data-rendering pipeline, which runs in the client browser as a JavaScript/HTML5 application. While the provided components of this pipeline work out-of-the-box for general application analytics, the Portal's real power lies in the ability to customize the way data is rendered, specific to your scenario.

This section of the User Guide describes how data-rendering pipeline works, and how to customize it.


There are four types of customizable components in the Portal's rendering pipeline:

  • Portal Queries define what data is requested from the Query Web Service.
  • Transformations allow manipulation of the data from Queries or other Transformations.
  • Widgets are a visualization of data from a Query or Transformation. Tables, charts, and graphs are all types of widgets.
  • Reports define a page in the Portal, including the Widgets, their layout, and how data on that page can be filtered.

Additional Portal settings, including which Reports are available to users, are found in the config.json file.

Rendering Pipeline

The components that make up the Portal form a dependency graph. For example:

Diagram of Rendering Pipeline

The Rendering Pipeline activates when a Report is loaded.

  1. The Report requests refreshed data from its Widgets, using the filters specified for the Report.
  2. Each Widget requests data from its source, either a Transformation or a Query.
    • This process occurs recursively for Transformations until only Queries remain.
  3. Each Query performs its request to the Query Web Service, using the filters specified originally by the Report. This populates the Query Dataset.
  4. Each dependent Transformation Dataset is populated recursively.
  5. When a Widget's source Dataset has been populated, the Widget renders the data in the Report (even if the other Widgets on that Report are not finished yet).

It is possible for an individual Widget to be refreshed, without refreshing any other Widgets in the Report or other Reports. However, the Portal does not allow users to refresh just one Report; clicking the Refresh button on the UI will refresh the current report and cause the others to be refreshed when navigated to.

Consider the different paths along the example dependency graph that are used when loading each report:

Diagram of Components used when different Reports are Loaded

A few things to note:

  • During a single loading sequence, each component activates at most once.
    For instance, though Query 1 (Q1) is needed by both a Widget and a Transformation, when Report 1 (R1) is loaded, it only activates once (and thus only sends one request to the Query Web Service), and the same information is shared to both of its dependents.
  • Transformations can depend on multiple components.
    This is possible by having multiple Datasets in a single Transformation. T3 is an example of this.
  • The way a field is referenced will be different depending on how it traveled through the pipeline.
    This is due to the way Transformation Datasets preserve their input's original data.
    Consider a field, FieldName, that Query 1 (Q1) defines. The name used to refer to it differs by the Widget:
    • Widget 1 (W1) refers to it as FieldName.
    • Widget 2 (W2) refers to it as data.FieldName, since it passed through a Transformation Dataset (in T2).
    • Widget 3 (W3) might refer to it as, or, if a zip transform was applied, it might be referred to by another name specific to Transformation 3 (T3)'s Dataset.
    • Note that this issue may be alleviated in Transformations by use of the copy transform.

Workbench Version 1.2.0. Copyright © 2016 PreEmptive Solutions, LLC