高品質コンテンツの基準

Marketplace のすべてのコンポーネントは、以下の一般的なガイドラインを満たす必要があります。

ガイドライン	詳細
モジュール式で再利用可能なコンポーネント	ソリューション アクセラレータはモジュール性を考慮して設計し、プロセス テンプレート、マシン ラーニング モデル、再利用可能なライブラリなどに対して考え抜かれたアーキテクチャを提供する必要があります。 これらのモジュラーコンポーネントは、統合と組み合わせが容易で、元々念頭に置いていた特定のユースケース用にカスタマイズされたプロセスを構築するか、さまざまな再利用可能なコンポーネントをプロセス間で転送できる必要があります。 これにより、重複作業が減り、異なるプロセス間で開発ガイドラインとの一貫性が促進されます。
設定可能なパラメータと設定	ソリューション アクセラレータは、エンド ユーザーの要件とそのビジネス ニーズに合わせて調整できる構成可能なパラメーターと設定を提供する必要があります。 構成には、変数、しきい値、タイムアウト、エンドポイント、機械学習モデル、人間参加型の担当者、およびカスタマイズと適応性を可能にするその他の調整可能なパラメーターを含めることができますが、これらに限定されません。 プロセスの構成ファイル、Orchestrator のアセット、プロセスの引数などは、設定可能性を実現するために使用可能な手段の一部です。
スケーラブルで適応性のあるアーキテクチャ	アーキテクチャ設計は、拡張性と適応性があり、多様な自動化要件を処理でき、ビジネス ニーズの進化や新しいユース ケースの出現に応じて、より多くのロボットやプロセスで簡単に拡張できる必要があります。 アーキテクチャは、ユースケースの業界内で見られるさまざまなシステム、アプリケーション、およびテクノロジーとの統合を可能にする必要があります。 ユーザーは、組織のニーズに合わせて、さまざまなソリューション アクセラレータ コンポーネントを簡単に交換したり、新しいコンポーネントを統合したりできる必要があります。
統合機能	Pre-built Integration Service connectors or connections built using Connector Builder should be utilized, when possible, to enable automation using APIs with an out of the box library of connectors while also providing a standard way to set up and manage connections with standardized authentication. 外部システムおよびアプリケーションとのシームレスな統合により、データ交換が合理化され、ソリューションアクセラレータが既存のITインフラストラクチャと連携できるため、大規模な変更やカスタム開発の必要性が最小限に抑えられます。 If API automation is not possible, UI automation should be contained within a GUI Integration Layer / Application Layer as described further below. This should utilize Object Repository within an Application Library.
拡張性とカスタマイズ性	ソリューション アクセラレータは、拡張およびカスタマイズできるように設計し、ソリューション アクセラレータのユーザーが組織の特定のニーズに合わせてオートメーション ワークフローを調整できるようにする必要があります。 ソリューション アクセラレータは、組織がユース ケースの基盤として特定のソリューション アクセラレータを使用し、独自のビジネス ニーズに適応させる機能を持つ必要があるという考え方で開発する必要があります。

:::note Through these areas, a Solution Accelerator should provide a structured but flexible framework for building an efficient and scalable automation solution. In summary, your Solution Accelerator should promote modularity, adaptability, best practice compliance, and easy integration with systems and applications to facilitate rapid development and deployment of automation. ::: :::note For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the UiPath products that are used in the automation or that are compatible with your automation, and the role that they play.

Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on UiPath Marketplace without express authorization from the third party. :::

Standards for solution accelerators

1. Layered architecture

ソリューション アクセラレータの設計では、ビジネス ロジック層 (実装層) とアプリケーション 層 (必要に応じて GUI 対話層) の分離を実装する必要があります。 これは、さまざまなプロセス ワークフロー内で直接実現することも、再利用性が必要な場合はライブラリを使用して実現することもできます。

2. Business logic layer (implementation layer)

• このレイヤーは、ソリューション アクセラレータのコア ビジネス ロジックとオートメーション ワークフローの実装を担当します。
• 特定のドメインまたはユース ケースにおいてソリューション アクセラレータが自動化を目指す特定のタスクやプロセスに焦点を当てています。
• ビジネス ロジック レイヤーは、目的の自動化の成果を達成するために必要なルール、条件、およびアクションを定義します。
• これには、データ操作、意思決定、外部システムとの統合、およびその他の処理タスクが含まれる場合があります。
• このレイヤーはモジュール式でカスタマイズ可能なように設計されており、組織はソリューション アクセラレータを特定のビジネス要件に適合させることができます。
• 通常は、アクティビティ、ワークフロー、変数などの UiPath のオートメーション機能を利用して、オートメーション フローを調整します。

