Blog

15Sep
2005
Building An IM Bot - Part I

I recently mentioned a Google Talk bot that I put online at cfdocs@gmail.com. Google Talk users can add this user to their buddy list and then submit CFML tag and function lookups to it. (I've also brought Yahoo IM and AIM versions online as nickname cflivedocs, but more on those in a subsequent post). As promised, in this post I explain exactly what the IM bot is and what it does, and will continue this topic in subsequent posts.

We've all used instant messaging (or IM), almost always for person-to-person communication; send a user a message and it'll pop up on their desktop allowing them to respond. An IM bot is a virtual IM user (bot is short for robot), an application that can receive and send messages programmatically. Bots are not a new idea, IRC bots have been around for years, in pre-web days we used to use e-mail bots to submit gopher and usenet searches via e-mail, and if you think about it, spiders (used by search engine to index web site content) are bots of sorts in that they programmatically simulate what it is that users would do with their web browsers.

So what would an IM bot be used for? Imagine that UPS or FedEx had bots online (named UPS or FedEx) that would allow you to simply type a tracking number in an instant message, instantly receiving a tracking response. Or an airline allowing you to type in a flight number to obtain gate information or flight status. Or your company employee directory allowing users to type in partial names to do lookups (the results of which could include an e-mail address which could be clicked on to send an e-mail). Or my ColdFusion LiveDocs example, mentioned previously. Of course, not all applications are suited to this type of interaction. But many are, and IM bots allow you to provide instant access to applications leveraging the immediacy and simplicity of now ubiquitous IM clients.

Developing an Google Talk IM bot obviously requires that you have an application waiting to receive requests (and thus running at all times) that is logged in to the Google Talk network (and thus requiring a thorough understanding of the technical implementations used by Google Talk). Or you can simple use ColdFusion, which obviously will be always running (so as to respond to HTTP requests), and which already comes with the code needed to login and interact with Google Talk. And this requires a word or two (or more) about ColdFusion event gateways.

ColdFusion MX 7 Enterprise (and Developer's Edition) includes support for event gateways. The best way to understand event gateways is to understand what it is they allow.

ColdFusion has long been an incredibly simple way to build Web apps. That's why we all use ColdFusion, simplicity (and thus productivity). But ColdFusion is not exclusively tied to the Web. In fact, ColdFusion does not even talk to Web browsers (that is the Web server's job). ColdFusion simply executes scripts on the server in response to requests, requests which (thus far) have been typically HTTP originated.

So could ColdFusion respond to other requests? For example, data sent to a specific port, or changes in a folder, or inbound SMS and IM messages, or database table changes, or ... ? The answer is yes, ColdFusion can respond to any and all of those, it just needs a way to know when those events occur.

And that is what the event gateways are all about. Gateways are interfaces to other systems, ways for events to trigger ColdFusion processing. A gateway watching a folder on a server can trigger ColdFusion execution when folder contents change. A gateway connecting to an SMS provider can respond to inbound SMS messages (and send SMS messages as well). A gateway can be pinged by a database trigger so that a database event forces ColdFusion processing (imagine being able to automatically dynamically generate static HTML pages whenever back-end databases change). And a gateway connected to Google Talk can respond to (and send) Google Talk instant messages.

ColdFusion has a built in event gateway service (which can be stopped and started using the ColdFusion Administrator, and which is running by default). The event gateway service receives all gateway requests, queuing and routing them to the appropriate gateways as needed, and then executing them using a designated number of allowed threads (10 by default).

ColdFusion ships with an array of gateway types out of the box (additional ones are available from 3rd parties, and you may write these yourself too). Gateway types written in Java, and are registered in the ColdFusion Administrator. Gateway types are just that, types, they are not gateway instances. The folder watcher type has no code specific to your folders or what you'd want when an event is triggered. An SMS gateway type knows how to connect to SMS servers and exchange messages, but is not tied to a specific account or processing. Gateway types are generalized, they are the processing that is not unique to your application. You can kind of think of gateway types as being a bit like database drivers, they contain (and encapsulate) the code and processing needed to interact with some system or technology. And, as already stated, they must be registered in the ColdFusion Administrator before they can be used.

Gateway instances are also defined in the ColdFusion Administrator. A gateway instance is simply an entry that defines the name, the associated type, the name of an optional configuration file, and the name of the CFC file containing your processing. So, if you needed a gateway to respond to requests coming in over a socket, you'd create a gateway instance using the appropriate gateway type and specifying a CFC file that would actually receive those requests so as to be able to respond to them. A single gateway type can be used in as many gateways as needed (so you can have several different IM applications running, or multiple folders being watched each triggering different events). The CFC used is no different to any other CFC, except that specific method names are used (these are specified by the gateway type being used, each gateway type will expect specific CFC methods to be present). The CFC is straight CFML, and can contain any CFML code and processing. When a gateway event occurs (an SMS message arrives, a database trigger fires, data is received by a socket being watched, and so on), the ColdFusion gateway engine calls the appropriate CFC method, telling it everything it needs to know about the event. And your CFC code can then respond, using the same CFML that you know and love.

Which brings us back to Google Talk IM bots.

Related Blog Entries

Comments (11)



  • Brian J Philippus

    Could you point me to samples of event gateway instance cfcs and config file? Or the documentation on what functions have to be implemented for which gateways? All I seem to find is scattered pieces of the information. For instance, on the "Developing event gateway listener CFCs" page in livedocs I can find the 5 methods for the XMPP gateway.

    #1Posted by Brian J Philippus | Sep 15, 2005, 04:23 PM
  • Ben Forta

    Brian, I am working on it, Part II will be posted very shortly. :-)

    #2Posted by Ben Forta | Sep 15, 2005, 04:38 PM
  • Mark Holton

    This is an awesome overview ...can't wait to see part II. Thanks for taking the time to supply this great info, Ben!

    #3Posted by Mark Holton | Sep 15, 2005, 05:07 PM
  • Mark Holton

    Ben,
    Is there a way to track if a user clicks on a link inside of Google Talk using the CF Gateway?

    For instance, if the bot returned a paragraph of text and then a link (like your CFDOCS app) could you record if that link was clicked on by that user?

    Many thanks

    #4Posted by Mark Holton | Sep 15, 2005, 08:24 PM
  • Mark Holton

    I should clarify ...meaning tracking in a direct way, other than <cflocation> to redirect, etc.
    thanks and cheers-

    #5Posted by Mark Holton | Sep 15, 2005, 08:28 PM
  • Ben Forta

    Mark, no, if you embed a URL which the IM client makes clickable, then no, you won't be able to track that server side. The only way to do what you want would be to return a URL to your own server which in turn redirected to the destination URL, using cflocation as you noted.

    #6Posted by Ben Forta | Sep 15, 2005, 09:36 PM
  • Mark Holton

    Many thanks!

    #7Posted by Mark Holton | Sep 15, 2005, 09:44 PM
  • Evagoras Charalambous

    Ben:
    Great article! You mentioned that:
    "A gateway can be pinged by a database trigger..."
    Have you seen any examples of this, or you know of any article that talks about how to do it?

    #8Posted by Evagoras Charalambous | Sep 16, 2005, 04:17 AM
  • Ben Forta

    Evagoras,

    This is very DBMS specific. SQL Server, for example, supports extended stored procedures which can call external code. So you could have a trigger that invoked an extended stored procedure which in turn pinged ColdFusion.

    Other DBMSs have similar options (although not all do, MySQL, for example, could not do this without hacking the C source).

    --- Ben

    #9Posted by Ben Forta | Sep 16, 2005, 09:33 AM
  • Evagoras Charalambous

    Great! Thanks Ben.

    #10Posted by Evagoras Charalambous | Sep 16, 2005, 09:46 AM
  • eric olson

    I must be missing some thing or is it that this dosnt work for coldfusion9?
    And where do you write and save the codes. And many more question

    #11Posted by eric olson | Dec 4, 2009, 02:39 PM