Change specific data in queueitem (in_transactionitem)

Hey hey,

I want to change the retryNo from 0 to 1 in the queueitem (in_transactionitem) variable. The reason is because i want to add an postpone to an the retried transaction.

QueueItem { AssignedTo=null, DeferDate=null, DueDate=null, Id=650671, ItemKey=[0be5cd45-2303-4b94-947d-2ead2a3b4fad], LastProcessingOn=null, Output=null, Priority=Normal, ProcessingException=null, Progress=“”, QueueDefinitionId=430, QueueName=“RPA_mission_impossible”, Reference=“Test”, RetryNo=0, ReviewStatus=“None”, RowVersion=byte[8] { 0, 0, 0, 0, 0, 22, 14, 34 }, SpecificContent=Dictionary<string, object>(0) { }, StartTransactionTime=[09/10/2021 12:23:29], Status=Successful }

My plan is to set the orchestrator on max retries 1, when it retries i want to set the postpone on the new transactionitem at +12 hours. But if i use the postpone with the in_transactionitem then he sets the transtionstatus from failed to new.

Anybody that can help me?

Thank youuu!

Have you tried the “SetTransaction” activity to set the retry number to match what you want?

From what i understand of your intent, you want to retry the transaction once, and after that retry you want to postpone it for 12h.

In that case you could go to the framework/set transaction section and add a condition where if in_transactionitem.specificContent=1 then postpone transaction.

The postponed items will always be generated in the “new state” , i’m not sure if they inherit the property of retry number from the original transaction though.

Thank you for your reaction

If the first transaction fails i want to postpone the new transaction that orchestrator retries. I want to do this because i dont want the retry i the same robot run.

In that case,

if the transaction fails and RetryNumber is 0 you do the postpone activity (after setting the transaction as failed), and the postpone activity will change the status to new (w/ RetryNumber=1)

If the transaction fails again and RetryNumber Is 1 you mark it as failed (as usual).

In this way you dont actually use the retry function of the orquestrator/queue , but postpone the failed itens to a new date, and after the postpone you check the retry number to avoid being stuck in loop

If you want to bypass the retry alltogether you could check for the postponed property in the transactionitem , if has no postpone date is a new item , if it has one is a retried one.

You should vote here.