Integration Cloud 6.1.0 | Applications | REST Applications | REST Applications - Account Configuration Details
 
REST Applications - Account Configuration Details
Integration Cloud allows you to create custom REST Applications. REST (Representational State Transfer) is an architectural style that requires web applications to support the HTTP GET, POST, PUT, and DELETE methods and to use a consistent, application-independent interface.
Field
Description
Server URL
This is the login Endpoint URL you have specified in the Define Application Details page while creating the REST Application.
Authorization Type
The type of HTTP authorization scheme to use for the connection. If you enter the username and password, then set the authorization type as basic. Basic refers to HTTP Basic Authentication. This option can be used if the Application requires or supports HTTP Basic authentication using a username and password. If you select none, no additional authorization scheme will be executed at run time. For example, when you specify a Username and Password, but do not specify a value for the Authorization Type, the user credentials are not inserted into an Authorization header.
Response Timeout
The number of milliseconds Integration Cloud waits for a response before canceling its attempt to connect to the back end. In case the network is slow or the back end processing takes longer than usual, increase the Response Timeout value. It is recommended to specify a value other than 0. If you specify 0, Integration Cloud will wait indefinitely for a response.
Retry Count on Response Failure
The number of times Integration Cloud attempts to connect to the back end to read a response if the initial attempt fails. If an I/O error occurs, it will retry only if you have selected the Retry on Response Failure option.
Retry on Response Failure
Whether Integration Cloud should attempt to resend the request when the response has failed, even though the request was sent successfully. Select this option if you want to re-establish the connection.
Consumer ID
Also referred to as the Client ID, in OAuth 2.0, this is a client identifier issued to the client to identify itself to the authorization server. For Auth 1.0a, it is the Consumer Key issued by the Service Provider and used by the consumer to identify itself to the Service Provider.
Access Token
This token is used for authentication and is issued by the Authorization Server. For OAuth 1.0a, it is a value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the User's Service Provider credentials.
Access Token Secret
A secret used by the Consumer to establish ownership of a given Access Token. For OAuth 1.0a, it is the secret used by the Consumer to establish ownership of a given Access Token.
Refresh URL
The provider specific URL to refresh an Access Token.
Session Timeout (min)
The maximum number of minutes a session can remain active, in other words, how long you want the server to wait before terminating a session. The value should be equal to the session timeout value specified at the SaaS provider back end.
Username
The username credentials for the current Account configuration.
Password
The password credentials for the current Account configuration.
Trust store Alias
Select the alias name of the Integration Cloud trust store configuration. The trust store contains trusted certificates used to determine trust for the remote server peer certificates. You can also add a new Truststore from this field. This option is available only if Credentials is selected as the Authentication Type while creating the Application.
Hostname verifier
Select a hostname verifier implementation. Guards against man-in-the-middle (MITM) attacks. The default is org.apache.http.conn.ssl.DefaultHostnameVerifier, which will enable hostname verification. Select org.apache.http.conn.ssl.NoopHostnameVerifier to disable hostname verification. This option is available only if Credentials is selected as the Authentication Type while creating the Application.
Enable SNI
Server Name Indication (SNI) is an extension to the TLS protocol by which a client indicates which host name it is attempting to connect to at the start of the handshaking process. Enable this option if the SaaS provider offers SNI-based TLS connectivity, and if you want to connect to an SNI enabled SAAS provider to send the host name specified in the Server URL field, as part of the TLS SNI Extension server_name parameter.
SNI Server Name
If you want to explicitly specify a host name to be included as a part of the SNI extension server_name parameter, in case the host name is other than the host name specified in the Server URL field, specify the host name value in the SNI Server Name field.
Keystore Alias
Select the alias for the Integration Cloud key store configuration. This is a text identifier for the keystore alias. A keystore file contains the credentials (private key/signed certificate) that a client needs for authentication. You can also add a new Keystore from this field. This option is available only if Credentials is selected as the Authentication Type while creating the Application.
Client Key Alias
Alias to the private key in the keystore file specified in the Keystore Alias field. The outbound connections use this key to send client credentials to a remote server. To send the client’s identity to a remote server, you must specify values in both the Keystore Alias and the Client Key Alias fields. This option is available only if Credentials is selected as the Authentication Type while creating the Application.
Consumer Secret
Also referred to as the Client Secret, this is a secret matching to the client identifier. For Auth 1.0a, it is the secret used by the Consumer to establish ownership of the Consumer Key.
Refresh Token
Issued with the OAuth v2.0 access token only. A token used by the client to obtain a new access token without having to involve the resource owner.
Refresh URL Request
Options for sending the parameters in the Access Token refresh request. The options are Body Query String, URL Query String, and Custom Integration.
Body Query String - The refresh request parameters, for example, refresh_token, grant_type, and so on, and their values are sent as query strings in the body of the POST request.
URL Query String - The refresh request parameters, for example, refresh_token, grant_type, and so on, and their values are sent as query strings in the URL of the POST request.
Custom ESB Service - Use this option if the back end requires refresh requests in a custom format. If you select this option, you must specify the name of your Integration in the Refresh Custom ESB Service field. You can also create an Integration by clicking the link.
Refresh Custom ESB Service
To refresh the access tokens for accounts which use the OAuth 2.0 protocol, you can specify a call-back Integration which will execute when the access token expires.
This is a user implemented service for refreshing the OAuth 2.0 Access Token. This option allows you to create an Integration, which will be executed when the Access Token has expired or is not valid.
To create this Integration, create a custom REST Application with an Operation that invokes the back end to fetch the refresh token. You can use this custom REST Application along with its Operation to create this Integration.
Click the Integration link to create a new Integration.
The Integration must have a specification whose input parameters are:
and the output parameters are:
Note:
The integration will be pre-populated with the input/output adhering to the above mentioned specification.
The newly created Integration will generate an access token that is mapped to the access token field in the output signature.
Note:
While editing the Account, this new Integration appears in the Refresh Custom ESB Service field in the Account Configuration page.