Subscribe

UiPath Orchestrator

The UiPath Orchestrator Guide

2019.10.14

Release date: 11 November 2019

What's New

Long-Running Workflows

This release graduates key features in handling end to end business processes, introducing support for processes that require logical fragmentation or human intervention. With this new functionality, workflow execution can now be suspended and resumed at a later time – not necessarily on the same machine. Among other things, this paves the way for intuitive and easy invoice processing, exception handling and performance reviews. We set the stage for automating complex processes that either rely on the completion of other processes, or require approval or validation, all this with no waste in terms of resources while waiting for process resumption. Learn more about it here.

Don't worry, we've introduced a new project template in Studio called Orchestration Process, and a brand new set of activities that allow the smooth fragmentation of your workflows. Read more about how to build an Orchestration Process and best practices here.

In this scenario, Orchestrator introduces the human in the loop and ensures a smooth management of your fragmented jobs.

The human aspect is handled through tasks which can be managed and completed without obstructing process unfolding. After human intervention is made and task completion takes place, resources are allocated for job resumption, thus ensuring no waste in terms of consumption. Details here.

To facilitate support for long-running workflows, we introduced two new job states which properly illustrate the job progress: suspended and resumed. More about job states here.

A new webhook event is also available for suspended jobs. Learn here all there is to know about this event.

Hierarchical Folders - Preview

Aimed at keeping your RPA deployment manageable and organized no matter the scale, the latest UiPath Orchestrator release introduces the Folders feature. There are now two organizational paradigms available in Orchestrator: Classic Folders and Modern Folders. Through classic folders, full backwards compatibility is maintained for your existing deployment and integrations while enabling you to segregate at the tenant level those divisions of your business that are wholly separate. Moving beyond the classic model, modern folders enable you to easily manage resources, and access to them, through support for hierarchical structuring of your Orchestrator instance combined with the new ability of fine-grained role assignment - your Orchestrator instance can now be structured inline with your corporate structure with each level, or employee, only having access to those resources needed for their role.

The previous experimental Organization Units feature is now fully supported as part of Orchestrator's Folders functionality. You can organize your instance using any number of classic and/or modern folders. Like Organization Units, classic folders are separate, flat structures with no shared Orchestrator entities between them. Modern folders enable you to create hierarchical structures, with users inheriting access to any subfolders of a folder to which they are assigned. User access in modern folders can be managed with greater granularity by creating custom roles and setting the desired permissions on a per folder, per user basis.

Deeper AD Integration

User management challenges brought by large deployments and employee dynamics have been addressed in this release by integrating Orchestrator with Active Directory. Broadly, you no longer need to go through the hassle of directory duplication in your instance, as added AD identities are checked directly against the directory database.

The feature enables you to either grant or restrict access to Orchestrator according to the configured group policies and based on your AD group membership. Manual intervention is limited to adding your groups and configuring access rights for them in Orchestrator; the rest of the process is, you guessed it, automated.

To better fit our new AD integration tool, we revisited user types in Orchestrator. As of 2019.10 we have: local users, directory users, directory groups and robot users. They are all described here.

Queues, Queues, Queues

Scheduling in Orchestrator has been treated to a major overhaul to make everything easier and more intuitive to use. The functionality is now called Triggers and comes along with a couple of new features and improvements. The highlight is that you no longer need to make arrangements to optimize the processing of your queue items. Orchestrator gives you the possibility to trigger a process whenever new queue items are available in your queues. Be reminded, since scheduling is not possible for attended use cases, and modern folders only work for those, this goodie is available for classic folders only. For now. Details here.

This is not all. We implemented a Queue SLA tool which gives you better control over the processing time of your queue items, and helps you assess what resources you need to allocate such that the items are processed in time. Whenever the SLA is in danger of not being met, you are properly notified such that you can make adjustments accordingly.

Individual transaction items from your Queues can now be edited or cloned, enabling you to change the priority or deadline to suit business needs. This feature also enables you to download a JSON file of the transaction data to review and upload it if any changes were needed. More details here.

You now have greater control of the data flowing through your queue items, making further processing and analytics that much easier. When creating a new queue, or editing an existing one, you can upload custom .json schemas for the Specific Data, Output Data, and Analytics Data generated by all future transactions to be validated against, ensuring any successfully processed queue item has a reliable form of data.

Licensing

A much-improved licensing experience awaits, making starting and growing your Orchestrator deployments easier than ever. For internet connected Orchestrators, activating and updating is an instant, one button process. Your offline Orchestrators weren’t ignored in this upgrade, with a simplified offline activation included as well.

