Use Cases and Recipes

Common use cases and recipes of REST Commander, REST APIs examples. -- REST Commander is not just an HTTP Client, it is an HTTP Client as a service.

Commander REST APIs enables complex request patterns, such as sending same or different requests to different servers, and different requests to single server. Further, it can aggregate the server response based on custom rules. Here are some common use cases with examples. For your convenience, import the Postman (a rest client as Chrome plugin) request collection immediately to try out!

Table of Use Cases

Request Type Use Case Examples
Same request to different servers 1. Monitoring cluster servers status where the status can be checked from same request;
2. Push same configuration to all the servers.
Assuming we want to monitor a list of servers, on which the health status can be checked through a uniformed "validateInternals.html" page. REST Commander can send request to parse health status information from server response, and aggregate the overall health status of cluster. (See example)
Different Requests to different servers 1. Push server-specific configuration to different servers, such as configuration with topology, ip address data;
2. Querying different servers with information which needs to be accessed through different requests.
Assuming we have a list of different servers, where each server has a unique URL/API or a page with unique name to describe its job id running on the server, and its current job execution progress. By using REST Commander, you can easily automate the process to aggregate job execution information from these servers. (See example)
Different requests to same server Get multiple response from same server in parallel, and aggregate the response based on custom rules. By querying the SOAP(WSDL)-based public weather web service: a central server (single target) with multiple requests each with a zip code, you can aggregate the wind/temperature/city information for these different zip code. See example: (REST APIs, GUI Wizards )

In more generic and abstract form, these examples demonstrates Commander ability for the following recipes over HTTP.

Table of Recipes (more generic form)

Recipe Description
Federated data aggregation Not limit to monitor or config pushes, Commander is great for aggregate any data that accessible by a HTTP URL, from a distributed environment where there are a large number of HTTP endpoints.
Scalable task execution e.g. you have HTTP based Puppet/SaltStack agents running on your servers, scalably executing tasks in parallel through these agents are simple. Commander will act as the agent master to talk with the agents via HTTP.

Assuming we want to monitor a list of servers, on which the health status can be checked through a uniformed "validateInternals.html" page. For example:

Each of the server stores a page called validateInternals.html, which shows the host name, server status, CPU usage information, and so on. For example, on one of the server, the validateInternals.html page looks like below:
<!DOCTYPE html>
<html>
<body>
<h1>My Server Status</h1>
<h4>System Health</h4>
<table border='1'>
    <tr>
        <td>Memory-Used-KB</td>
        <td>28338</td>
    </tr>
    <tr>
        <td>CPU-Usage-Percent</td>
        <td>23.54</td>
    </tr>
    <tr>
        <td>Server-Is-Healthy</td>
        <td>False</td>
    </tr>
    <tr>
        <td>Host-Name</td>
        <td>www.yangli907.com</td>
    </tr>
	</table>
	<h4>A demo page to show a sample server health page for use cases by REST Commander.</h4>
</body>
</html>

We want to send same http request (/validateInternals.html) to every server in the cluster, aggregate and analyze the health status of the cluster from the server response, which shows in the <td>Server-Is-Healthy</td> row. Then we can further take appropriate solutions to fix the unhealthy ones, in order to bring them back to healthy status.

a. Define Request Type and Aggregation Rule

