What are the different ways to use parameters to set the different kinds of StreamBase Operator and Adapter properties?

The StreamBase Properties view shows the static configuration that the Operator or Adapter will start with and use for the entire session. 



This shows the parameter reference syntax (${PARAM}) for simple text fields and expressions.

In the StreamBase Module Editor, Parameters tab, are the parameters and their default values. 



This shows the parameter default values that will be used for immediate typechecking.
 

Property Data Types

Each property expects a certain type of value. The types are:

• text string (example, no-quotes: localhost ), a textbox
• numeric string (example: 10080 ), a textbox
• an expression that returns a string (example: getNodeName() ), a textbox
• an expression that returns a boolean value (example: ""!="${HOSTNAME}" ), a checkbox
• selection from a list of labels (examples, no-quotes: DEBUG, Round Robin ), a dropdown pick-list or set of radio-buttons
• grid of user-entered field names with or without associated text expressions (examples: Map operator, Schema tab), a text list or text grid

For example, the property types in the above picture of the StreamBase Properties view, are:

• (1) Database Type is a text string
• (2) Port is a numeric string
• (3) Start SQL Server Agent Service is a boolean true/false value
• (4) Log Level is a text string of an exact label value

Database Name can take a simple assignment from a parameter, but Start SQL Server Agent Service can take any expression that results in a boolean value. The ability to take a text value is identified by the  ([T]) annotation for properties that typically take a list selection or checkbox. The Log Level property must take only a simple text label value from a parameter instead of an expression.

To tell the difference between a field that takes a simple text string and one that takes an expression that returns a string type, try the expression without quotes and if a typecheck error is raised then the field expects an expression. A quoted string is an expression statement returning the string type. This includes functions that return a string, a text constant like "myhost" or an expression like "${HOSTNAME}" (with quotes).

The constant expression syntax is described in the product documentation here:
  TIBCO Streaming > StreamBase References > StreamBase Expression Language Features
  “Specifying Literals in Expressions”

How Parameters are Evaluated

In the Parameters tab the Default Value contents should all be simple text. When the ${NAME} parameter reference is evaluated in a Properties view field, the text of the Default Value contents is copied exactly, replacing everything from $ to } in the field. This result must evaluate to the expected field type to be valid. The default value provides a reasonable value so that typechecking succeeds within the Studio IDE while editing. The default value at runtime will be overridden by its Module element, Parameters property-tab, in the parent module, or the EventFlowDeployment moduleParameterSettings or containerParameterSettings configuration.

Parameters and StreamBase Operator and Adapter properties are evaluated once at startup. An operator property cannot reference a dynamic input such as an input tuple field or Dynamic Variable. Even when you provide an expression and the typecheck error reports that a name in the expression cannot be evaluated to an input field, an input field is never correct for an operator property value. References to input fields can only be allowed in grid controls.

Expressions provided in a grid control, like those found in a Map operator, the output of a Query operator, or Aggregate operator are always full EventFlow Expression Language expressions and may refer to any fields, Dynamic Variables, Constants, functions, or Parameters available within that operator’s scope. These are evaluated with every tuple.

Map Operator Example:


This is an example showing Map expressions using constants, parameter references, and expressions using tuple fields. The parameter references will have the same values as set from configuration for the lifetime of the engine within the node.

Properties That Should Not Take Parameters or Expressions

Some fields which can take an expression should not because they control the availability of operator ports (for example: the Distributed Router “Enable Completion Port”) or the contents of schemas (example: Kafka Consumer adapter “Enable Passthrough Fields”). These settings must have a static value that does not change by configuration because that would invalidate arc connections or invalidate downstream expressions that use the affected fields. Before parameterizing a field, check to make sure that all likely values do not result in schema changes or structural changes to ports and arc connections.
 

Configuration guidance