プロジェクトの構成

高レベルのフレームワーク

ジェネリックな (プロセスに依存しない) フレームワークにより、どのプロセスも一貫性を有する構造化された方法で処理できます。フレームワークを使用すれば、高レベルの表示から開始して、各プロセスの特定の細部に深く進んで行くことができます。

Robotic Enterprise Framework テンプレートは、反復プロセスの柔軟性のある高レベルの概要を提示します。このガイドに記載するさまざまなプラクティスを含むため、UiPath を利用して RPA 開発を行う際の確かなスタート ポイントとなります。このテンプレートは、ステート マシン構造に基づいて構築されています。

動作のしくみ:

• ロボットは、構成ファイルおよび Orchestrator のアセットから設定を読み込み、ディクショナリーに保存し、各種ワークフローで共有します。
• ロボットは必要な資格情報を取得し、すべてのアプリケーションにログインします。
• エラーが発生した場合は数回リトライした後に、正常に実行するか、あるいは中止します。
• ロボットは、入力キューやその他の入力ソースを確認し、新しいトランザクションを開始します。
• (これ以上の) 入力データがない場合は、プロセスを待機してリトライするか、またはプロセスを終了するようにワークフローを設定します。
• トランザクションデータを処理する UI インタラクションが実行されます。
• トランザクションが正常に実行された場合、トランザクションのステータスが更新され、ロボットは次のトランザクションを続行します。
• 検証エラーが発生した場合、トランザクションのステータスが更新され、ロボットは次のトランザクションに移ります。
• 例外が発生した場合、ロボットはトランザクションの処理を数回リトライするか (設定されている場合)、またはそのアイテムを失敗としてマークして再開します。

• 最後に、プロセスのステータスを記載したメールが送信されます (設定されている場合)。

  
  

  

  
  

Orchestrator を通じて実行されないトランザクションベースのプロセス (Excel ファイルからすべての請求書を処理する場合など) については、ローカル キューを構築できます (.NET の enqueue/ dequeue メソッドを使用)。

これで、高レベル プロセス (例外処理、リトライ、リカバリー) のフローが容易に複製できるようになります。この方法は、プロセス全体を [繰り返し (各行)] ループの下でグループ化するよりも簡単です。

すべての REFrameWork ファイルと関連文書は、こちらに掲載されています。

デザインの原則

優れたプロジェクトの設計には、プロジェクトを小さなワークフローに分割して [ワークフロー ファイルを呼び出し] アクティビティを使用することが非常に重要です。サイズが大きい少数のファイルで構成されたプロジェクトに比べて、専用のワークフローを複数作成する方が、コンポーネントの独立したテストの実行、チームのコラボレーションの促進、デザインや実行パフォーマンスの向上が可能です。ワークフロー ファイルのサイズは 5 MB 未満にしておくことをお勧めします。10 MB を超えるワークフロー ファイルはサポートされていません。

レイアウトの種類 (フローチャートとシーケンス) の選択は慎重に行います。通常、プロセスのロジックはフローチャート、ナビゲーションとデータ処理はシーケンスになります。

シーケンス内で複雑なロジックを開発すると、コンテナーや分岐ブロックが迷路のようになり、フォローや更新が極めて難しくなります。

これとは逆に、UI インタラクションをフローチャートにすると、構築や維持が極めて難しくなります。

プロジェクト関連ファイル (メール テンプレートなど) は、ローカル フォルダーや共有ドライブで整理できます。

注: こうしたファイルをプロジェクト フォルダーに置くと、デプロイ プロセスの間に、lib/net45 フォルダー内のすべてのロボット端末上に (プロジェクトの各種ワークフローとともに) 複製されます。

これらのフォルダーも共有ドライブに保存できます。こうすることで、すべてのロボットが同一の固有ソースに接続できます。このように、プロセス関連ファイルは、RPA チームからのサポートがなくても、ビジネス ユーザー全体で確認して維持することができます。ただし、(共有か、ローカル フォルダーかの) 決定は単純なものではなく、ファイルのサイズ、変更の頻度、同一ファイル編集の同時並行性、セキュリティ ポリシーなど、プロセスや環境に関連するさまざまな側面を検討する必要があります。

ソース管理

プロジェクトのバージョン管理を簡素化し、より多くの開発者と作業を共有できるようにするには、バージョン コントロール システムの利用を推奨します。UiPath Studio は、GIT、TFS および SVN と直接統合されます。接続の手順と機能の詳細については、こちらのチュートリアルでご確認ください。

