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:
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:
CREATE OR REPLACE SERVER "FileReaderServer" TYPE 'FILE' FOREIGN DATA WRAPPER ECDA;
All server declarations for the Extensible Common Data Adapter must declare a type. Type parameter accepts the following options.
|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.|
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.
|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 http://www.info.teradata.com/HTMLPubs/DB_TTU_14_00/index.html# 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=
|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.
CREATE OR REPLACE SERVER "FileReaderServer" TYPE 'FILE' FOREIGN DATA WRAPPER ECDA OPTIONS (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.
CREATE OR REPLACE SERVER mysql_reader FOREIGN DATA WRAPPER SYS_JDBC OPTIONS ( DRIVER_CLASS 'com.mysql.jdbc.Driver', URL 'jdbc:mysql://localhost:3306/sample', USER_NAME 'sqlstream', PASSWORD 'sqlstream' );
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 SERVER EMEA_KAFKA_SERVER TYPE 'KAFKA10' OPTIONS ( SEED_BROKERS 'dcserver1.mycompany.co.uk:9092,dcserver2.mycompany.co.uk:9092' ); CREATE OR REPLACE FOREIGN STREAM emea.inventory_updates ( kafka_offset BIGINT NOT NULL, "ts" TIMESTAMP NOT NULL, "KAFKA_PARTITION" INT NOT NULL, --special column for Kafka partition "item" CHAR(200) NOT NULL, "item_number" DOUBLE ) SERVER EMEA_KAFKA_SERVER OPTIONS ( TOPIC 'emea_inventory_updates' STARTING_TIME 'LATEST' 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.
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/
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/LOCALDB.EMEA.INVENTORY_UPDATES.properties. 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/EMEA_KAFKA_SERVER.properties
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:
You can use properties files to abstract away certain options or hide connection credentials from app developers.
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.