CloudStreams 10.5 | webMethods CloudStreams | webMethods CloudStreams Development | CloudStreams Provider Project | Editing the Connection Properties
 
Editing the Connection Properties
 
Adding Properties
Editing Properties
Removing Properties
Start and Stop Sequences for REST-based providers
Start and Stop Sequences for SOAP-based providers
In this screen, you can define the required configurations to initiate communication with the SaaS provider. In case you want to change the default values for the properties, you can edit them using the respective screens. In the Connection screen you can override the system defined properties default value and can also add, edit and remove user defined properties
On the Authentication screen, you can select different authentication types, override the system defined property default value and can also add, edit, and remove the user-defined properties.
Note:
If you change the Authentication Type, all modifications and related references done to the previous authentication type will be lost.
For Protocol, Request Headers, and Custom screens, you can override the system defined property default value and can also add, edit, and remove the user-defined properties.
You can also add a Start Sequence and Stop Sequence if a provider requires a Start/Stop Sequence. See Start and Stop Sequences for REST-based providers and Start and Stop Sequences for SOAP-based providers for more information on how to configure start and stop sequences.
The connection properties are described below:
Name
The available fields are...
Connection
*Server URL: The native provider endpoint target for the connection configuration. The default configuration field provided with the connection factory is cn.providerURL.
*Min Pool Connections: The minimum number of socket connections to reserve for a connection configuration alias.
*Max Pool Connections: The maximum number of socket connections to reserve for a connection configuration alias.
*Connection TimeOut: The number of milliseconds a connection attempt will wait before giving up. (0 will wait indefinitely).
*Socket Read Timeout: The number of milliseconds in which the the client must read a response message from the server. (0 will wait indefinitely).
*Use Stale Checking: If true, the connection factory performs additional processing to test the socket to see if it is still functional each time it is used.
*Validate After Inactivity: This field is used in conjunction with the Use Stale Checking field to control the period of inactivity after which persistent connections must be revalidated prior to being leased. This field is considered only if the Use Stale Checking field is set to true, else this field is ignored.
*Connection Retry Count: How many times should the connection factory attempt to execute a failed invocation.
*Retry On Response Failure: If true, the retry mechanism will be used for failed responses even if the request was sent successfully.
*Use TCP NoDelay: If true, do not use Nagles algorithm as a socket optimization technique.
*Socket Linger: Determines how quickly a socket should close.
*Socket Buffer Size: The size of the read and write socket buffers, in bytes.
*Socket Reuse Address: If true, the socket will be reused even if it is in TIME_WAIT due to a previous socket closure.
*Hostname Verifier: Fully qualified class name that implements the Apache HC org.apache.http.conn.ssl.X509HostnameVerifier interface. Guards against man-in-the-middle attacks.
*Enable Compression: If true, the request will be compressed using the gzip compression technique.
*Proxy Server Alias: The alias to a web proxy server configuration in Integration Server.
*Trust Store Alias: Alias for the Integration Server trust store configuration.
*Session Token: Session token for a stateful session.
Protocol
*HTTP Content Character Set: The encoding to use for the request message.
*HTTP Protocol Version: The HTTP version (HTTP/0.9, HTTP/1.0 or HTTP/1.1. The default value for the connection factory is HTTP/1.1.
*User Agent: The value to the connection configuration will send for the User-Agent request header.
*Use Expect Continue: If true, use the Expect/Continue HTTP/1.1 handshake and send the Expect request header.
*Use Chunking: If true, use HTTP/1.1 chunking, using a chunk size that matches the socket buffer size.
*Follow Server Redirects: If true, follow server redirects.
*Server Redirect Maximum Tries: Maximum number of times to follow a server redirect.
Request Headers
*Request Header Names: An array of request header names to include for this connection configuration. The value should be a comma-delimited list of header names; for example Content-Type,SOAPAction.
*Request Header Values: An array of request header values to include for this connection configuration. The value should be comma-delimited list of values in the same order as the header names; for example, text/xml,login.
custom
Click the icon to add a custom configuration group. The Configuration Group dialog box appears. You can select the Protocol and Request Headers configuration groups if you have not selected them while creating a connector.
To configure the connection authentication, select the Authentication tab:
1. Select the Authentication Type from the drop-down list. If you change an Authentication type, all modifications and related references done to the previous Authentication type will be lost. By default, it shows the authentication you had selected while creating the connector.
2. Select Show Advanced properties to view more properties for the selected authentication type.
If the Authentication Type is...
The available properties are...
Credentials
*Username: The username credentials for the current connection configuration.
*Password: The password credentials for the current connection configuration
*Authorization Type: The string identifying the authentication protocol scheme to use for the connection configuration.
*Preemptive Auth: If true, basic auth credentials will be included when a request is sent. (It will not wait for a 401 response challenge.)
*Domain Name: The domain/security realm for the current connection configuration.
*Keystore Alias: Alias for the Integration Server key store configuration.
*Client Key Alias: Alias to reference a key inside a key store file.
OAuth V1.0a
*Consumer ID: The 'Consumer Key' issued by the Service Provider and used by the consumer to identify itself to the Service Provider.
*Consumer Secret: A secret used by the Consumer to establish ownership of the 'Consumer Key'.
*Access Token: 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'.
OAuth v2.0
*Consumer ID: A 'client identifier' issued to the client to identify itself to the authorization server.
*Consumer Secret: A secret matching to the 'client identifier'.
*Access Token: A token used by the client to make authenticated requests on behalf of the resource owner.
*Instance URL: Optional field, used to specify a run-time host, if applicable. This may be required in some backends like Salesforce.
*Refresh Access Token: Option to refresh the 'Access Token'. OAuth 2.0 access tokens typically have a very short lifetime. When an access token expires, the OAuth profile does not automatically refresh the expired access token. Select this option if you want an expired access token to be refreshed automatically. If you select this option, you must also specify the relevant refresh parameters. The access token is refreshed whenever the session expires. Session expiration is handled according to the setting of the Session Management property in your connection. Note that if Session Management is set to "none", then you must manually modify the access token in the OAuth alias. (The Refresh Access Token option will not be applicable in this case). Default is 'false'.
*Refresh Token: A token used by the client to obtain a new access token without having to involve the resource owner.
*Refresh URL: The provider specific URL to refresh an 'Access Token'. This is required when 'Refresh Access Token' is enabled (configured to 'true') and ‘Refresh URL Request’ is configured to 'URL Query String' or 'Body Query String'.
*Refresh URL Request: Options for sending the parameters in the 'Access Token' refresh request. The options are 'URL Query String', 'Body Query String', and 'Custom ESB Service'. Default is 'Body Query String'.
*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.
Example:
www.examplebackend.com/o/
oauth2/token?grant_type=refresh_token&client_id=
842428530070-pubfebfgfqkgj6t54m4ns6&client_secret=
4adQT95cAtUxWINbDxGP9SJ4&refresh_token=
1%2Fn072P4BXpuNObjCLUtiZTc4fMH6YersmxBIv8QN3bhw
*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.
Example:
POST /o/oauth2/token HTTP/1.1
Host: accounts.backend.com
Content-length: 163
content-type: application/x-www-form-urlencoded

client_secret4adQT95cAtUxWINbDxGP9SJ4&grant_type=
refresh_token&refresh_token=1%2Fn072P4BXpuNObj
CLUtiZTc4fMH6YersmxBIv8QN3bhw&
client_id=407408718192
*Custom ESB Service: If the backend requires the refresh request in a custom format, for example, requests which need more parameters than the ones specified by OAuth v2.0, or the backend uses some custom way of organizing parameters, or expects some other HTTP method request (other than POST), use the ‘Custom ESB Service’ option.
Refresh Custom ESB Service: User implemented service for refreshing the 'Access Token'. This is required when the 'Custom ESB Service' option is selected as the 'Refresh URL Request'. This service must strictly conform to the OAuth V2.0 (JWT Flow) and OAuth V2.0 (Authorization Code Flow) specifications. The specifications for these authentication types are described below:
*OAuth V2.0 (JWT Flow):
Use the
wm.cloudstreams.service.common.lookup.specs:oauthJWTRefreshServiceSpec
specification to implement a service to generate the JWT token to refresh the access token.
You must initially generate the JWT using cloudstreams.oauth:getJsonWebToken service with the required input and then use generated JWT to fetch the access token. The input and output details of the specification is provided below:
Input parameters:
*headers: Header contains the following two parts:
*The type of the token (JWT).
*The signing algorithm such as, HMAC, SHA, or RSA.
*claims: Claims are statements about an entity and additional data.
*customFields: This field allows you to add data that is required to refresh the token or a global connection fields used in API calls.
*omitPadding: This field omits '=' padding bytes from JWT payload. The JWT specification mandates to not use paading if base64url encoding is used along with JWTs.
*authenticationServerUrl: This URL is used to specify an authentication service that manages user authentication, and optionally provide additional metadata to be embedded in the token.
*keyStoreAlias: This is an alias for the Integration Server keystore configuration.
*keyAlias: This is an alias to reference a key inside a keystore file.
*proxyAlias: This alias refers to a web proxy server configuration in Integration Server.
Output parameter
*status: The HTTP status code sent by the server in response.
*statusMessage: The HTTP status message sent by the server in response.
*JSONResponse: The JSON response payload sent by the server.
*OAuth V2.0 (Authorization Code Flow): Use the
wm.cloudstreams.service.common.lookup.specs:oauthTokenRefreshServiceSpecEx
specification to implement a service to refresh the token. The input and output details of the specification is provided below:
Input parameter:
*access_token: The token used by the client to execute the service.
*consumer_id: The consumer identifier to renew the token.
*consumer_secret: The consumer secret to renew the token.
*refresh_token: The refresh token the renew the token.
*access_token_refresh_url: The URL to renew the token.
Output parameter
*status: The HTTP status code sent by the server in response.
*statusMessage: The HTTP status message sent by the server in response.
*jsonResponse: The JSON response payload sent by the server.
Authorization Header Prefix: The prefix to be used with the 'Access Token' in the Authorization header. Options are 'Bearer' and ‘OAuth’. Default is 'Bearer'.
OAuth V2.0 (Authorization Code Flow)
*Consumer ID: A client identifier issued to the client to identify itself to the authorization server.
*Consumer Secret: A secret matching to the client identifier.
*Access Token: A token used by the client to make authenticated requests on behalf of the resource owner.
Note:
See the OAuth v2.0 section for information on the other fields.
OAuth V2.0 (JWT Flow)
*Authentication Server URL: Used to specify a authentication service that manages user authentication, and optionally provide additional meta data to be embedded in the token.
*Issuer: Client ID, or Identifier, or name of the server or system issuing the JWT token.
*Subject: Identifier or the name of the user this token represents.
*Access Token: A token used by the client to make authenticated requests on behalf of the resource owner.
*Instance URL: Used to specify a run-time host, if applicable. This may be required in some back ends, like Salesforce.
*Authorization Header Prefix: The prefix to be used with the Access Token in the Authorization header. Options are Bearer and OAuth. Default is Bearer.
AWS S3 Signature
*Access Key: This is a username. It is an alphanumeric text string that uniquely identifies the user who owns the account. No two accounts can have the same AWS Access Key.
*Secret Key: This key plays the role of a password. It is called secret because it is assumed to be known only by the owner. When you type the secret key, it is displayed as asterisk or dots.
*Region: An area-specific value.
AWS V2 Signature
*Access Key: This is a username. It is an alphanumeric text string that uniquely identifies the user who owns the account. No two accounts can have the same AWS Access Key.
*Secret Key: This key plays the role of a password. It is called secret because it is assumed to be known only by the owner. When you type the secret key, it is displayed as asterisk or dots.
*Region: An area-specific value.
*Signing Algorithm: Explicitly specify the signing algorithm, for example, HMAC-SHA1 Signatures) used to sign the message.
AWS V4 Signature
*Access Key: This is a username. It is an alphanumeric text string that uniquely identifies the user who owns the account. No two accounts can have the same AWS Access Key.
*Secret Key: This key plays the role of a password. It is called secret because it is assumed to be known only by the owner. When you type the secret key, it is displayed as asterisk or dots.
*Region: An area-specific value.