コントロール設定

ワークフローで外部設定 (ファイル パス、URL など) をハードコーディングしなくてすむように、これらの設定を .config ファイルの (.xlsx、.xml もしくは .json)、または Orchestrator にアセットとして保存することを推奨します (設定が頻繁に変更される場合は特に当てはまります)。

一般的に、開発者の介入なしに入力データが変更できるようにするために、最終的なソリューションに拡張性を持たせます。たとえば、特定の種類のトランザクションを許可されている顧客リストや通知受信者のメール アドレスリストなどは、外部ファイル (Excel など) に保存し、ビジネス ユーザーや他の部門がこれらの情報を直接編集 (追加/削除/更新) できるようにします。

反復プロセスについては、メイン ループからのワークフロー呼び出しにはすべて、[分離] オプションのマークを付けて、ロボットがクラッシュする場合 (メモリ不足など) に備えて保護します。

資格情報

資格情報はワークフローに直接保存するのではなく、ローカルの Windows 資格情報ストアや Orchestrator アセットなどの安全性の高い場所から読み込むようにします。[資格情報を取得] アクティビティを通じて、これらの情報をワークフローで使用できます。

エラー処理

自動化したプロセスを実行する際に発生する例外には、ある程度予想可能なものと全く予想外のものの 2 種類があります。この区別に応じて、ワークフロー内で明示的なアクションを自動実行するか、人間のオペレーターに問題を報告するかのいずれかにより、例外に対応します。

例外が発生する場合を考慮して、グローバル例外ハンドラーをオートメーション プロジェクトに追加しておくと便利です。こうした種類のワークフローは、オートメーション プロジェクトごとに 1 つだけ追加できます。また、グローバル例外ハンドラーはライブラリには使用できません。

このワークフローは、例外発生時のワークフローの動作を決定するように設定できます。エラーを無視して次のアクティビティから続行する、例外をスローしたアクティビティをリトライする、実行を中止する、または続行して再度例外をスローする、から動作を指定します。

さらに、グローバル例外ハンドラーに含まれる引数を設定して、例外をスローしたアクティビティ名を記録したり、アクティビティの再試行回数を指定したりすることもできます。これらの引数の使用方法については、「グローバル例外ハンドラー」ページをご覧ください。

グローバル例外ハンドラーの代わりに、[トライ キャッチ] ブロックに疑わしいコードを置くことにより、例外の伝達を制御できます。これらのブロックでは、例外が適切に処理されます。より高次なレベルでは、メインのプロセス ダイアグラムにおいて、すべてのジェネリックな例外に対応し、システムの完全性を確保するための対策を幅広く定義する必要があります。

コンテキストハンドラーを使用すると、ロボットがさまざまな状況に柔軟に適応できるようになります。コンテキストハンドラーは、代替的手法、クリーンアップ、またはユーザー/ログメッセージのカスタマイズを実装する場合に使用します。垂直方向の伝播メカニズムを利用すれば、1箇所ですべての例外に対応するような高次のレベルにまでハンドラーを移動することで、キャッチセクションでのハンドラーの重複を防ぐことができます。

例外を理解し、必要なアクションを行うには、例外メッセージに記載されている詳細な内容を人間に報告する必要があります。例外メッセージとソースが非常に重要になります。例外オブジェクトのソースプロパティは、(呼び出されたワークフロー内で) 失敗したアクティビティ名を示します。そのためにも、わかりやすい名前を付けることが大切です。わかりにくい名前では、クラッシュしたコンポーネントに関する情報が全く得られないからです。

下図に示すように、[ワークフロー ファイルを呼び出し] アクティビティの名前を変更しなかった場合には、クラッシュ発生時に例外ソースが意味を持たなくなります (例: [ワークフロー ファイルを呼び出し] > [ワークフロー ファイルを呼び出し] > [ワークフロー ファイルを呼び出し] > [文字を入力])。

クリーンに保つ

プロセス フローでは、ロボットがターゲット アプリケーション (ブラウザー、アプリ) とやりとりした後にそれらを必ず閉じるようにします。アプリケーションを開いたままにしておくと、マシンのリソースを消費し、オートメーションの他の手順の妨げになる場合があります。

プロジェクトをパブリッシュする前に、ワークフロー全体を最終チェックして、次のようなクリーンアップを行います。

