优质内容标准

UiPath Marketplace 上的所有列表应符合以下一般准则：

准则	详细信息
模块化和可重用组件	设计解决方案加速器时应考虑到模块化，为流程模板、机器学习模型和可重用库等提供深思熟虑的架构。这些模块化组件应易于集成和组合，以便为最初考虑的特定用例构建自定义流程，或者能够跨流程转移各种可重用组件。这应该会减少重复工作，并促进与不同流程中开发准则的一致性。
可配置的参数和设置	解决方案加速器应提供可配置的参数和设置，您可以调整这些参数和设置，以满足最终用户及其业务需求的要求。配置可以包括但不限于变量、阈值、超时、端点、机器学习模型、人机回圈受分配人以及其他可调整的参数，以实现自定义和灵活性。流程配置文件、Orchestrator 资产和流程参数是实现可配置性的一些方法。
可扩展且自适应的架构	架构设计应具有可扩展性和适应能力，能够处理多样化的自动化要求，并允许随着业务需求的发展或新用例的出现，轻松地使用更多机器人或更多流程进行扩展。架构应允许与用例行业内的各种系统、应用程序和技术集成。用户应该能够轻松更换各种解决方案加速器组件或集成新组件，以满足组织的需求。
集成功能	如果可能，应利用预构建的Integration Service 连接器或使用连接器生成器构建的连接，以借助开箱即用的连接器库使用 API 来实现自动化，同时还提供通过标准化身份验证来设置和管理连接的标准方法。与外部系统和应用程序的无缝集成可简化数据交换，并使解决方案加速器能够与现有 IT 基础架构配合使用，从而最大限度地减少广泛修改或自定义开发的需求。如果无法实现 API 自动化，则应将用户界面自动化包含在 GUI 集成层/应用程序层中，如下所述。这应利用“应用程序库”中的“对象存储库”。
可扩展性和自定义	解决方案加速器应设计为可扩展和可自定义的，以允许解决方案加速器用户根据组织的特定需求定制自动化工作流。开发解决方案加速器时应牢记，组织应使用特定的解决方案加速器作为用例的基础，同时能够使其适应独特的业务需求。

备注：

通过这些领域，解决方案加速器应提供一个结构化但灵活的框架，用于构建高效且可扩展的自动化解决方案。总之，您的解决方案加速器应提高模块化性、灵活性、最佳实践合规性以及与系统和应用程序的轻松集成，以促进自动化的快速开发和部署。

注意：

对于要在 UiPath 市场上发布的列表，您必须在列表的描述中包含有关自动化中使用的或与自动化兼容的 UiPath 产品的所有详细信息，以及它们所扮演的角色。

未经第三方的明确授权，合作伙伴不得在 UiPath Marketplace 上的列表或产品说明文本中包含第三方或第三方应用程序或其他第三方产品的名称。

解决方案加速器标准

1. 分层架构

解决方案加速器的设计应在业务逻辑层（实施层）和应用程序层（GUI 交互层，如有必要）之间实现分离。这可以直接在各种流程工作流中实现，或者，如果需要可重用性，则可以使用库来实现。

2. 业务逻辑层（实现层）

该层负责实施解决方案加速器的核心业务逻辑和自动化工作流。
它侧重于解决方案加速器旨在在给定域或用例中自动化的特定任务和流程。
业务逻辑层定义实现所需自动化结果所需的规则、条件和操作。
它可能涉及数据操作、决策、与外部系统的集成以及其他处理任务。
此层采用模块化和可自定义的设计，允许组织根据其特定的业务需求调整解决方案加速器。
它通常利用 UiPath 自动化功能（例如活动、工作流和变量）来编排自动化流程。

3. 应用程序层

应用程序层充当自动化工作流与参与自动化流程的各种应用程序和/或系统的 GUI（图形用户界面）或 API（应用程序编程接口）之间的接口。
该层可以处理与目标应用程序或系统中用户界面元素的交互，例如按钮、字段、菜单和对话框。该层还可以处理目标应用程序或系统中应用程序编程接口的实现，例如通过代码通信而不是使用应用程序的用户界面输入数据。
此层可以包含支持用户界面自动化的活动和组件，例如屏幕抓取、数据输入/输出和导航。此层还可以包含用于以编程方式实现相同控件的应用程序逻辑。
应用程序层旨在适应特定的目标应用程序，对 API 或用户界面的任何更新都应一次性完成，然后适应该组件的所有实现。
GUI 交互层应灵活处理用户界面元素、屏幕布局和导航路径的变化。
在 API 交互层中，任何工作流的输出都应与工作流的目标一致。例如，如果您的工作流称为“检索所有用户”，则预期将返回一组用户对象，而不是随后需要进一步解析以提取所需用户数据的 JSON。
通过使用分页和在目标 API 实现相关筛选器时应用相关筛选器，将 API 调用持续时间最短地缩短。

