function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
gwestrgwestr 

streaming API limits thread

I receieved a question via email which I'll repost here, and answer:

 

Hi Greg,

I'm trying to interpret the Force.com Streaming API limits noted in the documentation. These are my questions:

1. "Maximum Number of Topics: 20" - is that referring to the total number of PushTopic records? Is that limit per user or per org?

2. "Maximum number of clients (subscribers) per topic: 10" - does that mean if I build a VF page that allows users to select streams to "follow" and deploy that into an org with 100 users, only 10 of them can subscribe to the same topic? Is that limit of 10 at any given moment, or is there a duration for which a subscription lives and "blocks" other subscribers?

gwestrgwestr

20 is the maximum number of PushTopic records per organization.  We would love to hear your use cases for having more topics.

 

Yes with any number of licenses, only ten subscribers are allowed per topic.  A subscription expires 40 seconds after the last connection from a client.

 

I hope you are finding the documentation to be helpful:

 

http://www.salesforce.com/us/developer/docs/api_streaming/api_streaming.pdf


jhennyjhenny

I feel like the 10 concurrent subscribers per topic limit really diminishes the value of this API, unless I am not envisioning using the API as it was intended.

 

For example, it seems like a great use case would be for a call center to see cases get submitted in real time & respond to them, or a sales team to see lead flow.

 

If you wanted to expose a VF page to stream the cases/leads, you would be limited to deploying this to teams of only 10 people or less, which really doesn't seem to make much sense.

 

Is this limit going to be increased, or is there some way to architect a solution where all users share a single subscription?

 

If this really isn't something the API was meant to do, what are some of the use cases for the API that wouldn't be effected by the 10 concurrent subscribers limit per topic?

 

(FYI I actually have an app on the appexchange that displays queues in the sidebar which used to function by polling for updates, so I just upgraded it to use the streaming API, however, I needed to build in functionality to revert back to polling in the event that the streaming limits have been reached, which I forsee happening often)

sammydsammyd

I want at LEAST 1000 entries. (900 service reps) I want to dynamically refresh my service reps console list if anything changes and also pop up a flashing message (update the status line, whatever) if a new case comes in they should look at while they don't have the case list up.

 

each service rep has at least 30 issues they are working on concurently.. If a customer sev 1 arrives, then they should stop working on the sev 2 or 3 case and get to the sev 1.. but if they are not actively looking at the list, then they won't know.

 

the service rep will create a unique query of the customer entered cases based on a huge filter in soql, and it would be perfect to use this on the pushtopic.  they can actually have a bunch of different filters, so just like standard console they can pick between them..  (really wish the std console or console 2 would allow me to extend the UI and save a SOQL stmt to be used). I do so hate polling..

 

I will use one pushtopic for integration with another system, to remove the polling, triggers and possible missed events, make the code all external to SFDC.

 

 

ddennddenn

Okay - please bear with me because I'm a bit new to this whole 'streaming' thing :)

 

Am I to understand that based on the default limits, SFDC only supports ten concurrent connections to a topic?

 

E.g., I have deployed a 'marquee' in the Service Cloud Console (SCC) footer (as suggested by the Summer '12 release notes) which is subscribed to the creation of new case records.  I have ten agents viewing the SCC... great, no problem.  Now an eleventh logs in - and some sort of error message is thrown?

 

Am I interpreting this incorrectly or is it just limited to a diminishingly small group of subscribers at this point?