高品質コンテンツの基準

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

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

注:

ソリューションアクセラレータは、これらの領域を通じて、効率的でスケーラブルな自動化ソリューションを構築するための、構造化された柔軟なフレームワークを提供する必要があります。要約すると、ソリューションアクセラレータは、自動化の迅速な開発とデプロイを促進するために、モジュール性、適応性、ベストプラクティスへの準拠、システムやアプリケーションとの容易な統合を促進する必要があります。

注意:

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) Process Framework を用意しました。

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

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

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

ディスパッチャーは、処理するドキュメントをアップストリームアプリケーションまたはシステムから収集します。
Document Understanding Process は、ディスパッチャーメソッドにより、スケーラビリティを備えながら、必要な情報を各ドキュメントから一度に 1 つずつ抽出します。
最後に、 実行者は ドキュメントから抽出されたデータを使用してプロセスを完了します。

3. Action Center を使用したトランザクションプロセス

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

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

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

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

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

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

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

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

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

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

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