More good news is afoot - if Studio is licensed locally, no additional license is consumed in Orchestrator. Furthermore, each time you create a Studio or StudioX Robot, you can specify if it uses an external license or not. Oh yeah, and while we were here we also renamed the Development type of license to Studio, to avoid confusion.

Credential Stores

Lots of good news to report here as we’ve not only expanded and improved the integration of CyberArk with Orchestrator but also added support for Azure Key Vault and a pluggable architecture that enables you to develop your own plugins and use any desired secure store.

Where before you were limited to only one CyberArk vault per Orchestrator instance, and forced to choose using either that or the native database, now vaults are created at tenant level where you can have as many as you need to store different credentials and assets. Additionally, CyberArk vaults can be used together with the native Orchestrator database, giving you control over how and where you store all credentials and assets in your Orchestrator instance.

Azure Key Vault integration is now supported as well, giving you three out-of-the-box options for credential stores with your new Orchestrator. Read more about it here.

Not wanting to limit your options, Orchestrator is ready to accept your custom plugins for any credential store that you want to use. For more details about developing and loading your custom plugin, see here.

User Experience

Orchestrator has a new look and feel, giving it an intuitive design with resources organized to provide a smooth, easy-to-use experience. Have a look at our new look here.

Package Explorer

For a better collaboration between RPA developers and Orchestrator managers, you can now view the graphical representation of any package version uploaded to Orchestrator, just as you do in Studio's Designer panel. You can see which .xaml file is marked as Main for a project, deep dive into any workflow, view a project's dependencies, and look up any activity property and its value. For a better picture of the entire feature, click here.

Feature Flags

In case you were yearning for a different feature configuration for each of your teams, you’ll be pleased to know that in this release we've come up with a feature flags functionality. We made this happen such that you can easily turn features on and off for each of your tenants. For now the following features can be enabled or disabled through this functionality: Monitoring, Queue SLA Monitoring, Tasks.

And while we're at it, you should know we've exposed the odata/Features/UiPath.Server.Configuration.OData.UpdateFeaturesBulk endpoint which allows you to enable or disable features from the API. Please keep in mind that you can only make these changes at host level. Click here to see how to use the functionality in the user interface, and here for the corresponding API request.

Localization

As a continuation of our efforts to reach out to the entire world and make automation a language everyone can speak, the entire platform is now available also in Simplified Chinese, Korean, German, German, Spanish (Spain), Spanish (Latin America), Portuguese (Brazil), Portuguese (Portugal), and Turkish.

Improvements

Starting with this release, the server that hosts Orchestrator requires .NET Framework 4.7.2. More details about software requirements can be found here.

To better support long-running workflows, you can now edit processes while having associated running or pending jobs by default. As a result, the Processes.AllowUpdateWithRunningJobs parameter now only controls whether or not you can remove such processes. More information is available here and here.

Thanks to multiple changes made by our dev team, it is now possible to use 7.x versions of Elasticsearch in conjunction with your on-prem deployment of Orchestrator. Please note that this is possible only starting with 2019.8, and all previous versions of Orchestrator work only with versions up to 6.x.

Creating and managing Assets is now simpler, no more creating single value or robot specific value assets. When creating an asset you now have the ability to add a global value. This global value serves as the default provided to any robot which does not have a specific value assigned to it. Read more about it here.

We all like to have things organized our own certain way. To help you keep your customizations just as you wish, all Orchestrator filters, including the number of items which are displayed per page, are now persisted throughout the app. Moreover, a handy Reset to default button was added for your convenience.

Individual transaction items from your Queues can now be edited or cloned, enabling you to change the priority or deadline to suit business needs. This feature also enables you to download a .json file of the transaction data to review and upload it if any changes were needed. More details here.

To ensure all of your processes are using the latest package version, you can now see all eligible processes when uploading a new package and upgrade any or all of them instantly. See here more details.

To make organizing and finding resources easier in your growing automation deployments, we have now added an editable Description field for Asset and Machine entities.

When performing a command-line installation using the UiPathOrchestrator.msi installer, the bulk of the available parameters can now be passed in a file. See here to learn more.

When deploying a process you can now configure it to start automatically when the user launches their robot agent.

You can now configure your Robot to automatically download processes so that it’s ready to execute whenever you are.

