Definition based query form, which use the registered application and transaction definition from the data source.
Free forms where any application and transaction name can be used.

Screenshot 2: ARM CGI form header

Screenshot 2 displays three different buttons. You can use the

Definitions button: for browsing through all registered application and transaction definitions
Applications button: for a free form to query application instances.
Transactions button: for a free form to query transaction measurements

ARM applications and transactions have their own identity. This identity is mainly formed by their name and optionally by identity properties. The CGI-based query shows all these identity strings if the query form was generated by browsing through the ARM definitions. Screenshot 3 depicts the identity display of the ARM'ed Apache web-server application:

Screenshot 3: ARM CGI form identity part

The first line displays the application name and its optional identity properties. The second line display the transaction name and identity properties. If the application has more than one transaction the user can select one transaction from a list of all possible transactions to submit queries for. Note: You have to press the select button to use the selected transaction in a query. The CGI has no real active part such as JavaScript since it is not really portable.

Query constraints

Screenshot 4 shows the query form part to select ARM transactions by various criteria. The list on the left side is used to select several fields of a transaction to display in the result (e.g. Name, ResponseTime, Status, etc).

Screenshot 4: ARM CGI form constraints part

On the right of the list there are input fields to specify your specific query constraints:

Time Format and Duration Unit selections: specifies the time and response time format to be used as in- and output formats. For example you can select a response time unit in seconds or in micro seconds depending on the transaction mean execution time.
Start From and Start Until input fields: matches only transactions which have started since and until the specified dates
Stop From and Stop Until input fields: matches only transactions which have stopped since and until the specified dates
Duration Min and Duration Max input fields: specifies the minimum and maximum response time of a transaction to match. All transactions which executed faster or slower are excluded in the result.
Status selection: specifies the status of a transaction to match. For example, GOOD or FAILED.
User selection: selects the user on behalf a transaction was executed (if any)
Show children checkbox: if marked, also displays any children of matching transactions.

If you have entered all constraints for your query you can press the Query button. This will load the result of the query into the right-frame. See also submit section for more details on queries.

Result configuration

When querying transaction measurements there are usually more matching transactions than can be displayed within a browser. Therefore the CGI can be configured to display only parts of the results and offers the possibility to navigate through the result set.

Screenshot 5: ARM CGI form result config part

Pages input field: Number of pages to provide direct access through the result navigation bar.
Max/Page input field: specifies the maximum number of matching transactions displayed at once (page).
Index input field: specifies the index into the result set.
Sorting selection: specifies if the result set should be sorted or not. Some sorting criteria are supported. For example stop time or duration time.
Descending checkbox: if checked the sorting is performed in a descending order instead of an ascending.

Submit query

After all constraints are specified the real query can be submitted to the ARM CGI. Screenshot 6 shows buttons of all different kinds of queries which the CGI supports:

Screenshot 6: ARM CGI form submit part

Query button: submits the query to the CGI and each matching transaction measurement is displayed to the right-frame side as a result. See also Result section for more details.
Statistic button: computes a statistic over the result transactions and displays it
Histogram button: generates a histogram of the result transactions and displays it
Correlate button: Executes the correlation function within underlying ARM data store which correlates parent/child transactions. You can only show parent/child relationships using the Show children checkbox in the query form if you executed this function first. It computes internal links from parent to child transactions.

The correlation process also operates on the constraints specified in the constraints form part. This is quite useful if you operate on a large set of transaction measurements.

Result frame

Screenshot 7 shows the result of a transaction query. The following sections describes the

Navigation bar
Transaction output

Screenshot 7: ARM CGI result frame

Result navigation bar

The results you received from your query are shown in the right frame. In many cases there are more transactions than can be displayed on the screen. Therefore a navigation bar provides the functionality to browse through the result set:

Screenshot 8: ARM CGI result navigation bar

In screenshot 8 above you can see on the right that the total number of matched transaction are displayed. Since so many transaction can't be viewed at once, several pages are created to browse through the transactions. A page shows the number of transactions specified into the Max results input field in the query form. You can navigate through the pages just by clicking on the page number or by selecting one of the arrow links.

Result transaction

Screenshot 9 displays the output for one transaction with its sub-transactions (children). The main (parent) transaction here is the Request transaction of a HTTP request to a web-server (Apache). With ARM 4.0 it is possible to add various internal information to a transaction measurement. Here the URI of the requested web-resource, the Content-Length of the resource and the HTTP-Status of the request are exported to ARM.

Screenshot 9: ARM CGI result transaction example

The Request is internally processed by some sub-transactions which are shown in the screenshot:

ReadReq reads the request from the client (browser).
ProcessReq processes the request and executes also some child transactions:
1. Mod_CGI executed and failed because the printenv CGI script did not have had the correct execution rights. This was fixed later.
2. LogReq logs the request to the web-servers log file.