3. Application layer

• アプリケーション層は、自動化ワークフローと、自動化プロセスに関与するさまざまなアプリケーションやシステムのGUI(グラフィカルユーザーインターフェイス)またはAPI(アプリケーションプログラミングインターフェイス)との間のインターフェイスとして機能します。
• このレイヤーは、ターゲット アプリケーションまたはシステム内のボタン、フィールド、メニュー、ダイアログなどのユーザー インターフェイス要素との対話を処理できます。 このレイヤーは、アプリケーションのユーザー インターフェイスを使用する代わりに、コード通信によるデータ入力など、ターゲット アプリケーションまたはシステム内のアプリケーション プログラミング インターフェイスの実装を処理することもできます。
• このレイヤーには、UI 操作の自動化を実現するアクティビティやコンポーネント (画面スクレイピング、データ入出力、ナビゲーションなど) を含めることができます。 このレイヤーには、同じコントロールをプログラムで実装するためのアプリケーション ロジックを含めることもできます。
• アプリケーション層は、特定のターゲットアプリケーションに適応できるように設計されています。APIやユーザーインターフェイスの更新は1か所で行われ、そのコンポーネントのすべての実装に適応する必要があります。
• GUI 対話レイヤーは、UI 要素、画面レイアウト、ナビゲーション パスのバリエーションを柔軟に処理できる必要があります。
• API 対話レイヤー内では、ワークフローの出力はワークフローの目的と一致している必要があります。 たとえば、ワークフローの名前が「Retrieve All Users」の場合、JSON ではなくユーザー オブジェクトのコレクションが返されることを期待する必要があります。その後、必要なユーザー データを抽出するためにさらに解析する必要があります。
• ページネーションを使用し、ターゲット API によって実装されるたびに関連するフィルターを適用することにより、API 呼び出しの実行時間を最小限に保ちます。

注:

ビジネス層とアプリケーション層を分離することで、オートメーションおよびプロセス ロジックと、アプリケーション固有の詳細を明確に区別できます。 これにより、GUIまたはAPIの変更をコアビジネスロジックとは別に管理できるモジュール式のスケーラブルなアーキテクチャが可能になります。 この分離により、メンテナンスの容易さ、ソリューション アクセラレータ内での再利用性または他のプロセスへの転送、およびソリューション アクセラレータのカスタマイズが可能になります。 ソリューション アクセラレータのエンド ユーザーは、アプリケーション レイヤーを簡単に置き換えて、基になるプロセス ロジックに影響を与えることなく、ターゲット アプリケーションの変更に対応できます。 同様に、ビジネス ロジックは、進化するビジネス ニーズに対応するために、アプリケーションから独立して変更または拡張できます。

Standard architecture types

Transactional / queue based processes

これは、標準のディスパッチャー/実行者モデルです。 単純なトランザクションベースのプロセスの実装には、Robotic Enterprise Frameworkを使用する必要があります。

The Robotic Enterprise Framework is a project template based on State Machines. It is created to fit all the best practices regarding logging, exception handling, application initialization, and others, being ready to tackle a complex business scenario. The template contains several pre-made State containers for initializing applications, retrieving input data, processing it and ending the transaction. All these states are connected through multiple transitions which cover almost every need in a standard automation scenario. There are also multiple invoked workflows, each handling particular aspects of the project.

ディスパッチャーと実行者モデルは、間にキューを配置することによってプロセスの 2 つの主要な段階を分離するために事前に設計されたソリューションです。 このように、トランザクション明細の生産は消費から完全に独立しています。 この非同期性により、ディスパッチャーと実行者の間の時間依存性が解消されます。

この標準的なアプローチにおけるディスパッチャーは、UiPath のキューにデータを読み込むオートメーションです。 1 つまたは複数のソースからデータを抽出し、これを使用して Performer ロボットが処理するキュー アイテムを作成します。 情報は 1 つまたは複数のキューにプッシュされるため、ディスパッチャーはキュー アイテムに格納されるすべてのデータに共通の形式を使用できます。 このデータは、後でオートメーション (実行者) で処理できます。 実行者は、キュー アイテムが一度に 1 つずつ処理されるときに、必要に応じてデータを処理できます。 処理された各アイテムに対してエラー処理と再試行のメカニズムを使用します。 実行者の主な利点は、そのスケーラビリティです (1 つのキューで複数の実行者を使用できます)。

