I have built a program to get application exceptions from orchestrator queues.
The scenario is - My robots are scheduled to run every hour, get data from work queues, and there can be some application exception in processing, so I have created a workflow which will be running every hour to check for application exceptions in the work queues and if there is any, it will add them to a seperate queue and process them as per business rule.
Process is woking fine in dev and test but it doesnt pick application exceptions in prod however exceptions are there in the queues. I have checked the configuration settings like time zone of the environments and they are same.
Following are the high level steps I am using to get applications exceptions happened in last hour-
Get failed Queue Items with QueueItemStates to Failed. Please see screenshot to get values for last hour.
Then checking the exception type of every Queue item using for-each, and expression to check exceptions type is item.ProcessingException.Type.ToString
If this exception type is application exception, add into new queue using Add Queue Item
Above steps works as expected in development and test but failed in production. I am unable to figure out the cause, has anyone faced this type of issue before? Please share if someone has any idea.
First off, interesting idea.
Secondly, my first thought of your problem is that in the Dev/Test Orchestrator you have different authorization for your “Robot” role than you do in the Prod Orchestrator. That would be the first thing I would suggest checking, that it has “View” access to the Transaction Items and Queues.
If that doesn’t help, can you explain better what is not working in Prod, like is there an error you are getting?
Thank you ClaytonM for your response, and excuse for my delayed response.
I figured out the problem, GetQueueItem activity reads first 100 items, and in productions we do have records more than 100, and it doesn’t necessary that application exceptions find in first 100 items. and if any exception exist after 100 records, was skipped.
In dev, I deliberately created application exceptions first few records so it was picked.
Following article helped to figure out and fix the issue-
Thanks for pointing that out. I think I ran across that post before, but forgot about the limitation. I’ll need to make sure it won’t impact me for what I’m doing too. For things like postponing Failed/Successful items to be retried if desired. I’m mainly using it to pull in the “InProgress” items to postpone them if it’s the first job run and also to get certain values that doesn’t come from the Get Transaction Item (for whatever reason) like “Due Date”. - In Progress will never exceed the 100 unless you just keep killing a process over and over leaving them in bad state by accident.
Before knowing the GetQueueItem limitation, I tried it with Orchestrator API and was nearly close to complete it but suddenly found that post and then implemented the solution. It is working fine.
I personally think we should have a place where these common terms/limitation/issues can be maintained to make people aware about.
Eventually it is interesting and a good experience.