Connecting to a Data Source Using an IDD

Step 1: Exporting entry points

An IDD can export entry points to K2 as one or more variables. Each variable is used to represent some well-defined chunk of data at the source. For example, the JDBC driver represents the tables in a database as variables, one variable for each table. Each variable is of type "bag of records", where the labels in the records correspond to the column names in the table. This way, if you want to write a query to select from a particular table, you simply refer to the corresponding variable in your query, treating it as a bag of records.

If you want to provide entry point variables, you need to implement the getSourceMetaData method in your connection class, to return an object that implements the K2.driver.DataSourceMetaDataI interface. (If you don't want to provide entry point variables, implement getSourceMetaData to simply return null.) K2 has a built-in class called K2.driver.DataSourceMetaData that implements this interface, which should be sufficient for most needs. The DataSourceMetaData constructor takes four parameters:

K2 makes the entry point variables available to incoming queries by adding them to the default environment that each client inherits when it connects. K2 also provides another "entry point" for each IDD, in the form of a "native query function". The function takes a string as its parameter, and can return any type of result. The intent of this function is to allow the user to pass the IDD a string containing a query in the native language of the underlying data source. For example, the JDBC driver's native query function expects its string parameter to contain an SQL query. The name that K2 uses for this function in the query environment is determined by the contents of the driver properties file.

The communication between the execution engine and the IDD is handled through DriverConnectionA's default implementation of its getNativeDriverFn method, which returns a K2.absyn.expns.absynNativeA object that, when applied, returns an K2.absyn.expns.absynDriverQuery that points back to your connection class. You don't need to be concerned with these details, unless you plan to override the default implementation of getNativeDriverFn. For most purposes, this is not necessary.

When constructing the absynNativeA, the return type of the function is determined by calling the getNativeQueryResultType method in your connection class with an empty string. To support its native query function, your connection class must implement both this method and the executeNativeQuery method. More details on this are provided later.

Once you've decided what kinds of entry points you want to support, you must make your IDD connect to the data source.

[Tech Docs Index]