To enable you to easily customize the maximum upload file size in Orchestrator when using Azure blob storage, a new web.config parameter - requestLimits maxAllowedContentLength - has been added. You can view more information on it here.

The first ever version of the Non-Working Days feature allowed you to define one set of non-business days in which your schedules were not triggered. We made it better. You can now create multiple calendars per tenant, each with its own set of dates, such that whatever restrictions you want to impose, they can be granularly controlled. To get one more thing off your chest, we also added the possibility to upload a CSV file containing the dates to Orchestrator, no extra manual intervention required. Find out more. To support the improved Non-Working Days feature, we added new endpoints for Calendars requests. Note that the GetCalendar and SetCalendar endpoints have been deprecated.

The newly added Restart Job feature saves you valuable time by enabling you to quickly run a job from the jobs list. You’ll be glad to know that you can restart any job with a final state – Stopped, Faulted or Successful. The decision to modify the previous settings of the job lies in your hands. Please keep in mind that you can change the job’s input parameters and robots, and that you can’t restart jobs triggered by an agent.

Orchestrator emails have been groomed up and you can now identify your tenant directly from the subject of the email.

We've added support for auto theme in Chrome 76 and above.

We now support Firefox. 69.0.1 and above.

Breaking Changes

  • The Auth.DisableBasicAuthentication parameter was renamed to Auth.RestrictBasicAuthentication.
  • You can no longer make POST requests using cookie authentication. A 400 Empty or invalid anti forgery header token response is received when trying to do so. Please authenticate using a bearer token instead.
  • Performing a GET request to retrieve credential assets now requires use of the $expand parameter on RobotValues in order to return the username in the response.
  • All API calls must now contain an HTTP header providing the FolderId or FolderPath for the desired action. See here for details.

Known Issues

Logging

We dove in head first when announcing the latest logging improvements related to the MongoDB NLog target. In this release, we identified some flaws in the way this target interacts with the current Orchestrator solution, hence we've come up with the following errata and clarifications on the 2019.4.2 release notes and documentation on the subject:

  • We support both read and write operations only when logging to Elasticsearch and the database.
  • The MongoDB NLog target is still compatible with Orchestrator when performing write operations. Read operations do not work. However, due to the large spectrum of potential corner cases, UiPath cannot provide assistance in configuring and troubleshooting the custom targets for write operations.

Beginning with this release, logging using the MongoDB NLog target is not recommended and has been removed entirely from the documentation.

AD Integration

  • Due to various networking or configuration issues, there is a chance that not all domains displayed in the Domain Name drop-down are accessible.
  • It can take up to an hour to update the domain list with newly added two-way trusted domains.
  • Removing a directory group does not remove the license of an associated directory user, even if the group removal unassigns the user from any folder. The only way to release the license is to close the Robot tray.
  • Changes made to AD user/group names are not propagated to Orchestrator.
  • The GetOrganizationUnits(Id) and GetRoles(Id) requests only return folders and roles explicitly set for an auto-provisioned user. The ones inherited from the group configuration can be retrieved through the /api/DirectoryService/GetDirectoryPermissions?userId={userId} endpoint.
  • Same goes for the user interface, where only explicitly-set folders and roles are displayed on the Users page, while inherited ones have a new dedicated location, the User Permissions window.
  • Auto-provisioned users do not inherit alert subscription settings from the parent group, nor do they receive any alerts. In order to have access to alerts you are required to explicitly grant the corresponding permissions to the user.
  • On certain browsers, logging in to Orchestrator using your AD credentials only requires your username, there is no need to also specify the domain. Hence, if the domain\username syntax does not work, try filling in the username only.

Package Explorer

  • Workflows that do not follow UiPath Studio standards are not supported.
  • Packages with UTF-16 encoding are not fully supported. As a result, package dependencies are not displayed for such archives.
  • Opening an empty package in Package Explorer does not throw an error and does not render any display.
  • The performance might degrade if you use the Expand All option with considerably large .xaml files.

