- Release Notes
- Overview
- Getting Started
- Marketplace Vendors
- Marketplace Customers
- Publishing Guidelines
- Publishing Guidelines for Ready-to-go Automations
- Publishing Guidelines for Solution Accelerators
- Publishing Guidelines for Integration Service Connectors
- Security & IP Protection
- Other UiPath Listings
- Node-RED
- Setup
- Teams
- Microsoft Teams Scope
- Create Team
- Create Team From Group
- Get Team
- Get Teams
- Channels
- Create Channel
- Delete Channel
- Get Channel
- Get Channels
- Update Channel
- Chats
- Get Chat
- Get Chats
- Get Chat Members
- Messages
- Get Message
- Get Messages
- Get Message Replies
- Reply To Message
- Send Message
- Events
- Create Event
- Delete Event
- Get Event
- Get Events
- Users
- Get User Presence
- How It Works
- Technical References
- Get Started
- About
- Setup
- Technical References
- Azure Form Recognizer Scope
- Activities
- Analyze Form
- Analyze Form Async
- Get Analyze Form Result
- Analyze Receipt
- Analyze Receipt Async
- Get Analyze Receipt Result
- Analyze Layout
- Analyze Layout Async
- Get Analyze Layout Result
- Train Model
- Get Models
- Get Model Keys
- Get Model Info
- Delete Model
- Connectors
- How to Create Activities
- Build Your Integration
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
Standards for Quality Content
All listings on the Marketplace should meet the following general guidelines:
Guidelines | Details |
Modular and Reusable Components |
|
Configurable Parameters and Settings |
|
Scalable and Adaptable Architecture |
|
Integration Capabilities |
|
Extensibility and Customization |
|
Through these areas, a Solution Accelerator should provide a structured but flexible framework for building an efficient and scalable automation solution. In summary, your Solution Accelerator should promote modularity, adaptability, best practice compliance, and easy integration with systems and applications to facilitate rapid development and deployment of automation.
For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the UiPath products that are used in the automation or that are compatible with your automation, and the role that they play.
Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on UiPath Marketplace without express authorization from the third party.
A Solution Accelerator’s design should implement a separation between the business logic layer (implementation layer) and the application layer (GUI interaction layer, if necessary). This can be achieved directly within the various process workflows or, if reusability is required, by using libraries.
-
This layer is responsible for implementing the core business logic and automation workflows of the Solution Accelerator.
-
It focuses on the specific tasks and processes that the Solution Accelerator aims to automate within a given domain or use case.
-
The business logic layer defines the rules, conditions, and actions required to achieve the desired automation outcomes.
-
It may involve data manipulation, decision-making, integration with external systems, and other processing tasks.
-
This layer is designed to be modular and customizable, allowing organizations to adapt the Solution Accelerator to their specific business requirements.
-
It typically utilizes UiPath automation capabilities, such as activities, workflows, and variables, to orchestrate the automation flow.
-
The application layer serves as the interface between the automation workflow and the GUI (graphical user interface) or API (application programming interface) of the various applications and/or systems participating in the automated process.
-
This layer could handle the interactions with the user interface elements, such as buttons, fields, menus, and dialogs, within the target applications or systems. This layer could also handle the implementation of the application programming interface within the target applications or systems, such as data entry through code communication instead of using the application’s user interface.
-
This layer can include activities and components that enable UI automation, such as screen scraping, data input/output, and navigation. This layer can also include application logic for programmatic implementation of the same controls.
-
The application layer is designed to be adaptable to the specific target application – any updates to APIs or to user interfaces should take place in one spot and then adapt across all implementations of that component.
-
The GUI Interaction Layer should provide flexibility to handle variations in UI elements, screen layouts, and navigation paths.
-
Within the API Interaction Layer, the output of any workflow should be consistent with the workflow's objective. For example, if your workflow is called “Retrieve All Users”, one should expect a collection of User objects to be returned and not a JSON which one would then need to further parse to extract the required user data.
-
Keep API call duration at a minimum by making use of pagination and by applying relevant filters whenever these are implemented by the target API.
A separation between a business layer and an application layer ensures a clear distinction between the automation and process logic versus the application specific details. This enables a modular and scalable architecture where changes in the GUI or API can be managed separately from the core business logic. Easier maintenance, reusability within the Solution Accelerator or transferring to other processes, and customization of the Solution Accelerator is enabled through this separation. The end user of the Solution Accelerator can easily replace the application layer to accommodate any changes in target applications without affecting the underlying process logic. Similarly, the business logic can be modified or extended independently from the application to cater to evolving business needs.
This is the standard Dispatcher-Performer Model. The Robotic Enterprise Framework should be utilized for the implementation of a straightforward transaction-based process.
The Robotic Enterprise Framework is a project template based on State Machines. It is created to fit all the best practices regarding logging, exception handling, application initialization, and others, being ready to tackle a complex business scenario. The template contains several pre-made State containers for initializing applications, retrieving input data, processing it and ending the transaction. All these states are connected through multiple transitions which cover almost every need in a standard automation scenario. There are also multiple invoked workflows, each handling particular aspects of the project.
The Dispatcher and Performer model is a pre-designed solution to separate the two main stages of a process by placing a queue in between. This way, the production of transaction items is entirely independent from their consumption. This asynchronism breaks the time dependency between the Dispatcher and the Performer.
In this standard approach, a Dispatcher is an automation to load data into a UiPath queue. It extracts data from one or multiple sources and uses the same to create queue items for Performer robots to process. Information is pushed to one or more queues allowing the dispatcher to use a common format for all data stored in queue items. This data can then be processed in an automation later, the Performer. The Performer can process the data as needed as queue items are processed one at a time. It uses error handling and retry mechanisms for each processed item. A major advantage of the performer is its scalability (multiple performers can be used with a single queue).
Most of the processes working with documents have in common their requirement to also "understand" their content. Hence, a dedicated framework specialized in document understanding has been put in place – the Document Understanding (DU) Process Framework.
This framework is essentially a UiPath Studio Project template based on a typical document processing flowchart. The process provides logging, error handling, retry mechanisms, and all the methods that should be used in a DU workflow. The workflow has an architecture decoupled from other connected automations:
-
It does not matter where the files to be processed come from or what triggers the execution – this is the responsibility of an upstream process.
-
It does not matter where the extracted information should be used – this is the downstream process's responsibility.
-
The framework’s architecture is common for both attended and unattended robots:
-
Document understanding logic (digitization, classification, data extraction)
-
Human-in-the-loop logic (validation) using Action Center for unattended robots, or a local Validation Station for attended ones
As a result of these mechanisms and architecture, the great majority of automations using Document Understanding typically combine a Dispatcher-Performer model with a Document Understanding framework in between:
-
The Dispatcher gathers documents to be processed from the upstream application or system.
-
The Document Understanding Process extracts the necessary information from each document one at a time with scalability because of the Dispatcher method.
-
Finally, the Performer utilizes the extracted data from the document to complete the process.
This architecture consists of Dispatcher – Performer - Finalizer processes with human in the loop, or Long-Running Workflow, process somewhere in the middle. The standard template for longrunning workflows is the Orchestration Process Template. Long-Running workflows have best practices that need to be followed to support service orchestration, human intervention, and long-running transactions in unattended environments.
This architecture is utilized when human intervention is needed to approve or monitor the automation. As a result, any flows after Action Center tasks must account for both acceptance and rejection.
Other architectural decisions can exist and be appropriate based upon the automation needs:
-
A finalizer can always be considered for any cleanup needed within a process.
-
A reporter that is run infrequently or ad-hoc can be considered to send automation statistics to the necessary stakeholders
-
Extract, Transform, and Load (ETL) processes could combine data from multiple sources into a large central repository.
-
Other automation frameworks such as the UiPath Attended Framework can be considered if applicable to the process.
It’s necessary to follow these best practices when developing any UiPath process for a Solution Accelerator:
-
Follow the out of the box Workflow Analyzer rules. When analyzed with this tool, your project should raise minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
-
There should be no hard coded delays.
-
No activities should have default names.
-
No two activities should have the same name within a workflow.
-
Arguments need to follow the in_, out_, and io_ naming convention.
-
Deeply nested activities should not exist and should be considered a strong argument for dividing the workflow into smaller components .
-
-
Before starting the development, thoroughly analyze the process requirements and design a solution that addresses the specific needs. Break down the process into smaller tasks and identify dependencies to ensure a clear and efficient workflow.
-
Identify reusable components or workflows that can be easily maintained and reused in other projects and separate them from an early stage. This modular approach improves reusability, simplifies debugging, and promotes scalability.
-
Implement robust error handling mechanisms to gracefully handle exceptions and failures. Use try-catch blocks and provide informative error messages to aid in troubleshooting and enhance the stability of the process.
-
Errors should be specific and display a relevant error message. A null pointer exception should not be thrown if a string should be populated but isn’t as a result of an application’s return value – the exception should be classified as a business rule exception caused by the application.
-
-
Incorporate configurable settings in your process, such as input parameters, to allow flexibility and adaptability. This enables users to easily customize the process based on their specific requirements without modifying the core workflow.
-
Validate inputs to ensure they meet the required criteria and handle exceptions for invalid or unexpected data. Implement proper data handling techniques, such as data cleansing and transformation, to ensure accurate and reliable processing.
-
Incorporate logging mechanisms to capture relevant information during the execution of the process. This helps troubleshooting and provides valuable insights for process optimization. Use debugging tools to identify and resolve issues efficiently.
-
Logging mechanisms for reporting and UiPath Insights should also be considered.
-
-
Thoroughly test the process to ensure its functionality and reliability. Use test cases and data to validate the expected outcomes and handle edge cases. This helps identify and fix any errors or inconsistencies before deployment.
-
Consider using UiPath Test Suite and providing test workflows for your automation.
-
-
Regularly review and enhance your processes based on feedback, evolving requirements, and technological advancements. Continuously seek opportunities to optimize the process, improve efficiency, and incorporate new features or functionalities.
It’s necessary to follow these best practices when developing any UiPath Library for a Solution Accelerator:
-
Follow the out of the box Workflow Analyzer rules. Your project should be able to be run against Workflow Analyzer and have minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
-
There should be no hard coded delays.
-
No activities should have default names.
-
No activities should have the same name within a workflow.
-
Arguments should NOT follow the in_, out_, and io_ naming convention as those arguments will appear as properties when the Library is being created. The default workflow analyzer rule for invalid argument names can be ignored while creating a Library.
-
Deeply nested activities should not exist and should be considered for dividing the workflow into smaller components.
-
-
Any UI interaction should occur only through Object Repository.
-
Break down your library into smaller, modular components that focus on specific tasks or functionalities. This promotes reusability and allows for easier maintenance and updates.
-
Supply comprehensive documentation for your reusable library, including usage instructions, input/output descriptions, and any dependencies or prerequisites. Clear documentation helps users understand how to effectively use the library.
-
Error Handling: Implement robust error handling mechanisms within the library to handle exceptions and failures gracefully. Use try-catch blocks and supply informative error messages to aid in troubleshooting.
-
Errors should be caught within the processes of the Solution Accelerator and not processed within the Library
-
Any business exceptions should throw a business rule exception. Any application exceptions should throw a system exception
-
-
Confirm inputs and handle edge cases to ensure the library functions correctly and prevents unexpected errors or undesired outcomes. Proper input validation enhances the reliability and stability of the library.
-
This applies to any API automation output as well.
-
-
Thoroughly test the process to ensure its functionality and reliability. Use test cases and data to validate the expected outcomes and handle edge cases. This helps identify and fix any errors or inconsistencies before deployment.
-
Consider using UiPath Test Suite and providing test workflows for your automation.
-
-
Regularly review and update your library to incorporate feedback, address bugs, and enhance functionality based on evolving requirements. Continuous improvement ensures that the library remains relevant and effective over time.
-
When updating libraries, design your next update with backward compatibility in mind.
Non-breaking change: Extending a library with a new workflow.
Potentially breaking change: Adjusting an existing workflow.
If unsure, test the backward compatibility with an intermediary release and if needed, move the update to a new workflow or library which could be separately consumed by only those processes requiring the update. In time, the old workflow can be deemed obsolete.
- Standards for Solution Accelerators
- 1. Layered Architecture
- 2. Business Logic Layer (Implementation Layer)
- 3. Application Layer
- Standard Architecture Types
- Transactional / Queue Based Processes
- 2. Document Understanding Processes
- 3. Transactional Processes with Action Center
- 4. Further Architectures
- Process Best Practices
- Library Best Practices
- Example