2. Document Understanding processes

Most of the processes working with documents have in common their requirement to also "understand" their content. Hence, a dedicated framework specialized in document understanding has been put in place – the Document Understanding (DU) Process Framework.

This framework is essentially a UiPath Studio Project template based on a typical document processing flowchart. The process provides logging, error handling, retry mechanisms, and all the methods that should be used in a DU workflow. The workflow has an architecture decoupled from other connected automations:

• 処理するファイルがどこから来たのか、何が実行をトリガーするのかは関係ありません - これはアップストリームプロセスの責任です。
• 抽出された情報をどこで使用するかは問題ではなく、これは下流プロセスの責任です。
• フレームワークのアーキテクチャは、Attended ロボットと Unattended ロボットの両方に共通です。
• Document Understanding ロジック (デジタル化、分類、データ抽出)
• Human-in-the-loop logic (validation) using *Action Center
• for unattended robots, or a local *Validation Station
• for attended ones

これらのメカニズムとアーキテクチャの結果として、Document Understanding を使用するオートメーションの大半は、通常、ディスパッチャー/実行者モデルと、その間に Document Understanding フレームワークを組み合わせたものです。

• The *Dispatcher
• gathers documents to be processed from the upstream application or system.
• The *Document Understanding Process
• extracts the necessary information from each document one at a time with scalability because of the Dispatcher method.
• Finally, the *Performer
• utilizes the extracted data from the document to complete the process.

3. Transactional processes with Action Center

This architecture consists of Dispatcher – Performer - Finalizer processes with human in the loop, or Long-Running Workflow, process somewhere in the middle. The standard template for longrunning workflows is the Orchestration Process Template. Long-Running workflows have best practices that need to be followed to support service orchestration, human intervention, and long-running transactions in unattended environments.

このアーキテクチャは、自動化の承認または監視に人間の介入が必要な場合に使用されます。 そのため、Action Center タスクの後のフローでは、受け入れと拒否の両方を考慮する必要があります。

4. Further architectures

オートメーションのニーズに基づいて、アーキテクチャ上の決定事項が存在し、適切である場合は他にもあります。

• ファイナライザーは、プロセス内で必要なクリーンアップに対して常に考慮できます。
• 実行頻度の低い、またはアドホックなレポーターは、必要な関係者に自動化の統計情報を送信するものと見なすことができます
• 抽出、変換、読み込み (ETL) プロセスでは、複数のソースからのデータを大規模な中央リポジトリに結合できます。
• Other automation frameworks such as the UiPath Attended Framework can be considered if applicable to the process.

Process best practices

ソリューション アクセラレータ向けの UiPath プロセスを開発する際には、以下のベスト プラクティスに従う必要があります。

• Follow the out of the box Workflow Analyzer rules. When analyzed with this tool, your project should raise minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • ハードコードされた遅延があってはなりません。
  • アクティビティに既定の名前を付けないでください。
  • ワークフロー内で 2 つのアクティビティに同じ名前を付けないでください。
  • 引数は、in_、out_、および io_命名規則に従う必要があります。
  • 深く入れ子にされたアクティビティは存在してはならず、ワークフローをより小さなコンポーネントに分割するための有力な議論材料と考える必要があります。
• 開発を開始する前に、プロセス要件を徹底的に分析し、特定のニーズに対応するソリューションを設計します。 プロセスを小さなタスクに分割し、依存関係を特定して、明確で効率的なワークフローを確保します。
• 他のプロジェクトで簡単に保守および再利用できる再利用可能なコンポーネントまたはワークフローを特定し、早い段階から分離します。 このモジュール式のアプローチにより、再利用性が向上し、デバッグが簡素化され、スケーラビリティが向上します。
• 堅牢なエラー処理メカニズムを実装して、例外とエラーを適切に処理します。 try-catch ブロックを使用し、トラブルシューティングに役立つエラー メッセージを提供し、プロセスの安定性を高めます。
  • エラーは具体的で、関連するエラー メッセージを表示する必要があります。 文字列を設定する必要があるが、アプリケーションの戻り値の結果ではない場合は、null ポインター例外をスローしないでください – 例外は、アプリケーションによって発生したビジネス ルール例外として分類する必要があります。
