The TIBCO® LiveView Create or Drop Table output adapter allows a StreamBase application to create, start, and drop LiveView tables dynamically on running LiveView servers.
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.
Name: Use this required field to specify or change the name of this instance of this component, which must be unique in the current EventFlow 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 options: This field provides a link to the Cluster Aware tab, where you configure the conditions under which this adapter starts.
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 Editor canvas, you can see the description by pressing Ctrl while the component's tooltip is displayed.
This section describes the properties on the Adapter Properties tab in the Properties view for the LiveView Create or Drop Table adapter.
|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 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
|Share LiveView Connection||When selected (the default), this instance of the adapter shares a single LiveView connection to the configured LiveView server with all other LiveView adapters in the same container that also have the Share LiveView Connection property selected.|
|Connect Inline||When selected, if the adapter does not currently have a LiveView connection to the configured server, it will attempt to connect immediately. This will block the application or concurrent region until the connection attempt succeeds or times out. Note that if the adapter is not currently connected there is a background thread that is periodically attempting reconnects. Thus, Connect Inline is only operable for a small timing window between when the background thread makes the LiveView connection and if a tuple arrives just before the background thread attempts the reconnection.|
|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.|
Use the settings in this tab to allow this operator or adapter to start and stop based on conditions that occur at runtime in a cluster with more than one node. During initial development of the fragment that contains this operator or adapter, and for maximum compatibility with TIBCO Streaming releases before 10.5.0, leave the Cluster start policy control in its default setting, Start with module.
Cluster awareness is an advanced topic that requires an understanding of StreamBase Runtime architecture features, including clusters, quorums, availability zones, and partitions. See Cluster Awareness Tab Settings on the Using Cluster Awareness page for instructions on configuring this 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.
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.
The LiveView Create or Drop Table adapter provides one input port, and two output ports:
The input port is used to send Create, Start, CreateStart, or Drop commands to the adapter.
The Status output port emits tuples that provide information about each table command, and the status of the connection to the configured LiveView server.
The other output port is a passthrough output of the input tuple.
As with other StreamBase adapters, you can optionally enable an Error Output Port, as described in Using Error Ports and Error Streams.
The input port is used to send Create, Start, CreateStart, or Drop commands to the adapter. Refer to the LiveView dynamic table documentation for more information about state transitions when creating, starting, and dropping tables.
The input port's schema is shown in the following table. When sending a tuple to unregister an existing query, use only the first and last fields.
The table command to execute which must be one of the following strings:
|TableName||string||The name of the table to operate on. This field must be set for all commands.|
|Indices||list<list<string>>||Defines the indexes for the table for use with the Create command. The inner list is a comma-separated list of field names that comprise a single index. The first list<string> in the outer list is the primary key for the table, while subsequent list<string> are secondary indexes. For example, an Indices value of list(list( "MyLong", "MyString"), list("MyDouble")) will create a table with primary key of MyLong,MyString and a secondary index of MyDouble.|
|Description||string||An optional text string for the Create command which is to be included in the Description field of the LiveView server's LVTables system table.|
This string defines the schema of the table to be used with the
Create command. The string
format is a comma-separated list of name-data type pairs, the whole
enclosed in parentheses. For example,
|WaitTime||int||The number of milliseconds to wait before declaring a timeout when Creating, Starting, or Dropping a table. If null, the default is 180,000 ms. This default can be changed by setting the system property streambase.adapter.lvcreatedrop.waitMS.|
If non-null, the table being created is an aggregate table and this field
should have a fully specified LiveQL select statement that uses aggregate
functions. For example,
|Synchronous||boolean||If true, do not emit the output pass-through tuple until the command completes, whether successfully or in failure. If null or false, emit the pass-through tuple immediately. In any case, the success or failure of a command is reported on the status port.|
|TableConfig||tuple||Optional. A tuple that contains all the advanced dynamic table creation configuration information.|
The adapter can import a proposed schema for the input port that you can use as a starting point.
To import an input schema, click the Import proposed schemas hyperlink in the top right corner above the Adapter Properties tab. From the dialog, click Browse to select an existing destination interface file, or click New File to save a Named schema file to a project folder.
The TableConfig tuple has advanced table creation feature configurations. The tuple fields are defined in the table below.
|SaveInProject||boolean||If true, save the tables to the server even after the restart of the LiveView server.|
|ShortDescription||string||A short description for the table being created.|
|RowDeleteRule||string||An optional rule specifying a predicate that is evaluated against the data in any incoming insert or update. If the incoming data satisfies the predicate and a row with a matching primary key exists, then no update occurs and the row is deleted. If the incoming data satisfies the predicate and no row with a matching primary key exists, then no insert occurs. If the incoming data does not satisfy the predicate, then an insert or update occurs as normal.|
Used for retention policy to specify a condition when the rows present in
this table are to be deleted. Set one of the following Table Delete Rules:
|SnapshotParallelism||int||Defines the number of table partitions and the number of parallel regions used to scan a table during the snapshot portion of a query.|
|SnapshotConcurrency||int||Defines the maximum number of snapshot queries (one per thread) within a partition that are executed at once.|
|PersistenceFolder||string||Used to set the persistent folder where this table will be persisted.|
|PersistenceRestoreDataOnStart||boolean||If true, recovers the data is to be restored after the table is restarted.|
|FilteredTableAliases||list<tuple>||A list of FilteredTableAlias tuples used to specify an alias format string that will provide a new name pattern for data that matches the predicate filter specified. See the FilteredTableAlias tuple fields definition for details.|
|Variables||list<tuple>||A list of variable tuples that can be used in both test and assignment expressions in the FieldRules. If there is a non-trivial expression that will be used more than once in the evaluation of FieldRules, then use a Variable to save the value of that expression. Note that all Variables are evaluated for every insert and update of every value. Variables can also be the target of assignments in RuleCases, if there are expressions that only need to be evaluated for certain cases.|
|FieldRules||list<tuple>||A list of field rule tuples that will be evaluated on every insert or update. See FieldRule tuple fields definition for details.|
Defines a list of fields that will contain case-insensitive values. If a
field is specified as case-insensitive, for example,
The FilteredTableAlias tuple contains configuration information that specify an alias format string that will provide a new name pattern for data that matches the predicate filter specified. The tuple fields are defined in the table below.
|Filter||string||A predicate string that when it is matched, a new name pattern specified in field Formatter will be generated.|
An alias format string. For example,
The Variable tuple contains variable configuration information. It can be used in
both test and assignment expressions in the FieldRules. If there is a non-trivial
expression that will be used more than once in the evaluation of FieldRules, then
use a Variable to save the value of that expression. Note that all Variables will
be evaluated for every insert and update of every value. Variables can also be the
target of assignments in RuleCases, if there are expressions that only need to be
evaluated for certain cases. For example, if there is a variable
var, you can put
current.var in an
Assignment tuple Value field to access the current value of variable,
|Name||string||The name of the variable.|
|InsertInitialValue||string||Initial value on an insert operation. As of 10.6.0, this field is currently not supported.|
|UpdateInitialValue||string||Initial value on an update operation. As of 10.6.0, this field is currently not supported.|
A FieldRule is a list of cases that will be evaluated on every insert or update. A RuleCase represents one case for a FieldRule, with a test, a list of assignments for an insert operation, and a list of assignments for an update operation. The first case whose test is true will be executed. If none are true and there is a default case, that case will be executed. If the RuleCase used as default includes a test, the test will be ignored. The FieldRule tuple fields are defined in the following table.
|Description||string||The description of this field rule.|
|DefaultCase||tuple||A default RuleCase tuple. If none of Cases are true, it will be executed.|
|Cases||list<tuple>||A list of RuleCase tuples used by this field rule. The first case whose test is true will be executed|
A RuleCase represents one case for a FieldRule, with a test, a list of assignments for an insert operation, and a list of assignments for an update operation. The first case whose test is true is executed. If none are true and there is a default case, that case is executed. If the RuleCase used as default includes a test, the test is ignored. The RuleCase tuple fields are defined in the following table.
|Test||string||A predicate string. If true, this rule case may be executed.|
|InsertAssignments||list<tuple>||A list of Assignment tuples that will be executed on an insert operation if Test is true.|
|UpdateAssignments||list<tuple>||A list of Assignment tuples that will be executed on an update operation if Test is true.|
An Assignment tuple represents one assignment to either a Field or a Variable. The fields are defined in the following table; you must set at least one of FieldName or VariableName.
|FieldName||string||The field name that the value will be assigned to.|
|VariableName||string||The variable name that the value will be assigned to.|
|Value||string||Required. The value that will be assigned.|
The LiveView Create or Drop Table adapter has one output status port and one through tuple output port.
The status port has the fields shown in the following table:
The basic state reported, always one of the following:
|Object||string||The name on the EventFlow canvas of the adapter reporting the status.|
The action that occurred, one of the following:
A human-readable string that provides additional context for the status
message. TABLE_* actions always start with
|Time||timestamp||The time the action occurred.|
The LiveView Create or Drop Table adapter has an output port that uses the schema of the input port and passes on the input tuple either immediately if not Synchronous, or delayed until the command action is completed if Synchronous — whether the command completes successfully or in failure. In all cases, the success or failure of the command is determined by looking at the status output port.
Add an instance of the adapter to a new EventFlow application with the following steps:
In StreamBase Studio, create a project, including an empty StreamBase EventFlow application file to host the adapter.
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.
In the search field, type a string such as
liveviewto narrow the list of adapters. Select the icon for the LiveView Create or Drop Table adapter, then click .
Double-click the adapter's icon and select the Adapter Properties tab in the Properties view.
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.
Or specify the URI for a local or remote LiveView server to connect to (or accept the default URI,
Specify the other options in the Adapter Properties tab as required.
Specify a schema for the input port, as described in LiveView Create or Drop Table Adapter Input Port.
Add two Output Streams and connect arcs to them from the LiveView Create or Drop Table adapter's output ports.
At runtime, this LiveView Create or Drop Table adapter connects to the specified LiveView server and is then ready to accept commands.
The LiveView Create or Drop Table adapter uses typecheck messages to help you configure the adapter.
The adapter generates warning messages at runtime under various conditions, including:
The configured LiveView server is not available.