• Introduction
• Modules in an EventFlow Application Diagram
• Modules in a StreamSQL Application
• Related Topics

A StreamBase EventFlow or StreamSQL application may incorporate any existing Application Diagram or StreamSQL Application as a modular component. To emphasize this point, you should refer to Application Diagrams and StreamSQL Applications as modules. The advantages you gain by using a modular approach to building complex StreamBase applications are the same as those that are gained by following an object oriented approach in any programming language:

• Code readability
• Code encapsulation
• Incremental testing
• Code re-use

When writing general purpose modules, for example, unique ID generators, it is advantageous to write the module such that it does not need to be modified prior to use in another application. That is, you want to avoid the situation in which you must edit the module's schemas in order to use the module in a new application. StreamBase provides an easy solution to this problem.

When a module is incorporated into an application, you can specify that schemas corresponding to module input should be overridden by the schemas associated with the application streams that feed tuples into the module. To effectively use this design pattern, the schema associated with a module's input stream must be a subset of the schema defined on the application stream. That is, the module stream's schema includes some, but not all, of the fields defined in the application stream's schema. The module accesses the tuple fields required for its processing and passes the additional fields, unaltered, to the tuple emitted from the module.

To ensure that the additional tuple fields are passed unaltered through the module requires attention to how you configure operators, or write StreamSQL statements, which can control the schema of their outputs. These operators, and StreamSQL statements, have two modes of operation.

• Explicit — where the output fields are listed by name and only named fields are passed to the output
• EventFlow Operator Output Settings Tab — Explicit Mode



• StreamSQL Statement — Explicit Mode

SELECT ID AS patientID, HeartRate AS bpm,
       BodyTemp AS temp, RespirationRate AS resp FROM...

• Implicit — where all input fields, as well as optionally added fields, are passed to the output without specifically listing every field by name
• EventFlow Operator Output Settings Tab — Implicit Mode



• StreamSQL Statement — Implicit Mode

SELECT *, 200 AS MaxHeartRate, 60 AS MinHeartRate,
       101.0 AS MaxTemp, 95.0 AS MinTemp,
       25 AS MaxRespirationRate,
       12 AS MinRespirationRate FROM ...

To ensure module reusability you need to avoid the explicit mode, as any fields not listed in the output schema will be lost from the emitted tuple.

This article will describe how you can use the ability to override a module's schema to increase the reusability of your modules.

Modules in an EventFlow Application Diagram To use an existing EventFlow or StreamSQL module in another EventFlow Application Diagram, simply drag its file entry from the Projects view, Application Diagrams or StreamSQL Applications directory onto the Application Diagram's canvas. StreamBase Studio will add a Module Reference icon to the Application Diagram. Then select the Module Reference icon to open its Properties view and on the Input Ports tab, check the Override module input schemas with incoming schemas checkbox.

Now the schema of tuples received on any of the module's input ports may differ from the schema defined on the associated input stream within the module. Of course, any field that the module uses in its processing must also be defined within the overriding schema, but any additional fields within the overriding schema will be passed unaltered to the module's output.

Modules in a StreamSQL Application While overriding module input schemas is optional in an EventFlow Module Reference, this behavior is the normal, and unalterable, mode of operation for modules incorporated into a StreamSQL application. This is best illustrated by considering an example.

The following StreamSQL statements, contained in a file named module.ssql, implement the module's functionality.

  CREATE INPUT STREAM InputStream (field_name1 field_type1);
  CREATE OUTPUT STREAM OutputStream AS
    SELECT * FROM InputStream;

If this were run as an independent application, the tuple emitted to the output stream would have one field named field_name1 of type field_type1.

If the following StreamSQL statements represent a StreamSQL application that uses this module, then the schema of each tuple emitted by the module, and subsequently emitted by this application, will be the same as the schema defined for the enclosing application's input stream.

  CREATE INPUT STREAM in (field_name1 field_type1, field_name2 field_type2);
  CREATE OUTPUT STREAM out;
  
  APPLY MODULE "module.ssql"
    FROM InputStream = in
    INTO OutputStream = out;

Even though no modifications have been made to the statements in module.ssql, tuples on the output streams OutputStream and out will have a schema corresponding to the schema defined for the input stream in.

Note that if the module actually used the value of field_name1 in some meaningful way, the tuple emitted on output streams OutputStream and out would still include the field field_name2 as well as any output fields derived from the module's processing.

Adding a Unique ID Field to a Tuple's Schema

Working with Shared Query Tables

Back to Top ^