April 11, 2018 | Written by: Anton McConville
Share this post:
This post is the second in a series taking a deeper look at the design and implementation of a cloud based Chatbot, built using Watson Conversation and IBM Cloud. To be familiar with the contents of this post, it is strongly recommended to read the first post in this series, “Getting Started with Watson Conversation and IBM Cloud”, here.
In this post, I’ll concentrate on the data model and the implementation of the cloud/server- based components (you can try the app here). Just note that you’ll need to make a local account, so that it’s personalized—it’s quick to do.
Each new ‘useful’ app concept that I build convinces me of the importance of relating the design intentions, user interface and even the conversation to a data model.
Ana uses a fairly simple model. Each personal account has a benefit object and each benefit object has a collection of policies (dental, medical, vision etc.). Each policy has a collection of claims against it.
This provides the foundation for policy interactions. Each time you query or file a claim on Ana, it’s referencing this data model.
For this project I started using Mongo from Compose with Node and decided to work with an Object Relational Wrapper for Mongo, called ‘Mongoose.’
I won’t dig deep into the details of how to work with Mongoose here, because their own documentation is pretty wonderful for getting started, but I will write a little more about Ana’s data model.
Mongoose steers you to define schemas for your data model. They’re still stored as json data in a Mongo database. Mongoose maps that for you, yet structures an elegant discipline and scaffolds a relationship between the JSON objects.
I find it really helps me to build a mental model of what I’m working with and the beautiful part is that it simplifies the control of reading and saving in the database.
If you take a look at the createPolicies function in Passport.js, you’ll see how we build up a person’s ‘healthPolicy’ data, culminating in a call of healthPolicy.save(), which simply saves it in the database.
Similarly, in app.js when we’re reading claim history, you can see a call: ‘Benefits.findOne()’ for a person’s email. That returns their benefits data in json form and allows us to simply iterate through all the policies to read the claim history.
You can also see in app.js where we relate the Mongoose package to the Compose Mongo URL.
I really value the simple approach to modeling and working with data that Mongoose provides. This combination of Mongo/Compose, Node and Mongoose has made me the happiest I’ve ever been in my cloud development work. The Compose service is impressively fast—it feels like data access is almost instant, and always available. If you refresh the page, it draws immediately. To me it’s amazing to think that it’s reading data records from a database, and building a json response, and dynamically building the page on the client in less than a second.
Mongo, Node and Passport
This project began as just a basic JS starter application template from IBM Cloud. Pretty much all of my node apps start there—I create a new JS app on Cloud, download the corresponding starter code and develop steadily locally, using the Cloud Foundry command line to push to the cloud when I change something.
I’m not a fan of frameworks on the client side; I try hard to keep grounded in ‘Vanilla JS.’ On the server side though, there are some Node modules that I’ve become fond of.
I added local authentication to the project using Passport.js. They’ve abstracted the common work needed to create and maintain user sessions. It even encrypts the password in the database.
I started from a basic default template from the Passport site, but you can see how I ended up implementing things in Passport.js where I integrated with Mongo.
It took me a bit of trying to figure Passport out at first, but I’ve used it in other projects since understanding it, and would easily recommend it. As I mentioned earlier, I’m using the Mongoose wrapper around the Mongo database.
You can check it all out in ana.js
Here’s a sequence diagram showing the flow of control:
From the sequence chart you can see that input is messaged to the Watson Conversation API. Depending on the response the conversation API decides on, the code may need to access the Mongo database to fill in some personal data. You can see more of that decision making in the bot.js file.
Take a look at the buildContextObject() function. You can see how the database/policy integration happens with the chat and context object too.
Watch for part 3 of the series, where I write about design thinking and the front-end design and development approaches used in making this chatbot.
Learn more about Watson Conversation
Build your own chatbot with Watson
Some other useful links:
Watson Conversation Developer Resources
IBM Bot Asset Exchange
Improve Your Chatbot Using Watson Conversation Chat Logs
Building Ana the insurance chatbot: Part 1 of 3 – Getting starting with Watson Conversation and IBM Cloud
Building Ana the insurance chatbot: Part 3 of 3 – Front end and UX design