IBM Watson Assistant — Multiple Workspace Orchestration, Part Two
In Part One of this series, we looked at three different options for creating a bot with multiple workspaces: router, waterfall, and spray. The previous post contains the full comparison between the three approaches. Now, we will dive into an example of the router approach.
As a quick reminder, the router approach is a workspace on top of the other workspaces that selects which child to route towards. This allows us to keep content in separate workspace but combine them at runtime.
Our example is using a sample banking bot. There are three domains that are worth keeping in separate workspaces: general customer support content, loan content, and credit checking content.
All workspaces and code live in this repo. Create your own or follow along with this example.
Workspace Setup — Intents
Create three separate workspaces for each of the domains. Within each workspace, create two intents to keep things simple. Add a few examples to each intent. Using the tooling or the API, export the intents and their examples as shown below in each workspace.
Open the exported CSV, and change the names of the intents to match the name of the workspace. For example, the two intents shown above will be renamed to be contained under the master #credit_checking intent.
Create another workspace called Router. Import the three CSVs created from the export to create three intents, one for each workspace. These intents contain all the utterances from that workspace despite being different intents in the child workspace.
Workspace Setup —Dialog
Within the dialog tree, create a node for every child workspace. The banking example contains three workspaces, so three nodes will be created in between the conversation_start and anything_else nodes. Create a single condition with the intent of the child workspace. Open the JSON editor and add a context variable workspace_id set equal to the ID of the child workspace. The end result will look like this:
In the child workspaces, set up the flows like a normal workspace. Here’s an example of the Credit Checking workspace:
Orchestration Layer
Connecting the parent workspace to the children is as simple as collecting the context variable from the parent, and passing to a second Conversation call. Here’s the initial call to Conversation (using the Watson Python SDK):
All that’s happening in the above is collecting the credentials, specifying the input text, and passing to the router workspace. Also, the response is printed to the console.
To add the second call to the correct child workspace, collect the workspace_id context variable in your response. Now, redo the call with the new workspace_id to call the child workspace as shown below.
Our response shows the correct response to what is my credit score as: “Credit scores attempt to evaluate how likely a person is to pay money back on debt. It is used in applications for things like Home loans and credit cards” from our credit checking workspace.
And that’s it! We’ve setup a router workspace for three child workspaces, created the orchestration layer for our code, and received the correct response. The next step would be to add logic if the child workspace had multiple turns in the dialog. We’d want the calls to go directly to the child workspace until that flow is finished. The way to do this is have a flag as a context variable at the end of the flow. Your app can listen for this flag, and when triggered, flip the workspace_id to be the parent workspace again.
