Please can someone share business scenario examples of criteria to decide “add transaction item” and “add queue item” activity?
Note : Conceptually, I do already understand that -
Add Transaction Item -->Adds a new item in the q and starts a transaction. The status of the item is set to InProgress. Returns the item as a
Add Q item → Adds a new item in an Orchestrator queue. The status of the item will be New
Add QueueItem activity scenario:
Let’s say multiple bots are working on one process. Then we will design the process as Dispatcher and Performer model.
Dispatcher: It will read items from input source and will add items to the Queue using Add QueueItem activity. Single BOT will execute dispatcher process.
Performer: It will read one by one item from Queue and will process. Multiple BOTs will execute Performer process.
In the above scenario, we need to use Add QueueItem activity such that all Transaction Item state will be new state.
Add Transaction Item activity scenario:
Let’s say single bot is working on one process and also we don’t have have Dispatcher and Performer design in our process then we will use Add Transaction Item activity such that it will add one by one item to the queue and then will process and will update the status immediately. Once item processed then BOT will go pick and next item.
If your query resolved then please close this thread by marking appropriate post as solution. So that it will help others who are facing similar issue.
Thanks @lakshman for your detailed answer! This perspective is a strong reason to choose between the two is what I can understand.
I am waiting to know if any other business case real scenarios if anyone can share, it will be really helpful.
What sort of detailed scenarios are you looking for? What @lakshman provided sums it up
- Add queue Item to Queue to be processed later or by another process
- Add queue item to queue and begin processing immediately within the current running process.
Many of our Business Processes are broken down to have a Dispatcher/Loader and a Performer/Processor type setup, but a couple of them are initiated by invoking a job directly and the job both creates and processes work item in one flow.
The reason all our process implements queue items is because it is how we decided to report on metrics and business outputs in downstream systems, by attaching Output data to the Set Transaction activity and to the Log Message fields and reporting on the rawMessage in the logs passed via NLog.
Yes, @lakshman’s details were indeed very useful to understand more about the differences.
@codemonkee - The examples you mentioned were exactly what I was looking for! Thanks a lot, it helps!
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.