OpenWhisk is an event-driven compute platform. OpenWhisk allows application developers to write and host application logic agnostic of the infrastructure on which it will run. This application logic is then triggered through events that can come from Bluemix services or other applications or sources. Such application logic are also called as actions. The uniqueness of this compute platform is that it is triggered only when an event occurs, which means that the trigger caused by an event will result in the application on OpenWhisk to be deployed and executed; if no event occurs the application unit does not run and hence does not use any infrastructure resources:
At the time of writing this book, OpenWhisk is in beta. To know the scope for use and support for experimental services, you can refer to http://ibm.co/2dMu4f7 .
You will see the editor, where you can write the application logic or actions. A sample Hello World action written in JavaScript is provided. You can make changes to the file in the editor and can run the action by clicking Run This Action:
The terminology that you will need to understand to work with OpenWhisk are as follows:
You can work with OpenWhisk using the Bluemix UI, OpenWhisk CLI, or by using an iOS mobile SDK. Here we will look at using the OpenWhisk CLI.
The OpenWhisk tool is also called the wsk command line tool.
You will need to follow the steps at https://ibm.biz/BdrxMfto
to install wsk command line tool.
The results of executing the pip install
command for OpenWhisk on the system used for this demo is as shown in the following screenshot:
You will need to copy the commands from the URL mentioned previously and run them in your terminal window or command prompt, based on your operating system, to complete the wsk tool installation and configuration.
Let us learn how to use the Bluemix service as a trigger source. In the example that we used earlier in this chapter, we created a CloudantNoSQLDB service instance on Bluemix, we shall now learn how we can configure this Cloudant database as our trigger source. This means that we would like to build a system where we would like some action to happen when there is a change in the Cloudant database we have created earlier:
cf services
The result of execution of the command is shown here:
B05307-07-01-eclipse-cloudantNoSQLDB
, in this case.wsk property get --namespace
The result of execution of this command gives you the namespace
property value that is set in wsk, as shown in the following screenshot:
namespace
is not set, you can use the following command to set the property namespace:wsk property set --namespace <Bluemix_Org>_<Bluemix_Space>
To know more about Cloudant package you can refer to https://ibm.biz/BdrxMM .
To create the package binding, execute the following command from the terminal window:
wsk package refresh
This results of this command are shown here:
wsk package list
The result of execution is as shown in the screenshot here:
Make a note of the package binding name from the results of the execution of the preceding command.
wsk trigger create <name_of_your_cloudanttrigger>
--feed /<package_binding_name_from_step_above>/changes
--paramdbname<name_of_cloudant_database_created>
--paramincludeDoc true
The name of the Cloudant database was sample_nosql_db
, from the example that we created during the Eclipse plugin demonstration. You can use that as name_of_cloudant_database_created
, in the preceding command. name_of_your_cloudanttrigger
is the name you would want to give to the trigger you are creating in this demo the name of the trigger created is B5307_07_CloudantTrigger
, as shown here:
wsk activation poll
This will create the listener for any changes in your Cloudant database.
https://b05307-07-01-eclipse.mybluemix.net/
.Sample
category and let us also create a new file category and add another file to this new category, as here:
Let us now look at creating a simple action that can be triggered when the data in the Cloudant database changes. We will see the steps to create an action from the Bluemix dashboard. You can create an action using the wsk command line tool as well:
_id
value of the Cloudant document that is modified:
Rule creates the association or link between the trigger and action. Now that we have created our trigger and our action, let us create a rule to link both, so that when our trigger is fired (in our case caused by Cloudant database update), an action occurs, which is our action created in the previous section, and executes. We will use the wsk
command line tool to create the rule. Rules can be created from the dashboard as well. Before we create the rule we should make a note of the name of the trigger and the action we would want to link. In our case the trigger is B5307_07_CloudantTrigger
, and the action is B05307_alert_cloudant_update
. Lets look at the steps to create a rule:
wsk
command to create the rule named B5307-rule
:wsk rule create --enable B05307-rule B5307_07_CloudantTrigger
B05307_alert_cloudant_update
The result of execution is shown in the following screenshot:
Let us now test to see whether the trigger caused by a Cloudant update leads to the execution of the JavaScript code which you have defined as part of your action:
https://b05307-07-01-eclipse.mybluemix.net/
, in our demo.Sample
, and let us upload a simple file to this category, as shown in the following screenshot:
This would have caused your trigger to fire and would have allowed your rule to invoke your action.
You will see that your action was triggered three times due to the updates you performed on your application UI, hence you will see the action code executed three times. You will see that it prints the document _id
value of the Cloudant document which was updated, as shown here:
3.129.194.106