Splunk® Enterprise

Knowledge Manager Manual

This documentation does not apply to the most recent version of Splunk® Enterprise. For documentation on the most recent version, go to the latest release.

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.

  1. Navigate to Settings > Fields > Workflow Actions.
  2. Click New to open up a new workflow action form.
  3. 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.
  4. 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.
  5. For Show action in determine whether you want the action to appear in the Event menu, the Fields menus, or Both.
  6. Set Action type to Link.
  7. Under URI provide the URI for a web resource that responds to POST requests.
  8. Under Open link in, determine whether the workflow action displays in the current window or if it opens the link in a new window.
  9. Set Link method to Post.
  10. 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.
  11. 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:

POST wf action example b.png

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 http_staus of 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. The 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 $!http$.

Last modified on 14 July, 2023
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.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.1.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.9, 8.0.10, 8.1.2, 8.1.3, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.4, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 8.0.8, 8.1.0, 8.1.1, 8.1.10


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters