- Index

< Previous |  | Next >

# LiveView Publish Output Adapter

## Introduction

The TIBCO LiveView® Publish output adapter allows a StreamBase application to publish data to LiveView tables.

This adapter is best used to publish real-time changes or updates to existing LiveView tables. For best performance of bulk populating data into a LiveView table, set up a `<data-source>` or `<publisher>` configuration element.

The adapter may be used to publish to tables for which the table name or table schema is not known at author time by using the Ad-Hoc mode. When in this mode, the table name is sent in the first element of the input tuple while the data to be published is sent as a JSON string in the second element. The JSON string does not need to contain all the fields of the table, any fields not present are considered to be null while any fields not in the table are ignored.

## Properties

This section describes the properties you can set for this adapter, using the various tabs of the Properties view for the adapter's icon in StreamBase Studio.

### General Tab

Name: Use this required field to specify or change the component's name, which must be unique in the current module. The name must contain only alphabetic characters, numbers, and underscores, and no hyphens or other special characters. The first character must be alphabetic or an underscore.

Adapter: A read-only field that shows the formal name of the adapter.

Class name: Shows the fully qualified class name that implements the functionality of this adapter. If you need to reference this class name elsewhere in your application, you can right-click this field and select Copy from the context menu to place the full class name in the system clipboard.

Start with application: If this field is set to Yes (default) or to a module parameter that evaluates to `true`, this instance of this adapter starts as part of the JVM engine that runs this EventFlow fragment. If this field is set to No or to a module parameter that evaluates to `false`, the adapter instance is loaded with the engine, but does not start until you send an epadmin container resume command (or its sbadmin equivalent), or until you start the component with StreamBase Manager.

Enable Error Output Port: Select this check box to add an Error Port to this component. In the EventFlow canvas, the Error Port shows as a red output port, always the last port for the component. See Using Error Ports to learn about Error Ports.

Description: Optionally enter text to briefly describe the component's purpose and function. In the EventFlow canvas, you can see the description by pressing Ctrl while the component's tooltip is displayed.

### Adapter Properties Tab

This section describes the properties on the Adapter Properties tab in the Properties view for the LiveView Publish adapter.

