Design Pattern for IM Pushbots

Ian Tree  25 May 2006 17:13:14

Design Pattern for IM PushBots

With the increasing use and acceptance of Instant Messaging in corporate IT landscapes people are becoming more familiar with the concept and design of IM Bots. A typical Bot is based around a simple design pattern, the Bot acts as a passive component and listens for IM/IRC connections to be opened by an IM/IRC client, after accepting the connection and issuing some type of salution to the connected user they enter a simple Query/Response loop which they exit when the query from the user indicates that the session should be closed or the session is directly closed by the IM/IRC client. This article presents a design pattern for a different type of Bot that acts as an active component of a workflow or information gathering type of application.

• The Problem
• The Solution
• The Design Pattern
• The Conversation Design

 

The Problem

I have an application that has to interact with a large number of people infrequently, each individual interaction is lightweight i.e. a low volume of data is presented and input, how should I set about making sure that the interactions with the users take place in a timely manner ? I can do any one of the following.

(a)  Generate a transaction in the application and hope that the users visit the application and then complete the transaction.
(b)  Do (a) plus send the user an e-mail (with a link to the application) informing them that there is a transaction awaiting their attention.
(c)  Put the information and code needed to complete the transaction into and e-mail and send it to the user.
(d) Do either (b) or (c) and then send reminders at regular intervals until the transaction gets actioned.

If the transaction rate per user is low enough (e.g. less that one per month) then the application scenario described above will be difficult to manage needing additional reminders, phone calls and special exercises to keep it up to date.

The Solution

When a transaction becomes ready for a user in the main application it is written onto a queue ready for the PushBot to process. The PushBot monitors the incoming queue from the application and for every transaction it monitors the IM system to see if the user is online and available. When a user is detected as being online and available (i.e. not in a Do Not Disturb or other uncontactable status) then the user is contacted by the PushBot. Once contacted the user is presented with the information from the transaction and the user input is collected and the IM session with the user is completed. The user input is stored in that transaction document and it is removed from the queue, the transaction can be passed back to the main application to complete the processing.

The Design Pattern

The design pattern described here is based on an implementation using the SameTime toolkit (Java), however, the pattern is capable of implementation on multiple IM/IRC platforms.

The PushBot has a simple gross architecture, it appears as a single process with a single inbound transaction queue and a single outbound transaction queue. Indeed for simple low volume applications the gross architectiure may be all that is needed for a successful implementation, however to construct a scalable solution a finer level of detail is required in the architecture.  The number of users being actively monitored at any one time should be constrained to a manageable limit, if too may people respond at the same time it could overwhelm the application and lead to unacceptable response times and this will lead to a loss of confidence in using the IM infrastructure as a part of the business application platform.

The main processing of the PushBot should be implemented as a multiple queue structure, as shown below.



The main application writes new transactions onto the input queue. Transactions are moved from the input queue to the monitor queue by the PushBot, the count of transactions on the monitor queue are limited to, so additional transactions are moved to the queue only when there is space for them. When transactions arrive on the monitor queue the user is added to a "watch list" mechanism which will raise an event signal if the users IM status changes, these events are then filtered to detect when the user comes on-line and is available to start an IM session with. There should be a time limit that users can remain in the monitor queue, once that time limit is exceeded then the user is removed from the "watch list" and the transaction is moved to the retry queue. Once a user is on-line and contactable then the conversation is initiated (see conversation design later), if the conversation collects the input data successfully then the user is removed from the "watch list" and the transaction is moved to the processed queue, from where it can be picked up again by the main application. An ageing process monitors the retry queue, any transaction on that queue remains there for a minimum period of time and is then re-queued onto the input queue, however there should be a limit to the number of times that a transaction is requeued, so a count must be maintained on the transaction. The limit to the number of times that a transaction can be requeued is especially important if the user base does not have a 100% takup of IM. If transactions exceed the requeue limit then they are moved to the processed queue with a status to show that the user could not be contacted, the main application can then take appropriate action.

The Conversation Design

Great care should be taken with the design of the user interaction with this type of processing, especially if you have a multi-ligual user base. Users are used to interacting in a very free, unstructured manner through the IM client so the application cannot expect them to be highly structured in their responses. Below are a few guidelines to assist with a successful conversation design.

• Give a clear greeting at the start of the conversation and ask the user if they have time to interact "now" or should the application try again "later" - if later then move the transaction to the retry queue.
• Filter every response for clues (in all languages) that the user does not know what is going on and fall back quickly to very simple question response mode.
• Use fault tolerant lexical analysis of every response.
• Do not ask complex questions that will have unpredictable response patterns.
• Ask for confirmation where the PushBot has made assumptions about a particular response.

• Comments [0]