Receiving notifications while user is online

[stephan.steiner]

Hi

I'm in the design stage for my first Finesse project and reading the developer guide has me worried.

On page 13, in the Pidgin section, the guide states

"You cannot be signed in to Pidgin at the same time you are signed in to Finesse as the XMPP event feed

is disrupted."

Yet, on page 4, there's a graph "Finess API and Event Flow" that shows a system where there's a browser based client and a server based client that seem to be running concurrently.

What I'm trying to do is have a server side application that monitors agents for their state, and do something with that information. All my agents should of course be able to work normally.. my server application must not interrupt any standard behavior.

So.. is that even doable given the note on Pidgin? XMPP is after all the only way to get notifications from the notification service, but if using XMPP interrupts the BOSH eventing to the browser based client, then the XMPP notification service is useless to me.

[conrchan]

Hi Stephan,

The picture on page 4 depicts how Finesse can communicate with both browser clients as well as thick clients and or server clients. The note about Pidgin was initially put in specifically regarding logging in the same XMPP user in two separate XMPP sessions.

That being said, I believe that note about PIdgin is outdated and since then we've upgraded to a more stable version of Openfire and though we don't specifically test it in our labs, I believe that logging in two XMPP users (with different resources!) should be fine. The Finesse browser desktop uses the resource "desktop" so if your server implementation conflicts with that resource then the agent in the browser will get kicked out.

Hope that helps,

Conrad

[stephan.steiner]

What do you mean by resource? The UserId of the agent? That's exactly what I'm trying to do.. I want the agent to work normally, and I want my server side app to receive notifications if the agent is ready, not ready, in a call, that kind of thing (and that for a whole list of agents).

I'm not planning any write operations, only gets - so my server app would only manually request information, and use the notification system to be informed about changes that are relevant to me. I can use this approach just fine for CUP (e.g. seeing the changing presence of Jabber users), and that note in the guide has me worried that something that should be standard operating procedure (user works normally, a server app gets information about relevant changes and has the opportunity to react to it... imagine if you will for instance a custom panel that shows queues with calls and their states and a list of agents and who is doing what).

[conrchan]

By resource I mean the last part of the JID (jabber id) that represents an XMPP user: <username>@<domain>/<resource>. The resource is optional but allows the XMPP server to uniquely identify the endpoint.

So as long as you avoid the "desktop" resource and login the XMPP user with another resource, you should be fine.