HTTP Source (HTTPSource)

In an application, right-click on Sources -> select Create source -> type any Source name and select HTTPSource in the Source type field -> click Create.

There two main use cases for HTTPSource:

HTTPSource is used by HTTPRequest opeation: common variables defined in the Variable section, common script functions defined in the Script Library section and authentication parameters defined in the Authentication section are used to perform HTTP requests.
Scenarios defined in the Objects/operations Mapping section are used to implement the standard internal Java API on top of which all generic operations such as Load, Insert, Delete, Update, Transform work.

Variables

In the Variables section you can define variables that can be used in the HTTPRequest operation properties: these variables will be added to the execution context at the begining of HTTPRequest execution.

Authentication

In the Authentication section you start by selecting authentication type: Basic Auth, API Key, OAuth 2.0. The rest of the parameters depends on the selected type.

Basic Auth

Basic authentication requires to enter a Username and Password. The request headers will be automatically extended with the Authorization header that contains a Base64 encoded string representing concatination of your username and password separated by colon :, appended to the text “Basic ”.

API Key

API Key authentication requires to enter the key name and value. From the Add to dropdown list, you can also select where the key-value pair to be added in the request: Header, Query Params. Query Params is used by default.

OAuth 2.0

With OAuth 2.0, you first retrieve an access token for the API, then use that token to authenticate future requests. The OAuth 2.0 flow depending on the grant type that you can select in the Grant type dropdown list: Password Credentials, Client Credentials, Authorization Code. After selecting a grant type you enter credentials and configure requests required by the selected grant type. Requests are configured as described in the HTTPRequest opeation section. The only difference is that the parsing script must return an object required by the OAuth 2.0 specification . You can leave the parsing script blank if the request’s response already comply to the specification.

Session

Session authentication provides a mechanism to support a proprietary session-based authentication: when the source usually has an API call to create a session that returns the session token; then you can make calls using the token; when the token expires, you refresh the token or recreate the session; there is an API call to close the session. In this case the token can expire on any execution of HTTPRequest operation or even during its execution when, for example, you provided a source table that HTTPRequest iterates over. Session authentication allows you to specify a scenario that will be called in case of token expiration and it will refresh the token.

Session expiration check - a Javascript code that must return true or false (not values that are equivalent to true and false but the values themselve). The code will be executed in case of any unsuccessful response to check that the error is the result of token expiration. Successful are only responses with status code 2XX (e.g. 200). Here is an example.
```
if ($il.response.statusCode == 404 && $il.response.bodyStr.indexOf("Session expired") !== -1) {
 return true;
} else {
 return false;
}   
```

Objects/operations Mapping

The mapping allows you to register scenarios that are used to implement the Infolink internal standard Java API on top of which all generic (source-agnostic) operations are implemented.

getSchema scenario

Called by InfoLink with the following parameters:

spaceName
tableName
targetModelSourceName
targetModelSpaceName
targetModelTableName