If someone remove’s a transaction from a queue in Orchestrator, is it possible to load another transaction with the same reference, if we’re enforcing the unique reference constraint?
Asking as we have a use-case that may require another transaction with the same reference be created in very seldom occasions.
We do need this constraint enabled though to prevent duplicates when loading normally.
Hi @abetts2114
Welcome back…!
Yes of-course you can add a new transaction with reference of removed transaction, it wont impact the queue and its status, as reference is mainly used to identify the transaction in queue with many items.
So you can go ahead buddy @abetts2114 and you can also set the constrain for unique reference once after or even while creating the queues in orchestrator
cheers
If a queue item is removed, it doesn’t count toward the unique reference, so it will let you add the same reference again.
While working with unique queue items (which I think should be preferred), you can’t add an item that has “Failed” already. So in this scenario, you would probably want to utilize the Postpone using Now as datetime, unless you want to manually choose Retry any time you need to perform the same queue item again. Imagine having 100 robots where you need to do this. I just don’t think it’s very ideal to manage this, so I suggest use Get Queue Items followed by a For Each loop on the the items you want to Postpone.
Depending on your project and what items you are processing, you could also have a range of days that you retry that were previously failed (aka Postpone), then also look at the Deadline and Fail the items that have passed its DueDate (add the deadline when you add the item to the queue). However, I’m still brainstorming ideas with this method to be managed by multiple robots, as each robot will postpone the failed items (if you have the queue dispatcher embedded in the project), which should not happen.
I still don’t understand why the Deadline does not work, almost like it’s bugged. I was expecting that the item will not be picked up by the process if it was passed due, but evidently it’s just for show. 
Hi There, so I’ve a queue with unique reference enabled for queue items. Somehow ‘Add Queue Item’ fails adding new items to the queue citing duplicate reference when there is no queue item with same reference that is in ‘New’ State.
Question is:
Does ‘Add Queue Item’ checks the reference of items in the queue with status other than ‘New’ if unique reference is enabled?
Regards
Hi @msangha80
The unique reference gets taken by all items not in “deleted” state. So any Retried, Failed, and Successful use it up.
I would suggest maybe using date or time in the reference so its unique to that day, in cas you need to run it again, but depends.
Also, make sure to have a condition that checks if the item is already in queue, so it will ignore it (use Get Queue Items and compare reference if it is in the list already). If you need to reset failed to new, you will need to postpone it probably (you may need to create a workflow that does that)
Once the items are used up their references are no longer valid or not considered whilst adding new items to the queue.Is this correct?
Actually I do want to add items to the queue with same reference on a daily basis. But making sure that no two items with same reference are added at the same time. I do not want to make reference unique for the sake of it by adding date and time instead making sure queues do not process same transaction again.
So essentially capturing the duplicate queue item as a failure and use it to report to business
Trying to use the same reference once it is already used will throw an exception. So you would need to check that the reference already exists or set the ContinueOnError to True (if it has that property)
I agree, and there are times when this is applicable, when adding a date or datetime will allow more freedom for an end user that utilizes the process. For example, if they need to process many invoices, there might be times when they need to do the same invoice again, which then you would need to decide if you want to restrict the same invoice to a day or job run time.
On the other hand, there are many other times in which you would want to not include the date for items that are consistent and duplicates would not occur unless by mistake. In this scenario, you may consider a workflow component to reset the Failed, so even if the item went through its retries, and you want to attempt it again, you don’t need to do any manual steps to reset the item. In addition to that, you would want a due date, which in the version I’m using (2018), is not accessible from the transactionItem variable and it seems the Queue doesn’t automatically close the item by due date - so, a Get Queue Items activity is needed (to match with reference) plus a sequence to change the status to Failed if due date is passed. While this point is not that important, there is still the potential where you could have an item that sits there and never completes, so due date would disable it after some time. […incoming learning curve]
In both cases, you will want to only add queue items that don’t exist already by the reference. To do this, you can do something like this (after a Get Queue Items):
I believe I used the Try Catch, so it would skip the item counter. I’m using the counter so I can Log the number of items which were added out of the total number of items.
Regards.
Wow, this was hugely useful to me today. My use of this was a minor tweak on the logic. For me the Condition above is a Contains vs an equals. Why … cuz I have “Orders” which come back for further processing later (and other reason for why I’m doing it this way … not wanting this reply to be an Epic.) So Reference is basically the OrderID with an appended “=(generated GUID)” value. The GUID is ignored and is used to simply make sure the Reference is a value unique (hopefully for as long as the queue exists … gulp). As such, the condition in the If statement was changed to a Contains.
Very very helpful … thank you !!!
ashokkarale
Anil_G
lrtetala
B_o_D
postwick
shaik.muktharvalli1
marina.dutta
Evelyn_Lu
Ejaz_Ab
ppr