• 入力パラメーターなどの構成可能な設定をプロセスに組み込んで、柔軟性と適応性を実現します。 これにより、ユーザーはコア ワークフローを変更することなく、特定の要件に基づいてプロセスを簡単にカスタマイズできます。
• 入力を検証して、必要な基準を満たしていることを確認し、無効または予期しないデータの例外を処理します。 データのクレンジングや変換などの適切なデータ処理手法を実装して、正確で信頼性の高い処理を保証します。
• プロセスの実行中に関連情報をキャプチャするためのログ メカニズムを組み込みます。 これはトラブルシューティングに役立ち、プロセスの最適化のための貴重な洞察を提供します。 デバッグ ツールを使用して、問題を効率的に特定して解決します。
  • レポートと UiPath Insights のログ記録メカニズムも考慮する必要があります。
• プロセスを徹底的にテストして、その機能と信頼性を確認します。 テスト ケースとデータを使用して、期待される結果を検証し、エッジ ケースを処理します。 これは、デプロイ前にエラーや不整合を特定して修正するのに役立ちます。
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• フィードバック、進化する要件、および技術の進歩に基づいて、プロセスを定期的にレビューおよび強化します。 プロセスを最適化し、効率を向上させ、新しい機能を組み込む機会を継続的に模索します。

Library best practices

ソリューション アクセラレータ用の UiPath ライブラリを開発する際には、以下のベスト プラクティスに従う必要があります。

• Follow the out of the box Workflow Analyzer rules. Your project should be able to be run against Workflow Analyzer and have minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • ハードコードされた遅延があってはなりません。
  • アクティビティに既定の名前を付けないでください。
  • ワークフロー内で同じ名前のアクティビティがあってはなりません。
  • 引数は、ライブラリの作成時にプロパティとして表示されるため、in_、out_、およびio_命名規則に従わないでください。 無効な引数名に関するワークフロー アナライザーの既定のルールは、ライブラリ作成時には無視できます。
  • 深く入れ子にされたアクティビティは存在してはならず、ワークフローをより小さなコンポーネントに分割する場合に考慮する必要があります。
• UI の操作は、オブジェクト リポジトリを通じてのみ行う必要があります。
• ライブラリを、特定のタスクや機能に焦点を当てた小さなモジュール式のコンポーネントに分割します。 これにより、再利用性が促進され、メンテナンスと更新が容易になります。
• 使用手順、入力/出力の説明、依存関係や前提条件など、再利用可能なライブラリに関する包括的なドキュメントを提供します。 明確なドキュメントは、ユーザーがライブラリを効果的に使用する方法を理解するのに役立ちます。
• Error Handling: Implement robust error handling mechanisms within the library to handle exceptions and failures gracefully. Use try-catch blocks and supply informative error messages to aid in troubleshooting.
  • エラーはソリューション アクセラレータのプロセス内でキャッチし、ライブラリ内で処理しないでください
  • ビジネス例外は、ビジネス ルール例外をスローする必要があります。 アプリケーション例外はシステム例外をスローする必要があります
• 入力を確認し、エッジケースを処理して、ライブラリが正しく機能し、予期しないエラーや望ましくない結果を防ぐことを確認します。 適切な入力検証により、ライブラリの信頼性と安定性が向上します。
  • これは、すべての API オートメーションの出力にも当てはまります。
• プロセスを徹底的にテストして、その機能と信頼性を確認します。 テスト ケースとデータを使用して、期待される結果を検証し、エッジ ケースを処理します。 これは、デプロイ前にエラーや不整合を特定して修正するのに役立ちます。
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• ライブラリを定期的に確認および更新して、フィードバックを組み込み、バグに対処し、進化する要件に基づいて機能を強化します。 継続的な改善により、ライブラリの関連性と有効性が長期にわたって維持されます。
• ライブラリを更新するときは、下位互換性を考慮して次の更新を設計します。

例

非破壊的変更: 新しいワークフローによるライブラリの拡張。

重大な変更の可能性: 既存のワークフローの調整。

不明な場合は、中間リリースとの後方互換性をテストし、必要に応じて、更新を必要とするプロセスのみが個別に使用できる新しいワークフローまたはライブラリに更新を移動します。 やがて、古いワークフローは時代遅れと見なされる可能性があります。