备注：

业务层和应用程序层之间的分离可确保明确区分自动化和流程逻辑与应用程序特定的详细信息。这可实现模块化且可扩展的架构，在该架构中，可以独立于核心业务逻辑单独管理 GUI 或 API 中的更改。通过这种分离，可以更轻松地维护、在解决方案加速器中重用或转移到其他流程，以及解决方案加速器的自定义。解决方案加速器的最终用户可以轻松替换应用程序层，以适应目标应用程序中的任何更改，而不会影响底层流程逻辑。同样，可以独立于应用程序修改或扩展业务逻辑，以满足不断变化的业务需求。

标准架构类型

基于事务/队列的流程

这是标准的“调度程序-执行者模型”。机器人企业框架可用于实施基于事务的简单流程。

机器人企业框架是一个基于状态机的项目模板。它的创建符合有关日志记录、异常处理、应用程序初始化和其他方面的所有最佳实践，准备好处理复杂的业务场景。该模板包含几个预制的“状态”容器，用于初始化应用程序、检索输入数据、处理数据和结束事务。所有这些状态都通过多个转换连接，这些转换几乎涵盖了标准自动化场景中的所有需求。还有多个被调用的工作流，每个工作流处理项目的特定方面。

调度程序和执行者模型是一个预先设计的解决方案，可通过在其间放置一个队列来分隔流程的两个主要阶段。这样，事务项目的生产完全独立于其消耗。此异步打破了调度程序和执行者之间的时间依赖关系。

在此标准方法中，调度程序是将数据加载到 UiPath 队列的自动化。它从一个或多个来源提取数据，并使用相同的数据创建队列项目以供 Performer Robot 处理。信息被推送到一个或多个队列，允许调度程序对队列项目中存储的所有数据使用通用格式。稍后可以在自动化（即执行者）中处理这些数据。执行者可以根据需要处理数据，因为一次处理一个队列项目。它对每个已处理的项目使用错误处理和重试机制。执行程序的一个主要优势是其可扩展性（单个队列可以使用多个执行程序）。

2. Document Understanding 流程

大多数处理文档的流程都有一个共同点，即都要求“理解”文档的内容。因此，我们建立了一个专门研究Document Understanding 的专用框架，即Document Understanding (DU) 流程框架。

此框架本质上是一个基于典型文档处理流程图的 UiPath Studio 项目模板。该流程提供日志记录、错误处理、重试机制以及应在 DU 工作流中使用的所有方法。工作流的架构与其他已连接的自动化分离：

要处理的文件来自何处或触发执行的原因都没有关系，这是上游流程的职责。
在何处使用提取的信息并不重要，这是下游流程的职责。
该框架的架构对于 Attended 和 Unattended Robot 是通用的：
Document Understanding 逻辑（数字化、分类、数据提取）
对于无人值守机器人使用Action Center的人机回圈逻辑（验证），对于有人值守的机器人使用本地验证站点

由于存在这些机制和架构，大多数使用 Document Understanding 的自动化通常会将 Dispatcher-Performer 模型与 Document Understanding 框架结合使用：

调度程序从上游应用程序或系统收集要处理的文档。
由于使用了“调度程序”方法，“ Document Understanding 流程”会一次从每个文档中提取一个具有可扩展性的必要信息。
最后，执行者利用从文档中提取的数据来完成流程。

3. Action Center 的事务流程

此架构由“调度程序”-“执行程序”-“终结程序”流程组成，循环中的人员或长时间运行的工作流位于中间的流程。长时间运行的工作流的标准模板是Orchestration 流程模板。长时间运行的工作流具有需要遵循的最佳实践，以支持无人值守环境中的服务编排、人工干预和长时间运行的事务。

当需要人工干预来批准或监控自动化时，可以使用此架构。因此，Action Center 任务之后的任何流程都必须同时考虑接受和拒绝。

4. 其他架构

根据自动化需求，可能存在其他合适的架构决策：

流程中所需的任何清理始终可以考虑使用终止程序。
可以考虑不经常运行或临时运行的报告器，将自动化统计信息发送给必要的利益相关者
提取、转换和加载 (ETL) 流程可以将来自多个来源的数据组合到一个大型中央存储库中。
如果适用于该流程，可以考虑其他自动化框架，例如UiPath Attended Framework 。