The first step is to define request command sent to the servers. In this case we want to get the same server endpoint "/validateInternals.html", so the request command looks like:
GET_VALIDATE_INTERNAL GET https 80 /validateInternals.html 0 -1 -1 SUPERMAN_GLOBAL
```$AM_FULL_CONTENT
(for the meaning of each segment above, please refer to Commands Section in Documentation page.)

Then you need to define the aggregation rules, which tells REST Commander what's the value we are interested in to aggregate. For example, in the request, we need to specific the name("aggregationType") and expression("newAggregationExpression") of the aggregation rule:
"aggregationType" : "PATTERN_PARSE_MONITOR_HEALTH",
"newAggregationExpression" : ".*<td>Server-Is-Healthy</td>\s*<td>(.*?)</td>[\s\S]*"

Note!: In REST APIs to Commander, the aggregation rule (regular expression) must be URL encoded to avoid special characters.

Here the (.*?) expression shows we need to extract the content in the html table cell at "Server-Is-Healthy" row.

b. Send Request

The second step is building the json request body, which tells REST Commander how to build http request for each server, and what's the aggregation rules.

POST http://localhost:9000/commands/genUpdateSendCommandWithReplaceVarMapAdhocJson (Commander running at http://localhost:9000)
POST BODY
{ "targetNodes":[ "www.restsuperman.com", "www.jeffpei.com", "www.yangli907.com" ], "useNewAgentCommand":"true", "newAgentCommandLine":"GET_VALIDATE_INTERNAL GET http 80 /validateInternals.html 0 0 5000 SUPERMAN_GLOBAL", "newAgentCommandContentTemplate":"$AM_FULL_CONTENT", "willAggregateResponse":false, "useNewAggregation":true, "aggregationType":"PATTERN_PARSE_MONITOR_HEALTH", "newAggregationExpression":".%2A%3Ctd%3EServer-Is-Healthy%3C%2Ftd%3E%5Cs%2A%3Ctd%3E%28.%2A%3F%29%3C%2Ftd%3E%5B%5Cs%5CS%5D%2A" }

Alert! When defining the new command (not a predefined in agentcommand.conf: must have both "newAgentCommandLine" and "newAgentCommandContentTemplate" to form the 2 lines. Otherwise the new command will fail to create.

Upon successful submission of request "GET /validateInternals.html" on all the servers, Commander will get the raw response from each server.

For the meaning of each post body field parameter, please refer to Request Options

c. Sample Response:

Based on different aggregation preference parameters, REST Commander can propagate raw server response from server without aggregation, or the aggregated data after applying specified aggregation rule.
For example, without aggregation, REST Commander returns an array of json objects, each stands for the response metadata from the server:
 {
   "www.jeffpei.com":{
      "dataMap":{
         "GET_VALIDATE_INTERNALS":{
            "requestParameters":{
               "AM_FULL_CONTENT":"",
               "HEADER_TYPE":"SUPERMAN_GLOBAL",
               "HTTP_METHOD":"GET",
               "PREPARE_TIME":"2014-01-12 21:27:37.212-0800",
               "TRUE_CONTENT":"",
               "TRUE_PORT":"80",
               "TRUE_URL":"/validateInternals.html"
            },
            "responseContent":{
               "isError":false,
               "response":"<!DOCTYPE html>\n<html>\n<body>\n\n<h1>My Server Status</h1>\n\n\n<h4>System Health</h4>\n<table border='1'>\n    <tr>\n        <td>Memory-Used-KB</td>\n        <td>19213</td>\n    </tr>\n  \n    <tr>\n        <td>CPU-Usage-Percent</td>\n        <td>27.08</td>\n    </tr>\n\n        \n    <tr>\n        <td>Server-Is-Healthy</td>\n        <td>True</td>\n    </tr>\n    <tr>\n        <td>Host-Name</td>\n        <td>www.jeffpei.com</td>\n    </tr>\n\n\t\n\t</table>\n\t\n\t\n\t<h4>A demo page to show a sample server health page for use cases by REST Commander.</h4>\n\t\t\n\t\n\n</body>\n</html>",
               "responseTime":"2014.01.12.21.27.37.474-0800",
               "statusCode":"200 OK"
            }
         }
      },
      "fqdn":"www.jeffpei.com"
   },
   "www.restsuperman.com":{
      "dataMap":{
         "GET_VALIDATE_INTERNALS":{
            "requestParameters":{
               "AM_FULL_CONTENT":"",
               "HEADER_TYPE":"SUPERMAN_GLOBAL",
               "HTTP_METHOD":"GET",
               "PREPARE_TIME":"2014-01-12 21:27:37.212-0800",
               "TRUE_CONTENT":"",
               "TRUE_PORT":"80",
               "TRUE_URL":"/validateInternals.html"
            },
            "responseContent":{
               "isError":false,
               "response":"<!DOCTYPE html>\n<html>\n<body>\n\n<h1>My Server Status</h1>\n\n\n<h4>System Health</h4>\n<table border='1'>\n    <tr>\n        <td>Memory-Used-KB</td>\n        <td>51243</td>\n    </tr>\n  \n    <tr>\n        <td>CPU-Usage-Percent</td>\n        <td>7.08</td>\n    </tr>\n\n        \n    <tr>\n        <td>Server-Is-Healthy</td>\n        <td>True</td>\n    </tr>\n    <tr>\n        <td>Host-Name</td>\n        <td>www.restsuperman.com</td>\n    </tr>\n\n\t\n\t</table>\n\t\n\t\n\t<h4>A demo page to show a sample server health page for use cases by REST Commander.</h4>\n\t\t\n\t\n\n</body>\n</html>",
               "responseTime":"2014.01.12.21.27.37.756-0800",
               "statusCode":"200 OK"
            }
         }
      },
      "fqdn":"www.restsuperman.com"
   },
   "www.yangli907.com":{
      "dataMap":{
         "GET_VALIDATE_INTERNALS":{
            "requestParameters":{
               "AM_FULL_CONTENT":"",
               "HEADER_TYPE":"SUPERMAN_GLOBAL",
               "HTTP_METHOD":"GET",
               "PREPARE_TIME":"2014-01-12 21:27:37.212-0800",
               "TRUE_CONTENT":"",
               "TRUE_PORT":"80",
               "TRUE_URL":"/validateInternals.html"
            },
            "responseContent":{
               "isError":false,
               "response":"<!DOCTYPE html>\r\n<html>\r\n<body>\r\n\r\n<h1>My Server Status</h1>\r\n\r\n\r\n<h4>System Health</h4>\r\n<table border='1'>\r\n    <tr>\r\n        <td>Memory-Used-KB</td>\r\n        <td>28338</td>\r\n    </tr>\r\n  \r\n    <tr>\r\n        <td>CPU-Usage-Percent</td>\r\n        <td>23.54</td>\r\n    </tr>\r\n\r\n        \r\n    <tr>\r\n        <td>Server-Is-Healthy</td>\r\n        <td>False</td>\r\n    </tr>\r\n    <tr>\r\n        <td>Host-Name</td>\r\n        <td>www.yangli907.com</td>\r\n    </tr>\r\n\r\n\t\r\n\t</table>\r\n\t\r\n\t\r\n\t<h4>A demo page to show a sample server health page for use cases by REST Commander.</h4>\r\n\t\t\r\n\t\r\n\r\n</body>\r\n</html>\r",
               "responseTime":"2014.01.12.21.27.37.223-0800",
               "statusCode":"200 OK"
            }
         }
      },
      "fqdn":"www.yangli907.com"
   }
}
Further, enable the aggregation by setting "willAggregateResponse":true in the request POST body: aggregation on the "Server-Is-Healthy" row, the returned result is as below:
{
   "aggregationMap":{
      "False":"1",
      "True":"2"
   },
   "aggregationValueToNodesList":[
      {
         "isError":false,
         "nodeList":[
            "www.yangli907.com"
         ],
         "value":"False"
      },
      {
         "isError":false,
         "nodeList":[
            "www.jeffpei.com",
            "www.restsuperman.com"
         ],
         "value":"True"
      }
   ]
}

Here is the use cases when you need to query different job progress on different servers, or push different configs to different servers. Assuming we have a list of different servers, where each server runs its own job with a different job id. Via a unique job URL you can access a page describing the job id running on the server, and its current job execution progress:

Each of the job html page has the content such as below:
<!DOCTYPE html>
<html>
<body>
<h1>My Job Status</h1>
<table border='1'>
    <tr>
        <td>JobID</td>
        <td>51243</td>
    </tr>
	<tr>
        <td>JobProgress</td>
        <td>80%</td>
    </tr>
</table>
	<h4>A demo page to show a sample server-based job status page for use cases by REST Commander.</h4>
</body>
</html>          
          
As you can see, the HTTP request sent to each server is different. With REST Commander, you can easily automate the process to send different requests to each server.

a. Define Request Type and Aggregation Rules

The first step is to define request command with server-specific variable replacement template, where the $APIVARREPLACE_JOBID is the stub to be replaced based on each server:
GET_JOB_STATUS GET https 80 /$APIVARREPLACE_JOBID 0 -1 -1 SUPERMAN_GLOBAL
```$AM_FULL_CONTENT
In the actual request which REST Commander sends to each server, the stub (variable) will be replaced accordingly, for example, Commander will replace it to job_a.html when sending request to server www.yangli907.com, and to job_b.html when sending to server www.jeffpei.com.
(for the meaning of each segment above in the command, please refer to Commands Section in Documentation page.

Then you need to define the aggregation rules, which tells REST Commander what's the value we are interested in to aggregate. For example, in the request, we need to specify the name("aggregationType") and expression("newAggregationExpression") of the aggregation rule:
"aggregationType" : "PATTERN_PARSE_JOB_PROGRESS",
"newAggregationExpression" : ".*<td>JobProgress</td>\s*<td>(.*?)</td>[\s\S]*"
Here the (.*?) expression shows we need to extract the content in the html table cell at "JobProgress" row.

b. Sample Request:

The second step is building the json request body, which tells REST Commander how to build http request for each server, and what's the aggregation rules. Please note the aggregation expression will be URL encoded in the json request body.

POST http://localhost:9000/commands/genUpdateSendCommandWithReplaceVarMapNodeSpecificAdhocJson (Commander running at http://localhost:9000)
{
   "targetNodes":["www.yangli907.com","www.jeffpei.com","www.restsuperman.com"],
   "willAggregateResponse":false,
   "useNewAggregation":true,
   "aggregationType":"PATTERN_AGGREGATE_JOB_STATUS",
   "agentCommandType":"GET_JOB_PROGRESS",
   "newAgentCommandLine":"GET_JOB_STATUS GET http 80 /$APIVARREPLACE_JOB_NAME 0 0 5000 SUPERMAN_GLOBAL",
   "useNewAgentCommand":"true",
   "newAggregationExpression":".%2A%3Ctd%3EJobProgress%3C%2Ftd%3E%5Cs%2A%3Ctd%3E%28.%2A%3F%29%3C%2Ftd%3E%5B%5Cs%5CS%5D%2A",
   "newAgentCommandContentTemplate":"$AM_FULL_CONTENT",
   "replacementVarMapNodeSpecific":{
     "www.yangli907.com":{
       "map":{
         "APIVARREPLACE_JOB_NAME":"job_a.html"
         }
       },
     "www.jeffpei.com":{
       "map":{
         "APIVARREPLACE_JOB_NAME":"job_b.html"
         }
       }
     ,
     "www.restsuperman.com":{
       "map":{
         "APIVARREPLACE_JOB_NAME":"job_c.html"
         }
       }
     }
     
}
For the meaning of each post body field parameter, please refer to Request Options

c. Sample Response:

Based on different aggregation preference parameters, REST Commander can list raw server response from server without aggregation, or the aggregated data after applying specified aggregation rule.
For example, without aggregation, REST Commander returns an array of json objects, each stands for the response metadata from one server:
{
    "www.jeffpei.com": {
        "fqdn": "www.jeffpei.com",
        "dataMap": {
            "GET_JOB_STATUS": {
                "requestParameters": {
                    "TRUE_URL": "/job_b.html",
                    "PREPARE_TIME": "2014-01-18 13:29:58.980-0800",
                    "NODE_REQUEST_WILL_EXECUTE": "true",
                    "REPLACE-VAR_APIVARREPLACE_JOB_NAME": "job_b.html",
                    "AM_FULL_CONTENT": "",
                    "TRUE_PORT": "80",
                    "HEADER_TYPE": "SUPERMAN_GLOBAL",
                    "HTTP_METHOD": "GET",
                    "TRUE_CONTENT": ""
                },
                "responseContent": {
                    "response": "<!DOCTYPE html>\n<html>\n<body>\n\n<h1>My Job Status</h1>\n\n<table border='1'>\n    <tr>\n        <td>JobID</td>\n        <td>51243</td>\n    </tr>\n                <tr>\n        <td>JobProgress</td>\n        <td>80%</td>\n    </tr>\n</table>\n                <h4>A demo page to show a sample server-based job status page for use cases by REST Commander.</h4>\n</body>\n</html>",
                    "responseTime": "2014.01.18.13.29.59.425-0800",
                    "statusCode": "200 OK",
                    "isError": false
                }
            }
        }
    },
    "www.restsuperman.com": {
        "fqdn": "www.restsuperman.com",
        "dataMap": {
            "GET_JOB_STATUS": {
                "requestParameters": {
                    "TRUE_URL": "/job_c.html",
                    "PREPARE_TIME": "2014-01-18 13:29:58.981-0800",
                    "NODE_REQUEST_WILL_EXECUTE": "true",
                    "REPLACE-VAR_APIVARREPLACE_JOB_NAME": "job_c.html",
                    "AM_FULL_CONTENT": "",
                    "TRUE_PORT": "80",
                    "HEADER_TYPE": "SUPERMAN_GLOBAL",
                    "HTTP_METHOD": "GET",
                    "TRUE_CONTENT": ""
                },
                "responseContent": {
                    "response": "<!DOCTYPE html>\n<html>\n<body>\n\n<h1>My Job Status</h1>\n\n<table border='1'>\n    <tr>\n        <td>JobID</td>\n        <td>77727</td>\n    </tr>\n                <tr>\n        <td>JobProgress</td>\n        <td>27%</td>\n    </tr>\n</table>\n                <h4>A demo page to show a sample server-based job status page for use cases by REST Commander.</h4>\n</body>\n</html>",
                    "responseTime": "2014.01.18.13.30.00.033-0800",
                    "statusCode": "200 OK",
                    "isError": false
                }
            }
        }
    },
    "www.yangli907.com": {
        "fqdn": "www.yangli907.com",
        "dataMap": {
            "GET_JOB_STATUS": {
                "requestParameters": {
                    "TRUE_URL": "/job_a.html",
                    "PREPARE_TIME": "2014-01-18 13:29:58.981-0800",
                    "NODE_REQUEST_WILL_EXECUTE": "true",
                    "REPLACE-VAR_APIVARREPLACE_JOB_NAME": "job_a.html",
                    "AM_FULL_CONTENT": "",
                    "TRUE_PORT": "80",
                    "HEADER_TYPE": "SUPERMAN_GLOBAL",
                    "HTTP_METHOD": "GET",
                    "TRUE_CONTENT": ""
                },
                "responseContent": {
                    "response": "\n<!DOCTYPE html>\n<html>\n<body>\n\n<h1>My Job Status</h1>\n\n<table border='1'>\n    <tr>\n        <td>JobID</td>\n        <td>32145</td>\n    </tr>\n\t<tr>\n        <td>JobProgress</td>\n        <td>95%</td>\n    </tr>\n\n\n\t\n\t</table>\n\t\n\t\n\t<h4>A demo page to show a sample server-based job status page for use cases by REST Commander.</h4>\n\t\t\n\t\n\n</body>\n</html>",
                    "responseTime": "2014.01.18.13.29.59.087-0800",
                    "statusCode": "200 OK",
                    "isError": false
                }
            }
        }
    }
}

Further, enable the aggregation by setting "willAggregateResponse":true in the request POST body: with aggregation on the "JobProgress" row, the returned result is as below:
{
    "aggregationMap": {
        "27%": "1",
        "80%": "1",
        "95%": "1"
    },
    "aggregationValueToNodesList": [
        {
            "value": "27%",
            "nodeList": [
                "www.restsuperman.com"
            ],
            "isError": false
        },
        {
            "value": "80%",
            "nodeList": [
                "www.jeffpei.com"
            ],
            "isError": false
        },
        {
            "value": "95%",
            "nodeList": [
                "www.yangli907.com"
            ],
            "isError": false
        }
    ]
}

Commander can send the same set of requests via (1) UI Wizards and (2) REST APIs; here we show the REST APIs; for the corresponding step by step screenshots of the wizard part: check Wizards and Response Analysis and Logs sections in "Documentation" page.

REST Commander API also supports using template to define node-specific requests, send to remote hosts and aggregate the returned response.
Here is an example to demonstrate how to define REST Commander command, and post request to query weather information for different cities from a single WSDL-based forecast website, which shows how to define such type of request(assuming server is running on localhost).

a. Define Command

GET_PUBLIC_WEATHER_APIVARREPLACE POST http 80 /WeatherWS/Weather.asmx 20 -1 -1 HEADER_PUBLIC_WEATHER
```<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:weat="http://ws.cdyne.com/WeatherWS/"><soapenv:Header/><soapenv:Body><weat:GetCityWeatherByZIP><weat:ZIP>$APIVARREPLACE_ZIP_VAR</weat:ZIP></weat:GetCityWeatherByZIP></soapenv:Body></soapenv:Envelope>

b. Send Request

POST URL: http://localhost:9000/commands/genUpdateSendCommandWithReplaceVarMapNodeSpecificAdhocJson   (Commander running at http://localhost:9000)
POST BODY:
{
   "targetNodes":[
      "95131",
      "95132",
      "95037",
      "48824",
      "48823"
   ],  
   "willAggregateResponse":true,
   "useNewAggregation":false,  
   "aggregationType":"PATTERN_WEATHER_WSDL_CITY",  
   "agentCommandType":"GET_PUBLIC_WEATHER_APIVARREPLACE",
   "replacementVarMapNodeSpecific":{
      "95131":{
         "map":{
            "APIVARREPLACE_ZIP_VAR":"95131",
  			"APIVARREPLACE_SUPERMANSPECIAL_TARGET_NODE_VAR":"wsf.cdyne.com"
         }
      },
 	  "95132":{
         "map":{
            "APIVARREPLACE_ZIP_VAR":"95132",
  			"APIVARREPLACE_SUPERMANSPECIAL_TARGET_NODE_VAR":"wsf.cdyne.com"
         }
      },
       "95133":{
         "map":{
            "APIVARREPLACE_ZIP_VAR":"95133",
   			"APIVARREPLACE_SUPERMANSPECIAL_TARGET_NODE_VAR":"wsf.cdyne.com"
         }
      },
      "95037":{
         "map":{
            "APIVARREPLACE_ZIP_VAR":"95037",
   			"APIVARREPLACE_SUPERMANSPECIAL_TARGET_NODE_VAR":"wsf.cdyne.com"
         }
      },
  	   "48824":{
         "map":{
            "APIVARREPLACE_ZIP_VAR":"48824",
   			"APIVARREPLACE_SUPERMANSPECIAL_TARGET_NODE_VAR":"wsf.cdyne.com"
         }
      },
      "48823":{
         "map":{
            "APIVARREPLACE_ZIP_VAR":"48823",
   			"APIVARREPLACE_SUPERMANSPECIAL_TARGET_NODE_VAR":"wsf.cdyne.com"
         }
      }
   }
}
For the meaning of each post body field parameter, please refer to Request Options

c.Aggregated Response

User can define regular expression for custom response aggregation. For example, in this request body we use a pre-defined aggregation rule of PATTERN_WEATHER_WSDL_CITY with the regex "```.*<City>(.*?)</City>.* " . It aggregates the response based on "City" attribute:
{
    "aggregationMap": {
        "East Lansing": "2",
        "Morgan Hill": "1",
        "San Jose": "2"
    },
    "aggregationValueToNodesList": [
        {
            "value": "East Lansing",
            "nodeList": [
                "48823",
                "48824"
            ],
            "isError": false
        },
        {
            "value": "Morgan Hill",
            "nodeList": [
                "95037"
            ],
            "isError": false
        },
        {
            "value": "San Jose",
            "nodeList": [
                "95131",
                "95132"
            ],
            "isError": false
        }
    ]
}
Further, you can change the aggregation rule to PATTERN_WEATHER_WSDL_TEMPERATURE with regex "```.*<Temperature >(.*?)</Temperature>.* " to aggregate the temperature of these areas:
{
    "aggregationMap": {
        "18": "2",
        "49": "2",
        "56": "1"
    },
    "aggregationValueToNodesList": [
        {
            "value": "18",
            "nodeList": [
                "48823",
                "48824"
            ],
            "isError": false
        },
        {
            "value": "49",
            "nodeList": [
                "95131",
                "95132"
            ],
            "isError": false
        },
        {
            "value": "56",
            "nodeList": [
                "95037"
            ],
            "isError": false
        }
    ]
}

In the json request, user can enable various request options, such as enabling aggregation, defining new command, custom aggregation rules, etc.

Option Description
targetNodes (Required) Target servers to which REST Commander sends the request
agentCommandType (Required) Name of the agent command, which can be defined either in the .conf file, or in "newAgentCommandLine" request parameter.
useNewAgentCommand (Optional, default: false) Option to not use pre-defined commands; but to use a new command defined by 2 lines: "newAgentCommandLine" and "newAgentCommandContentTemplate". Remember a command is awlays defined by *TWO* lines. Missing one will fail the request!. If set to true, "newAgentCommandLine" and "newAgentCommandContentTemplate" parameters are mandatory, and command defined with same name in .conf file will be overridden by it.
newAgentCommandLine (Optional) New custom agent command expression. If "useNewAgentCommand" option is true, this field is mandatory.
willAggregateResponse (Optional, default: false) Option to aggregate the response based on aggregation rule. If it's set to true,
aggregationType (Required)Name of the aggregation type, which can be defined either in the .conf file, or in "newAggregationExpression" request parameter.
useNewAggregation (Optional, default:false)Option to enable new aggregation defined in the "newAggregationExpression" parameter.
newAggregationExpression (Optional)Custom regular expression to aggregate the response.