Guidelines for starting RPA Project

Hi All,

I have to automate an application for a Client. Prior actual implementation , client wanted to have a POC kind of something. That I created just like a plain sequence with hard coding values.

Demo was successful , now I have to develop the bot for production.

My ask here is can someone help me with best practices to follow while developing an RPA Project.

Below are some I am going to follow , please add to the list .

  1. No Hardcoding within workflows.
  2. Relevant Name to each activity for debugging purpose.
  3. Naming arguments and variables properly.
  4. Well defined scope of variables.
  5. Divide the workflow into smaller pieces for easy debugging purpose.
  6. Having a config File.
  7. Prior starting the bot , kill all applications required.
  8. Logging of events.
  9. Exception Handelling and recovery mechanism.
  10. Use of RE Framework.

Please add to the list or if you have guidelines please share.

2 Likes

Hello @mukeshkala
*Use proper annotations
*Remove unused variable and arugment
As well as see orchestrator guidelines

Thanks

5 Likes

Have a few comments on this point. Sometimes less is more. Keep it simple and organized. Don’t create a Labyrinth of workflows, where you invoke a workflow and invoke a workflow in that one and so on, unless it is necessary.

Keep re-usability in mind. Many clients and company RPA infrastructures fail at this point. Typically and potentially, systems/applications will be performed in from multiple projects. In a perfectly groomed company RPA infrastructure, you would not actually need to develop any new components but rather just organize the process, nor should you have any issue releasing an update to those re-usable components when something changes with a system/application. - This can be challenging to get right though. I believe the move to Libraries will probably be a good answer.

Interacting with a system/application web or desktop should have a Login script and a workflow for each individual task that would be performed within the application, and the Login script should be developed in a way that can be invoked from each individual workflow task (ie logging in only if it needs to and attaching to the window). This allows you to simplify your logic by only invoking one workflow to perform the task and the sign on part is handled easily.

This ties in with last point, but create your workflows so no set up work is needed. Like you shouldn’t need to sign out or close out of systems and you shouldn’t need to close or move around files first for it to run. Less set up means you have to think less = better, lazier times :grin: EDIT: I wanted to clarify this point too. Like, if a system is already on a particular screen, it should attach to that screen and continue from there, instead of closing the window, opening it up again, and needing to log in, which I believe works but just doesn’t work as efficiently in the long run, compared to if it simply was able to attach to the existing window and skip many navigational steps.

Check for if a login was invalid, then throw a Business Rule Exception with a custom message. This is important, so you know why you received the failure, and a retry attempt will not be performed. Additionally, catch any invalid input data as Business Rule Exceptions, where a retry attempt will not resolve issue (like wrong column names for example if it requires a file from an end user) - this is not usually needed if the data is consistent or if the code can still read in the data given certain situations.

I have so much more to say, but I don’t want this to get too lengthy, haha.

Regards.

5 Likes

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.