(by Scott Chapman)

In my first story I wrote about how excited I was to be able to write Watson Work applications in a Serverless environment. But I left out a bunch of details about what I did and how it all works. So, let me explain…

First a reminder, Watson Workspace lets people collaborate in virtual spaces enhanced with Watson technologies. Developers can write applications to further customize the experience including Action Fulfillment (which I will explain in a future story). For my Serverless technology I am a fan of IBM Cloud Functions (based on OpenWhisk) and use it for this example. You can find my code for this here.

Like any good framework designer, I set out with two major goals in mind:

  • Integrate into the native architecture for ease of integration. Specifically the use of Triggers as input sources, and Actions as re-usable functions as building blocks for application developers.
  • Simplify the Watson Work application development process by abstraction, letting the application developer focus on what their application actually does.

Much of the heavy lifting is done in my Webhook action. It handles all the incoming events from Watson Work Outbound Webhook mechanism including:

  1. Verify that requests originated with Watson Work. If it is not, then the action simply returns a 401 — invalid request signature.
  2. Respond to the verification request made by Watson Work during the Webhook registration process.

In addition the Webhook action cleans up the events, and takes care of some of the common work Watson Work developers often do when writing applications. Including:

  1. JSON parsing the annotation payload. On the raw events, the annotation payload comes in as a string, but is actually a serialized JSON object.
  2. Annotation events include container message information. It is often useful to know what message the annotation is on, when and who created it.
  3. Is the event the result of a message created by this application? Applications processing their own events can easily result in dangerous infinite loops.
  4. Managing Action Fulfillment flow. This will be described in a subsequent blog posting.

There are different kinds of event flows Watson Work application often make, and so there are Triggers (event sources) that are used to support those flows. They include:

  1. WWApplicationEvents — Watson Work events associated with messages created by this app.
  2. WWWebhookEvents — Watson Work events associated with messaged created by everyone other than this app.
  3. WWActionSelected — Watson Work events created when a user selects an action created by this app
  4. WWButtonSelected — Watson Work events created when the user selects a button created by this app.

Currently Triggers exist only in the “Default” package, so I’ve adopted the naming convention of prefixing the Watson Work related triggers with “WW”.

There are also a couple of Actions your application can leverage including:

  1. SendMessage — which does exactly what you’d expect; sends a message to a space.
  2. GraphQL — this is the fundamental API mechanism used by Watson Work which you can play around with here.

To better understand how all this hangs together, and to see the results of the data flowing through the framework I’ve created a very simple Development Application called Dumper. Dumper consists of an Action for each of the four Triggers mentioned above associated by a rule. This means that each time a Trigger gets an event, the data for that event is sent to the corresponding Dumper action which simply echos the data to the Logs which can be viewed in the IBM Cloud Functions Monitor.

This is just the beginning, so I thought I would start simply. I will write another story on how I leverage the framework to implement Commands in Watson Work.

This post was originally published in Scott’s blog at https://medium.com/@scottedchapman.

Join The Discussion

Your email address will not be published. Required fields are marked *