项目组织

高级别框架

从通用（且独立于流程）框架开始，可以确保您以一致和结构化的方式处理任何流程。框架帮助您从高级视图开始，然后深入了解每个流程的具体细节。

“机器人企业框架”模板提出一个灵活的可重复流程的高级概述，包含本指南中阐述的一系列良好做法，并可轻松用作通过 UiPath 进行 RPA 开发的稳妥起点。该模板的构建采用状态机结构。

工作方式：

• 机器人从配置文件和 Orchestrator 资产中加载设置，并将它们保存在要跨工作流共享的字典中。
• 机器人获取所需的凭据并登录到所有应用程序中。
• 如果遇到任何错误，请重试几次，然后成功或中止。
• 机器人检查输入队列或其他输入源以启动新事务。
• 如果没有更多的输入数据，请将工作流配置为等待和重试，或者结束流程。
• 将执行用于处理事务数据的用户界面交互。
• 如果事务处理成功，则事务状态将更新，并且机器人将继续处理下一个事务。
• 如果遇到任何验证错误，则事务状态将更新，机器人移动到下一个事务。
• 如果遇到任何异常，若已配置则机器人会重新尝试处理事务几次，或者将项目标记为失败并重新启动。

• 最后，将发送一封包含流程状态的电子邮件（如果已配置）。

  
  

  

  
  

对于未通过 Orchestrator 执行的基于事务的流程（例如处理 Excel 文件中的所有发票），则可以构建本地队列（使用 .NET 入队/出队方法）。

然后，相对于将整个流程分组到一个“遍历每一行”循环下面，高级别流程（异常处理、重试或恢复）可以更轻松地重现。

可以在此页面上找到所有 REFrameWork 文件以及文档。

设计原则

将项目拆分为较小的工作流并使用“调用工作流文件”活动对于良好的项目设计至关重要。与在更少、更大的文件中组织的项目相比，专用工作流允许对组件进行独立测试、鼓励团队协作，并提高设计和执行性能。我们建议将工作流文件大小保持在 5 MB 以下。不支持超过 10 MB 的工作流文件。

明智地选择布局类型（流程图和序列）。通常，流程的“逻辑”停留在流程图中，而“导航和数据处理”则是在序列中。

通过在序列中开发复杂的逻辑，您最终会将容器和决策块变得错综复杂，非常难以追踪和更新。

相反，流程图中的用户界面交互使构建和维护变得更加困难。

与项目相关的文件（如电子邮件模板）可以在本地文件夹或共享驱动器中组织。

注意：如果放置在项目文件夹中，则在部署过程中，这些文件与项目工作流一起复制到机器人计算机上的 lib/net45 文件夹中。

这些文件夹也可以存储在共享驱动器上，因此所有的机器人都连接到相同的唯一来源。这样，业务用户可以完全检查和维护与流程相关的文件，而不需要 RPA 团队的支持。但是，决策（共享或本地文件夹）很复杂，应该考虑到与进程和环境有关的各个方面：文件的大小、更改的频率、编辑同一文件的并发性、安全策略等。

源代码控件

为方便管理项目版本控制以及共享更多开发人员的工作，我们建议使用版本控制系统。UiPath Studio 直接与 GIT、TFS 和 SVN 集成。您可以在此找到说明连接步骤和功能的教程。

控件设置

避免对外部设置（如文件路径、URL 等）进行硬编码。在工作流中，如果它们经常更改，我们建议将它们作为资产保存在 .config 文件（.xlsx、.xml 或 .json）或 Orchestrator 中。

一般来说，最终的解决方案应该是可扩展的，以便在不需要开发人员干预的情况下允许输入数据发生变化。例如，如果列表包含了进行某种类型的事务的客户、接收通知的人员的电子邮件等，那么列表应该存储在外部文件中（如 Excel），业务人员或其他部门可以直接这些文件中修改（添加/删除/更新）。

对于任何重复的流程，主循环中的所有工作流调用都应该使用“隔离”选项来标记，以防止潜在的机器人崩溃（例如，内存不足）。

凭据

不应直接将凭据存储在工作流中，而应该从更安全的地方（如本地 Windows 凭据存储库或 Orchestrator 资产）加载凭据。可以通过“获取凭据”活动在工作流中使用这些凭据。

错误处理

在运行自动化过程时可能会发生两种类型的异常：某种程度上可预测，或完全意外。基于这种区别，有两种解决异常的方法，一种是在工作流中自动执行的显式操作，另一种是将问题升级到人工操作者。

在可能遇到异常的情况下，将全局异常处理程序添加到自动化项目中会很有帮助。每个自动化项目只能添加一种这样的工作流类型，而且库不能使用全局异常处理程序。

可以设置工作流以确定在遇到异常时的行为：让执行忽略错误并从下一个活动开始继续执行，重试抛出了错误的活动，中止执行或继续并重新抛出错误。