Property | Description
--- | ---
Set Server URI to encapsulating LiveView | Select this check box when the adapter is part of a LiveView project. In this case, the adapter connects to the port of the running LiveView server. When authentication is enabled, the credentials used to connect to the LiveView server are retrieved from the `liveview.internal.username` and `liveview.internal.password` system properties. The corresponding LiveView user must be configured with the appropriate permissions to allow this adapter to perform its operations.
LiveView Server URI | A LiveView server URI, or an expression or variable that resolves to a LiveView server URI. For example, the URI for the local machine and default port is `lv://localhost:10080`.
Ad-Hoc mode | When selected, the Target Table Name field is ignored. Instead, the name of the table to publish data into is taken from the first field of a tuple on the input port; this field must be a string and must contain a valid table name for the specifiedLiveView server (or must contain an expression that resolves to a valid table name). In addition, the second field contains the data to be published. This field takes the form of a JSON string. Any of the table's fields may be present in the JSON string. If an element is not present, it is assumed to be NULL. A `CQSDelete` or a requested delete field (Delete Field Name) may be present in the input schema and of type boolean. If so, is used to determine if this is a publish or delete operation. All other fields in the input tuple are ignored. The field, if present, must not be the first or second field of the schema. The `CQSDelete` or the Delete Field Name is ignored for delete purposes if present in the JSON. Enforce Strict Schema is disabled and assumed to be false.
Get table name from input | When selected, the Target Table Name field is ignored. Instead, the name of the table to publish data into is taken from the first field of a tuple on the input port; this field must be a string and must contain a valid table name for the specified LiveView server (or must contain an expression that resolves to a valid table name).
Target Table Name | The name of the LiveView table to publish data to. This control is ignored when the Get table name from input or the Ad-Hoc mode check box is selected.
Delete Field Name | If not empty, this field contains the name of the boolean field in the input schema to be used to indicate that the current tuple should be deleted or published. It is an error to have something in this field and an input field named `CQSDelete`, unless the field has the string `CQSDelete`. If the value of the named field is `true`, this is a delete action, otherwise it is a publish action. The field must exist in the input schema. If in Ad-Hoc mode, the field cannot be in the JSON string, it is only recognized when in the input schema.
Enforce Strict Schema | This control is ignored when the Get table name from input or Ad-Hoc mode check box is selected. When selected, the schema of the input port must exactly match the schema of the target table specified in the row above, except that the strict schema can contain an additional field of the name `CQSDelete`. Strict matching means the schemas must match each field's name and data type and in exact field order. When cleared, the input port accepts tuples with any schema. When used with the Get table name from input check box, the input port's schema's first field must be a string containing or resolving to the name of a table on the specified LiveView server.
Copy input to output | When this check box is selected, the adapter creates an output port that gets a copy of the tuple sent to the input port. The output tuples are sent regardless of the LiveView connection state. Default state is cleared.
Connect Inline | When this check box is cleared (the default state), tuples are sent to the target table after every Publisher Flush Interval. A background reconnection thread in the adapter continuously tries to reconnect to the specified server so that a connection is available when tuples need to be sent. However, a window can occur during which the server is actually up, but the adapter is disconnected, and the reconnection thread is waiting for its next connection attempt. This situation can cause a delay in having the freshest tuple information written to the LiveView table. To avoid this situation, select this check box. In this case, if the adapter is currently disconnected from the server, it attempts to reconnect inline each time a tuple or batch of tuples is ready to be sent to the target table. Use this feature carefully, because, while it can speed up the freshness of live data on the server, it can also cause long application delays while each connection is attempted.
Publisher Buffer Size | The number of tuples to buffer before forcing a network write to the target table.
Publisher Flush Interval (ms) | The maximum number of milliseconds that can elapse before each tuple or batch of tuples is written to the target table.
Log Level | Controls the level of verbosity the adapter uses to send notifications to the console. This setting can be higher than the containing application's log level. If set lower, the system log level is used. Available values, in increasing order of verbosity, are: OFF, ERROR, WARN, INFO, DEBUG, TRACE.

### Concurrency Tab

Use the Concurrency tab to specify parallel regions for this instance of this component, or multiplicity options, or both. The Concurrency tab settings are described in Concurrency Options, and dispatch styles are described in Dispatch Styles.

### Caution

Concurrency settings are not suitable for every application, and using these settings requires a thorough analysis of your application. For details, see Execution Order and Concurrency, which includes important guidelines for using the concurrency options.

## Using the Adapter in a StreamBase Application

The LiveView Publish adapter has an input port that accepts tuples to be published to the target table, and a status port to provide information about connection status.

As with other StreamBase adapters and operators, you can optionally enable an Error Output Port, as described in Using Error Ports and Error Streams.

### LiveView Publish Adapter Input Port

If Enforce Strict Schema is set, the schema of the PublishIn input port must exactly match the schema of the LiveView table specified in the Target Table Name control. In this case, fields must match by exact, case-sensitive field name and data type, and in exact field order. However, even with Enforce Strict Schema set, the input port's schema can also contain an extra boolean field named CQSDelete. If the value of this field is `true`, then the primary key fields set in the tuple are used to look up and delete the specified row in the table.

With or without Enforce Strict Schema, tuples sent to the PublishIn input port do not need to specify data for every field. You can leave any field null if you only need to update a few fields in the LiveView table.

If Enforce Strict Schema is cleared, then the schema of the PublishIn input port can contain any field names and data types, within the following guidelines:

- The schema of the PublishIn port can contain any subset of the fields of the LiveView table or tables to which this adapter instance is to publish or delete rows. If a table has many fields, but you only expect to publish updated data to a few of those fields, then only the few target fields need to be in the schema.

- If Get table name from input is also selected, then the first field of the input schema must be a string that contains or resolves to the valid name of a LiveView table on the specified LiveView server.

