Bindings on Streams, Delta Streams, and Windows

Bindings enable data to flow between projects. When you create a binding, a stream, delta stream, or window in one project subscribes or publishes to a stream, delta stream, or window in another project.

A binding is a named connection from an input or output stream (or delta stream or window) of one project to an input stream (or delta stream or window) of another; you can configure it at either end.

An input stream can subscribe to one or more streams in other projects. The stream subscribed to need not be an output stream—you can create an output binding on an input stream. For more information, see Example: Configuring an Output Binding on an Input Stream or Window.
An output stream can publish to one or more input streams in other projects. An output stream cannot receive incoming data, whether by subscription or publication.

Bindings reside in the CCR project configuration file so you can change them at runtime. The streams being bound must have compatible schemas.

Example: Binding to a Stream on an SSL-Enabled Cluster

This example shows a binding called BaseInputBinding that connects a local input stream called sin to a remote output stream that is also called sin. When the SSL protocol is enabled on the manager node of the data source stream’s cluster, the <Manager> element that specifies the cluster hostname and port in the CCR file must include the https:// prefix, as shown here. If you omit the https:// prefix, the binding cannot pass data, so the input stream will not receive anything.

<Configuration>
  <Runtime>
    <Clusters>  
      <Cluster name="cluster1" type="remote">
        <Username>USER_NAME</Username>
        <Password>PASSWORD</Password>
        <Managers>
          <Manager>https://CLUSTER_MANAGER_HOSTNAME:
          CLUSTER_MANAGER_RPC_PORT</Manager>  
          <!-- use https:// when SSL is enabled -->
        </Managers>
      </Cluster>
    </Clusters>
             
    <Bindings>                  
      <Binding name="sin">
        <Cluster>cluster1</Cluster> 
        <Workspace>ws2</Workspace>                          
        <Project>prj2</Project>
        <BindingName>BaseInputBinding</BindingName>
        <RemoteStream>sin</RemoteStream>                  
      </Binding>
    </Bindings>
  </Runtime>
</Configuration>

Example: Reconnection Intervals for Bindings

This example shows two bindings, b1 and b2, on a local input stream called MyInStream. The b1 binding includes a reconnection interval option specifying that if the connection between MyInStream and the remote output stream is lost, the project will attempt to reconnect every 10 seconds. Because the b2 binding does not specify a reconnection interval, its reconnection attempts will occur at the default interval of five seconds. To suppress all reconnection attempts, set <ReconnectInterval> to 0. Use positive whole number values to set the reconnection interval in seconds.

<Bindings>
  <Binding name="MyInStream">
    <Cluster>c1</Cluster>
    <Workspace>w1</Workspace>
    <Project>p1</Project>
    <BindingName>b1</BindingName>
    <RemoteStream>MyInStream1</RemoteStream>
    <ReconnectInterval>10</ReconnectInterval>
  </Binding>
  <Binding name="MyInStream">
    <Cluster>c1</Cluster>
    <Workspace>w1</Workspace>
    <Project>p1</Project>
    <BindingName>b2</BindingName>
    <RemoteStream>MyInStream2</RemoteStream>
  </Binding>
</Bindings>

Example: Configuring an Input Stream or Window to Provide Output

This example shows how to configure an input stream to send data to another input stream by setting the <Output> parameter in the <Binding> element to true.

Note: Set the <Output> parameter to true only when you configure a binding on an input stream or window that is providing output. If you configure the binding on the stream or window that is receiving input, do not set the <Output> parameter. (It is never necessary to set the <Output> parameter when you configure a binding on an output stream; output streams can only produce output.)

In this example, output from the input stream MyInStream, in the local project, is bound to the input stream MyInStream1 in project p2. The line <Output>true</Output> tells the binding to publish (send data out) to the remote stream. Without that line, this binding would subscribe to data from MyInStream1 because bindings on input streams receive data by default.

<Binding name="MyInStream">
  <Cluster>c1</Cluster>
  <Workspace>w1</Workspace>
  <Project>p2</Project>
  <BindingName>b1</BindingName>
  <RemoteStream>MyInStream1</RemoteStream>
  <Output>true</Output>
</Binding>

Example: Configuring a Window for Guaranteed Delivery

This example shows how to enable and configure guaranteed delivery (GD) on a window’s output binding. The GD parameters are the same for input bindings.

Enable GD for a binding to guarantee that if the connection between the binding and the remote stream is severed (by shutting down the project that contains the local stream, for example), all transactions that are supposed to be transmitted through the binding during its downtime are processed once the connection is re-established.

Use these parameters in the <Binding> element of your CCR file to set a binding to support guaranteed delivery:

<EnableGD> – Specifies whether guaranteed delivery is enabled for this binding. Values are true and false.
Note: When you enable GD on a binding, make sure:
- The binding’s source data window is running in GD mode or GD mode with checkpoint.
- The binding’s target data window is backed by a log store.
<GDName> – Supply a unique name for the GD session (subscription) this binding establishes.
<GDBatchSize> – The number of transactions this binding may collect in a batch before releasing the batch to the target window. The binding issues a GD commit to the source data window after releasing the data. This setting is ignored when the source data window is in GD mode with checkpoint and the <EnableGDCache> parameter on this binding is set to true. Default is 10.
<EnableGDCache> – Enable this binding to cache data. When the source data window is in GD mode with checkpoint, the binding receives checkpoint messages indicating the last row of data that has been checkpointed by the window. If the binding is enabled for GD caching, it caches incoming transactions until it receives a checkpoint message from the source window. The checkpoint message triggers the binding to send to the target window all cached transactions up to the one indicated in the checkpoint message. The binding issues a GD commit to the source data window after releasing cached data. If GD caching is disabled, checkpoint messages are ignored and the binding forwards data based on the value of <GDBatchSize>. The setting of <EnableGDCache> is ignored if the source data window is not in GD mode with checkpoint. Values are true and false; default is true.

In this example, output from the local output stream MyOutStream is bound to MyInStream1 in project p1. GD and GD caching are enabled. The GD session name is b1_GD1 and the GD batch size is 20 transactions.

<Binding name="MyOutStream">
  <Cluster>c1</Cluster>
  <Workspace>w1</Workspace>
  <Project>p1</Project>
  <BindingName>b1</BindingName>
  <RemoteStream>MyInStream1</RemoteStream>
  <ReconnectInterval>5</ReconnectInterval>
  <EnableGD>true</EnableGD>
  <GDName>b1_GD1</GDName >
  <GDBatchSize>20</GDBatchSize >
  <EnableGDCache>true</EnableGDCache >
</Binding>