An HTTP request action sends an HTTP request in response to an event. These types of actions allow you to integrate AppDynamics' policies with third-party HTTP APIs.
You create an HTTP request action using an HTTP request template. The template describes the HTTP request that will be sent when the policy fires the action. These templates are reusable by different HTTP request actions within an AppDynamics account.
A template must exist before someone can create an action that uses it. Account-level Configure Http Request Templates permission is required to create an HTTP request template. See Scope and Access in Alert and Respond for information about account-level permissions to create templates.
A template is required. There is no way to create an HTTP Request action without a template.
To create the HTTP Request action:
After the template has been created:
- Access the actions configuration window. See Create and Modify Actions in Actions.
- Select Make an HTTP Request in the Create Action window and click OK.
- Name the action and select the appropriate template from the dropdown list.
The rest of this topic describes how to create an HTTP request template.
Access HTTP Action Templates
To access existing templates or to create new ones, in the application click Alert & Respond in the menu bar, then HTTP Request Templates.
The HTTP Request Templates list appears. Click an existing template in the list to view, edit or delete it. Click the New + icon to create a template.
Create or Modify an HTTP Request Template
The template itself is self-documenting. Click the info icons in the template to get information about how to complete the configuration. The following subsections clarify some details in the template configuration that may require additional information.
After you have created a template, click the Save button at the bottom to save it.
Custom Templating Variables
You can use variables that replace values in the URL path and payload when the HTTP request is sent. Foreach loops are supported.
The template already knows a set of predefined variables, which are described in Predefined Templating Variables. Check this list before you create any custom templating variables. Chances are the variable you want to use has already been defined.
You can optionally configure custom variables if the predefined variables do not meet all your needs. When a predefined variable and a custom variable are both configured with the same variable name, the template uses the predefined variable
The template uses Apache Velocity version 1.7 to process the variables. See the Velocity User Guide for details about usage.
Enter the URL for the request in the Raw URL field and select the URL encoding scheme from the pulldown menu. Only UTF-8 and ISO_8858-1 are supported. Verify that the Encoded URL is the exact request to send.
Response Handling Criteria
Success or Failure
If you do not specify any response-handling criteria for either success or failure, the HTTP response is always success.
- Failure criteria are evaluated before success criteria. As soon as a match is found on a fail criterion, the response is set to failure and the remaining fail match conditions, if there are any, are not evaluated.
- If no failure criteria are matched, the success criteria are then evaluated.
If no success criteria are configured, the response will always be success as long as no fail criteria were previously matched.
- If you specify at least one success criterion, there must be a match on a success criterion for the response to be success. In other words, if any success criteria are configured but not matched, the response will be failure.
Both failure and success criteria are considered in the order in which they appear in the template.
Criteria With and Without Payload
You can set separate criteria for the same status code. For example, you can set one criterion on a status with payload as success and another criterion on the same code without payload as failure.
Or you can set separate criteria for the same status code with payload of different content types. For example, payload of type application/xml and application/xhtml+xml might be success and payload of other types could be failure.
Content Types for Payload
You can specify the content type for the payload using the dropdown list that appears for requests for which the Expect Payload check box is checked.
If you do not know the content type but the request expects payload, use "*/*" to specify all content types.
The following configuration returns a success response for a 200 status code with an XML payload. Any other code will cause the request to return a failure response.
One Request Per Event
Several separate events, or separate occurrences of the same event, could potentially invoke the same HTTP action.
The One Request Per Event setting controls whether the action bundles the HTTP requests.
If this check box is clear, the HTTP request is sent once every minute, no matter how many events triggered the action within that time frame. This is the default behavior.
If this check box is checked, the request is sent every time an event triggers it. In this case, if ten events trigger the action, the HTTP request is sent ten times, even if all those events occurred within a single minute.
You might want to send one request per event, (check box checked) if you are trying to log tickets and your ticketing system API does not support bulk create. However, if it does, you probably want a single bulk request every minute (checkbox clear).
Event Clamp Limit
If you have not checked the One Request Per Event check box and the list of triggering events could be large, you might want to limit the display of the events that triggered the action in the response. The clamp limit is the n most recent triggering events. The default -1 means no limit. This setting is ignored if One Request Per Event is checked.
Timeouts and Redirects
The Connect timeout is the maximum number of milliseconds to wait for the request to reach the server.
The Socket timeout is the maximum number of milliseconds to wait to receive the response.
The Max Redirects is the maximum number of times that a single request can redirect.
Test the Template
You can test the template, by clicking Test at the bottom of the template configuration.
In the Template Test configuration window, specify the test variables to use for the test. These variables may be different from those that will be used in the real requests that will be automatically sent when the HTTP action is live.
Also specify the type of events that trigger for the test.
The log level defaults to INFO, but you can change this using the dropdown Log Level list.
The following sample test template configuration simulates three POLICY OPEN CRITICAL events triggering this action. More triggers could be added.
When you run the test, the request is sent when it is triggered. You get a transcript of the run.
If the results are not what you expect, you may need to modify the template test configuration, the HTTP action template, or both before you use the template in an action.