Using LiveView as a Front End

Contents

Overview

Overview

As a front end, LiveView can connect to other tools as data sources. LiveView can connect to the following back-ends:

  • Other LiveView servers in a federated system.

  • StreamBase Query Tables.

  • TIBCO ActiveSpaces spaces and metaspaces.

  • JBDC tables.

  • A user-written Custom Table Provider can provide access to an arbitrary source. See the TableProvider interface in the Java Client API Documentation for more information.

LiveView back-ends allow specific queries, based on their own capabilities. All table types can accept all simple predicates in queries.

Back-end Type Query Language Query Type Projections Streaming Modifiers Query Modifiers
Foreign LiveView Server LiveQL SNAPSHOT, CONTINUOUS, SNAPSHOT_AND_CONTINUOUS, DELETE *, exact field name, aggregate expression Time-delay, Time-window Top-N
StreamBase Query Tables StreamBase expression language

SNAPSHOT, CONTINUOUS, SNAPSHOT_AND_CONTINUOUS (not DELETE)

See Details below.

*, simple StreamBase expressions (which includes aliasing). None None
ActiveSpaces ActiveSpaces query language

SNAPSHOT, CONTINUOUS, SNAPSHOT_AND_CONTINUOUS, DELETE

See Details below.

*, exact field name.

ActiveSpaces query language does not accept single quotes around strings. Any strings must be delimited with double quotes.

None None
JDBC Tables SQL SNAPSHOT SQL projections None None

LiveView back ends support specific LiveView capabilities.

Back-end Type Publish Alert External host
Single Foreign LiveView Server Y Y Y
Multiple Foreign LiveView servers N Y Y
StreamBase Query Table N N Y
TIBCO ActiveSpaces Y N N
JDBC N N N

LiveView ships with an ActiveSpaces sample that you can use to get started with the integration of LiveView and TIBCO ActiveSpaces.

StreamBase Query Table Back-end Details

All Rows deletes do not report delete events to LiveView clients, but instead issue a new snapshot.

The Spotfire Streaming Query operator Delete All Rows option is an atomic operation that does not operate on individual rows, so there is only one event produced and reported back to the LiveView. One key difference between a StreamBase row-by-row delete and an All Rows delete is that the latter does not report the primary keys deleted, so there is no way for the LiveView layer to identify which rows are deleted and report that to the client. The only reporting action LiveView can take is to report a new snapshot. Also note that SNAPSHOT_BEGIN is used:

  • When a LiveView High Availability table becomes unavailable and the client is being moved to another copy of the table.

  • In the MulticonnectConfig Java client API to indicate the LiveView it was previously connected to became unavailable and the query is being moved to a different server.

There is no equivalent operation for native LiveView tables, so even running an lv-client clear TableName command results in one update per row back to the client. This is an architectural difference between StreamBase query tables and LiveView tables.

If individual row deletion events is important to a client, do not use Delete All Rows. Instead design the StreamBase application to use a Query Delete by Primary Index with Match Expression set for true. This reports each row deleted back to LiveView and reports individual delete events to any LiveView client application.

ActiveSpaces Back-end Details

SNAPSHOT_AND_CONTINUOUS queries to an ActiveSpaces table can have their result sets truncated without an error indication if the result set size is larger than the configured ActiveSpaces space QueryLimit. SNAPSHOT-only and DELETE queries will correctly report an error if the result set has been truncated by the configured ActiveSpaces space QueryLimit. See the ActiveSpaces documentation on how to configure the QueryLimit on a space.