- 发行说明
2020 年 3 月
在 2018.3 版中，我们介绍了有人值守的浮动机器人和计算机模型的概念。
两者结合使用，已成为一个理想的机制，可以处理基于非持久性 VDI 的部署，带热座转换的长时间轮班以及通常具有任意机算机/用户组合的环境。
在拥有 8 个用户和 8 个 VDI 的环境需要配置一个计算机模板和 8 个浮动机器人的情况下，计算机模型消除了在用户和计算机集之间定义笛卡尔乘积的必要性，而以前您必须定义这 8 个用户和 8 个 VDI 之间的所有 64 个机器人组合。
在 2019.10 版中，为了进一步减少部署工作，我们引入了有人值守的机器人自动配置和管理功能。然后，您可以为实例中拥有的任何类型的用户身份自动创建有人值守机器人。此功能以及机器人设置和许可需求可以直接在用户级别进行配置。
如果到目前为止，您只能通过我们的有人值守计划来利用这些优点，则可以采用此版本，因为我们已将注意力转移到无人值守产品上，从而充分实现我们的成熟解决方案。为此，上述每个行为现在也适用于无人值守机器人和非生产机器人。
综上所述，无论机器人类型如何，新的主要功能都集中于轻松管理大型部署。其目的在于通过动态分配、自动配置和非持久性 VDI 支持（如果需要的话），来高效使用机器人。最后，推荐一篇文章，其中描述了新式文件夹中的机器人。
已对“任务”功能进行重大改进。它现在称为“Action Center”，其中操作 （而非任务）充当中心的操作单元。别担心，功能本身保持不变。有关订阅源的详细信息，请参阅此处。
我们还引入了一种新型操作，这个操作非常棒！具体做法是，我们已将“验证站点”与新更名的 Action Center 集成在一起。这意味着什么？
为确保在等待长时间运行的流程完成时不会浪费资源，每当需要用户输入以查看和更正文档分类以及自动数据提取结果时，都会生成“文档验证”操作。
此操作将由分配到此操作的用户执行。 在操作等待完成期间，没有机器人被扣为人质。 它们可用于执行不同的流程。 完成“文档验证”操作后，系统将在任何可用的机器人上恢复初始工作流。
如果您定期处理后台流程，您将很高兴知道，从现在开始，我们不再限制您使用不同的用户来执行流程。是的，您没有听错，现在可以同时在同一用户上执行任意数量的此类流程。我们还对用户界面进行了几处更改，以便您轻松区分需要用户干预的流程和不需要用户干预的流程，以便您轻松管理流程及其执行。单击此处可了解此方面详情。
我们添加了大家翘首期盼的“作业优先级”功能。现在，您可以更好地控制哪个作业优先于其他竞争作业。优先级较高的作业先获取资源，并在优先级较低的作业之前执行。具有相同优先级的作业将按照其创建顺序执行。就是这样。希望您喜欢这个功能！
Orchestrator 现在为您提供了对 Blob 存储的内置支持，您可以使用 Orchestrator 数据库或外部提供程序（即 Azure、Amazon、MinIO）。这些存储桶是文件夹作用域内的实体，可用于对存储和内容的访问和使用进行细化控制。
从今天的部署开始，您无法再使用 Studio 或 StudioX 类型机器人从 Orchestrator 启动作业或创建触发器。为了确保您的环境不会发生问题，您需要做到以下几点：
- 如果您通过在 Orchestrator 中配置的 Unattended 计划在生产环境中使用 Studio，请使用 Unattended Robot。
- 如果您在开发环境中使用 Orchestrator，在 Studio 或 StudioX 机器人上计划和执行作业，请改用 NonProduction Robot。
关于即将进行的 Orchestrator 更改，请参阅如下快览：
从 2020.4 版开始，您不再能够使用 Studio 或 StudioX 机器人从 Orchestrator 启动作业或创建触发器。我们很清楚这可能会带来调整方面的麻烦，但您要知道，为了实现更精简的业务解决方案，这种情况在所难免。言归正传，为了确保您的环境不会发生问题，您需要做到以下几点：
- 如果您通过在 Orchestrator 中配置的 Unattended 计划在生产环境中使用 Studio，请使用 Unattended Robot。
- 如果您在开发环境中使用 Orchestrator，在 Studio 或 StudioX 机器人上计划和执行作业，请改用 NonProduction Robot。
为了更好地控制 Orchestrator 的性能，新队列项目不能包含超过 1 MB 的特定数据。超出此限制的任何内容都无法添加到队列中。如果您需要上传较大的项目，请将相应数据存储在外部存储空间，并且仅引用项目中的链接。
