I currently have the following process, split into two robots :
RobotA : retrieves queue items from queueA, creates documents on SAP and adds each one to a second queue to process later : queueB
Robot B : follows the robotA, retrieves data from queueB in order to process them
Now, i would like to add a third process (robot C) that would follow the robot B. I have thought about two solutions :
since the process is way too small, I do not feel it’s worth it to create a new robot so rather attach it to the existing robotB as the following logic:
at the end robotB process for a transaction, i add the transaction to queueB with a specific name. in the process i would distinguish the processing of items based on the reference of the transaction. so i would have one queue and an “if” in the process to distinguish them
the second solution would be to create a new robot for the processing C, a new queue
This is the first time i encounter this case, would appreciate any input thanks
If the third bot is dealing with one more application and thwn it is better to do it in another process rather than the same…
If its same aystem and navigations are kot a problem or does most of it in backend then can go with one as well as there is no harm…you can use reference in queue to identify the different items
Just thinking out loud: if the queue is the same and the robot is the same, is there any reason why you can’t let the robot B do all the work at once (process B + process C) without passing through a different queue? Or there’s something manual that has to be done between process B and C? Just asking to better understand the need, as I don’t know your context.
This is a good question I forgot to mention that the process C cannot be done right away, there is a validation needed after process B (external). so i would add to the queue (same or new one) and postpone it to the next day
Thanks for the confirmation! It’s always good to get info about other people’s business cases and how they’re implemented, I might end up with the same need someday
As mentioned if the navigations are not very different and it is straight to reset navigation for both with same Process then can go with one and use reference to understand which type of queue item it is
But on sap we generally use tcodes…and sometimes we dont search the tcode always instead search it ones and in process we navigate to respective pges…considering that better to gow woth two …but if number of transactions and time it takes is small then can go with one as well
Gladly! I agree with @Anil_G : if the process B and C are very similar (same applications used, same type of data, similar purpose, etc…) then it makes sense to put it all together. It would be as saying that Process B is split into a Phase 1 and a Phase 2 (rather than considering it as two completely different processes).
On the other hand, if the two processes are quite different, I would not recommend putting them together just because the 2nd process is small and it’s not worth it to put the effort in creating a separated robot for it: I’m usually not a big fan of mixing pears and apples just for the sake of doing something quick Primarly, you never know how your processes might evolve in 6 months or a year, and you might end up with a lot of patchwork development to do if you decided to keep everything together and the two processes have different evolutions (or you might have to split the robot in two later on anyway). Finally, it all depends on your business processes and on the likelyhood that they might evolve drastically in the future. My two cents.
No. The first part of your process would get data from one queue, the second part would get data from the other queue, both with their own Get Transaction activities.
Primarly, you never know how your processes might evolve in 6 months or a year, and you might end up with a lot of patchwork development to do if you decided to keep everything together and the two processes have different evolutions (or you might have to split the robot in two later on anyway). Finally, it all depends on your business processes and on the likelyhood that they might evolve drastically in the future. My two cents.