We suggest you use the countSince API to find out how many new posts there are and then use the "numberOfResults" query param on campaign results to only return that many.

An alternative would be to use the HTTP post notification method to get asynchronously notified with each new social contact.

This would work in 8.5(2) whereby each time a tag was applied, you would get notified. Tag application would need to be "manual". However in 8.5(3) which will be released in a week or so we will support auto-tagging so that you could configure all social contacts to be tagged and therefore all social contacts to generate a "notification".

8.5(3) documentation has just been posted. API doc and software will be coming in about a week.
http://docwiki.cisco.com/wiki/SocialMiner

a) Yes, there would be a small window. Perhaps get more then you need and de-dup.

b) asking development for their view on this question.


Tod
(Note: we realize this isn't optimal. Hence the http may be better route to go long term or the script filter we're working on in 8.5(4) may be best. We're working on 8.5(4) now. We should have something on our hosted system in July.)

 
Unfortunately, its not bullet proof.  Is perfectly legal to set the contact state back from RESERVED to UNREAD, so I don't think I can rely on the contact's state to determine which posts are new. I'd still have to figure out some way to determine the difference between new, unseen posts and these posts that have had the state set back to UNREAD.
 
I did notice that all new posts have a state of UNREAD and a null ccp:scstatususerid element.  Could I rely on this to indicate a new, unread post?  Is there some other way to get the contact's state set back to UNREAD, but not have a valid userId value?
 
thanks,
Brett

Note: this has a reporting implication.

the handled time in SocialMiner is the time between the first time the Social Contact gets "reserved" until the social contact is handled.

If the post goes reserved, then unread, then reserved, then handled. We take the time from the first reserved.

So if the external application reserves items, then it will dramatically increase the AHT.

Tagging is probably a better approach to marking items. For example, tag every item you've pulled with a tag that indicates it's been read.


I'm not entirely sure what you're trying to do end to end with your integration. We should probably review that holistically.

I *think* what you are trying to do is look at the SC's and tag them or perhaps discard them. If that's the case, then the SC's that have no tags are the SC's that you have yet to /process/. So what you might do is pull a bunch of unread SC's, process them and put tags on all of them (even if you are putting a tag that says "we aren't sure how to tag". You can also delete the ones that you thing should be deleted etc. Then you go pull a another set of SC's. You would discard any that had been tagged as they have already been processed.

 
Unfortunately postId goes the wrong way.  It is used for paging backwards, so if you give it a postId it will return the results earlier than that postId.  We'd have to change the api to add an option to make it show you everything _after_ that postId.

 
Ah I see.  The postId of the SC is a guid that we generate internally.  Its possible that the algorithm will always produce a larger hex value but it is absolutely not part of the API and not guaranteed to be the case all the time.  It could flip over at any time resulting in really weird bugs on your end. 
 
I think your best bet right now might be the count since API and then fetching more than the result to handle any overlap and looking for duplicates.  Its very unlikely to give you problems and should work until you can bug Tod enough to put in a story for the actual feature which does sound very useful.