RPA General GuidelinesSummary Introduction The purpose of RPA (Robotic Process Automation) general guidelines is to establish guidelines and standards that optimize the implementation, management, and maintenance of RPA solutions. These guidelines aim to: Ensure Efficiency: By following the RPA guidelines, organizations can streamline RPA development processes, reduce implementation time, and maximize the efficiency of robotic processes. Enhance Reliability: RPA guidelines help in building reliable and robust RPA solutions that minimize errors and ensure consistent performance across various tasks and scenarios. Facilitate Scalability: Implementing RPA guidelines enables RPA solutions to scale effectively to accommodate changes in business requirements, increasing the adaptability and longevity of the automation. Ensure Compliance: Adhering to RPA guidelines s ensures that RPA implementations meet regulatory and compliance standards, mitigating risks associated with data security and privacy. Promote Collaboration: RPA guidelines encourage collaboration between business stakeholders, RPA developers, and IT teams, fostering alignment of automation initiatives with organizational goals and objectives. Overall, the purpose of RPA guidelines is to drive successful RPA adoption, optimize automation outcomes, and deliver tangible business value to organizations. Related Links Application Assessment Application Assessment entails analyzing the software intended for automation and collecting the necessary information for constructing the SDD. While developers typically perform this task, there are instances where the business analyst responsible for project documentation may also conduct it. Prior to initiating any development activities, the developer should examine the Preliminary Process Assessment (PPA) to verify if the underlying applications have been encountered previously. The PPA must specify whether the underlying applications have already been identified or not. Following set of rules need to be applied, where the application assessment is required: It is imperative to consistently utilize the most recent version of the Application.Whenever feasible, subject matter experts (SMEs) should collaborate with developers to conduct the Application Assessment in the Application Production environment, distinct from the <<Tool Name>> Production database. This ensures that the design does not require rework during development. In cases where access to the Production environment for the underlying application before development is unattainable, it is essential to reevaluate all assumptions made during this stage once development begins, documenting any changes in the SDD. Always conduct the Application assessment with SMEs. Always make detailed notes (and capture screenshots when feasible) to identify which aspects of the application might pose challenges for automation, and which do not. Always pose probing questions such as: What are the inputs and outputs? Are there any mandatory formats? What are the operational impacts of data errors? Are there any unexpected downtimes? What are the IT Policies related to the underlying application? What are the operating hours for the underlying application? (Are there any scheduled downtimes?) For Example: The above screenshot looks straightforward to automate, however there might be some rules applied within the code that are not obvious when looking at it. Examples of these include but are not limited to. Number of retries allowed for the entry.If the input is case sensitive or not Does the form initiate any popup windows? Are keystrokes/hotkeys allowed on the form? These and the other “hidden” information should be supplied during the walkthrough by SME or other qualified personnel. During the walkthrough of the process the following additional information should also be noted Application NameApplication Type Application Version Application Classification Responsiveness Number of screens to automate. Application Design consistency Application Complexity Does the application have TEST/UAT environment? Any additional system requirements (<<Machine specific>>) 2. Activity Design Activities is the structure used to build the solution for an application. It is crucial to select the optimal solution for the project at hand, as inefficiencies and confusion may be instilled by selecting the wrong design. Always include the main activity and its associated sub-activities to effectively perform the task, enabling the reuse of sub-activities. For Example: 2.1 Global Objects Global objects should be treated in a similar way as Modules in Programming – software components or parts of the program that contains one or more routines. With the difference being, these routines contain business logic, instead just focusing on creating a functionality which will allow setting up business logic. Below is the object list, but this is not a defined or maintained list. 2.2 Activity Utilization To ensure good performance over time and quicker development lead times, activity reusability is paramount. Providing a detailed description while creating activity will expand on reusability by allowing greater knowledge of what the activity does before calling on it. The recommended activity nesting level is 2. This depends on the customer logic and the complexity. To put simply, an object should be used to interrogate the Application, take out some data, and give it back to the process to manipulate. As per the above diagram, the flow of the information should be: Main Activity calls the Sub-Activity.Global Object interrogates application for data (based on Input from the Process) for e.g. Universal Application Connector Object reads data from Application Screens/Layers Object passes the data back to the main Activity for further manipulation. Including business process logic in main activity removes the possibility of re-using it for another automated process, increasing the amount of work required to create an automated solution. This leads to duplicating functionalities and a steady performance decrease of the automation solution. 2.3 Naming Convention 2.3.1 Project Naming Give easier to understand what the project does by giving more description. For e.g. 2.3.2 Activity Naming Change Activity names so that they are easier to understand what the activity does and create separate folder as per the functionality. For e.g. 2.3.3 Global Objects Naming Change Global Object names so that they are easier to understand what the object is for and create separate folders as per the functionality. For e.g. 2.3.4 Global Variables and Local Variables Naming Name the variables (Global/Local) based on the subject area, so that the variable name clearly describes its purpose. Avoid using the same name in the automation twice. Choose appropriate scope for the variables without duplicating. Recommended that naming of the variables should not be longer than a set of number characters (approx. 20 to 30 in length respectively). It is recommended to abbreviate longer words, as they make it difficult to monitor during debugging, especially if the first part of the name is same for 2 variables. Make sure all the variables follow the naming convention. Also, the names of the variables start with “var”. For e.g. Camel case: the Camel case convention specifies that each word in the middle of the variable name begins with capital letter, with no intervening spaces. Always delete unused variables. Try avoiding default variable values. 2.3.5 Comments To ensure clarity for developers or configurators regarding the purpose of each process or workflow, commence each activity with a comment. This comment provides a brief explanation for why a particular process or workflow is created. To add a comment, right-click on the component and select "Add a Comment" to write a specific description. Please check below: 2.3.6 RPA HUB A consistent pattern should be followed while defining the RPA HUB components as well. 2.3.6.1 Bot Process Configuration Name the bot process configuration with a specific name that pertains to the use case and is uniquely identifiable. For e.g., 2.3.6.2 Robots Ensure proper naming conventions for the machines defined in each environment. For e.g. Development: DEV_ <Machine Name> Test: TEST_<Machine Name>_<Robot ID> Production: PROD_<Machine Name>_<Robot ID> 2.4 Work Queues Strongly recommended to use work queues for transactional processes. Naming Convention: Follow proper naming convention which defines the purpose of the queue. For e.g., ShippingManagement_Queue.Set a unique reference value while adding a new item into the queue. Enable auto retry with a retry value greater than zero to reattempt items that have failed due to a System Exception. Always set the priority for the items that have an SLA. Else, the items will be served in First In, First Out order. Utilize the “PickWorkItem” component within a While Loop to process all work items unless a specific work item needs to be picked. “PickWorkItem” defaults to selecting work items in FIFO (First In, First Out) order. Always ensure to verify that the “WorkItemID” output of the “PickWorkItem” component is not Null or Empty before proceeding with further processing. 2.5 Credentials 2.5.1 Robot Credentials Required to start an interactive windows session on an unattended robot. These are defined in Credential Set in RPA HUB. Proper naming should be followed so that these can be easily identified. For e.g., <Robot ID>_<Workstation Name> 2.5.2 Application Credentials Always store the application credential in the “Application Credentials” tab in RPA HUB. Never store the application credentials in any static variables or process parameters. The scope of credential-related variables, such as username and password, should be confined to where they are required. Never extend the scope of these variables beyond their necessity. Secure String The output of “GetApplicationCredential” is a secure string datatype. This is a special class in the .NET Framework that represents text that should be kept confidential. Once a SecureString is retrieved, it should be used to log into the applications. The credential should not be used for any purpose other than the intended one. 2.6 Process/Shared Parameters Always define the configurable values in the process parameters and if the same are used across multiple projects define in the shared parameters. For e.g. shared drive paths / email addresses etc. If the parameter has sensitive content, then enable “Sensitive” flag, so that the content is not visible. 2.7 GracefulStop Graceful Stop functionality provides a capability for robots to exit the automation smoothly. You can define a secure termination point within an automation process. It also enables you to perform clean-up tasks such as closing in-use applications. However, it is recommended to have graceful stop in case of transaction workflows. Instead of stopping the robot abruptly, in middle of the transaction, bot can be stopped gracefully without interruption to the current transaction. Navigation in RPA HUB: All > Robotic Process Automation > RPA HUB Workspace > On the lists tab > Build > Bot Process > Stop Process > (Optional) To terminate the bot process gracefully, enable the Graceful Stop toggle switch. How to use in Studio: For complete code, please refer to the template in studio. 2.7 Maintain tidiness In the workflow, ensure to shut down the target applications (browsers, apps) after the robots interact with them. Leaving them open can consume machine resources and potentially disrupt subsequent automation steps. Prior to publishing the package, conduct thorough code quality checks. Add comments at activity level. Remove unreferenced variables, components, activities etc. The project name carries significance as it determines how the process will be identified on the RPA HUB. Therefore, it should adhere to our internal naming conventions. Additionally, the project description is crucial as it aids in distinguishing between processes. Hence, it is advisable to select a meaningful description. 2.8 Error Handling RPA utilizes an exception handling mechanism akin to those found in modern programming languages, primarily centered around the Try Catch activity. When combined with the Throw activity, it facilitates a refined error handling process. During the execution of an automated process, two categories of exceptions may arise: expected or unexpected. These distinctions prompt two approaches to handling exceptions—either by incorporating explicit actions that are automatically executed within the workflow or by elevating the issue to a higher level for resolution. Business Exception: These are expected exceptions. These incidents can arise when a specific aspect of the automated process deviates from the anticipated flow. For instance, a robot may encounter a situation where it is required to download an invoice from an email, but no attachments are present in the email. Treating a business exception the same way as a system exception by retrying may not be advisable, as it often necessitates external intervention for successful resolution. System Exception: All runtime exceptions, excluding those specifically categorized as System Exceptions, fall under the umbrella of System Exceptions. These may also be referred to as Application Exceptions (AE), although the underlying concept remains consistent. It is essential to establish effective handling procedures for these exceptions, as they have the potential to disrupt the process flow and lead to failure. Exception management can be achieved by encapsulating vulnerable code within Try Catch blocks, enabling appropriate handling of exceptional situations. At a higher level, the primary process diagram should outline comprehensive corrective actions to address generic exceptions and uphold system integrity. “Unattended Transaction workflow” or “Unattended Non-Transaction workflow” or “Attended workflow” template has this exceptional handling mechanism in place. How to Navigate: Open RPA Desktop Design Studio > Create Automation >Select an Automation Type (Unattended Automation/Attended Automation) > Type Name and Description>Click on Next > Select a Template Try Catch: Every activity that has the potential to throw an exception should be encompassed within the Try block of a Try Catch activity. Example: When the bot process is not assigned and the component “GetProcessParameters” is executed. Throw Error: The Throw Error component is employed when the desired action is to deliberately raise an exception. This component takes exception type and the exception message as an input. Ideally, this should be used in Business Rule exceptions scenarios that are drafted in PDD (Process Definition document). The Business exceptions can be stored in any external input file depending on the use case requirement. 2.9 Logging Employing Log activities to track the progression of a running process is vital for overseeing, diagnosing, and debugging. Messages should furnish comprehensive details to precisely pinpoint a situation, encompassing transaction ID and state information. As an RPA guideline, logging should be used: At the beginning and end of each activity, logs can be stored locally on the machine to prevent excessive logging to the RPA HUB.If it is a transactional process, start and end of each transaction should be written to the RPA Hub using “Log” component. Every time an exception is captured in a Try Catch. Whenever a Business Rule exception is raised. When data is read from external sources, for example data fetched from excel etc. Tracking execution logs are at 2 levels in RPA HUB: Storage at Instance and Robot machine level Logs stored by default at instance level are Errors. Logs Stored at machine level can be error or verbose (information) and can be stored as DB file or flat files 3. General Guidelines Always remove unused resources like Plugins, User Plugins, Activity Variables, Global objects and Components before publishing the automation.Always clear the break points before publishing. The customer should maintain the versions of the iBot or use a version control tool, such as GitHub, for storing the iBot files. Ensure that the same resolution used during development is utilized for both UAT and PROD environments. For Unattended automations use the “ChangeResolution” component from studio to set the 'Display Resolution' for the machine. For Attended automations use the 'Screen Resolution' option available on RPA Hub Ensure each out port is connected as applicable. Ex: WaitForCreate False port should be linked to exception handling or retry mechanism as applicable. Return Success / Failure for each activity by using End Parameters. Success / Failure can be checked before proceeding to the next activity. Before looping, check if the loop input object is nothing or not. During looping, ensure not to connect to END of activity within the Loop and add Break component if required within the loop and not outside of loop. Use “WaitForCreate” or “IsCreated” before performing some action on Screen / Element to ensure that Screen / Element is created.Use the Retry mechanism using variables instead of making automation to go on an infinite loop by passing control back to initial component wherever applicable. For E.g. If some application is not launched properly / Not navigated to expected screen etc., retry the logic only for few times like 3 - 5 times instead of making automation to loop through till required screen is found. Ensure the system state is same before and after executing the automation.Make sure to close all the applications / excels/ word etc. which are opened by automation after execution of automation as well. Ensure proper exception handling to close applications in case of exceptions. While using loops, ensure to validate the conditions and it doesn't go on infinite loop. It is not recommended to use the back port connection as it leads to infinite loop in stack overflow exception When using Terminate component make sure to use "Mark As Error" property for errors.Use “WaitForCreate” component and validate the result instead of using "Delay Before execution" property. Before running the process from the studio, ensure that you connect to the instance and assign the bot process and robot to prevent any potential issues with RPA Hub components. Instead of employing a static delay in “WaitForCreate”, utilize parameters to configure the delay, such as “Max_WaitTime”, “Medium_WaitTime”, and “Min_WaitTime”. For unattended automation, avoid utilizing components located under “MessageBox” in the Toolbox when running automation from the runtime in a virtual machine (VM). These components halt execution and await user input or action, rendering them unsuitable for unattended automation scenarios. Note: “MessageBox” components can still serve useful purposes during bot design, such as for output checking or input passing purposes. 4. Pre-requisites: Points to ensure while connecting to a robot:The Windows machine or the VM should always be in 'on' state to run Unattended robots. If connected via Citrix, the Windows machine or the VM should not go to sleep mode. Remote desktop to Windows machine access must be provided to the developers. Disable legal notices if enabled on the VDIs. RPA can handle only login related screens such as “Ctrl+Alt+Del” screen and Username and Password input screen. RPA cannot handle Legal Notice as this is an organization specific setting. Therefore, it needs to be disabled through the Active Directory Organizational (AD OU) policy. Idle timeout setting must be disabled for the VDI pool. Communication with Instance host must be whitelisted. Recommend to re-boot the machines once in a week. The System property "glide.cometd.websocket.enabled" should be set to "true" in the instance. Ensure that the OLEDB drivers are installed on the Developer/VDI machine if the Excel component is used.