Code Standards and Folder Structure in a Project

I'll do my best to present information on RPA Best Practices in this post that is based on study and understanding. This will assist you in comprehending the RPA Coding Standards and Best Practices that each RPA Developer should adhere to when creating BOTs. It aids in enhancing the entire software system's quality and the code's maintenance.

The information we are providing is general in nature and will apply to all RPA tools, as seen in the list below.

• Automated Coding Standard for Anywhere

• UiPath coding convention

• Standard for Blue Prism Coding

• Standard Power Automate Coding

What best practices exist for RPA?

Following are the some of the best practices to be followed while working with RPA −

Split the Assignment

Split an assignment into many related tasks in order to grasp the code quickly in the event that updates or debugging are required, the job shouldn't exceed 400 lines. Make careful to integrate any subtasks you create with the main task. As an illustration, consider the following subtasks− reading configuration files, logging into applications, creating folders, etc.

• Bot Exception scenario

• Folder structure with share drive path

• Application Name, Application Path

• Debug Mode – Keep debug flag to enable to disable message boxes

• Email Address

• Email Subject

Configuration File

Configuration File to be Used to prevent any code modifications when the bot is transferred into the production environment, make sure you are producing and utilizing data from the configuration file. All the information that could change in the future should be in your configuration file. The information shown below should be in your configuration file.

• Exceptional circumstance for bots

• Folder organization and shared drive route

• Name and location of the application

• Keep the debug flag enabled to turn off message boxes in the debug mode

• Contact Email

• Subject of Email

There should be an appropriate naming convention

To simplify complicated projects and make maintenance easier, the naming standard for variables and activities is crucial. Make sure you provide the tasks, variables, or subtasks the right names when creating them. You should appropriately declare the names of your job and variables as shown below.

XYZ MasterTask version, Process Name Task Name
XYZ SAPLoginTask v01
Name of the variable− strCustomerName
numAccountNumber
dtLoanDate

Remark and Log

The benefit of adding adequate comment and log entries is that they make it easier to comprehend the flow of the created code without having to open every command in the job.

To ensure clarity, every remark and log should be correctly formatted and grammatically sound. To keep track of information and to identify when a task began and concluded, a log should be added wherever action is taking place.

• Use the hash symbol, slashes, or asterisks to create a comment box.

• Use one brief comment to clarify a premise, a problem, or a line of reasoning.

• To ensure clarity, give useful commentary.

Nothing should be hard-coded in the code

To prevent future code modifications, make sure there are no hard−coded variables or information in the code. Instead, read from the configuration file. At all costs, avoid storing sensitive or client data in code, variables, or configuration files; instead, preserve it safely. To prevent any security threads, keep in encrypted or credential locker mode.

Utilizing Reusable Parts

To save time for other developers or in other projects, be careful to create any common activities as reusable components.

As an illustration, routine actions like creating folder structures, reading configuration files, and logging into applications should be used by other developers or other processes only after making the barest of alterations inside the organizations.

Structure for Robots

Following is the suggestable structure of files in RPA.

├── bin
│  └── # Place your external binaries & executable in this file
├── config
│  └── conda.yaml
├── devdata
│  ├── env.json
│  └── # A place for your development phase test data
├── .gitignore
├── libraries
│  └── # Collect your library files here
├── LICENSE
├── output
│  └── # Having a standard place for outputs is always good
├── README.md # Mark−down readme in the root is a good place to describe what the thing does.
├── resources
│  └── #
A common style in Robot Framework is to place your keyword implementations in one location
├── robot.yaml # The must−have configuration file in the root
├── tasks
│  └── # Another common style in Robot Framework is to place your robot task implementations in one location
├── temp
│  └── # Always good to have one standard place for temp files
└── variables
  └── # A place for your variable definitions makes these easy to find and manage

Categories

Using the RPA platform, anyone who is not an IT specialist may create an RPA BOT. Although this may sound like a standard sales pitch for RPA technologies, why does RPA have such a high failure rate? Why is it so difficult to extend the benefits of RPA? Why does the overall IT environment's use of RPA BOTs still pose a security risk? In order to guarantee a high−quality BOT conclusion, the industry took these inquiries extremely seriously and got to work on developing a standard framework.

The majority of these standards and best practices, regardless of RPA products, may be grouped into the FIVE categories listed below −

• Readability − The simplicity of the code's logic and naming conventions, the absence of trash code, and other factors make it easy to grasp.

• Configurability − Makes it simple to manage adjustments and BOT calibration by incorporating adjustable elements like performance parameters, URLs, File &Folder paths, Email Ids, Credentials, Business Rule Threshold Parameters, Log Messages, Email Formats, etc. and a generic design.

• Reliability − Achieving a high degree of accuracy with a low exception rate by incorporating components such as effective exception handling, the best feasible interaction approach, memory leakage prevention, and properly constructed auto−recovery and auto−healing systems.

• Security − Security is a measure of freedom from both known and unknowable risks, and it includes components like credential management, authorization & authentication, and the storage & exchange of corporate data.

• Performance − Lowest possible average handling time through effective delay management, parallel execution, use of the best interface style, effective memory management, and effective business logic setup.