此外，可以将全局异常处理程序中包含的参数设置为记录抛出异常的活动的名称或多次重试该活动。有关如何使用其参数的更多信息，请查看“全局异常处理程序”页面。

作为全局异常处理程序的替代方法，可以通过在“Try Catch 异常处理”块中放置易受攻击的代码来控制异常传播（可以在不同情况下正确处理这些块）。在最高级别，主流程图必须定义全面的纠正措施，以解决所有一般异常，并确保系统的完整性。

上下文处理程序为机器人提供了更高的灵活性以适应各种情况，它们应该用于实现替代技巧、清理或定制用户/日志消息。利用异常的垂直传播机制在“捕获”部分中避免重复处理程序，方法是将处理程序提升几个级别，这可能在单个位置涵盖所有异常。

应该在异常消息中提供足够的细节，让人们理解异常并采取必要的措施。异常消息和来源必不可少。异常对象的来源属性指示失败活动的名称（在调用的工作流中）。同样，命名是至关重要的，因为不良的命名方式不能明确表明组件崩溃的原因。

如下所示，如果选择不重命名“调用”活动，那么在崩溃时，异常来源就变得毫无意义（例如，“调用工作流文件”>“调用工作流文件”>“调用工作流文件”>“键入”）。

保持整洁

在流程中，确保在机器人与目标应用程序（浏览器、应用程序）交互后关闭应用程序。如果仍然打开，那么它们将使用计算机资源，并可能干扰其他自动化步骤。

在发布该项目之前，请对工作流进行最后全面检查，并进行一些清理：

• 删除未引用的变量。
• 删除临时“写入行”输出。
• 删除已禁用的代码。
• 确保命名有意义并且是唯一的。
• 删除不必要的容器（右击 >“删除序列”）。

项目名称也很重要。这是 Orchestrator 中的流程，因此它应该符合您的内部命名规则。默认情况下，项目 ID 是初始项目名称，但您可以从 project.json 文件中修改。

项目的描述也很重要（描述在 Orchestrator 中可见）。描述可能帮助您更容易地区分流程，因此也请选择一个有意义的描述。

代码可重用性

在开发时，我们通常需要在多个工作流/项目中自动化相同步骤，因此一种常见做法是：创建包含小部分正在发生的自动化的工作流，并将它们添加到库中。

没有通用的诀窍可以告知您如何分割任何给定的流程。

然而，一个不错的原则是将业务逻辑与自动化组件分离，这有助于构建一个可以有效重用的代码。

示例

让我们假设您的流程的一部分需要读取客户信息，然后根据该信息和内部业务规则来更新客户详细信息。

“获取客户信息”和“更改客户信息”应该是两个不同的自动化组件，完全独立于任何流程。逻辑（仅当过去 12 个月的总量大于 10 万时才更新客户类型）应与自动化分离。这两个组件可以在以后使用，分别在同一个项目中使用或者在不同的项目中使用，但逻辑不同。如果需要，可以通过参数将特定数据发送到这些组件。

不得从“获取客户信息”中调用“更改客户信息”，因为这会造成测试、处理异常和重用变得更加困难。

注意：对“获取信息”和“更改信息”使用单独的组件。

当操作之间的分离不是那么明显时，将现有代码从一个工作流复制粘贴到另一个工作流（或从一个项目复制粘贴到另一个项目）也能明确表明您应该为代码构建一个单独的组件（工作流），并在需要时调用。

存储可重用组件的位置

将现有代码从库拖放到工作流中比反复从头开始创建代码更容易。可以向样本库中添加的内容包括处理数据（排序、过滤）或文本（拆分、正则表达式模式）。请注意，一旦代码被添加到工作流中，它就会变成静态的，所以如果您在库中更新工作流，代码不会反映在现有的活动流程中。

常见的（可重用的）组件（如应用程序导航、登录、初始化）最好在网络共享驱动器上单独存储和维护。从该驱动器，这些组件可以由不同机器人从不同流程中调用。这种方法的最大优点是，主组件中的任何更改都会立即反映在使用主组件的所有流程中。

重要提示： Windows 和跨平台项目不支持调用 .xaml 和 .cs 项目位置之外的 .csv 文件。

如何检查质量自动化

• 模块性：

  • 将关注点与专用工作流分离，以实现精细粒度开发和测试；
  • 在项目之间提取和共享可重用组件或工作流。

• 可维护性：

  • 良好的结构和开发标准。

• 可读性：

  • 标准化的流程结构，鼓励明确的开发实践；
  • 工作流文件、活动、参数和变量具备有意义名称。

• 灵活性：

  • 将环境设置保存在外部配置文件或 Orchestrator 实例中，这样可以方便地在测试和生产环境中运行自动化。

• 可靠性：

  • 异常处理和错误报告；
  • 实时执行进度更新。

• 可扩展：

  • 准备好合并新用例。