• 参照されていない変数を削除する。
• 一時的な [1 行を書き込み] 出力を削除する。
• 無効化されているコードを削除する。
• 名前がわかりやすく一意であることを確認する。
• 不要なコンテナーを削除する (右クリック > [囲んでいるシーケンスを削除])。

また、プロジェクト名も重要です。プロジェクト名は、Orchestrator でプロセスがどのように表示されるかを示すため、内部的な名前付けルールに沿ったものにします。既定では、プロジェクト ID は最初のプロジェクト名になりますが、project.json ファイルから変更できます。

プロジェクトの説明も重要です (Orchestrator で表示されます)。さまざまなプロセスを簡単に区別できるようになるため、わかりやすい説明を心がけます。

コードの再利用性

開発においては、1 つ以上のワークフロー/プロジェクトで同じ手順を自動化することが多くなります。このため、通常のプラクティスとしては、オートメーションの小さなグループを含むワークフローを作成し、ライブラリに追加します。

プロセスをどのように分割すればよいかに関して普遍的な方法はありません。

しかし、オートメーション コンポーネントからビジネス ロジックを分離することはベスト プラクティスであり、効果的に再利用できるコードの作成に役立ちます。

例

プロセスの一部として、顧客情報を読み取り、その情報と内部の業務規則に基づいて、顧客の詳細情報を更新する必要があるとします。

Get Customer Info (顧客情報の取得) および Change Customer Info (顧客情報の変更) は、2 つの別々のオートメーション コンポーネントとして、他のいずれのプロセスからも完全に独立させます。このロジック (過去 12 ヵ月間に合計金額が 100,000 を超える場合に限り、顧客の種類を更新する) は、オートメーションから分離しておきます。この 2 つのコンポーネントはいずれも、後で同じプロジェクトや異なるプロジェクトで、また異なるロジックで、別々に使用できます。必要に応じて、これらのコンポーネントに引数を介して固有データを渡すことができます。

Change Customer Info (顧客情報の変更) を Get Customer Info (顧客情報の取得) から呼び出すべきではありません。そのようにすると、テスト、例外処理、再利用が難しくなるからです。

注: Get Info (情報の取得) と Change Info (情報の変更) には別々のコンポーネントを使用します。

アクション間の分離がそれほど明確ではない場合、1 つのワークフローから別のワークフロー (1 つのプロジェクトから別のプロジェクト) に既存のコードをコピーして貼り付けることも推奨されます。このようにすると、コード用に別のコンポーネントを構築し、必要に応じて呼び出すべきであることがよくわかります。

再利用可能なコンポーネントを保管する場所

何度も何度もコードを一から作るよりも、既存コードをライブラリからワークフローにドラッグアンドドロップする方が簡単です。サンプルライブラリに追加できる項目の例としては、データの操作 (並べ替え、フィルター) やテキストの操作 (分割、正規表現パターン) があります。ワークフローに追加したコードは静的コードになるため、ライブラリ内のワークフローを更新しても、実稼働中の既存プロセスには反映されないことを考慮に入れてください。

共通 (再利用可能) なコンポーネント (アプリのナビゲーション、ログイン、初期化) はネットワークの共有ドライブに別途保存して維持する方がよいでしょう。保存されたコンポーネントは、このドライブから、さまざまなロボットやさまざまなプロセスにより呼び出すことができます。このアプローチの最大のメリットは、マスターコンポーネントで変更を行った場合、これを使用するすべてのプロセスに即座に反映されることです。

重要: Windows プロジェクトおよびクロスプラットフォーム プロジェクトでは、.xaml および .cs ファイルをプロジェクトの場所の外から呼び出すことはサポートされていません。

オートメーションの品質をチェックする方法

• モジュール性:

  • 懸案事項を分離して専用ワークフローに落とし込むことにより、きめ細かな開発とテストが可能になる。
  • プロジェクト間で再利用可能なコンポーネントやワークフローを抽出して共有する。

• 保守性:

  • 優れた構造と開発基準。

• わかりやすさ:

  • 標準化されたプロセス構造により、明確な開発プラクティスを促す。
  • ワークフロー ファイル、アクティビティ、引数、変数にわかりやすい名前を付ける。

• 柔軟性:

  • 環境設定を外部の構成ファイルまたは Orchestrator インスタンスに保存して、テスト環境でも本番環境でも、オートメーションを簡単に実行できるようにする。

• 信頼性:

  • 例外処理とエラーレポート。
  • リアルタイム実行での進行状況の更新。

• 拡張性:

  • 新たなユースケースの組み込みに対応できる。