Cloras
Search…
Systems
The Systems page is where users can add, edit, and maintain Systems for a project.
The individual platforms that Cloras directly connects to, or connects using APIs are known as systems. For example, ERP is a system.
These systems need to be configured in Cloras 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.

Add System

Click on the Add New button in 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 Cloras 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 Cloras.
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

Error Handler

By default, Cloras 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: {...}}

Test Connection

URL

The Test connection API is used to check if Cloras 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:
1
/SapB1/controller/testConnection
2
/api/Ping/PingToken
Copied!

Params, Header, and Body

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
    application/json
    application/xml
If the Authorization Header key has a value: "DYNAMIC_TOKEN", then the Dynamic Token section gets populated on the screen.
Cloras 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.

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 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, Cloras 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]

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 page for the user to enter.
GET_FROM_CREDENTIALS entered in the Systems page
"username" field populates in Credentials page
Last modified 9mo ago