高品質コンテンツの基準

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

ガイドライン	詳細
モジュール式で再利用可能なコンポーネント	ソリューション アクセラレータはモジュール性を考慮して設計し、プロセス テンプレート、マシン ラーニング モデル、再利用可能なライブラリなどに対して考え抜かれたアーキテクチャを提供する必要があります。 これらのモジュラーコンポーネントは、統合と組み合わせが容易で、元々念頭に置いていた特定のユースケース用にカスタマイズされたプロセスを構築するか、さまざまな再利用可能なコンポーネントをプロセス間で転送できる必要があります。 これにより、重複作業が減り、異なるプロセス間で開発ガイドラインとの一貫性が促進されます。
設定可能なパラメータと設定	ソリューション アクセラレータは、エンド ユーザーの要件とそのビジネス ニーズに合わせて調整できる構成可能なパラメーターと設定を提供する必要があります。 構成には、変数、しきい値、タイムアウト、エンドポイント、機械学習モデル、人間参加型の担当者、およびカスタマイズと適応性を可能にするその他の調整可能なパラメーターを含めることができますが、これらに限定されません。 プロセスの構成ファイル、Orchestrator のアセット、プロセスの引数などは、設定可能性を実現するために使用可能な手段の一部です。
スケーラブルで適応性のあるアーキテクチャ	アーキテクチャ設計は、拡張性と適応性があり、多様な自動化要件を処理でき、ビジネス ニーズの進化や新しいユース ケースの出現に応じて、より多くのロボットやプロセスで簡単に拡張できる必要があります。 アーキテクチャは、ユースケースの業界内で見られるさまざまなシステム、アプリケーション、およびテクノロジーとの統合を可能にする必要があります。 ユーザーは、組織のニーズに合わせて、さまざまなソリューション アクセラレータ コンポーネントを簡単に交換したり、新しいコンポーネントを統合したりできる必要があります。
統合機能	可能であれば、既製の Integration Service コネクタ 、または コネクタ ビルダー を使用して構築されたコネクションを利用して、すぐに使えるコネクタ ライブラリで API を使用した自動化を実現すると同時に、標準化された認証でコネクションを設定および管理するための標準的な方法を提供する必要があります。 外部システムおよびアプリケーションとのシームレスな統合により、データ交換が合理化され、ソリューションアクセラレータが既存のITインフラストラクチャと連携できるため、大規模な変更やカスタム開発の必要性が最小限に抑えられます。 API自動化が不可能な場合は、以下で説明するように、UI自動化をGUI統合レイヤー/アプリケーションレイヤーに含める必要があります。これには、アプリケーション ライブラリ内の オブジェクト リポジトリ を利用する必要があります。
拡張性とカスタマイズ性	ソリューション アクセラレータは、拡張およびカスタマイズできるように設計し、ソリューション アクセラレータのユーザーが組織の特定のニーズに合わせてオートメーション ワークフローを調整できるようにする必要があります。 ソリューション アクセラレータは、組織がユース ケースの基盤として特定のソリューション アクセラレータを使用し、独自のビジネス ニーズに適応させる機能を持つ必要があるという考え方で開発する必要があります。

:::note これらの領域を通じて、ソリューション アクセラレータは、効率的でスケーラブルなオートメーション ソリューションを構築するための、構造化された柔軟なフレームワークを提供する必要があります。要約すると、ソリューション アクセラレータは、モジュール性、適応性、ベスト プラクティスへの準拠、およびシステムやアプリケーションとの容易な連携を促進して、オートメーションの迅速な開発とデプロイを促進する必要があります。::: :::note UiPath Marketplace でコンポーネントを公開するには、オートメーションで使用されている、またはお使いのオートメーションと互換性のある UiPath 製品に関するすべての詳細と、それらが果たす役割をコンポーネントの説明に含める必要があります。

パートナーは、サードパーティからの明示的な承認なしに、サードパーティまたはサードパーティのアプリあるいは他のサードパーティ製品の名前を、UiPath Marketplace のコンポーネントまたは製品の説明のテキストに記載することはできません。 :::

ソリューション アクセラレータの標準

1. 階層型アーキテクチャ

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

2. ビジネスロジック層(実装層)

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

3. アプリケーション層

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

注:

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

標準アーキテクチャの種類

トランザクション/キュー ベースのプロセス

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

Robotic Enterprise Framework は、ステート マシンに基づくプロジェクト テンプレートです。これは、ログ、例外処理、アプリケーションの初期化などに関するすべてのベスト プラクティスに適合するように作成されており、複雑なビジネス シナリオに取り組む準備ができています。このテンプレートには、アプリケーションの初期化、入力データの取得、その処理、およびトランザクションの終了を行うための、事前に作成された State コンテナーがいくつか含まれています。これらのステートはすべて複数の遷移を介して接続されており、標準的なオートメーション シナリオのほぼすべてのニーズに対応します。また、複数の呼び出されるワークフローもあり、それぞれがプロジェクトの特定の側面を処理します。

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

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

2. Document Understanding のプロセス

ドキュメントを扱うほとんどのプロセスには、コンテンツも「理解」するという共通の要件があります。そのため、Document Understanding に特化した専用のフレームワークである Document Understanding (DU) プロセス フレームワークが導入されました。

