Page 2 of 4   « previous page   next page »

Creating The Config File
Next you'll need to save that account information into a configuration file. Gateway config files are typically stored in /gateway/config under the ColdFusion root (c:\cfusionmx7\gateway\config on a Windows standalone installation, c:\jrun4\servers\cfusion\cfusion-ear\cfusion-war\web-inf\cfusion\gateway\config on the default ColdFusion instance on a Windows multi-server installation), although they could be stored elsewhere too. That folder may contain a sample XMPP configuration file named xmpp.cfg which you may copy and modify. Your configuration file should contain (at a minimum) the following entries (obviously setting userid and password to your GMail account information):

userid=account@gmail.com
password=password
resourceName=ColdFusion MX 7
secureprotocol=TSL
securerequirement=true
serverip=talk.google.com
serverport=5222

Creating The Bot CFC
Next you need the CFC that will respond to inbound requests. At a minimum you need two methods in your CFC, onIncomingMessage and onAddBuddyRequest.

All instant messages sent to your bot are routed to a method named onIncomingMessage. This method is the one that actually receives all inbound messages, and this is where you'd process user requests, generating responses if needed.

Here is a simple example:

<cffunction name="onIncomingMessage">
<cfargument name="CFEvent" type="struct" required="yes">

<!--- Get the message --->
<cfset var message=CFEvent.data.message>
<cfset var originatorID=CFEvent.originatorID>

<!--- Result structure --->
<cfset var retValue=structNew()>
<cfset retValue.BuddyID= originatorID >
<cfset retValue.Message="You said: #message#">

<!--- send the return message back --->
<cfreturn retValue>
</cffunction>

All methods invoked by gateways receive a single argument, a CFEvent structure (the contents of which vary based on the gateway type). In this example, two local variables are created containing values extracted from the CFEvent structure, message is the actual text sent by the user, and originatorID is the sender name.

Typically your bot would do some processing based on the contents of message, but this simple example just echoes the content back to the sender. A return structure is created, and two values are set, BuddyID is set to originatorID (so that the message is sent back to the sender), and Message contains a string echoing the received message.

And that is all that is needed. The return structure is returned by the <cfreturn> tag, and the echo will be sent back to the sender.

That's onIncomingMessage. Next comes onAddBuddyRequest. When you add a user to your own IM buddy list, the network sends a message to that user asking them to accept or deny the request. If accepted you'll be able to see when that user is online and will be able to send him or her messages, and if denied then you'll not be able to see online status, and you may not even be able to send messages. When a user adds your bot as a buddy, the server will ask it to accept or decline the request. Obviously, these requests must be handled programmatically (as there is no actual user), and so these are routed to a CFC method named onAddBuddyRequest. This method can always return an accept response, or can conditionally accept or decline based on some code (maybe a database lookup, or some password or code provided, and so on).

Here is an example:

<cffunction name="onAddBuddyRequest">
<cfargument name="CFEvent" type="struct" required="true">
<cfset var retValue = structNew()>

<cfset retValue.Command="accept">
<cfset retValue.BuddyID=CFEvent.data.sender>
<cfset retValue.Reason="Welcome!">

<cfreturn retValue>
</cffunction>

Once again, onAddBuddyRequest receives a CFEvent structure. This method must respond to the network either accepting or denying the request. Here a return structure is created. Command is set to accept, accepting the request (set it to decline to deny the request). BuddyID is the name of the user being accepted, and Reason is a welcome message that may be sent to the user (depending on the network and IM client being used). And like before, the return structure is then returned using the <cfreturn> tag.

Other methods are supported too. And best practices dictate that every method be present in your CFC, even if they are not all used. So every IM bot CFC you create should probably contain the following (even if the methods are all empty):

<cffunction name="onAddBuddyResponse">
<cfargument name="CFEvent" type="struct" required="YES">
</cffunction>

<cffunction name="onBuddyStatus">
<cfargument name="CFEvent" type="struct" required="YES">
</cffunction>

<cffunction name="onIMServerMessage">
<cfargument name="CFEvent" type="struct" required="YES">
</cffunction>

<cffunction name="onAdminMessage">
<cfargument name="CFEvent" type="struct" required="YES">
</cffunction>

Page 2 of 4   « previous page   next page »