Skip to content

Testing Connections

Before relying on a connection in production orchestrations, you should test it thoroughly. DIBOP provides built-in tools to verify that your connections are working correctly.

Quick Test (Ping)

The simplest test is the Ping -- a lightweight health check that verifies DIBOP can reach the external system and authenticate.

How to Run a Ping

  1. Navigate to CONNECT > Integrations or CONNECT > My Connections
  2. Find the connection you want to test
  3. Click the Ping button (or the connection status icon)
  4. Wait for the result (typically 1-3 seconds)

Ping Results

Result Meaning
Online (green) The system responded successfully
Offline (red) The system did not respond or returned an error
Timeout The system did not respond within the configured timeout
Auth Error The system rejected the credentials

Bulk Ping

When you open the Integrations page, DIBOP automatically pings all configured connections in parallel. This gives you an instant view of which systems are reachable.

Test Runner

For more thorough testing, use the Test Runner. The Test Runner executes a series of test cases against a connection, verifying not just connectivity but also specific API operations.

What the Test Runner Tests

The Test Runner validates:

  1. Connectivity -- can DIBOP reach the system?
  2. Authentication -- are the credentials accepted?
  3. API Operations -- do registered API calls return expected responses?
  4. Response Format -- does the response match the expected schema?
  5. Latency -- is the response time within acceptable limits?

Running the Test Runner

  1. Navigate to CONNECT > My Connections
  2. Click on the connection you want to test
  3. Click Run Tests
  4. The Test Runner executes all test cases and displays results in real time

Understanding Results

Each test case shows:

Column Description
Test Name What is being tested (e.g., "Authentication", "Search Vehicles")
Status Pass, Fail, or Skip
Duration How long the test took in milliseconds
Details For failures, the error message and HTTP response code

A summary bar at the top shows the overall result:

  • All Passed -- every test case succeeded
  • Partial -- some test cases passed and some failed
  • Failed -- critical test cases (connectivity, auth) failed

Creating Custom Test Cases

If the built-in tests do not cover your specific needs, you can create custom test cases.

Adding a Test Case

  1. In the Test Runner panel, click Add Test Case
  2. Configure the test:
Field Description
Name A descriptive name for the test
Operation The API operation to call (selected from the connector's registered operations)
Parameters Input parameters for the API call (JSON format)
Expected Status The expected HTTP status code (e.g., 200, 201)
Assertions Optional JSONPath assertions on the response body

Example: Custom VIN Lookup Test

{
  "name": "VIN Lookup - Known Vehicle",
  "operation": "search_vehicles",
  "parameters": {
    "vin": "WDB1234567890"
  },
  "expected_status": 200,
  "assertions": [
    {
      "path": "$.results[0].vin",
      "equals": "WDB1234567890"
    },
    {
      "path": "$.results",
      "not_empty": true
    }
  ]
}

Saving Test Cases

Custom test cases are saved per connection and persist across sessions. They run alongside the built-in tests whenever you click Run Tests.

Interpreting Common Failures

Connection Refused

Error: ECONNREFUSED 10.0.0.1:443

The external system is not accepting connections. This could mean:

  • The system is down for maintenance
  • The base URL is incorrect
  • A firewall is blocking the connection

Action: Verify the base URL and check if the external system is operational.

SSL Certificate Error

Error: CERT_HAS_EXPIRED

The external system's SSL certificate has expired or is not trusted.

Action: Contact the external system's administrator. This is not a DIBOP issue.

401 Unauthorized

HTTP 401: Invalid API key

The credentials were rejected by the external system.

Action: Verify your credentials are correct and have not expired. See Managing Credentials.

403 Forbidden

HTTP 403: Insufficient permissions

The credentials are valid but do not have permission to access the requested resource.

Action: Check that your API key or OAuth2 scopes include the required permissions.

429 Too Many Requests

HTTP 429: Rate limit exceeded

You have exceeded the external system's rate limit.

Action: Wait and retry. DIBOP's built-in retry mechanism handles this automatically, but excessive 429 errors may indicate you need a higher rate limit tier with the external provider.

Timeout

Error: Request timed out after 30000ms

The external system did not respond within the configured timeout.

Action: Increase the timeout in the connection settings, or investigate whether the external system is experiencing performance issues.

Scheduled Health Checks

DIBOP automatically runs health checks on all active connections at regular intervals. You can view the health check history for any connection:

  1. Navigate to CONNECT > My Connections
  2. Click on a connection
  3. Scroll to the Health History section

The health history shows:

  • Timestamp of each check
  • Result (healthy/unhealthy)
  • Response time
  • Any error messages

Best Practices

  1. Test after credential rotation -- always run the Test Runner after updating credentials
  2. Test before activating orchestrations -- ensure the connection is healthy before putting it into production workflows
  3. Create custom tests for critical operations -- do not rely solely on the ping; test the specific API calls your orchestrations will use
  4. Monitor test trends -- if tests that previously passed start failing intermittently, it may indicate network issues or rate limiting

Next Steps