- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- Control Flow
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- Logging
- The Diagnostic Tool
- Workflow Analyzer
- About Workflow Analyzer
- ST-NMG-001 - Variables Naming Convention
- ST-NMG-002 - Arguments Naming Convention
- ST-NMG-004 - Display Name Duplication
- ST-NMG-005 - Variable Overrides Variable
- ST-NMG-006 - Variable Overrides Argument
- ST-NMG-008 - Variable Length Exceeded
- ST-NMG-009 - Prefix Datatable Variables
- ST-NMG-011 - Prefix Datatable Arguments
- ST-NMG-012 - Argument Default Values
- ST-NMG-016 - Argument Length Exceeded
- ST-NMG-017 - Class name matches default namespace
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DPB-010 - Multiple instances of [Workflow] or [Test Case]
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-021 - Hardcoded Timeout
- ST-DBP-023 - Empty Workflow
- ST-DBP-024 - Persistence Activity Check
- ST-DBP-025 - Variables Serialization Prerequisite
- ST-DBP-026 - Delay Activity Usage
- ST-DBP-027 - Persistence Best Practice
- ST-DBP-028 - Arguments Serialization Prerequisite
- ST-USG-005 - Hardcoded Activity Arguments
- ST-USG-009 - Unused Variables
- ST-USG-010 - Unused Dependencies
- ST-USG-014 - Package Restrictions
- ST-USG-020 - Minimum Log Messages
- ST-USG-024 - Unused Saved for Later
- ST-USG-025 - Saved Value Misuse
- ST-USG-026 - Activity Restrictions
- ST-USG-027 - Required Packages
- ST-USG-028 - Restrict Invoke File Templates
- ST-USG-032 - Required Tags
- ST-USG-034 - Automation Hub URL
- Variables
- Arguments
- Imported Namespaces
- Coded automations
- Introduction
- Registering custom services
- Before and After contexts
- Generating code
- Generating coded test case from manual test cases
- Trigger-based Attended Automation
- Recording
- UI Elements
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Automating Citrix Technologies
- RDP Automation
- VMware Horizon Automation
- Salesforce Automation
- SAP Automation
- macOS UI Automation
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Extensions
- About extensions
- SetupExtensions tool
- UiPathRemoteRuntime.exe is not running in the remote session
- UiPath Remote Runtime blocks Citrix session from being closed
- UiPath Remote Runtime causes memory leak
- UiPath.UIAutomation.Activities packages and UiPath Remote Runtime versions mismatch
- The required UiPath extension is not installed on the remote machine
- Screen resolution settings
- Chrome Group Policies
- Cannot communicate with the browser
- Chrome extension is removed automatically
- The extension may have been corrupted
- Check if the extension for Chrome is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and Incognito mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Chrome
- Chrome Extension on Mac
- Edge Group Policies
- Cannot communicate with the browser
- Edge extension is removed automatically
- The extension may have been corrupted
- Check if the Extension for Microsoft Edge is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and InPrivate mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Edge
- Extension for Safari
- Extension for VMware Horizon
- Extension for Amazon WorkSpaces
- SAP Solution Manager plugin
- Excel Add-in
- Test Suite - Studio
- Troubleshooting
Coded Workflow
- Workflows have a visual design interface.
- Coded workflows have a code-based interface.
Additionally, you can integrate coded workflows with low-code activities and workflows, and use a hybrid automation approach. This enables you to combine the benefits of code-based automation with the visual design of low-code components.
Coded automations feature a structured design with namespaces, helper classes, and entry point methods. The framework of coded automations allows you to write the automations using the C# programming language.
Follow the detailed structure of a coded automation as described in the following sections.
When you create a coded automation, a namespace is automatically generated using the name of the Studio project. For instance, if your Studio project is named "My project", the namespace for all coded automations will be "Myproject".
Additionally, if you create a coded automation inside a folder in your Studio project, then the namespace will be the name of the project and the name of the folder. For instance, if your Studio project is named "My project", and the folder is named "place", then the namespace will be "Myproject.place".
CodedWorkflow
partial class from the
UiPath.CodedWorkflows package. This class gives the automation access to
necessary interfaces for services (equal to activity packages), based on the
installed activity packages in your project.
CodedWorkflow
partial class, creating
a relationship of type CodedAutomationExample : CodedWorkflow
. This
means that the CodedAutomationExample
class inherits attributes,
methods, and functionality from the CodedWorkflow
class.
Essentially, it can access and utilize the features defined in the
CodedWorkflow
class, which provides a foundation for the coded
automation, making it easier to build upon and customize the automation's behavior.
CodedWorkflow
class is declared as a partial class, allowing you
to extend its functionalities by defining the same partial
CodedWorkflow
class in a code source file. This way, you can
add new fields and methods to further customize the behavior of your coded
automations. You can use this approach to implement a Before and After
interface, specifically for coded test cases.
CodedWorkflow
partial class inherits the
CodedWorkflowBase
class.
CodedWorkflowBase
class holds the built-in
functionalities that a coded automation inherits. This class contains methods and
specific properties for managing workflow instances, runtime access, handling
service containers, and configuring environment contexts. The
CodedWorkflowBase
class also offers another separate method for
logging that you can customize yourself.
CodedWorkflowBase
class.
CodedWorkflowBase
methods in the table below:
Method | Description |
---|---|
ICodedWorkflowServices services Note: We recommend you to use the the
Log , BuildClient , and
RunWorkflow methods through the
services class and their corresponding
services, instead of using them as standalone, readily available
methods.
| Provides access to the available services for coded workflows,
such as:
|
serviceContainer(ICodedWorkflowServiceContainer) Note: This has been replaced by
ICodedWorkflowServices services . If you
continue to use this syntax, you get a warning pointing you to
use the new services.Container syntax.
| Provides access to the dependency injection container that is specific to the current coded workflow. This container, known as the service container, allows you to retrieve instances of services that have been registered within it. |
GetRunningJobInformation() | Retrieves information about the currently running job within the
context of the coded workflow. The method accesses the
RunningJobInformation property of the
executorRuntime object, that holds information
about job status, progress, parameters, and timestamps.
|
Log(string message, LogLevel level =
LogLevel.Info, IDictionary<string,
object> additionalLogFields =
null) | Adds additional log fields to log messages with specified attributes. |
RunWorkflow(string
workflowFilePath, IDictionary<string,
object> inputArguments = null, TimeSpan?
timeout = null, bool isolated = false,
InvokeTargetSession targetSession =
InvokeTargetSession.Current) | Provides a structure to execute a workflow within the context of the given workflow runtime. It can set parameters, handle potential isolation, and initiate workflow execution. The returned task provides the results of the executed workflow, including its output and input/output arguments. |
RunWorkflowAsync(string
workflowFilePath, IDictionary<string,
object> inputArguments = null,
TimeSpan? timeout = null, bool isolated = false,
InvokeTargetSession targetSession =
InvokeTargetSession.Current) | Provides a structure to execute a workflow asynchronously within the context of the given workflow runtime. It can set parameters, handle potential isolation, and initiate workflow execution. The returned task provides the results of the executed workflow, including its output and input/output arguments. |
DelayAsync(TimeSpan time) and
DelayAsync(int delayMs) | Suspends execution for a specified period of time asynchronously. |
Delay(TimeSpan time) and Delay(int
delayMs) | Suspends execution for a specified period of time. |
HttpClient BuildClient (string scope =
"Orchestrator", bool force = true) | Builds an HTTP client with a specified scope and access token. |
RegisterServices (ICodedWorkflowsServiceLocator
serviceLocator) | Registers services (activity packages) to the coded workflow's service locator. You can override it when you want to inject custom services into the dependency injection container. Learn how to create and use custom services (coded activity packages) here. |
Execute()
and is attributed as either Workflow
or TestCase
. You can change the name of the method, as long as you
attribute it to either Workflow
or TestCase
.
Execute()
method ([TestCase]
or [Workflow]
) inside a file, that inherits the Coded
Workflow
class.
In this method, you can add input and/or output arguments, which are equivalent to In, Out or In/Out arguments in low-code automations. Go through the Working with Input and Output arguments tutorial to learn how to use arguments in coded automations.
Execute()
method.