Watson Dialog NodeRED Test harness
Hickmat 100000QA3T Visits (10289)
As part of my on-going search for knowledge and interesting technology to play with I thought it was about time that I tried to build something with Watson Dialog and the Natural Language Classifier.
After a little bit of experimentation I got the hang of setting up basic Dialogs and thought it would be interesting to look at building a test harness in NodeRED to allow me to interact with the Dialog. Now there is a excellent Dialog Test tool available from Github (and can be found here ) but I really like the flexibility of NodeRED to allow to me quickly create proof of concepts and experiment with ideas so I decided to look at how to get it working with the Dialog Service.
Now the usual caveats apply to my blog entry i.e. this is how I did it and this may not be the best approach but if did work for me
First thing I did was to look at the NodeJS API for the Watson Developer Cloud and confirmed that it included a set of API's to interact with Dialog, which it did. Armed with this I set about configuring an NodeRED instance on my Bluemix account to allow me to access this API. To do this I did the following:
Once this was completed and my NodeRED app was active I could set about working on a suitable flow. Looking at the API it was clear that I needed to first create a "session" with a Dialog Service instance and I could then use that instance to create and interact with conversations. All easy enough eh... Well not quite.. The Watson Cloud API is asynchronous so calling just invoking it via a Function node was not going to allow me to capture and pass on the response from the API call. Fortunately those clever people working on NodeRED have a way to address this via the node.send() operation. Using this I can allow the Function node to return null from its default execution path and then once the Watson API call returns I can update the msg object and send it via node.send(). This resulted in the following function node configuration which I created to set up a session with a Dialog service and then get a list of available Dialog applications.
You can see that I've blanked out my service instance's username and password so you would just add your own there. Once I understood how to invoke the API it was a relatively simple task to create a flow which presented a set of available Dialog apps, allowed me to choose one to initiate a conversation with and then allow a chat interaction between the user and the Watson Dialog application. To accelerate the creation of the "Chat" part I reused the HTML from the NodeRED realtime chat app (see here) created by Luis Aoqui and Bradley Steinfel. Rather than using the Websocket approach I changed the HTML to make REST calls back to my NodeRED flow. The overall flow ended up looking as follows:
The "Startup" Injection node in the flow is set to fire once at start up so I can initialise the Dialog API instance and stash the instance into the Global context. If anyone is interested I can share more information about this flow (or probably the flow its self) but just now its working and I plan to experiment with it a bit more. One thing I want to double check is if there are any issues with they way I am doing the node.send() as its dependant on the msg object passed into the node and I do wonder if there is a risk that could get cleaned up before my node.send() is invoked.