In order to access a foreign data source, you first need to create a server object. A server object contains connection information that a foreign-data wrapper uses to access the external data source.

CREATE SERVER creates an instance of a plugin with these options. Server options required depend on the data wrapper used. Most foreign data sources use one of three data wrappers:

  • ECDA. The Extensible Common Data Adapter, which lets you read and write data from s-Server to and from a variety of sources, including the file system, network sockets, AMQP, and Kafka. Options.
  • SYS_JDBC. A plugin implementing SQL/MED access to any foreign DBMS for which a JDBC driver is available. Options.

To read from or write to a foreign data source, you use the Extensible Common Data Adapter. For more information on the code structure for writing to sources using this adapter, see the topic Reading from Other Sources in the Integrating Guavus SQLstream with Other Systems.

For example, the following code defines an Extensible Common Data Adapter server of type "file", for reading over the file system:




Server Definition Options for Extensible Common Data Adapter

All server declarations for the Extensible Common Data Adapter must declare a type. Type parameter accepts the following options.

Option I/O Type
file Reading and writing over the file system. See the topics Reading from the File System and Writing to the File System for more details.
net Configured for a socket. Reads or writes data streamed from a client program using TCP or UDP. See the topics Reading from Network Sockets and Writing to Network Sockets for more details.
amqp Reads to and writes to AMQP message bus. See the topics Reading from AMQP and Writing to AMQP for more details
kafka Allows s-Server to exchange data with Kafka clusters. See the topics Reading from Kafka and Writing to Kafka for more details.
kinesis Allows s-Server to exchange data with Kinesis streams. See the topics Reading from Kinesis and Writing to Kinesis for more details.
websocket Allows s-Server to read and write data over web sockets. See the topics Reading from Websockets and Writing to Websockets for more details.
http Allows s-Server to read and write data over http. See the topics Reading over HTTP and Writing over HTTP for more details.
mongodb Allows s-Server to write to MongoDB. See the topic Writing to MongoDB for more details.
snowflake Allows s-Server to write to Snowflake warehouses. See the topic Writing to Snowflake for more details.
hive Writes to the Hadoop file system. See Using the ECDAgent with Hadoop for more details.

Server Definition Options for RDBMS Databases

The table below lists options for reading from and writing to RDBMS databases. See the topics Reading Data from RDBMS Sources and Writing Data to RBDMS Destinations in the Integrating Guavus SQLstream with Other Systems for more details.

Name Description
DRIVER Class name of the JDBC Driver for the remote database. Fully-qualified name of the JDBC driver class to load. This must be available on the classpath.
USER_NAME Remote database user.
PASSWORD Remote database password
DIALECT Type of database, generally auto detected. Valid values are: Oracle, POSTGRES, MYSQL, TERADATA, SQL SERVER
TERADATA_QUERY_BAND Optional, and for Teradata connections only. Teradata query bands "tag" the query. For more information, see page/SQL_Reference/B035_1144_111A/End_Logging-Syntax.027.143.html This is run before the actual query. The submitted SQL looks like the following: SET QUERY BAND = 'ApplicationName=SQLstream_s-Server;Version=;' FOR SESSION
queryCol Name of the column to use for a highwater mark, such as ROWTIME. No default
pollingInterval In milliseconds, how often to sleep when now new rows are available. Default is 1000.
txInterval How many rows to wait before reading a row, in order to ensure that no rows are missed as a result of rollbacks or dirty reads. If queryCol is ROWTIME, you should consider setting txInterval to 1000. Larger values add latency to the query, but make the stream more consistent (safer) in the face of crashes and multiple inserters to the remote database's table. Smaller values add less latency, may result in a missed row, in the remote chance of a dirty read.
JNDI_WRITEBACK True/False. Defaults to "false". When you specify the JNDI_WRITEBACK option as "true" in the DDL or in the .properties file, s-Server writes back consolidated options (including options inherited from the parent as well as from the properties file) to the same properties file under $SQLSTREAM_HOME/plugin/jndi. This lets you configure the JNDI file using DDL.


