General Migration Notes

For reference when dealing with StreamBase installations older than 7.5.0, the following sections document the default locations for StreamBase assets.

C:\Program Files (x86)\StreamBase Systems\StreamBase.n.m

C:\Users\username\Documents\StreamBase Studio n.m Workspace

C:\Users\username\AppData\Roaming\
StreamBase\StreamBase Studio n.m.x

C:\Users\username\Documents\StreamBase Manager n.m Workspace

C:\Documents\username\Documents\
StreamBase Manager n.m.x

Applications/TIBCO StreamBase CEP n.m.x

$HOME/streambase-studio-n.m-workspace

$HOME/.streambase/streambase-studio-n.m.x

$HOME/streambase-manager-n.m-workspace

$HOME/.streambase/streambase-manager-n.m.x

/opt/streambase

$HOME/streambase-studio-n.m-workspace

$HOME/.streambase/streambase-studio-n.m.x

$HOME/streambase-manager-n.m-workspace

$HOME/.streambase/streambase-manager-n.m.x

If you used a previous release of StreamBase Studio on the target machine, create backup copies of your existing Studio workspace and configuration directories, before using StreamBase Studio in the current release. Save the backup copy with filenames that indicate the version number of the release you are archiving. For example, save SB-workspace-7-6-04.zip.

The default location of the StreamBase Studio workspace directory on OS X for Studio 7.5.0 and later is the following:

/Users/sbuser/Documents/StreamBase Studio n.m Workspace

Using Studio 7.4.x and earlier, the default Studio workspace directory is:

/Users/sbuser/streambase-studio-n.m-workspace

You may have specified a different directory the first time you ran StreamBase Studio.

For 7.5.0 and later, the StreamBase configuration directory is stored in a version-specific directory under $HOME/Library. This folder is hidden in Finder by default; either enable hidden files in Finder Preferences, or navigate to the same folder in a Terminal window:

/Users/sbuser/Library/Application Support/com.streambase.sb.sbstudio/n.m.x/Configuration

For Studio 7.4.x and earlier, the configuration directory is:

/Users/sbuser/.streambase/streambase-studio-n.m.x

In these paths, n.m are the major and minor release numbers of the currently installed StreamBase release, and x is the service pack release number.

The field-grids sample illustrates how fields specified with the Include and Add actions, and local variables created with the Declare action, can be used in both simple and aggregate expressions in output grids. It also shows how to avoid typechecking errors by properly qualifying field names. Prior to release 7.5.0, fields added using the Add action could not be used in expressions within the same field grid, but that restriction was lifted. See Field Grids Sample for more information regarding this sample.

The Iterate operator to emit one tuple for each element in a list. You specify a field of type list in an incoming stream, and the operator emits one tuple for each element in that field's list.

The Iterate operator acquired its output field grid in StreamBase Studio 7.4. Previously, values for each iteration were placed in a prepended output field, the name of which the Output Element Field Name parameter on the Operation Settings tab specified. This parameter was removed in favor of the flexibility of a field grid, which enables any number of output fields to be defined. When running or editing older EventFlow applications that use Iterate operators, the current version upgrades applications by adding a field with the specified Output Element Field Name to the output field grid using the expression each.element to capture the current element. See for Using the Iterate Operator more information about the operator.

As explained in Aggregate Operator: Field-Based Dimension Options, with a field-based dimension, a new window is established and evaluated based on the value of a numeric field in the incoming tuple. A tuple containing the results of the aggregation is emitted and typically the window is closed when a tuple arrives whose field value exceeds the specified range of the open window. The arriving tuple that triggered the close is placed in the next window.

With a time-based dimension, a new window is managed and evaluated based on the time a tuple arrives. A window closes and emits when the period specified in the Close and emit after expression elapses, even if no tuple arrives. Prior to StreamBase release 7.4, an input tuple was required to close any time-based window in a Field or Time dimension.

A dynamic variable is a variable you can declare for a StreamBase module that can thereafter be referenced by name in expressions in operators and adapters in that module. In the declaration, you can link each dynamic variable to an input or output stream in the containing module. In versions of StreamBase Studio prior to 7.4, you had to create an input or output stream before you could define dynamic variables. After StreamBase Studio 7.4, you can define dynamic variables before creating a stream, as explained in Using Dynamic Variables.

Also, while placing a stream on the canvas before creating a dynamic variable is normal practice, as of version 7.4.0 it is not a requirement. Updating streams do not need to be connected to any other component, but can be used on their own to update dynamic variables. In the event you do not want a dynamic variable to be updated by any stream, leave the input stream field empty.

As explained in Supported Configurations, TIBCO supports and recommends the Zing ZDK, version 14 or 15, from Azul Systems for use with large heap and/or low-latency StreamBase and Live Datamart applications. For releases 7.3.1 through 7.3.7, your license for those systems included access to only the Zing versions bundled with StreamBase. If you are maintaining one of these StreamBase releases and plan to upgrade, please contact Azul Systems to obtain a compliant ZDK version.

As explained in Running Applications in Studio, if one EventFlow application references a second EventFlow application in the same subfolder within a project, to run the application you must add the subfolder to the module search path. One symptom of failing to do this is receiving a "module not found" message from the debugger when attempting to step into a referenced module. This behavior differs from StreamBase Studio 7.3.x and previous releases, in which applications in subfolders that referenced other one could run without adding the subfolder to the module search path.

