Private Systems
Last updated
Last updated
If you cannot find the system that you are looking for, you can create a private system and use it. These systems are private and only accessible to the project members.
Provide the following information and then provide the necessary credentials to make the connection.
System Name: Name of the system
System Logo: Image file of the system logo
Get Hostname from User (Yes/No):
If yes, the hostname will be prompted from the Credentials. This will be helpful when you have multiple environments like staging and production.
If no, the user has to provide the URL with the hostname in the API Manager
Status enabled/disabled: To enable or disable the system to use in other modules
Authentication Type: The Authentication to be used by the system. The following authentication methods are available in the dropdown list:
No Auth
Cookies Authentication
OAuth1
NTLM
Basic Authentication
MySQL Authentication
Description: Description of the system
Token Failure Status Code: The status code that the system will return for an invalid token. Example: 401, 403
Timeout: This is the "maximum allowed time" value, before which a Timeout error is thrown. You can set a time (in seconds) for both the "Connect" and "Read" fields.
"Connect" refers to the maximum allowed time for DCKAP Integrator to establish communication with the system to which the API call is made.
"Read" refers to the maximum allowed time for the system to respond back to DCKAP Integrator.
Users can enter only 4-digit numeric values in the Connect and Read fields.
The default value for Connect = 30 seconds
The default value for Read = 240 seconds
The Test connection API is used to check if DCKAP Integrator is successfully connected to your system.
If the user has chosen Get Hostname from User as NO, then the hostname should be provided in the URL here.
Some example URLs are:
Three fields are set for each parameter/header/body:
Field | Description | Example |
Label | A suitable display name for headers/params/body data | Content-Type |
Key | Variable name at which the value is populated | Content-Type |
Value | The actual value stored in the Key | Support Content Types
|
If the Authorization Header key has a value: "DYNAMIC_TOKEN", and then the Dynamic Token section gets populated on the screen. Learn more.
DCKAP Integrator has the ability to provide a static value directly here. But if the dynamic token is to be generated from a different URL, this keyword can be used.
By default, DCKAP Integrator treats all status codes other than 200 as errors. But some systems provide error responses in the 200 OK status code itself. This section is used to identify those scenarios and treat them as errors. Users can configure the error messages that need to be displayed during the "Test Connection" process.
Provide the following details:
Status Code: The code for which the error is thrown. Example: 200
Validator: The logic that validates the error message. Example: isValid= Yes/No
Message: Enter the content that needs to be displayed in the error message. The "key" of the message to be displayed is given here.
Example:
200 Error Response
{"isValid": "No", message: "Some Error Occured"}
200 Success Response
{"isValid": "Yes", data: {...}}
Example Dynamic Token URL: /connect/token
The Dynamic token body contains information on how the token is generated. It can either be a username/ password combination or a client id/ client secret combination got from the user. The token generated using this information is utilized while triggering any API Call to the system.
DYNAMIC_TOKEN is also supported in the raw body of the request. While using in the body, the user can provide a content type to pass in the respective format. By default, DYNAMIC_TOKEN will be passed as a string. To pass as JSON, add content-type: application/json.
Authorization: This is the Header that is used in most API calls and is used to validate the API request using the authorization token. This token is stored in the system and will be inherited whenever the API is called.
Define the TokenURL in the System page as /get/token or /connect/token, etc.. depending on the system.
Sample Use Cases: Now, let's say your system requires a Username and Password to return a token. After providing the Username and Password on the System page, DCKAP Integrator will use that information to get the token by triggering the TokenUrl.
The following are four use cases explaining how to provide Authorization details in the API Manager page to retrieve token details from the TokenURL API response.
Sample Response from the TokenURL API | Format in which the system API Accepts token | Structure to enter in your API manager |
Value: | Label: As you wish | Key: Usually "Authorization". This might differ according to your system |
response = { "token":"TOKEN_VALUE_FROM_THE_SYSTEM" } | Bearer TOKEN_VALUE_FROM_THE_SYSTEM | Bearer DYNAMIC_TOKEN[token] |
response = "TOKEN_VALUE_FROM_THE_SYSTEM" | Bearer TOKEN_VALUE_FROM_THE_SYSTEM | Bearer DYNAMIC_TOKEN |
response = { "authentication":{ "access_token":"TOKEN_VALUE_FROM_THE_SYSTEM" } } | Bearer TOKEN_VALUE_FROM_THE_SYSTEM | Bearer DYNAMIC_TOKEN[authentication][access_token] |
response = { "authentication":{ "access_token":"TOKEN_VALUE_FROM_THE_SYSTEM" } } | Basic TOKEN_VALUE_FROM_THE_SYSTEM | Basic DYNAMIC_TOKEN[authentication][access_token] |
The data field for which GET_FROM_CREDENTIALS is entered here will be obtained from the user while configuring the System Credentials.
In the following example, the "username" value will be populated in the Credentials section for the user to enter.
Below is the prompt in the credentials section
Click "Edit System" on the System details page to manage the system fields.
