Workflows Actions: RSS Feeds, whois, and even BPM

Splunk 4.1 re-introduced a feature called workflow actions, that allows users of Splunk Web to click on a drop down next to a field to send the field as an argument to a remote HTTP server via POST or GET. The 4.1 version is much improved in that the administration and authorization of the feature can be done via Splunk Manager, workflow actions can be set for entire events as well as fields, and one of actions of clicking on the drop down can initiate a new Splunk Search rather than make a remote HTTP call.

This provides an incredibly easy way to integrate external web sites with events and fields in your data. For instance, if one of the fields in your events happens to be called stock_symbol, as in the name of a financial security, and you want more information about it, you can simply go to Splunk Manager->Fields->Workflow Actions->New and set up a new workflow action. A simple one would be a HTTP GET which resolves the link to http://finance.yahoo.com/q?s=$stock_symbol$. Call the workflow action “Get Stock Price” and now when you have the stock_symbol field on the event viewer within Splunk Web, you can select the drop down and select the “Get Stock Price” option. You can have more than one workflow action per field or event. This opens up the possibilities for getting as much information as you can about an event or field or sending your fields or events to as many places as needed to initiate further actions.

I will outline a few more workflow actions that you can get from Splunkbase that I have created.

RSS Feeds Workflow Actions

Back in 2009 on Splunkbase, I created a simple Python based application that can read any RSS feed and index each entry’s date, title, description, and HTML link. The link field literally has an URL that refers to the article mentioned in the RSS entry. In Splunk Web’s default event viewer, you could see the link field, but you would have to copy and paste it into your browser’s address window to get to it. Along comes workflow actions.

I’ve created three separate workflow actions for the link field of the RSS feed. The first one “Get Article” simply sends the link field to Google to do a search for it. The second one is even easier as it opens up a new window with a HTTP request for the link field itself. This is called with much pizazz, “Get Article From Link.” The third workflow action called “Get Proxy Article” is a little more complex in that it makes a HTTP Post call to a public proxy server, which in turn sends the request to show the original link’s article. You can see what this looks like in Splunk Web below.

Essentially, what this does is turn Splunk Web into an RSS reader as it first indexes RSS events using the RSS application and then allows you get to the article’s contents using the workflow actions. You can get this add-on from Splunkbase.

Whois

Let’s discuss a more IT specific example. In most organizations that use Splunk, an IP address often appears in the events and is extracted as a field. There are quite a few statistics you can get on an IP address such its DNS name, geolocation, traceroute, decimal results, etc. I’ve chosen to call the whois service on the IP address field using a free service at http://www.dnsstuff.com/tools/whois/?ip=$ip$ for the sake of example. If you followed the example above, the explanation for this is the same. You can download this workflow action add-on from Splunkbase as well.

In addition, developer Adam Kahtava, has created a much more comprehensive whois service for testing purposes. As a bonus, the same Splunkbase add-on that I have for the whois workflow action has a dynamic lookup whois Python script that I use to call Adam’s whois service. This will add a new field called, whois, corresponding to the IP address field in your original events. Sample usage is like this:

sourcetype="my_events"| head 10| lookup whoisLookup ip OUTPUT whois


For more information on lookup, please look at past entries in the Splunk blogs.

BPM Workflow Actions

Since this feature is called workflow actions, it makes sense that one of the use cases would be a workflow action that initiates a Business Process Management (BPM) flow. For instance, one of the fields in your events may be a trade ID and the trade was rejected. The workflow action of the trade ID field could initiate a BPM call via HTTP GET or HTTP POST to start a workflow to resolve the issue. The same can be done for retail orders, insurance quotes, trouble tickets, request for repair, etc. The possibilities are only limited by the use cases that your data can support. Below is a simple illustration for the high level architecture for this approach:

Any BPM that calls itself integration-ready will have the ability to communicate with the outside world using protocols such as HTTP. As you can see, Splunk is not only an initiator to the BPM, which is a gateway to a larger Service Oriented Architecture, but it is also the place to index the BPM logs to troubleshoot and provide further workflow actions on subsequent events. Unfortunately, I do not have a Splunkbase example for calling a BPM via a Splunk workflow action as each user will be using their BPM vendor of choice. However, the concepts are the same to initiate this call regardless of the vendor.

I hope this article has given you more reason to use workflow actions and provides a basis for some the possibilities for what you can further do with your data indexed within Splunk.