Custom Systems

If you cannot find the system that you are looking for, you can create a custom system and use it. These systems are private and only accessible to the project members.

Add Custom System

Step 1: Choose from Systems

Step 2: Provide system details

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

    • OAuth2

    • 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

Test Connection

URL

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
https://www.example.com/api/Ping/PingToken

Params, Header, and Body

Three fields are set for each parameter/header/body:

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.

Error Handler

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: {...}}

Available Keywords

1. DYNAMIC_TOKEN

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.

2. GET_FROM_CREDENTIALS

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

Edit a Custom System

Click "Edit System" on the System details page to manage the system fields.

Last updated