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
greentruck55greentruck55 

size of topic list

In our customer service environment our support person will be working on at least 30 issues constantly, and their lifetime is in multi-digit days.  we will be using the console or console 2 UI's to view the list of issues to work on.

 

once u select an issue, the list goes away, and it might be hours til you get back to the list again.

we wanted to use the streaming api as a 'wakeup' type operation that could be driven via javascript, and so could

refresh and pop the list view, if an important issue arrived while they were off the list view.. (like a severity 1 issue while they were working a long sev 2 issue). 

 

but each support person is looking at a different (unique) view of the case list.  So, I would want to register a 'topic' for each support person, to have their notification sent..  I have 900 such support personnel.. and 20 topics clearly wouldn't cover that.

 

we were going to develop a polling javascript solution that did this, but it seems such a waste of processor power haveing 900 polls every 10 seconds. (we have unlimited so aren't worried about the api count, but want to be a good resource consumer citizen too)

 

any suggestions on design alternatives?

alextalext

You may want to consider having a generic query for the issues (LiveIssues Topic), and let sharing drive the visibility.


So for example if I am Bob, I would subscribe to the LiveIssues topic, when a change happen on a record that I am entitle to see I would get notified. So should get back records that everybody can see, plus records in which you are the owner. Next on your side you could split the results on the client side. Therefore only 1 PushTopic would be needed for all reps.

 

You may want to prototype this strategy and let us know what you think!

 

--alex

sdetweilsdetweil

somehow I have two ids..

 

thanks.. everyone can edit everything so sharing won't work.and new issues are not assigned to me yet (in general). This data design simplifies our processes SO much, but we have this update/notification problem regardless..

each support engineer has crafted, thru menus, (ala views) a customized criteria for records they are interested in. they have multiple of these (like named views) and could select any one of them as their current view.  I have no way of knowing similarity or differences of the criteria.

 

but if I could create a generic soql it would be very dumb.. select id,name, account,name, number from case;  (or select all fields from case)

 

Then this design would cause a notification of all the changed records to all the clients near simulatenously, and no way to apply the client filter criteria to them without doing another soql query.(only for these customers, on these products, in these languages for these support staff(me and the guy I am covering for). (or creating my own soql like engine that processes the returned record(s). not)  So everytime a notification occurs we have a flood of 900 soql queries near simultaneously. about 10,000 times a day.. not a good design for the system.  polling is less worse.

 

but this streaming design overall helps solidfy some ideas..  

we had a defined soql query for each user  (they have a list of them depending on the circumstances, aka views)

and would have made a web service that would have invoked the soql

so this will loop a number of times inside the SF platform per user request with a decent delay,

(adding onto the soql a time compare of last loop time to changed/created case record time), instead of returning immediately.

and delay loop at the client invoking the web service if no records are returned.

 

only the delay inside sf task is unknown to me at the moment.

 

alextalext

It seems like if we had some server side filtering options, or just plain more topics, this could help you here?

 

This is really good feedback.


Thank you,

 

--alex

sdetweilsdetweil

more topics of course would be nice.. but I worry about the overhead of a 1000 soql statements that might have to be executed whenever the 'record' changes.. in our situation 'case'....

 

can u tell me more about ideas on server side filtering?

 

thanks

 

Sam

 

 

sdetweilsdetweil

any more info we can discuss on server side filtering?

Vinod MehraVinod Mehra

server-side-filtering is a future enhancement which is still being discussed. The idea is simple. When the client subscribes it provides the list of record ids it is interested in. Salesforce will send out events only for ids the client is interested in.

sdetweilsdetweil

thanks.. you mean specific 'ID's, right?  

 

for us that wouldn't be useful in this use case.

 

I am intersted in being informed when a NEW record appears meeting some where clause criteria.  obviously when I set the filter, the record does not exist, so no ID could be provided..

 

not sure I see a really useful usecase for watching only  records of certain IDs, that can't be covered by a good select stmt.

altho you could watch records across types which is hard in a SOQL select..

 

Sam

 

Vinod MehraVinod Mehra

> I am intersted in being informed when a NEW record appears meeting some where clause criteria.

 

This should already work today. The CREATE events will be sent only when the new records match the query.

 

The id based filtering applies only for UPDATEs. Suppose you are on a list view watching certain records. That's the only record IDs you are interested in. So you will subscribe with only that list.

 

Indeed you can do this with PushTopic.query. select ... from ... where ... and ID in (....)

 

But that means for different views and different users you will need a different pushtopic. Since there is a limit on number of push topics an org can create, id filtering feature helps overcome that shortcoming.

 

> altho you could watch records across types which is hard in a SOQL select..

 

PushTopic is per entity type. Subscribe is per topic. So the mixed (w.r.t. entity type) list doesn't apply here.