skip to main content
Using Hybrid Data Pipeline : Creating data sources with the Web UI : JDBC parameters for third party drivers
  

Try Now

JDBC parameters for third party drivers

Important: Before you can proceed with creating a third party driver data source, an administrator must integrate the third party driver with Hybrid Data Pipeline. For detailed information, see Using third party JDBC drivers with Hybrid Data Pipeline.
The following tables describe parameters available on the General and OData tabs of a JDBC Data Source dialog.
*General tab
*OData tab

General tab

To see a larger view of the screenshot of the General tab, click the thumbnail; or, double-click the thumbnail and select an option to open the thumbnail in a different window or tab. The screenshot shows the tab with the Set Custom Properties options displayed.
General tab of the JDBC data source setup dialogGeneral tab of the JDBC data source setup dialog
Table 19. General tab connection parameters for JDBC
Field
Description
Data Source Name
A unique name for the data source. Data source names can contain only alphanumeric characters, underscores, and dashes.
Description
A general description of the data source.
Driver Class
The name of the class of the third party driver which is plugged into Hybrid Data Pipeline.
User Id, Password
The login credentials used to connect to the JDBC database. A user name and password is required if user ID/password authentication is enabled on your database. Contact your system administrator to obtain your user name.
Note: By default, the password is encrypted.
By default, the characters in the Password field you type are not shown. If you want the password to be displayed in clear text, click the eye Watchful eye password icon icon. Click the icon again to conceal the password.
Connector ID
A general description of the data source.
Metadata Exposed Schemas
Restricts the metadata exposed by Hybrid Data Pipeline to a single schema. The metadata exposed in the SQL Editor, the Configure Schema Editor, and third party applications will be limited to the specified schema. JDBC, OData, and ODBC metadata calls will also be restricted. In addition, calls made with the Schema API will be limited to the specified schema.
Warning: This functionality should not be regarded as a security measure. While the Metadata Exposed Schemas option restricts the metadata exposed by Hybrid Data Pipeline to a single schema, it does not prevent queries against other schemas on the backend data store. As a matter of best practice, permissions should be set on the backend data store to control the ability of users to query data.
Valid Values
<schema>
Where:
<schema>
is the name of a valid schema on the backend data store.
Default: No schema is specified. Therefore, all schemas are exposed.
Connection URL
The URL used by the third party driver to make a JDBC connection. This includes connection specific information like server name, the port to connect to, the database etc.

OData tab

The following table describes the controls on the OData tab. For information on using the Configure Schema editor, see Configuring data sources for OData connectivity and working with data source groups. For information on formulating OData requests, see Formulating queries with OData Version 2.
Click the thumbnail to view the screen. Required fields are marked with an asterisk.
OData tab of the JDBC setup dialogOData tab of the JDBC setup dialog
Table 20. OData tab connection parameters for JDBC
Field
Description
OData Version
Enables you to choose from the supported OData versions. OData configuration made with one OData version will not work if you switch to a different OData version. If you want to maintain the data source with different OData versions, you must create different data sources for each of them.
OData Access URI
Specifies the base URI for the OData feed to access your data source, for example, https://hybridpipe.operations.com/api/odata/<DataSourceName>. You can copy the URI and paste it into your application's OData configuration.
The URI contains the case-insensitive name of the data source to connect to, and the query that you want to execute. This URI is the OData Service Root URI for the OData feed. The Service Document for the data source is returned by issuing a GET request to the data source's service root.
The OData Service Document returns the names of the entities exposed by the Data Source OData service. To get details such as the properties of the entities exposed, the data types for those properties and the relationships between entities, the Service Metadata Document can be fetched by adding /$metadata to the service root URI.
Schema Map
Enables OData support. If a schema map is not defined, the OData API cannot be used to access the data store using this data source definition. Use the Configure Schema editor to select the tables/columns to expose through OData.
Page Size
Determines the number of entities returned on each page for paging controlled on the server side. On the client side, requests can use the $top and $skip parameters to control paging. In most cases, server side paging works well for large data sets. Client side pagination works best with a smaller data sets where it is not as expensive to fetch subsequent pages.
Valid Values: 0 | n
where n is an integer from 1 to 10000.
When set to 0, the server default of 2000 is used.
Default: 0
Refresh Result
Controls what happens when you fetch the first page of a cached result when using Client Side Paging. Skip must be omitted or set to 0. You can use the cached copy of that first page, or you can re-execute the query to get a new result, discarding the previously cached result. Re-executing the query is useful when the data being fetched may change between two requests for the first page. Using the cached result is useful if you are paging back and forth through results that are not expected to change.
Valid Values:
When set to 0, the OData service caches the first page of results.
When set to 1, the OData service re-executes the query.
Default: 1
Inline Count Mode
Specifies how the connectivity service satisfies requests that include the $count parameter when it is set to true (for OData version 4) or the $inlinecount parameter when it is set to allpages (for OData version 2). These requests require the connectivity service to include the total number of entities that are defined by the OData query request. The count must be included in the first page in server-driven paging and must be included in every page when using client-driven paging.
The optimal setting depends on the data store and the size of results. The OData service can run a separate query using the count(*) aggregate to get the count, before running the query used to generate the entities. In very large results, this approach can often lead to the first page being returned faster. Alternatively, the OData service can fetch the entire result before returning the first page. This approach works well for small results and for data stores that cannot optimize the count(*) aggregate; however, it may have a longer initial response time for the first page if the result is large.
Valid Values:
When set to 1, the connectivity service runs a separate count(*) aggregate query to get the count of entities before executing the query to return results. In very large results, this approach can often lead to the first page being returned faster.
When set to 2, the connectivity service fetches all entities before returning the first page. For small results, this approach is always faster. However, the initial response time for the first page may be longer if the result is large.
Default: 1
Top Mode
Indicates how requests typically use $top and $skip for client side pagination, allowing the service to better anticipate how to process queries.
Valid Values:
Set to 0 when the application generally uses $top to limit the size of the result and rarely attempts to get additional entities by combining $top and $skip.
Set to 1 when the application uses $top as part of client-driven paging and generally combines $top and $skip to page through the result.
Default: 0
OData Read Only
Controls whether write operations can be performed on the OData service. Write operations generate a 405 Method Not Allowed response if this option is enabled.
Valid Values:
ON | OFF
When ON is selected, OData access is restricted to read-only mode.
When OFF is selected, write operations can be performed on the OData service.
Default: OFF