Set up a POST workflow action
You set up POST workflow actions in a manner similar to that of GET link actions. However, POST requests are typically defined by a form element in HTML along with some inputs that are converted into POST arguments. This means that you have to identify POST arguments to send to the identified URI.
Note: During transmission, variables passed in URIs for POST actions are URL encoded, which means you can include values that have spaces between words or punctuation characters. However, if you are working with a field that has an HTTP address as its value, and you want to pass the entire field value as a URI, you should use the
$! prefix to keep Splunk software from escaping the field value. See "Use the $! prefix to prevent escape of URL or HTTP form field values" below for more information.
- Navigate to Settings > Fields > Workflow Actions.
- Click New to open up a new workflow action form.
- Define a Label for the action.
- The Label field enables you to define the text that is displayed in either the field or event workflow menu. Labels can be static or include the value of relevant fields.
- Determine whether the workflow action applies to specific fields or event types in your data.
- Use Apply only to the following fields to identify one or more fields. When you identify fields, the workflow action only appears events that have those fields, either in their event menu or field menus. If you leave it blank or enter an asterisk the action appears in menus for all fields.
- Use Apply only to the following event types to identify one or more event types. If you identify an event type, the workflow action only appears in the event menus for events that belong to the event type.
- For Show action in determine whether you want the action to appear in the Event menu, the Fields menus, or Both.
- Set Action type to Link.
- Under URI provide the URI for a web resource that responds to POST requests.
- Under Open link in, determine whether the workflow action displays in the current window or if it opens the link in a new window.
- Set Link method to Post.
- Under Post arguments define arguments that should be sent to web resource at the identified URI.
- These arguments are key and value combinations. On both the key and value sides of the argument, you can use field names enclosed in dollar signs to identify the field value from your events that should be sent over to the resource. You can define multiple key/value arguments in one POST workflow action.
- Enter the key in the first field, and the value in the second field. Click Add another field to create an additional POST argument.
- Click Save to save your workflow action definition. Splunk software automatically HTTP-form encodes variables that it passes in POST link actions via URIs. This means you can include values that have spaces between words or punctuation characters.
Example - Allow an http error to create an entry in an issue tracking application
You have configured your Splunk app to extract HTTP status codes from a web service log as a field called
http_status. Along with the
http_status field the events typically contain either a normal single-line description request, or a multiline python stacktrace originating from the python process that produced an error.
You want to design a workflow action that only appears for error events where
http_status is in the 500 range. You want the workflow action to send the associated python stacktrace and the HTTP status code to an external issue management system to generate a new bug report. However, the issue management system only accepts POST requests to a specific endpoint.
Here's how you might set up the POST workflow action that fits your requirements:
Note that the first POST argument sends
server error $http_status$ to a
title field in the external issue tracking system. If you select this workflow action for an event with an
500, then it opens an issue with the title
server error 500 in the issue tracking system.
The second POST argument uses the
_raw field to include the multiline python stacktrace in the
description field of the new issue.
Finally, note that the workflow action has been set up so that it only applies to events belonging to the
errors_in_500_range event type. This is an event type that is only applied to events carrying
http_error values in the typical HTTP error range of 500 or greater. Events with HTTP error codes below 500 do not display the submit error report workflow action in their event or field menus.
Use the $! prefix to prevent escape of URL or HTTP form field values
When you define fields for workflow actions, you can escape these fields so that they can be passed safely to an external endpoint using HTTP. However, in certain cases this escaping is undesirable. In these cases, use the
$! prefix to prevent the field value from being escaped. This prefix prevents URL escape for GET workflow actions and HTTP form escape for POST workflow actions.
Example - Passing an HTTP address to a separate browser window
You have a GET workflow action that works with a field named
http field has fully formed HTTP addresses as values. This workflow action opens a new browser window that points at the HTTP address value of the
http field. The workflow action does not work if it opens the new window with an escaped HTTP address.
To prevent the HTTP address from escaping, use the
$! prefix. In Settings, where you might normally set URI to
$http$ for this workflow action, instead set it to
Set up a GET workflow action
Set up a search workflow action
This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 9.0.0, 9.0.1