When using a module marked as non-hygienic, the schema of the input to the Module Reference automatically overrides the schema defined in input streams in the module. Non-hygienic modules were formerly referred to as flexible modules in previous releases. See Hygienic and Non-Hygienic Modules for more information.

All modules and interfaces created in releases before 7.2.0 are non-hygienic, and they retain that setting when imported into release 7.2.0 or later.

When comparing two Query operators or two states of one Query operator in Studio's EventFlow Compare Editor, you may see the following warning at the top of one side of the comparison:

The Query operator's design changed in major ways at StreamBase release 7.2.0, in the number and names of tabs in its Properties view, and in the internal XML structure. Query operators created in releases before 7.2.0 are silently upgraded to the new format when opened, changed, and saved in the EventFlow Editor for 7.2.0 or later.

This message occurs when you try to compare a Query operator created in or upgraded to the 7.2 XML Query operator structure to an earlier version of the same operator, or to a similar Query operator, that is still in the XML format for a previous release. Because the underlying XML formats are so different, no meaningful comparison can be drawn in graphical form. This is especially true for comparisons of the Fallback tab, which did not exist before release 7.2.0.

Workarounds

There are two workarounds for this condition:

The Lock and Unlock operators and the Lock Set data construct are deprecated as of StreamBase 7.2.0 and will be removed in a future release. Do not design new applications that use this feature. Contact StreamBase Technical Support if you need help with replacing this feature in an existing application.

As explained in Using Modular Configuration Files, you can break a complex server configuration file into fragments, and then assemble a top-level configuration file by including smaller fragments into the top-level file. This feature allows for greater reusability of standard or site-specific configuration file settings, and allows you to quickly switch between different configurations for development, testing, and production environments.

Include files are supported only for server configuration files, and not for any other StreamBase file type. For example, you cannot include the contents of a StreamBase deployment file into a server configuration file.

Include file support is provided in two ways:

TIBCO recommends using the <sb-include> element over XIncludes.

You use <sb-include> and XInclude differently in server configuration files, depending on your StreamBase release:

The schema of the StreamBase error tuple changed starting with release 7.1.0. The primary difference is that the originalTuple field in previous releases was of data type blob, but is now of type string. This change causes a typecheck error in any module created with an earlier release, when loaded into StreamBase 7.1.0 or later, if the module uses Error Streams or error ports.

StreamBase provides a Java system property and environment variable that directs StreamBase Server to emit error tuples using the schema of previous releases. You can set this property to continue working in 7.1.0 or later with a large application in which several modules emit and manipulate error tuples. When you have migrated all modules to take advantage of the new schema, change this system property or environment variable to specify the new error tuple schema.

You can either set the system property for the JVM that will host StreamBase Server or set the environment variable in the environment in which StreamBase Server will run.

There are several features in StreamBase Studio that help you detect and eliminate any schemas or constants imported into a module that are not currently being used by that module. Minimizing Module Imports describes these features in detail.

When invoking the Remove Unused Imports wizard using StreamBase 7.1.x, the following menu option is at the top level of the EventFlow menu:

Select to make the module of interest currently active in the EventFlow Editor, then select EventFlow → Refactor → Remove Unused Imports from Studio's top-level menu.

The Map to sub-fields of tuple fields option appears in two places in StreamBase Studio:

In StreamBase releases before 7.0, this option was labeled Map to Leaf Fields. For more information about this option, see Map to Sub-Fields Option.

You can view performance statistics for a running StreamBase application, such as the number of tuples each operator processes per second, the time required to process each tuple, and how much CPU time is used by each thread.

StreamBase monitoring utilities from the 6.x release family cannot connect to and monitor StreamBase Servers from a 7.x release. If you receive an unable to connect or Monitoring is disabled on this server message, try again using a 7.x monitor utility.

StreamBase provides the following ways to monitor StreamBase applications:

Profiling is a subset of monitoring that extracts and analyzes performance statistics about the operators and queues in a running application. Profiling can occur interactively while an application is running, or separately, using a file of collected statistics.

You can also create your own performance monitor client utility using the StreamBase monitoring API, as described in Developing StreamBase Monitor Applications.

StreamBase monitoring utilities from the 6.x release family cannot connect to and monitor StreamBase Servers from a 7.x release. If you receive an unable to connect or Monitoring is disabled on this server message, try again using a 7.x monitor utility.

The StreamBase Java Client library uses SLF4J, the Simple Logging Facade for Java, for all internal logging. TIBCO encourages customers to use the same logging system when developing your custom embedded Java adapters and Java operators. Logging is described in Using StreamBase Logging.

A change in format of logback.xml files between StreamBase 6.x and 7.x means that Logback configuration files that worked well with a 6.x release will continue to work with StreamBase 7.x, but at the cost of a dozen WARNING messages emitted that urge you to switch to the <encoder> format in your configuration files.

For more complex Logback configuration, there is an online wizard for generating Logback configuration files that makes basic logging setup straightforward. The online wizard generates Logback configuration files using the syntax for older versions of Logback that used the <layout><pattern></pattern></layout> format. This is appropriate for configuration files used with the Logback version shipped with StreamBase 6.6.x. For use with StreamBase 7.0.x, convert those layout patterns to <encoder><pattern></pattern></encoder> as illustrated in the logback.xml file in the logging-logback sample.