Call Stored Proc vs UI - Best Practice

Question - as far as best practices, curious what others think from a design perspective, which is better or optimal when it comes to implementing a RPA Design: 1. Automate via User Interface only or 2. Automate via Database Stored Procedure calls (if available)…?

What are the pros and/or cons of each…?

@rstaylor62 - If you can use a DB stored procedure to automate a process, then that should be the first choice as there is no need to invest in an RPA tool. But using an RPA tool makes more sense and sometimes the only choice in processes where there is lot of manual activity is involved and there are no other alternative ways to automate the process. For example if a process involves checking a mailbox at regular intervals of time, opening an attachment, read the attachment for specific values and input these values in another application, then this is an ideal case for using an RPA tool.

Yes, agree with what you have stated, but believe there are times to where there are hybrid type situations, for example: There is Application A and WebSite B. The process is to go into Application A first, search for an Account and then pull out a Key Value. Next, the process goes to the external WebSite B and searches based on the Key Value pulled from Application A and the resulting web page is stored to the local file system.

So given all this, if Stored Procedures existed so that one would not have to navigate or integrate with Application A, but obtain the Key Value from the Stored Procedure, would this be an acceptable or optimal way to code the process? Then only use RPA Tool (UiPath) to automate and integrate with the Website B.

@rstaylor62 - Yes, you can certainly do that. But in this use case, if you have all the Accounts you need to search in App A in a list, you can input this list to the bot and then the bot can open App A, search for the account, get the Key Value for the account, open Website B, search using the Key Value and store the web page in a local folder. And then repeat for all the accounts in the list and then stop.

If you are using the stored procedure, you need to run the stored procedure manually (or schedule this), the stored procedure would then write all the Key Value to a text file and then the bot can be scheduled to look for this text file and then process.

You can do both, but you will get more bang for the buck if you use the bot to do more activities rather than limiting it to a few activities. You also need to think about maintaining the code for the stored procedure and the bot versus just maintaining the code for the bot. Also if there are different teams maintaining the stored procedure and the bot, then there needs to be a process for communicating the changes in stored procedure to the bot developers so that the bot would not fail. So these are some of the factors to consider in deciding which option to go with. Hope this gives you some ideas on how to chose the best option.

Again, I see your points and where you are coming from, BUT as for a List of Accounts, that is what the Stored Proc would be providing. My thought is that it would be triggered on a Schedule and each Key Value would be dropped into a Queue (Dispatcher Model).

Then there would be a separate (Processor) Robot scheduled that would pick-up the queue item(s) and process within a transaction utilizing the REFramework.

“but you will get more bang for the buck if you use the bot to do more activities rather than limiting it to a few activities.”…not sure about this statement as the Bot(s) would still be performing a lot of activities. Whether going thru a UI to derive a list of Account Numbers or calling a Stored Proc from with the Robot, what is the different? UI interaction versus Database interaction.

I understand the point about communication in regards to any code changes that might impact the Stored Proc, but the same could be said for the UI also. If a different Team or Developer modifies a UI that a Robot is interacting with, then the same is true.

Overall, still not sure whether one is better than the other as both seem to have pros and cons.