Orchestrator without using Queues

Help
1

Hi All,

My process is very small and doesnot have any specific input item. But it is time bounded.
Can I just publish and schedule the process directly in orchestrator without using Queues(i.e, not creating queue and providing input to the robot).

Please advise if this action is possible, also mention the pros and cons.

Thank you.

2

If you can think it, it’s possible! :+1:

I still recommend the Queues, just because you can provide a secondary retry mechanism when machines are the problem, and get more info on the items being processed. Even if the item is just a date, to show that you have processed the items for each day, and you can see the results or any info that is helpful.

On the other hand, there is a major learning curve with Queues, and to be quite frank, you need a well-planned Framework to get it working in a more “hands-off” way to manage uniquely referenced items.

With or without Queues, you will also need a Retry mechanism and various phases like Initializing variables, Killing Apps, and Error Handling.

To skip Queue, you can just skip the Get Transaction phase and go directly to the Process phase. If you use a ForEach for multiple items, then you will need to continue to the item that is being retried, so be aware of that too.

If you are using the ReFramework, then look over the documentation for it as there might be a setting to disable it.

Hope this provides some info, but I didn’t really give you any samples. There might be different Frameworks you could check out in Go!

Regards.

3 Likes
3

Thank you for the detailed explanation. It is useful.

4

Thanks a lot for sharing.
My question is quiet easy, what if I am nt using the queues and need to retry a particular transaction.
How to do that

Thank you

5

Hi @kartik_sareen
It depends on how your loop is.

Essentially, you should have a Try/Catch surrounding your invokes/steps that perform the process. That way you can capture the exception and need for a retry. Make sure you use BusinessRuleExceptions to capture non-retry exceptions.

This strategy works well in a State Machine, because you can use transitions to check if an exception occurred, then go back to beginning again. However, you can also accomplish this in a Flowchart with a Decision. When an exception occurs, you will simply add 1 to a retry counter and check if it is less than the max retry number.

When it loops back around, you will use an index so you can either get the same item or the next item. If using ForEach to iterate your items, you would need to use the .Skip() method with the index. Or, if you use a counter-style loop (not a ForEach), just store each item using that index prior to going to process the item.

So, it depends on your approach.

If this is the first time you are thinking about this and have not attempted a retry mechanism before, then I suggest looking for the REFramework which is a template in Studio, and it comes with a pdf document explaining all its parts.

Performing a retry is just a matter of using logic. For example, if you are shooting freethrows in basketball, and you have 10 balls… each time you miss, you must go get the previous ball, then shoot it again. If you were only allowed 3 retries per ball, then you would just need to add 1 to retry until it reaches the 3rd retry, and reset it to zero each time you successfully make a ball. So, you can apply real logic to this.

Regards.