|
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.
|
|
Endpoints
|
Specify REST endpoints in either of the following ways. The REST endpoints specified are used to generate a relational model of the REST data.
 Option 1. Add REST endpoints via the Web UI. Click Add, and provide the following information in the dialog.
Entity Name is the name of the relational table to which the connectivity service maps the endpoint.
Request Type is the type of request that is used to retrieve data from the endpoint. (If POST is selected, a HTTP Body field will be provided.)
URL is the URL of the REST endpoint. For example, http://mysite.com/countries/.
JSON Root is the JSON object which the connectivity service uses to develop a tabular data model. When a JSON root is specified, JSON layers between the endpoint and the root are ignored.
Option 2. Import an input REST file. Click Import REST file, and browse to the input REST file you want to import. For information on creating an input REST file using a text editor, see Creating an input REST file .
Take the following steps to refine the relational model of REST data.
1. Click the generate (or edit) configuration button.
2. Edit the JSON to meet application or query requirements. See Creating an input REST file for syntax requirements.
3. Click Update in the editor to save your changes.
4. Click Update in the data source dialog to update the data source.
|
|
Connector ID
|
The unique identifier of the On-Premise Connector that is to be used to access the on-premise data source. Select the Connector that you want to use from the dropdown. The identifier can be a descriptive name, the name of the machine where the Connector is installed, or the Connector ID for the Connector.
If you have not installed an On-Premise Connector, and no Connectors have been shared with you, this field and drop-down list are empty.
If you own multiple Connectors that have the same name, for example, Production, an identifier is appended to each Connector, for example, Production_dup0 and Production_dup1. If the Connectors in the dropdown were shared with you, the owner's name is appended, for example, Production(owner1) and Production(owner2).
|
|
Field
|
Description
|
|
Authentication Method
|
Determines which authentication method the connectivity service uses during the course of a session.
Valid Values:
None | Basic | HttpHeader | UrlParameter
When set to None, the service does not attempt to authenticate.
When set to Basic, the service uses a hashed value, based on the concatenation of the user name and password, for authentication. In addition to the User and Password properties, you must also configure the AuthHeader property if the name of your HTTP header is not Authorization (the default).
When set to HttpHeader, the service passes security tokens via HTTP headers for authentication. You must also configure SecurityToken property and, if the name of your HTTP header is not Authorization (the default), the AuthHeader property.
When set to UrlParameter, the service passes security tokens via the URL for authentication. You must also configure the AuthParam and SecurityToken properties.
Default: None
|
|
User
|
Specifies the user name that is used to connect to the REST service. A user name is required if user is enabled by your REST service. This parameter is ignored when Authentication Method is set to None.
Valid Values:
string
where:
string
is a valid user name. The user name is case-insensitive.
|
|
Password
|
Specifies the password to use to connect to your REST service. This parameter is ignored when Authentication Method is set to None.
Valid Values:
password
where:
password
is a valid password. The password is case-sensitive.
|
|
Authentication HTTP Header Name
|
Specifies the name of the HTTP header used for authentication. This parameter is used when Authentication Method is set to Basic or HttpHeader authentication has been selected.
Valid Values:
auth_header
where:
auth_header
is the name of the HTTP header used for authentication. For example, X-Api-Key.
|
|
Authentication URL Param Name
|
Specifies the name of the URL parameter used to pass the security token. This property is required when Authentication Method is set to UrlParameter.
Valid Values:
auth_parameter
where:
auth_parameter
is the name of the URL parameter used to pass the security token. For example, apikey or key.
|
|
Security Token
|
Specifies the security token required to make a connection to your REST API endpoint. This parameter is required when Authentication Method is set to UrlParameter or HttpHeader. If a security token is required and you do not supply one, the connection will fail.
Important: The Security Token parameter, like all parameters, is persisted in clear text.
Valid Values:
string
where:
string
is the value of the security token assigned to the user.
|
|
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 the data source, for example, https://example.com:8443/api/odata4/<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.
See Configuring data sources for OData connectivity and working with data source groups for more information.
|
|
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
|
|
Field
|
Description
|
|
Refresh Schema
|
Specifies whether the connectivity service automatically refreshes the relational map of the data model when a user connects to a REST service.
Valid Values:
When set to ON, the service automatically refreshes the map of the data model when a user connects to a REST service. Changes to objects since the last time the map was generated will be shown in the metadata.
When set to OFF, the service does not refresh the map of the data model when a user connects to a REST service.
Note:
This parameter should not be enabled when Create Mapping is set to session.
You can choose to refresh the schema by clicking the Refresh
 icon. This refreshes the schema immediately. Note that the refresh option is available only while editing the data source.
Use the option to specify whether the connectivity service attempts to refresh the schema when an application first connects. Click the Refresh icon if you want to refresh the schema immediately, using an already saved configuration.
If you are making other edits to the settings, you need to click update to save your configuration. Clicking the Refresh icon will only trigger a runtime call on the saved configuration.
Default: OFF
|
|
Create Mapping
|
Determines whether the connectivity service creates the internal files required for a relational map of the REST data when establishing a connection.
Valid Values:
session | forceNew | notExist
When set to session, the service uses memory to store the internal configuration information and relational map of REST data. A REST file is not created when this value is specified. After the session, the view is discarded.
When set to forceNew, the service generates a new REST file and creates a new relational map of the REST data.
This causes all customizations defined in the REST file to be lost.
When set to notExist, the service uses the current REST file and relational map of REST data. If the files do not exist, the service creates them.
Default: notExist
|
|
Field
|
Description
|
|
Web Service Call Limit
|
The maximum number of Web service calls allowed for a single SQL statement or metadata query.
When set to 0, there is no limit on the number of Web service calls on a single connection that can be made when executing a SQL statement.
Default: 10
|
|
Web Service Fetch Size
|
Specifies the number of rows of data the Hybrid Data Pipeline connectivity service attempts to fetch for each call.
Valid Values:
0 | x
If set to 0, the Hybrid Data Pipeline connectivity service attempts to fetch up to a maximum of 10000 rows. This value typically provides the maximum throughput.
If set to x, the Hybrid Data Pipeline connectivity service attempts to fetch up to a maximum of the specified number of rows. Setting the value lower than 10000 can reduce the response time for returning the initial data. Consider using a smaller value for interactive applications only.
Default: 0
|
|
Web Service Retry Count
|
The number of times to retry a timed-out Select request. The Web Service Timeout parameter specifies the period between retries. A value of 0 for the retry count prevents retries. A positive integer sets the number of retries. The default value is 3.
|
|
Web Service Timeout
|
The time, in seconds, to wait before retrying a timed-out Select request. Valid only if the value of Web Service Retry Count is greater than zero. A value of 0 for the timeout waits indefinitely for the response to a Web service request. There is no timeout. A positive integer is considered as a default timeout for any statement created by the connection. The default value is 120.
The default is an empty string.
|
|
Max Pooled Statements
|
The maximum number of prepared statements to cache for this connection. If the value of this property is set to 20, the connectivity service caches the last 20 prepared statements that are created by the application.
|
|
Extended Options
|
Specifies a semi-colon separated list of connection options and their values. Use this configuration option to set the value of undocumented connection options that are provided by Progress DataDirect technical support. You can include any valid connection option in the Extended Options string, for example:
Valid Values:
string
where:
string
is a semi-colon separated list of connection options and their values.
Syntax:
Database=Server1;UndocumentedOption1=value[;UndocumentedOption2=value;]
Note: If the Extended Options string contains option values that are also set in the setup dialog, the values of the options specified in the Extended Options string take precedence.
|
|
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.
|