Apex Code Development You need to sign in to do that
Don't have an account?
sammyd Simulating Streaming for 1000 users
We want to use Service Cloud Console, which runs off of a View definition.
the UI & data for picking our product/serviceable component will not fit into the View list definition tool
When the service rep selects a case from the console list, the list is no longer shown.. working the selected
case might be hours worth of work.. with the list of cases not shown..
we want to tell the service rep somehow that a new case has arrived that is higher priority than the one they are working on,
without having the user have to do something on the SF web page.. (alert popup, something) cause the rep could be using
some other app during this long work period ( our cases last way longer than a day).
if we write our own service cloud console app, then we can do whatever we need.. I don't want to go there..
if we had 1000 pushtopics, we could get almost everythign we need.. but there are only 10 per org.
so, we are thinking how we could simulate what streaming does.. when a case changes, inform the interested parties..
we can build & store a soql stmt with a new view list type & UI.
if we somehow make a special case relationship object for each user for each case (inclusion list), then we could show THAT in the
std view list..
so, one idea is a shared folder, for each user with a list of related cases in it. don't know if the system supports 1000 shared folders.
another idea is a junction object for each case ot each user when the view criteria match.
another might be permission sets..
effectively we would have to run a trigger/workflow on any case change, and run all 1000 defined soql stmts and make/update the relationship in some way or another. we have at least 10,000 case updates a day.
then we could use the new case console marque feature (added in summer 12) to poll to see if the list changed to add new priority 1 cases to the users list over what is already displayed on the console list (on the non-visible tab).
OR we could use a generic case streaming event to fire this check..
when does streamimg event happen relative to triggers? (I hope guaranteed to be after.)
Ihate the inrush of streaming client callbacks on every event hit.. but such is the current limitations
man, if there were just more pushtopics..
No takers eh?!..
interesting post, as our org is faced with a similar set of challenges in presenting service personnel with real-time updates of their workload. our app currently does intensive polling against SFDC data to the extent that SFDC has felt that it represents an inordinate drain on their resources and THEY have proposed streaming as a possible remedy. in discussions with them it surfaces that they are open to or already have substantially expanded the number of allowed topics. The current mantra seems to be that the way to go is to use broad queries as topics and let sharing rules filter them out. Sounds ideal, but I don't see how it could work for us. They have also proposed that it would be feasible to use broad-based queries as topics and filter the unwanted data on the client side. I havent had a chance to test the implications of this approach.
What is the case console marque feature?
Mike
thanks for your post.. nice to know we are not alone!.. and to reconfirm that polling is a bad design choice.
Our model is that the support engineer (case worker) has a personal view of the existing and arriving cases. We have the forced view now (defined queue), and every single user hates it, cause no one queue is THE list of cases. AND each user has a workload of 20-30 cases at one time, due to the nature of the workload.
the difficulty with using broad based streaming topics is that you must then fire too many clients, who then have to get more data to make a decision ('filter the unwanted data on the client side') if this event is important.
If you cannot decide at the server (topic), then the client must work it out. and how do they 'work it out'? they have to run some logic, that looks very much like a soql select stmt effectively. So you are moving from supported near the data code (soql) to private code far from the data (javascript probably) ..
But, this pub/sub model has always been a challenge when the number of subscriptions is large.
so, in our case, if there are a 1000 users waiting on an event, and the (general) event is 'a case/some cases changed', then there is a rush of all the clients at once trying to determine if it matters, I have no model yet to tell me if this really is 1, 10, or 100 clients that care, but I KNOW it is not 1000.. truely this is SO much worse than polling. this will probably be at LEAST 2 * the number of clients soql stmts.. 1 to get the personally defined 'filter' defintion, stored at the server, and at LEAST one SOQL call to get the rest of the data needed to decide.. (I don't want to send 90 fields on each event trigger, cause that sort of guarantees that the phone pipe will die on each event,.. some of our agents are in remote locations where the phone lines are not up to US standards no matter what we do).
(note that this is only about 'Case')
I have not included using streaming for other record types as well, account, contract, ...that non-support users might need to manage,
so the problem gets worse quickly.
and yes, WE could design a model where the users 'view preference' is loaded & cached at the browser each time the console is loaded to try and prevent 1 soql call.. but again thats ME writing and maintaining code to workaround a lack of support from the server. not a good way to start a solution design.
console margue..
we have talked about putting some 'live' info on the browser status line (footer) to indicate if an important event has occurred, vs a popup or a screen refresh which WILL upset some users who will lose data.
see the http://na1.salesforce.com/help/doc/en/salesforce_summer12_release_notes.pdf, and page 47 shows the use of the Marque.
but that is really THIS code we are talking about.. so we can make a pretty trivial screen update, if we can figure out how to get the info without killing the server and our dev staff (code development & support).