Here is an example that configures a connection to a file server. See Writing to the File System for more information.

(directory 'myDirectory',
//directory for the file
format_type 'CSV',
filename_pattern 'myRecord.csv',
//regex for filename pattern to look for
character_encoding 'UTF-8',
skip_header 'true');

Note: ECD Adapter server definitions need to reference the ECD foreign data wrapper. You can do so with the syntax FOREIGN DATA WRAPPER ECDA.

The following code block defines a JDBC connection for a MySQL database.

DRIVER_CLASS 'com.mysql.jdbc.Driver',
URL 'jdbc:mysql://localhost:3306/sample',
USER_NAME 'sqlstream',
PASSWORD 'sqlstream'

Using SQL/MED Inheritance with Server objects

SQLstream's implementation of the SQL/MED framework supports OPTIONS inheritance. That is, each SQL/MED object inherits OPTIONS of its parent/ancestor unless specified in the OPTIONS clause of the object itself.

Specifically, this means that you can specify options in a SERVER object that will be passed through to foreign streams invoking the SERVER object.

The following example defines a SERVER object with a SEED_BROKERS option for a Kafka source/sink:


CREATE OR REPLACE FOREIGN STREAM emea.inventory_updates (
  kafka_offset BIGINT NOT NULL,
  --special column for Kafka partition
  "item" CHAR(200) NOT NULL,
  "item_number" DOUBLE
TOPIC 'emea_inventory_updates'
max_poll_records '2MB'
parser 'CSV',
character_encoding 'UTF-8',
skip_header 'false');

In this case, the foreign stream emea.inventory_updates inherits the SEED_BROKERS option from EMEA_KAFKA_SERVER. Every foreign stream that invokes EMEA_KAFKA_SERVER will similarly inherit this option, unless the foreign stream itself specifies SEED_BROKERS as an option. In that case, the foreign stream option SEED_BROKERS will override the SEED_BROKERS option in the SERVER object.

This approach has several advantages. If you know that a number of foreign streams share configuration options, you can specify these once in a SERVER object, and then change them as needed in the same SERVER object.

Here, an application developer writing a foreign stream may not even know hostnames in the Kafka cluster. The developer simply uses EMEA_KAFKA_SERVER to create multiple foreign streams, all of which will inherit the SEED_BROKERS option from the foreign server. A single change to EMEA_KAFKA_SERVER definition can allow update of SEED_BROKERS property for all foreign streams quickly.

Using Properties Files

With this options inheritance in place, the SQL/MED framework also supports loading some of these options through .properties files. SQLstream s-Server looks for these .properties files in $SQLSTREAM_HOME/plugin/jndi/.properties.

You, or your system administrator, can create a file called $SQLSTREAM_HOME/plugin/jndi/<server_name>.properties. Properties from this file will be automatically imported as OPTIONS in a foreign server with the name <server_name>.

For the EMEA.INVENTORY_UPDATES stream defined above, the file path would be $SQLSTREAM_HOME/plugin/jndi/ Please note that the file name will be uppercased if the object name is NOT quoted. We recommend quoting this option.

For EMEA_KAFKA_SERVER, the path would be $SQLSTREAM_HOME/plugin/jndi/

For the configuration above, app developers can simply create these .properties files with appropriate names and those properties will be automatically imported when SQL/MED objects are created. Any options explicitly defined in the OPTIONS clause of the DDL will override those options defined in the .properties file.

OPTIONS inheritance works in the following order for each SQL/MED object:

  1. Inherit options from the parent.
  2. Override options from the <> file.
  3. Override options explicitly specified in the OPTIONS clause of the DDL.

You can use properties files to abstract away certain options or hide connection credentials from app developers.

Using the JNDI_WRITEBACK Option

This option enables system administrators to persist options supplied in the OPTIONS clause of the DDL to the <objectname>.properties file. This allows administrators to supply connection credentials through the DDL once and then disable the JNDI_WRITEBACK option. Resubmitting the DDL will eliminate options that need to be hidden away from the DDL statements.