- To successfully use the Get table name from input feature, the second and subsequent fields of the PublishIn port's schema must be a union of the names and data types of all the fields you expect to update in all the LiveView tables that you expect to name at runtime in the first field. For maximum flexibility, you can specify the full schema of each LiveView table you might name in first field. Or, if you know in advance the fields you expect to update in each table, then you can specify only those fields in the schema.

- After the first field, the order of fields in the PublishIn port's schema does not matter. Fields are matched by name and data type, not field order.

- If any field has the same name and data type in two or more LiveView tables, you only need to specify it once in the PublishIn port's schema; since the table's name is specified in the first field, the input tuple is matched only against that table's instance of the like-named field.

Deletions are triggered by the use of either a `CQSDelete` field or a field named by the Delete Field Name property. These fields are optional, but if a `CQSDelete` field is present, the value of Delete Field Name must either be empty or have the value `CQSDelete`. The field must be of type `boolean` and if true, the row determined by the publish data is deleted. Any other value results in a publish action. Except in the case of Ad-Hoc mode or if Get table name from input being checked, these fields may exist anywhere on the top level of the input tuple, for those, they must come after the required fields.

When in Ad-Hoc mode, the input must have at least two fields. The first field must be a `string` and contains the table name or an expression which resolves to a valid table name. The second field is a JSON representation of the data to be published. Any field in the JSON which exists in the table will be sent, any field which does not exist in the table will be ignored and any table field which is not present will be set to `null`. Additional fields may be present in the input and will be ignored except in the case of `CQSDelete` or a valid value in Delete Field Name.

### LiveView Publish Adapter Output Ports

The LiveView Publish adapter has one output status port. For each publish request sent as an input tuple on the adapter's input port, a connection status report tuple is emitted on the status port. For each publish request that fails, an error tuple is emitted:

- A CONNECTION message shows the success or failure of the connection to the LiveView server.

- For failing publish requests, a PUBLISH message shows FAILED or ERROR it its Action field, with an explanatory note in the Message field.

The status port has the fields shown in the following table:

Field | Data Type | Description
--- | --- | ---
Type | string | The basic state reported, always one of the following:
CONNECTION | PUBLISH
ERROR |
Object | string | The name on the EventFlow canvas of the adapter reporting the status.
Action | string | The action that occurred, one of the following:
CONNECTED | ERROR
FAILED |
Message | string | A human-readable string that provides additional context for the status message.
Time | timestamp | The time the publish request or error occurred.

### Adding the Adapter to an EventFlow Application

Add an instance of the adapter to a new EventFlow application with the following steps:

1. In StreamBase Studio, create a project, including an empty StreamBase EventFlow application file to host the adapter.

2. From the Operators and Adapters drawer of the Palette view, drag the Adapters, Java Operators icon to the canvas. This opens the Insert an Operator or Adapter dialog.

3. In the search field, type a string such as `liveview` to narrow the list of adapters. Select the icon for the LiveView Publish adapter, then click OK.

4. Double-click the adapter's icon and select the Adapter Properties tab in the Properties view.

5. Next, either:

   1. If this adapter is part of an EventFlow module that is itself part of a LiveView project, select the Set Server URI to encapsulating LiveView check box. This check box tells the adapter to connect to the host and port for the current project's LiveView server.

   2. Or specify the URI for a local or remote LiveView server to connect to (or accept the default URI, `lv:/localhost:10080`).

6. Add an Input Stream and connect an arc from it to the LiveView Publish adapter's input port.

7. Specify a schema for the Input Stream that matches its intended use, as described in LiveView Publish Adapter Input Port.

8. Add an Output Stream and connect an arc to it from the LiveView Publish adapter's output port.

9. At runtime, send a tuple to this module's input port, specifying the a tuple to publish to the specified LiveView table.

## Typechecking and Error Handling

The LiveView Publish adapter uses typecheck messages to help you configure the adapter.

The adapter generates warning messages at runtime under various conditions, including:

- The configured schema of this adapter does not match the LiveView table, if the Enforce Strict Schema option is set.

- The configured LiveView server is not available.

## Suspend and Resume Behavior

When suspended, the adapter stays connected to the LiveView server, but no longer processes input tuples. On resume, the adapter continues to process new input tuples.