We have an automation that is provided queue items from multiple other automations. In some instances this performer could pick up a transaction, process it, and look for the next queue item before the dispatcher can add the next item.
I am considering using the Wait Queue Item activity so the performer won’t just check for a queue item, find nothing, and stop. This could lead to a lot of instances where it starts, does one queue item, then stops…even though another queue item will be added within a minute or so.
If the Timeout is what controls it, it is workable, but seems odd that the wait time isn’t a separate setting. Seems like the Timeout should be reserved for what it’s usually reserved for in this context - if Orchestrator is having issues and doesn’t respond to the queue item request in a timely manner.
Also, the documentation says it throws an exception after the Timeout expires. If the Timeout is what controls how long it waits, an exception isn’t ideal. It should just do the same as Get Transaction and return a null value to the queueitem output.
If this is how the Timeout actually works, I’ll probably just use a Do While or something with a regular Get Transaction activity to mimic the Wait Queue Item activity. That way I can keep the functionality of Timeout separate from how long it waits for a new queue item.
If exception on timeout is an issue why not use continue on error so that no error is thrown even when item is not retrieved
ideally we are knowingly waiting for item to come and if it does not come that means something expected has not happened so exception should be good…for get transactionitem thats not the same till items are present it should send and once items are done it should be stopping so null value is returned if same is needed continue on error can be used
As I explained, this could result in the performer starting, processing one item, then stopping…then a minute later starting, processing one item, then stopping. This is inefficient.
Because then if Orchestrator throws an error when the activity tries to look for a queue item, that error is not caught. There being no new queue item should not be considered an error. Get Transaction doesn’t consider it an error, because it’s not an error.
Ideally if you are expecting a item to come and if it does not come for any reason then that is an issue…for get transaction item a queue item is not expected but for waiting for it …it is definitely expected to be coming
Agreed with you on orchestrator connectivity issues though…apart from connectivity issues if orchestaryor has any other issue then the bot itself should not be working in the first place
It isn’t about expecting an item. There may or may not be a new item coming. I just want it to wait for a minute or so before deciding nothing new is coming.
It’s simple enough to code this manually with a Do While or Retry Scope or something, but it would be nice if the activity meant for this was a little better designed IMO.
