{
"items": [
{
"id": "29e53d7d-1b19-3794-b71a-9bf8efaea48f",
"title": "Datomic Diagnostic Testcase",
"description": "Test Datomic database creation, transaction, query, retraction, and deletion on default backend."
},
{
"id": "233e6441-d769-494f-ba72-c46a52ff3d0c",
"title": "Events Subscription Diagnostic Testcase",
"description": "Test Events subscription is healthy by subscribing to a well-known topic."
},
{
"id": "f9bdcf39-5c7d-4788-85a2-e5c7fa915a43",
"title": "Events End-to-End Diagnostic Testcase",
"description": "Test Events end-to-end by declaring a topic and verifying published messages are delivered to subscriber."
}
],
"total": 3,
"offset": 0
}
Blue Planet diagnostics APIs
Blue Planet includes a diagnostics REST API component located at https://<server_IP>/bpocore/diagnostics/api/v1. Two resources are available to help you diagnose several Blue Planet scenarios.
Understanding the test cases
The test cases resource includes a list of the diagnostic test cases. They are configured in the diagnostics.conf file and refer to plugin class names that are inherited from the DiagnosticTester. These test cases are Scala/Java code plugins. The three test cases coded into bpocore follow:
You can use these tests for other purposes beyond the stated description. For example, if you run the Datomic Diagnostic Test, it not only confirms the behavior of the database, it also confirms:
-
haproxy is working
-
the REST server inside bpocore is functioning
-
the UAC app is authenticating requests
-
the persistence layer of Datomic/Cassandra is working
Running the test cases
You can run the test cases using either asynchronous/polled or synchronous methods. Ciena recommends that you use the asynchronous method, where you create a test instance and then poll the test instance state.
Asynchronous test method
To poll the test instance state use:
POST /test-instances {"title": "my test title", "testcaseId" :<testcaseId from above list>}
This command returns the code 201. This indicates that the test instance was created. The response body might look as follows:
{
"id": "56c34eee-b91a-4510-a3ab-be06a823a705",
"title": "string",
"creationTime": "2016-02-16T16:31:42.105Z",
"testcaseId": "f9bdcf39-5c7d-4788-85a2-e5c7fa915a43",
"state": "creating"
}
The state initially displays as “creating”.
The test runs asynchronously. Poll GET /test-instances/{instanceId} based on the “id" of the test instance until you confirm the state is either passed or failed. For example, the output might look as follows:
{
"id": "56c34eee-b91a-4510-a3ab-be06a823a705",
"title": "string",
"creationTime": "2016-02-16T16:31:42.105Z",
"testcaseId": "f9bdcf39-5c7d-4788-85a2-e5c7fa915a43",
"state": "passed",
"details": "\ndeclareTopic -> passed\nsubscribe -> passed\nartificialDelay -> passed\npublishMessages -> passed\nexpectMessages -> passed\nunsubscribeStep -> passed"
}
Synchronous test method
You can also run the test synchronously using the GET/testcases/{testcaseId} API.
This command returns the code 200 if the operation was successful. Check the state to determine if the test passed or failed. The system immediately returns the state in the response without the need for polling.
For example, the output might look as follows:
{
"id": "56c34ff4-1201-42de-ac11-ef418f5ea1a8",
"title": "",
"creationTime": "2016-02-16T16:36:04.582Z",
"testcaseId": "f9bdcf39-5c7d-4788-85a2-e5c7fa915a43",
"state": "passed",
"details": "\ndeclareTopic -> passed\nsubscribe -> passed\nartificialDelay -> passed\npublishMessages -> passed\nexpectMessages -> passed\nunsubscribeStep -> passed"
}
}