高级别框架
从通用(和未知流程)框架开始，确保您以一致和结构化的方式处理任何流程。框架帮助您从高级视图开始，然后深入了解每个流程的具体细节。
机器人企业框架模板 建议对重复过程进行灵活的高层概述，并包含本指南中描述的一组良好的实践，并且可以很容易地用作使用 UiPath 进行 RPA 开发的坚实起点。该模板构建在状态机结构上。
它是如何运作的：
- 机器人从配置文件和 Orchestrator 资源中加载设置，并将它们保存在要跨工作流共享的字典中。
- 机器人获取所需的凭据并登录到所有应用程序中。
- 如果遇到任何错误，则重试几次，然后成功或中止。
- 机器人检查输入队列或其他输入源以启动新事务。
- 如果没有(更多的)输入数据可用，则将工作流配置为等待和重试，或者结束流程。执行用于处理事务数据的UI交互。
- 如果事务处理成功，则更新事务状态，机器人继续进行下一个事务。
- 如果遇到任何验证错误，事务状态被更新，机器人移动到下一个事务。
- 如果遇到任何异常，机器人会重新尝试处理事务几次(如果配置的话)，或者将项目标记为失败并重新启动。
-如果配置了邮件，最后则可以发送一封带有进程状态的电子邮件。
用于基于事务的流程（例如 处理 Excel 文件中的所有发票 ），没有通过 Orchestrator 执行，则可以构建本地队列（使用 .net 的 enqueue/ dequeue 方法）。
然后，高级别流程(异常处理、重试、恢复)的流程可以很容易地重复执行，这比将整个流程分组在一个 For Each Row 循环下面更容易。
所有的 REFrameWork 文件和文档可以在 这里 找到。
设计原则
在较小的工作流中分解流程对于良好的项目设计至关重要。 专用工作流允许对组件进行独立测试，同时通过开发单独的文件来鼓励团队协作。
明智地选择布局类型(流程图和序列)。通常，流程的逻辑停留在流程图中，而导航和数据处理则以顺序进行。
通过在序列中开发复杂的逻辑，您最终将得到一个由容器和决策块组成的迷宫，非常难以跟踪和更新。
相反，流程图中的UI交互使构建和维护变得更加困难。
项目相关的文件（例如邮件模板）可以被组织在本地文件夹或者共享磁盘中
注意
如果放置在项目文件夹中，则在部署过程中(以及项目工作流)在 lib/net 45 文件夹中的所有机器人机器上复制它们。
这些文件夹也可以存储在共享驱动器上，所以所有的机器人都连接到同一个唯一的源。这样，业务用户可以完全检查和维护与流程相关的文件，而不需要 RPA 团队的支持。但是，决策(共享或本地文件夹)很复杂，应该考虑到与进程和环境有关的各个方面：文件的大小、更改的频率、编辑同一文件的并发性、安全策略等。
源代码控制
为了方便地管理项目版本控制和共享更多开发人员的工作，我们建议使用版本控制系统。UiPath Studio 是直接与 TFS 和 SVN 集成的。您可以在 这里 找到一个说明连接步骤和功能的教程。
源代码控制相关设置
为了避免在工作流中硬编码外部设置(如文件路径、URL等)，我们建议将它们保存在.config文件(.xlsx、.xml或.json)中，或者作为 Orchestrator 的资源(如果它们经常更改)。
一般来说，最终的解决方案应该是可扩展的，以便在不需要开发人员干预的情况下允许输入数据的变化。
例如，允许客户进行某种类型的交易的列表、接收通知的人的电子邮件等应该存储在外部文件中(如excel)，在这些文件中，业务人员或其他部门可以直接修改它们(添加/删除/更新)。
对于任何重复的过程，主循环中的所有工作流调用都应该使用隔离选项来标记，以防止潜在的机器人崩溃(例如内存不足)。
凭证
不应直接将凭据存储在工作流中，而应从更安全的地方(如本地 windows凭据存储区 或 Orchestrator 资源)加载凭据。您可以通过 GetCredential 活动 在工作流中使用它们。
错误处理
在运行自动化过程时可能会发生两种类型的异常：某种程度上可预测的或完全出乎意料的。基于这种区别，有两种处理异常的方法，要么通过在工作流中自动执行的显式操作，要么通过将问题升级到人工操作员。
异常传播可以通过在TRY/CATCH块中放置易受攻击的代码来控制，在这些块中，情况可以适当地处理。在最高级别，主流程图必须定义广泛的纠正措施，以解决所有一般异常并确保系统完整性。
上下文处理程序为机器人适应各种情况提供了更大的灵活性，它们应该用于实现可供选择的技术、清除或定制用户/日志消息。利用异常的垂直传播机制，通过将处理程序向上移动一些级别，从而避免捕获部分中的重复处理程序，其中处理程序可能涵盖单个位置的所有异常。
应该在异常消息中提供足够的详细信息，让人理解它并采取必要的操作。异常消息和源是必不可少的。异常对象的源属性指示失败活动的名称(在调用的工作流中)。同样，命名是至关重要的，因为错误的命名没有给出崩溃组件的明确指示。
正如你如下看到的那样，选择不对调用的活动改名，使奔溃时输出的异常源提示信息毫无意义。例如 (Invoke Workflow File > Invoke Workflow File > Invoke Workflow File > Type Into 这样的信息并不能准确地告诉你发生了什么情况).
没有提示信息的流程图
代码重用
在开发时，我们通常需要在多个工作流/项目中自动化相同的步骤，因此创建包含小部分正在发生的自动化的工作流并将它们添加到库中应该是一种常见的做法。
没有通用的方法告诉你如何分割任何给定的过程。
然而，业务逻辑与自动化组件的分离是一个很好的原则，它有助于构建一个可以有效重用的代码。
例子
假设流程的部分需要读取客户的信息，然后基于该信息和内部业务规则来更新客户的详细信息
获取客户信息 和 修改客户信息 应该是两个不同的自动化组件，完全不知道任何过程。逻辑(仅在过去12个月的总量大于100 k时才更新客户类型)应与自动化分离。
这两个组件可以在以后使用，分别在同一个项目中使用，或者在不同的项目中使用，具有不同的逻辑。如果需要，可以通过参数将特定的数据发送给这些组件。
不应从 获取客户信息 中调用 修改客户信息 ，因为这使得测试、处理异常和重用变得更加困难。
代码重用例子
推荐:
分别使用 修改信息 和 获取信息 组件。
当操作之间的分离不那么明显时，将现有代码从一个工作流复制到另一个工作流(或从一个项目到另一个项目)也能一个很好地表明您应该为代码构建一个单独的组件(工作流)，并在需要时调用它。
可重用组件存储在哪里
将现有代码从库拖放到工作流中比从头开始重新创建代码更容易。处理数据(排序、过滤)或文本(拆分、regex模式)是可以添加到 示例库 中的示例。
请注意，一旦代码被添加到工作流中，它就会变成静态的，所以如果您在库中更新工作流，它将不会反映在现有的活动流程中。
普通(可重用)组件(如应用导航、登录、初始化)更好地分别存储和维护，在 网络共享驱动器 上。从该驱动器，它们可以被不同的机器人，从不同的进程。这种方法最大的优点是，任何在主组件中所做的更改都会立即反映在使用它的所有进程中。
怎样检验自动化程序的质量
-
模块化:
- 将关注点与专用工作流分离，允许细粒度开发和测试；在项目之间提取和共享可重用组件或工作流。
-
可维护性:
- 良好的结构和发展标准。
-
可读性:
- 标准化的程序结构，鼓励明确的发展做法；
- 工作流文件、活动、参数和变量的有意义名称。
-
灵活性:
- 将环境设置存放在外部配置文件中或者 Orchestrator 示例，使在测试和生产环境中运行自动化变得容易。
-
可靠性:
- 异常处理和错误报告；
- 实时执行进度更新。
-
可扩展:
- 为新用例的合并做好准备。
更多 UiPath 相关的资讯，请关注公众号：UiPath教程
由于简书禁止直接在文章中插入公众号二维码，请点击 这里 了解添加该公众号的细节。
网友评论