Others

  • Upon upgrading your existing Orchestrator instance to v2019.10, certain scenarios occur in which organization units are not properly displayed as the equivalent classic folders, thus rendering Orchestrator unusable. Specifically, if you had multiple OU's in a previous Orchestrator version, and deleted at least one which had a user assigned to it, the folder correspondents of the remaining units are not visible to the respective user after migrating.
    Say I have defined five OUs in my v2018.3 Orchestrator instance. I assign John to one of them, and then delete the unit entirely. After fully migrating to v2019.10, John does not see any of the other 4 equivalent classic folders in his Orchestrator instance, hence won't be able to use it.
  • Live Metrics are no longer sent to Application Insights upon upgrading to Orchestrator v2019.10. As a workaround, if you want to use your own Application Insights instance to receive Live Metrics, add <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector"/> in the TelemetryModules section of the ApplicationInsights.config file.
  • You cannot download the Orchestrator offline activation request file if you are using Internet Explorer. As a workaround please use another browser.
  • Removing a license at tenant level is not possible if was initially uploaded at host level.
  • Upgrading a multi-node Orchestrator to v2019 must be performed with the application stopped. If performed with the application running, any schedules triggered during that time will fail and not resume.
  • Performance degradation and possible errors occur when loading the Folder Selection menu for a user assigned to more than 1,000 folders.
  • Where you have set schemas in a Queue for Output Data and/or Analytics Data, queue items that do not contain any output and/or analytics parameters are nonetheless processed successfully.
  • Packages that contain files without an extension and special characters or a blank space cannot be uploaded to Orchestrator.
  • A suspended job is not resumed if a Delay activity is used in the workflow before the job reaches the Suspended state.
  • The Windows authentication web.config parameter is not properly set if you enable it during clean installations using UiPathPlatform.exe. To mend this, open the config file and manually set WindowsAuth.Enabled to true.

Bug Fixes

Orchestrator

  • Fixed an issue where uploading a package from Orchestrator to an Azure Storage hosted package feed resulted in the blob access policy being changed from Private to allow anonymous read access.
  • The License Status is now properly displayed for NonProduction and Unattended machines, in the Unattended or NonProduction licensing pages.
  • The hostAdminPassword and defaultTenantAdminPassword parameters of the Publish-Orchestrator.ps1 script did not properly enforce password complexity rules.
  • We identified and fixed an issue that caused the heartbeat to malfunction if the connection to Redis was lost. Now, the heartbeat is being sent regardless of the Redis-Orchestrator connection status.
  • The logging configuration of the web.config file produced the Elasticsearch index logflow-yyyy.MM where previously it was default-yyyy.MM. This would impact any existing dashboards and visualization based on that index.
  • The Telemetry.Enabled key appeared twice in the web.config file if you updated your v2018.4.6 Orchestrator instance to v2019.4 or higher.
  • The Migrate_Deployment_Settings query used incorrect column names, resulting in potential failure of the migration.
  • Occasional deadlocks in the Orchestrator database would occur when: detecting unresponsive robots, simultaneously updating machines and deleting robots, or connecting multiple robots, with different users, on the same machine.
  • When selecting authentication settings during a UiPathOrchestrator.msi installation, the Reset at first login option for the Default tenant password would not work unless also checked for the Host.
  • If there was not enough free disk space, the UiPathPlatformInstaller.exe installer previously would not start nor provide any error message. Now the installer performs a check of available disk space prior to starting.
  • After a bulk update to enable or disable Tenants, only a single name would appear when reviewing the action on the Audit page.
  • Alerts were not generated if a job was started on a process with missing input parameter values.
  • Renaming a Robot, and then creating a second one with the name of the first, caused the errors on the Monitoring page to be misassociated. The errors of the first Robot were displayed for the second one instead.
  • The tooltip for schedules defined with CRON expressions was incorrectly rendered if you used numbers instead of day names in the expression. For example, 0 0/30 19-20 ? * 1-5 was displayed as Every 30 minutes, between 07:00 PM and 08:59 PM, Monday through Friday instead of Every 30 minutes, between 07:00 PM and 08:59 PM, Sunday through Thursday. Note that the job execution was performed correctly.
  • Processes could not be executed on Robots which were installed in user-mode if they were defined in Orchestrator only using the username. This issue did not occur if you defined your Robot using the machine username format.
  • Changes made to the input and output parameters of a process did not propagate to the existing associated schedules. Additionally, on the Edit Schedule window, parameters inherited from the process had their actual values displayed instead of the appropriate label.
  • The CreationTime field in the Audit Data window for start job actions was not correctly populated.
  • In some cases, language preferences were not persisted between login sessions.
  • Performance issues were encountered when editing schedules (now called triggers) where a process was linked to an environment with a large number of robots.
  • No error message was displayed when jobs associated to a schedule (now called trigger) could not be created due to having no robots defined.
  • The Create Robot window was not properly displayed in Internet Explorer.
  • Error summary emails were sent for disabled tenants and users.

Updated 9 days ago


2019.10.14


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.