Systems
The Systems page is where users can add, edit, and maintain Systems for a project.
The individual platforms that DCKAP Integrator directly connects to, or connects using APIs are known as systems. For example, ERP is a system.
These systems need to be configured in DCKAP Integrator in order to be able to communicate with them (read, write, and update data) and also to provide a level of security.
The Systems page is where users can add, edit, and maintain Systems for a project. A System added and configured in the Systems page, can later be used in the API Manager and Credentials page which will, in turn, be used in building Flows and Integration pipes.
Click on the Add New button on the Systems page. Here users will be able to add and configure a new system. Enter the following information:
- System Name: Name of the system
- System Logo: Image file of the system logo
- Token Failure Status Code: The status code that the system will return for invalid token
- Example: 401, 403
- Description: Description of the system
- Status enabled/disabled: To enable or disable the system to use in other modules
- Get Hostname from User (Yes/No): If yes, the hostname will be got from the user in the Credentials page.
- If no, the user has to provide the URL in API Manager itself
- 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
- OAuth2
- NTLM
- Basic Authentication
- MySQL Authentication
- 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.
- Default value for Connect = 30 seconds
- Default value for Read = 240 seconds
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.
Enter 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: {...}}
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:
/SapB1/controller/testConnection
/api/Ping/PingToken
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", then the Dynamic Token section gets populated on the screen.
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, we can make use of this option.
Example Dynamic Token URL: /connect/token.
The Dynamic token body contains information on how the token is generated. It can either be a user name/ 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.
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.
Now, let's say your system requires a Username and Password to return a token. After providing the Username and Password in 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 Label: As you wish Key: Usually "Authorization". This might differ according to your system |
Value: | | |
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 page for the user to enter.
GET_FROM_CREDENTIALS entered in the Systems page
"username" field populates in Credentials page
Last modified 10mo ago