How to Trigger OpenWhisk Actions from Watson IoT Analytics

Watson IoT Analytics rule triggering supports several action types: email, webhook, Node-RED, and IFTTT. In most cases, these actions allow…

Watson IoT Analytics rule triggering supports several action types: email, webhook, Node-RED, and IFTTT. In most cases, these actions allow you to integrate with almost any system. You can push a notification to mobile devices, post to a Slack channel, tweet it, persist to some data store, or even issue commands back to the devices.[4]

But sometimes, we just need more. Maybe you don’t have an endpoint for receiving the notification. Maybe your endpoint is behind an enterprise firewall. Or, maybe you need some pre-processing applied before you receive the notification.

Many users use Node-RED for these kinds of use cases. The downside is an extra server set up and its maintenance. Also, the scaling of it has always been a challenge.

What if we could use any custom code as actions for Watson IoT Analytics, without setting up a server? That would be nice!

Let’s say we want to publish the notification from Watson IoT Analytics to a message queue so that we can easily decouple it from all downstream applications.

We are going to use OpenWhisk for custom code and Message Hub for the message queue. Since OpenWhisk already has a built-in Message Hub package, we can even avoid writing our own code for this simple use case. First, create a package binding from /whisk.system/messaging with your Message Hub credentials parameters.

> wsk package bind /whisk.system/messaging myMessageHub \
    -p kafka_brokers_sasl "[\"kafka01-prod01.messagehub.services.us-south.bluemix.net:9093\", \"kafka02-prod01.messagehub.services.us-south.bluemix.net:9093\", \"kafka03-prod01.messagehub.services.us-south.bluemix.net:9093\", \"kafka04-prod01.messagehub.services.us-south.bluemix.net:9093\", \"kafka05-prod01.messagehub.services.us-south.bluemix.net:9093\"]" \
    -p kafka_admin_url https://kafka-admin-prod01.messagehub.services.us-south.bluemix.net:443 \
    -p user <Message Hub User> \
    -p password <Message Hub Password> \
    -p topic myTopic

In case you are not familiar with OpenWhisk yet, package binding is just an alias for a package with some default parameters. By using package myMessageHub instead of /whisk.system/message, I don’t need to specify my Message Hub credentials over and over again. As you can see later, it also decouples the usage of this OpenWhisk action from the underlying Message Hub.

With this ready, you can test publishing some messages by invoking the action:

> wsk action invoke myMessageHub/messageHubProduce -p value "This is a test message"

In addition to CLI, OpenWhisk also has REST API for invoking actions. Let’s try it out with curl first:

# first find out your OpenWhisk credentials
> wsk property get --auth
whisk auth
<user>:<password>

> curl -u <user>:<password> -H Content-Type:application/json --data-ascii "{\"value\":\"message body\"}" \
https://openwhisk.ng.bluemix.net/api/v1/namespaces/_/actions/myMessageHub/messageHubProduce?blocking=true

That’s all we needs for Watson IoT Analytics webhook actions.[2]

Now when a rule is triggered, its webhook action would invoke OpenWhisk Message Hub publish action to publish the alert to the topic. The job is done!

Note: webhook action must use application/json content type and the body must contain the key “value” because we use the default Message Hub publish action.

For simplicity, I use OpenWhisk default Message Hub publish action directly. You certainly can write your own action and invoke it in the same way (just replace the package and action name).

What I’m showing here really is about applying any code logic (in any language!) to be triggered from Watson IoT Analytics. With OpenWhisk, you can truly integrate Watson IoT Analytics with any system. The sky’s the limit.

Oh, did I mention there’s no server needs to be setup and maintained? And, it REALLY scales?[3]

Notes:

1. In most cases, this performs pretty well regarding processing throughput. However, if your triggering rate is too high for webhook style processing, it might be better to go with streaming style solution. That is a topic for another day.

2. If it bothers you that webhook body must use a key “value” to wrap the actual message content to be published to Message Hub, you can use your own OpenWhisk action. You need to use a sequence action within which the first action receives and wraps the payload (with the required key “value”), and the second action being the Message Hub publish action.

3. While IBM’s OpenWhisk does scale pretty well, there is currently some limitation set. I believe this will be relaxed and improved over time.

4. There is a recipe showcasing how to stop a device when some condition is met, in the same way by webhook action plus OpenWhisk action.