ATS : ATS HTTP DB Logger Guide

Introduction

The ATS framework is an automated testing framework which usually sends its test execution results to a database. The test results are naturally and nicely reviewed by the ATS Test Explorer web application.

If we imagine you want to run non-Java tests and still review the execution results through Test Explorer, then this page is just for you. The HTTP DB Logger is an application which will connect your non-Java tests with the Test Explorer database.

The HTTP DB Logger is a simple REST-like application which can accept your REST calls and translate them properly to the Test Explorer database.



Installation

The ATS HTTP DB Logging Server is distributed as a regular WAR (Web ARchive) file which needs to be started as any other web application by Tomcat or a similar Java Web Container Server.

The server is ready to be used once it gets started.

The HTTP Db Server can be used to log into different databases located on different hosts. You just have to specify the right target database host in the REST requests.
Anyway, usually it makes sense to have the HTTP DB Logging Server located on the same host where the Test Explorer DB is.


Request format

The request type is expected in the form of application/json , so you must specify accordingly the "Content-Type" header.

The log event itself is expected to be contained in the JSON body, so you must properly set the expected key-value pairs for each event type.

Each request must contain a sessionID body token which points to the current session. The only exception is the startRun request which does not expect such token.

Unless specified, requests that send data to the database are using POST, while requests that read data from the database are using GET.



Response format

The response type in the form of application/json, so you should specify accordingly the "Accept" header.



Some important tokens used in the communication

Session ID

Once the server give you back a Session ID, all following requests should pass this token as part of the body, so this request can be assigned to the proper session on the server side.

The session stores information like connection to a database, previously started run, suites and test cases.

The Session ID is created on executing a startRun event.

Timestamp

Many requests are allowed to optionally provide a timestamp. The timestamp (expected in milliseconds) is the time and date of the event occurrence (Java System.currentTimeMillis() and UNIX-like, time since Jan, 1st, 1970).

If the request is to be persisted in the database (with other words if this is not a GET), then it must reach the database with some timestamp set. In case the request does not specify one, the logging server will apply the time of the server itself.

Parent ID

When used, you specify the parent of the current event. For example when do startTestcase the parent ID tells us the particular SUITE this TESTCASE will belong to.

The parent ID is the actual database ID of the parent table.

Only a RUN cannot have a parent.



Sending data to Test Explorer database

Here you will find how to use the application for sending data to the database



Reading data from Test Explorer database

Here you will find how to use the application for reading data from the database



Retrieving the distribution

Here is the location with all available versions



Release notes

Here they are



Example using the HTTP DB Logging API

As all communication is REST based, you can interact with any kind of programming language.

Here we have made an example via python.



Go to parent page

Go to Table of Contents