Processing Transaction item from Queue based on date created

Hello Team,

I have a business requirement as below :

there is a SharePoint folder for which the files will be getting added to every 10-15 or 20 mins, a bot is scheduled to run every hour, for 12 hours. I have requirement where for each time when files arrived to sharepoint it will be having old files added sometimes (10-15 or 20 mins) back along with the arrived files. for each run bot will add the files to queue with file name. Now i don’t want to add those files which are already added to the queue , while adding files to the queue bot has to skip adding those files which are added for previous runs on the current day since bot runs on hourly basis as for each runs. Any leads can let me know what is the best approach to handle this scenario.


Set the Queue to Unique Reference, and when creating the queue item populate the Reference with something like the filename and date. Then it won’t be able to add that filename and date to the queue again.

I am doing this , but it is under try catch. when it is duplicate item, i am throwing exception for that duplicacy i have to avoid adding that item instead. hence before adding to the queue only is there any way to handle this to make sure that item which already exist in queue can be ignored through some checks before reaching to step add queue item.
Add queue item is kept under try catch because , if it doesnt throw exception then it will go to process that file during processing it will fail due to some factors so.

You don’t need to check manually if it’s a duplicate. The Unique Reference setting on the queue does that for you. Yes you need to use a Try Catch to handle the error. Why is that a problem?

when its duplicate in the catch if i add Throw or rethrow then execution will end right. then in this case i need to remove the throw or rethrow here correct?

You don’t put Throw into a Catch block. Throw is for the Try block, for example when you use a Check App State to make sure something happened the way you want it, if it doesn’t you Throw an exception so then it jumps to the Catch block.

Rethrow is for the Catch block, but only for very specific circumstances like when you have a Try Catch inside another Try Catch and want to pass the child exception up to the parent Try Catch.

But to answer your question - yes, if your Try Catch is not in another Try Catch, then a Throw/Rethrow in the Catch block will fault your job.

Typical design:

  • Try
    – Item validation, ie the queue item account number is 12345 but account numbers are supposed to be 8 digits, so you Throw a business exception “Invalid account number” and it skips the rest of the steps and goes to the Catch block (ie mark queue item failed, send email notification, etc)
    – Item processing steps
    – Check App State that has a Throw if something doesn’t appear
    – More item processing steps
    – Check App State etc.
  • Catch
    – What to do when an exception occurs

Also, my general style is that any time I manually Throw an exception it’s a businessruleexception. That way it’s easy to differentiate between what we’ve Thrown manually vs what happened on its own like when an activity fails (ie “could not find UI element”). Then you have two Catches - one for BusinessRuleException (your manual Throws) and one for everything else (System.Exception). The main time I deviate from this is if my Check App State is, say, looking for a particular page to load but it doesn’t load, I’ll Throw an ApplicationException for that (which is caught by the System.Exception catch)

Hi @postwick Thanks for details explaination, I got the complete understanding now on how to handle this scenario. It was really a great help
Thanks for your response as always :slight_smile:

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.