このフレームワーク は、基本的に、一般的なドキュメント処理フローチャートに基づいた UiPath Studio プロジェクト テンプレートです。このプロセスでは、ログ記録、エラー処理、リトライ メカニズム、および DU ワークフローで使用する必要があるすべてのメソッドが提供されます。ワークフローには、接続された他のオートメーションとは切り離されたアーキテクチャがあります。

• 処理するファイルがどこから来たのか、何が実行をトリガーするのかは関係ありません - これはアップストリームプロセスの責任です。
• 抽出された情報をどこで使用するかは問題ではなく、これは下流プロセスの責任です。
• フレームワークのアーキテクチャは、Attended ロボットと Unattended ロボットの両方に共通です。
• Document Understanding ロジック (デジタル化、分類、データ抽出)
• *Action Center を使用した人間参加型のロジック (検証)
• Unattended ロボット、またはローカルの *検証ステーション
• 有人の場合

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

• *ディスパッチャー
• 上流のアプリケーションまたはシステムから、処理するドキュメントを収集します。
• The *Document Understanding Process
• ディスパッチャー方式のため、各ドキュメントから必要な情報を一度に 1 つずつ抽出します。拡張性も備えています。
• 最後に、*パフォーマー
• ドキュメントから抽出したデータを利用してプロセスを完了します。

3. Action Center でのトランザクション プロセス

このアーキテクチャは、ディスパッチャー – 実行者 - 人間参加型のファイナライザー プロセス、または長期実行ワークフローの中間のプロセスで構成されます。長期実行ワークフローの標準テンプレートは 、オーケストレーション プロセス テンプレートです。長期実行ワークフローには、無人環境でのサービス オーケストレーション、人間の介入、および長期実行トランザクションをサポートするために従う必要のある ベスト プラクティス があります。

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

4. その他のアーキテクチャ

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

• ファイナライザーは、プロセス内で必要なクリーンアップに対して常に考慮できます。
• 実行頻度の低い、またはアドホックなレポーターは、必要な関係者に自動化の統計情報を送信するものと見なすことができます
• 抽出、変換、読み込み (ETL) プロセスでは、複数のソースからのデータを大規模な中央リポジトリに結合できます。
• プロセスに適用できれば、 UiPath Attended フレームワーク などの他のオートメーション フレームワークも検討できます。

プロセスのベスト プラクティス

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

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

ライブラリのベスト プラクティス

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

• すぐに使える ワークフロー アナライザーのルールに従います。プロジェクトはワークフロー アナライザーに対して実行でき、警告がゼロではないにしても最小限である必要があります。命名規則、 デザインのベスト プラクティス、 保守性と読みやすさのルール、 および使用ルール に従う必要があります。これらのルールの主な例をいくつか示します。
  • ハードコードされた遅延があってはなりません。
  • アクティビティに既定の名前を付けないでください。
  • ワークフロー内で同じ名前のアクティビティがあってはなりません。
  • 引数は、ライブラリの作成時にプロパティとして表示されるため、in_、out_、およびio_命名規則に従わないでください。 無効な引数名に関するワークフロー アナライザーの既定のルールは、ライブラリ作成時には無視できます。
  • 深く入れ子にされたアクティビティは存在してはならず、ワークフローをより小さなコンポーネントに分割する場合に考慮する必要があります。
• UI の操作は、オブジェクト リポジトリを通じてのみ行う必要があります。
• ライブラリを、特定のタスクや機能に焦点を当てた小さなモジュール式のコンポーネントに分割します。 これにより、再利用性が促進され、メンテナンスと更新が容易になります。
• 使用手順、入力/出力の説明、依存関係や前提条件など、再利用可能なライブラリに関する包括的なドキュメントを提供します。 明確なドキュメントは、ユーザーがライブラリを効果的に使用する方法を理解するのに役立ちます。
• エラー処理: ライブラリ内に堅牢なエラー処理メカニズムを実装して、例外と失敗を適切に処理します。try-catch ブロックを使用し、トラブルシューティングに役立つ有益なエラー メッセージを提供します。
  • エラーはソリューション アクセラレータのプロセス内でキャッチし、ライブラリ内で処理しないでください
  • ビジネス例外は、ビジネス ルール例外をスローする必要があります。 アプリケーション例外はシステム例外をスローする必要があります
• 入力を確認し、エッジケースを処理して、ライブラリが正しく機能し、予期しないエラーや望ましくない結果を防ぐことを確認します。 適切な入力検証により、ライブラリの信頼性と安定性が向上します。
  • これは、すべての API オートメーションの出力にも当てはまります。
• プロセスを徹底的にテストして、その機能と信頼性を確認します。 テスト ケースとデータを使用して、期待される結果を検証し、エッジ ケースを処理します。 これは、デプロイ前にエラーや不整合を特定して修正するのに役立ちます。
  • UiPath Test Suite を使用してオートメーション用のテスト ワークフローを提供することを検討してください。
• ライブラリを定期的に確認および更新して、フィードバックを組み込み、バグに対処し、進化する要件に基づいて機能を強化します。 継続的な改善により、ライブラリの関連性と有効性が長期にわたって維持されます。
• ライブラリを更新するときは、下位互換性を考慮して次の更新を設計します。

例

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

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

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