Programmatic calls in Watson Assistant

With Watson Assistant, you can build chatbots—solutions that understand natural language and respond to the user input. In order to not just return hard-coded answers, it is pretty common to integrate database systems and other services into the solution. Watson Assistant allows you to directly execute actions coded with IBM Cloud Functions (server actions). Another option is client actions that are run by the application. In that case, Watson Assistant signals the client to perform the action and send the result back.

You can use an external service to validate information that you collected from the user, or perform calculations or string manipulations on the input which are too complex to be handled by using supported SpEL expressions and methods. Or you can interact with an external web service to get information, such as an air traffic service to check on a flight’s expected arrival time or a weather service to get a forecast. You can even interact with an external application, such as a restaurant reservation site, to complete a simple transaction on the user’s behalf.

In a tutorial with a chatbot for Slack, the actions perform searches in Db2 databases and validate data. Testing server actions is easy because only the credentials for executing the embedded IBM Cloud Functions are needed. The action itself runs on the server and, therefore, can be utilized by any client app. On the other hand, client actions are executed by the app—the client application. I wanted to be able to easily test them during the development process, so I extended my Watson Conversation Tool.

Client actions require a different approach. Using the Python-based tool, they can be tested in two ways:

Manually modify the session context: The tool saves the entire session context to a file session_context.json after receiving the response from Watson Assistant. It reads that file before sending the next message request. By using an editor, you could modify the session context and add, change, or delete values. The new request would pick up those values and send them to Watson Assistant. The process works well in general but does not strictly follow the protocol for the client actions.

Provide code for/to simulate client action: As a new feature, the tool now accepts a parameter “-actionmodule name.” That module or single Python file is then dynamically loaded and a function handleClientActions is called. That function either provides the regular logic for the client action or could be some code to simulate the action by assigning test values. I have successfully used it to test some client actions with a Watson Assistant workspace. This way, you could test Watson Assistant independently of the actual client application.

Here is a sample invocation of how I use the Watson Conversation Tool to test the dialog flow. The handling of a client action is in handleClientAction.py and I am only interested in the regular output (“-outputonly”):

Closing remarks

Let me know if you have questions or feature requests by opening an issue against my GitHub “watson-conversation-tool” repository or reaching out to me directly. Please note that the tool is provided “as-is,” and it not an official IBM project and is unsupported. I hope that you find it useful nonetheless. To get started, check out these links:

For feature requests, defects, or suggestions, open an issue or a pull request against the repository. If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.

We would like to inform you that we are removing the P100 compute tier from Watson Machine Learning service. We will still keep supporting K80 and V100 compute tiers and there will be no impact to K80 and V100 users.

Effective December 1, 2018, the IBM Watson Speech to Text and Text to Speech services will be removing the free tiers from their Standard plans (i.e., the 1,000-free-minute tier in Speech to Text and 1,000,000-free-character tier in Text to Speech).

IBM Watson services will automatically change all accounts to support Virtual Routing and Forwarding (VRF), making it easier to connect to private endpoints. The upgrade will occur Saturday, November 10th from 5:30 PM US Eastern to 6:00 PM US Eastern in order to minimize impact to you and your customers’ workloads.