How Do You Assume A Session From Event Gateways?

[RLS]

I am using event gateways to send and receive via SMS, IM, and Email. I can go back and forth just fine, and if the client initiates the session, session persistence is not a problem.

Sometimes, though, we need the server to initiate the session and the client to assume that session so we don't have to re-establish the thread before we move on.

For example, if the client says "Approve John Doe" for something, the bot can respond with "John Doe found. Reply with A for admin rights, W for web rights", and so on. Because the client established the session, replies are cemented in the bots brain so they know if an "A" is returned, it will give John Doe Admin access.

The trouble is if the SERVER initiates the call to the IM Client: "This is the server speaking. John Doe is attempting to access the double-secret files. Reply with A to Allow or X to send 10,000 volts to their computer". Reply with A and the bot will respond with, basically, "request unknown" because the client actually initiated a new session and nothing the server said was heard or can be viewed by the client.

When the server creates a session in the event gateway, there also appears to be no sessionid, cfid, or cftoken. Especially for SMS, it's difficult to pass a UUID or specially coded variable for the client to use to at least search and retrieve the particulars of the event.

So, how does one get a CLIENT IM, Email or SMS to assume the Session from the server?

Alternative solutions welcomed!

RLS

[BKBK]

The docs show one way of defining sessions for Coldfusion gateway applications.

[RLS]

BKBK,

Thank you for your response. That does adequately cover the client-originated sessions, but still leaves the ability I am looking for unavailable.

It did serve to definitively answer my most pressing question, however, with this statement:
Note: ColdFusion cannot create a session if an initiator application uses a SendGatewayMessage method to start an interaction with a client, such as an SMS user. In this case, the sending code must keep track (for example, in a database) of the messages it sends and their destinations. When a response event arrives, it can look up the origniatorID to determine whether it was in response to an outgoing message.

I will play around with the Application scope to see if there might be a workable solution there.

RLS