流程最佳实践

为解决方案加速器开发任何 UiPath 流程时，有必要遵循以下最佳实践：

遵循开箱即用的工作流分析器规则。使用此工具进行分析时，您的项目应该会引发最少的警告（如果不是零）。需要遵循命名约定、设计最佳实践、可维护性和可读性规则以及使用规则。这些规则的一些关键示例：
- 不应存在硬编码延迟。
- 所有活动都不应具有默认名称。
- 工作流中的两个活动不得重名。
- 参数需要遵循 in_、out_ 和 io_ 命名约定。
- 深度嵌套的活动不应存在，并应将其视为将工作流划分为较小组件的有力依据。
在开始开发之前，请彻底分析流程要求并设计满足特定需求的解决方案。将流程分解为更小的任务并识别依赖项，以确保工作流清晰高效。
识别可在其他项目中轻松维护和重用的可重用组件或工作流，并在早期阶段将其分离。这种模块化方法提高了可重用性，简化了调试并提高了可扩展性。
实施可靠的错误处理机制，以妥善处理异常和故障。使用 Try-Catch 块并提供错误消息，以帮助排除故障并增强流程的稳定性。
- 错误应该是特定的，并显示相关的错误消息。如果应填充字符串，但应用程序返回值的结果并非如此，则不应引发空指针异常 – 该异常应分类为由应用程序引发的业务规则异常。
在流程中纳入可配置的设置（例如输入参数），以实现灵活性和自适应性。这使用户能够根据自己的特定要求轻松自定义流程，而无需修改核心工作流。
验证输入以确保其符合所需条件，并处理无效或意外数据的异常。实施适当的数据处理技术，例如数据清理和转换，以确保准确可靠的处理。
合并日志记录机制，以在流程执行期间捕获相关信息。这有助于进行故障排除，并为流程优化提供宝贵的见解。使用调试工具高效地识别和解决问题。
- 还应考虑用于报告和 UiPath Insights 的日志记录机制。
彻底测试流程，以确保其功能性和可靠性。使用测试用例和数据来验证预期结果并处理极端情况。这有助于在部署之前识别并修复任何错误或不一致问题。
- 考虑使用UiPath 测试套件，并为您的自动化提供测试工作流。
根据反馈、不断变化的要求和技术进步，定期检查和增强您的流程。不断寻找机会优化流程，提高效率，并合并新特性或功能。

库最佳实践

在为解决方案加速器开发任何 UiPath 库时，有必要遵循以下最佳实践：

遵循开箱即用的工作流分析器规则。您的项目应该能够根据工作流分析器运行，并且具有最少的警告（如果不是零）。需要遵循命名约定、设计最佳实践、可维护性和可读性规则以及使用规则。这些规则的一些关键示例：
- 不应存在硬编码延迟。
- 所有活动都不应具有默认名称。
- 工作流中的任何活动都不应具有相同的名称。
- 参数不应遵循 in_、out_ 和 io_ 命名约定，因为在创建库时，这些参数将显示为属性。创建库时，可以忽略针对无效参数名称的默认工作流分析器规则。
- 不应存在深度嵌套的活动，在将工作流划分为更小的组件时，应考虑深度嵌套的活动。
任何用户界面交互都只能通过对象存储库进行。
将您的库分解为更小的模块化组件，这些组件专注于特定的任务或功能。这提高了可重用性，并简化了维护和更新。
为可重用库提供全面的文档，包括使用说明、输入/输出说明以及任何依赖项或先决条件。清晰的文档可帮助用户了解如何有效地使用该库。
错误处理：在库中实施可靠的错误处理机制，以妥善处理异常和故障。使用“尝试捕获”块并提供错误消息以帮助进行故障排除。
- 应在解决方案加速器的流程中捕获错误，而不应在库中处理错误
- 任何业务异常都应引发业务规则异常。任何应用程序异常都应引发系统异常
确认输入并处理边缘情况，以确保库正常运行，并防止意外错误或不良结果。正确的输入验证可增强库的可靠性和稳定性。
- 这也适用于任何 API 自动化输出。
彻底测试流程，以确保其功能性和可靠性。使用测试用例和数据来验证预期结果并处理极端情况。这有助于在部署之前识别并修复任何错误或不一致问题。
- 考虑使用UiPath 测试套件，并为您的自动化提供测试工作流。
定期查看和更新您的库，以根据不断变化的需求纳入反馈，解决错误并增强功能。持续改进可确保库始终保持相关性和有效性。
更新库时，在设计下一次更新时，请考虑向后兼容性。