- 发行说明
2022 年 4 月
为了适应具有多帐户连接的自动化项目，我们实施了一项新功能，允许个人工作区所有者查看这些帐户并指定一个用于启动作业的帐户。创建流程或编辑现有流程时，您可以在“包要求”选项卡上更改帐户。与多个帐户的每个连接都有一个下拉列表，允许您查看可用帐户的完整列表并根据需要更改活动帐户。
要管理连接或添加新连接，您可以通过单击 
按钮跳转到 Integration Service。
/odata/UserLoginAttempts({key}) 端点和相应的“登录尝试次数”部分已被弃用，并且仅返回此更改之前的登录尝试次数（即使用 Cookie 的登录尝试）。从现在开始，使用访问令牌进行的登录尝试只能通过 Automation Cloud 中的审核日志进行访问。请联系管理员以请求这些数据。
基于令牌的身份验证改变了 Orchestrator 计算用户上次登录时间的方式。从现在开始，对于主动使用 Orchestrator 的用户，系统会每小时计算一次其最后一次登录时间。
假设用户在 14:10 到 15:00 之间使用 Orchestrator。在 14:10 通过身份验证后，表示其上次登录时间为 14:10，直到下一个每小时的检查时间为止。在 16:00 之前使用 Orchestrator 表示用户的上次登录时间显示为 15:10。
您可以在 Orchestrator 用户界面的以下位置看到我们计算用户上次登录时间的方式发生的变化：
- “分配角色”页面（“租户”>“管理访问权限”）
-
“个人工作区”页面（“租户”>“文件夹”>“个人工作区”）
注意：此次发布与我们之前的发布惯例不同，企业版用户在社区版发布日期的一周后无法使用此功能。相反，企业版用户将于 5 月 2 日的当周享用该功能。
您现在可以使用 OAuth2 在 Swagger 用户界面中授权 API 调用。
了解如何获取访问令牌、发送请求或撤销访问权限。
此功能仅适用于社区用户。
有没有想过，如果您不必担心执行自动化的基础架构，您的生活会如何？
在过去的几个月中，我们将实现这一目标作为我们的首要任务，因此今天我们为您带来 UiPath Automation CloudTM Robot - Serverless（简称 Cloud Robot - Serverless）。
Serverless Cloud Robot 可让您轻松运行后台自动化，而无需担心必要的基础架构。它们使您可以完全自由地配置、管理、维护和扩展任何底层基础架构。 UiPath 会在后台处理所有工作，因此您不必处理容器、虚拟机或物理服务器。
请参阅 Automation Cloud Robot - Serverless 的有关详细信息以及相关设置说明。
API：用于分配角色的新端点
Orchestrator API 现在提供了一个新的端点，用于分配角色或覆盖现有帐户的分配角色：
/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles与我们现有的用户端点相比，此端点得到了改进，因为它根据角色 ID 而非角色名称分配角色，从而使其更可靠。
<OrchestratorURL>/swagger。
API：重大变更
这将影响：
-
与默认角色的自定义版本相关的 API 调用，该角色现已重命名为“
Role name- 自定义”重要提示：这些调用可以在不进行任何更改的情况下继续工作，但结果并不像预期的那样。也就是说，调用现在会分配默认角色，而不是角色的自定义版本。 -
与旧的 Tenant Administrator 角色（现在称为 Orchestrator Administrator）相关的 API 调用。
由于无法找到具有指定名称的角色，这些调用失败并显示错误。
受影响的端点
以下请求可以根据角色名称分配角色：
- POST
/odata/Users - PUT
/odata/Users({key}) - PATCH
/odata/Users({key}) - POST
/odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole
修复
要解决此问题，您可以使用新的端点根据角色 ID 而不是角色名称来分配角色。
您可以通过两种方式更新受此更改影响的集成，使其按预期运行：
A. 添加第二个 API 调用（推荐）
您可以保留现有的 API 请求，但在每个分配角色的调用后，都会调用新端点，以使用更正的角色覆盖已分配的角色。
/odata/Users 发出了创建 Tenant Administrator 帐户的 POST 请求（即作为帐户创建的一部分，该请求将尝试分配已重命名为 Orchestrator Administrator 的 Tenant Administrator 角色），则您之后应向 /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles 发送新的 POST 请求，该请求会传递 Orchestrator 管理员角色的角色 ID，以便正确分配该角色。
对于此修复方法：您需要识别集成中受影响的请求，然后针对每个已识别的请求：
- 记下受影响的请求要分配的用户 ID 和角色名称。
- 向
/odata/Roles发出 GET 请求以检索当前角色列表。 - 记下您之前记下的角色名称的 ID。
-
（可选，但建议）在集成中，更新受影响的请求以删除角色名称属性。
进行此更改后，请求将不再分配角色，下一步中的请求将处理角色分配。
您可以选择不从此请求中删除角色属性，因为下一步中的请求将覆盖任何已分配的角色。
-
在受影响的请求之后，立即向
/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles添加一个 POST 请求，并在请求正文中包括角色 ID。{key}值应为受影响请求中的用户 ID。
这可确保您已识别的受影响请求分配的任何角色立即被正确的角色覆盖。
B. 更新角色名称
一种更简单但效率较低的修复方法是使用新角色名称更新受影响的请求。
对于此修复方法，您需要识别集成中受影响的请求，然后针对每个已识别的请求：
- 向
/odata/Roles发出 GET 请求以检索当前角色列表。 - 记下受影响的请求分配的角色名称的当前名称。
- 在集成中，使用更新后的角色名称更新受影响的请求中的角色名称属性值。
由于最近的变更，并且我们希望在不会对您造成影响的前提下保留将来更新角色的能力，我们宣布打算弃用 Orchestrator API 中的角色名称属性。
我们将在自现在起的至少 6 个月内继续支持此属性。
但是，我们建议您开始转换为使用新的端点来分配角色，以避免在弃用后破坏更改。
我们已将角色名称允许的最大字符数从 32 个字符增加到 64 个字符。
jobs.created Webhook 的有效负载现在显示特定的机器人 ID 和用于运行作业的计算机。
