オートメーションのライフサイクル

プロセスの理解

Attended ロボットによるオートメーションと Unattended ロボットによるオートメーションとでは、一般的な実行フレームワーク (ロボットのトリガー、インタラクション、例外処理) が異なるため、オートメーションをどちらの手段で行うかは、開発者によるコード構築方法に影響を与える最初の重要な判断となります。後でもう一方の種類のロボットに切り替える場合、作業が煩雑になる恐れがあります。

コールセンターのように、タイムクリティカルでライブ感があり、人間によってトリガーされるようなプロセスについては、Attended ロボットと人間が協働で作業する方法が唯一の解決策となる場合もあるでしょう。

しかし、人間による入力を必要とするプロセスのすべてに Attended ロボットによる実行が推定される訳ではありません。プロセス中に完全な判断による (ルール ベースではない) 分岐が避けられない場合、フローの変更が可能かどうかを評価します。たとえば、最初のサブプロセスの出力が 2 番目のサブプロセスの入力になる場合では、大きなプロセスを 2 つの小さなサブプロセスに分割することができます。サブプロセス同士の間に人間の介入 (最初のサブプロセスの出力の検証/変更など) があるとしても、両方のサブプロセスは自動でトリガーし、Unattended で実行することが可能です。

典型的なケースは、プロセスのいずれかの段階で手動によるステップが必要なプロセスです。たとえば、チケットの構造化されていないコメントセクションをチェックした後、その結果に基づいてチケットを特定のカテゴリに割り当てるといった場合です。

一般的に、Unattended ロボットを使用した方がロボットの負荷をより効率的にし、ROI が向上し、ロボットのキャパシティを容易に管理・追跡できます。

しかしこういった場合には、Attended ロボットは通常人間の標準的な勤務時間にのみ実行されること、実行が終了するまでマシンとユーザーはビジー状態のままになる場合があることなど、さまざまな側面を考慮に入れる必要があります。入力の種類、トランザクションの量、時間的な制約、利用可能なロボット数なども加味して判断する必要があります。

プロセスを文書化する - DSD

プロセスをドキュメント化することで、開発者が作業する際の指針となり、リクエストやアプリケーションのメンテナンスを追跡する上でも役立ちます。テクニカルドキュメントは数多く存在しますが、その中でも実装を円滑に進めるために極めて重要なのが DSD (Development Specification Document: 開発仕様書) です。

開発仕様書には、オートメーション プロセスの詳細を記載しますが、ランタイム ガイドと開発の詳細の 2 つに重点を置きます。

ランタイム ガイドには、高レベルのランタイム ダイアグラムとともに、ロボットの機能の詳細を記載します (サブプロセス、スケジュール、構成設定、入力ファイル、出力ファイル、一時ファイル、実行されたアクションなど)。マスター プロセスのその他の詳細も指定する必要があります。これには、前提条件、自動/手動エラー処理、障害発生時のプロセス再開、Orchestrator の使用状況、ログおよびレポート、資格情報管理、その他セキュリティまたは機能に関する情報などがあります。

開発の詳細には、使用中のパッケージに関する情報、開発環境、ログ レベル、ソース コードのリポジトリおよびバージョン情報、ワークフロー コンポーネントのリスト (各コンポーネントの説明と引数リストを含む)、再利用可能なコンポーネントのリスト、ワークフローの呼び出しツリー、定義済みのカスタム ログおよびログ フィールド、プロセス フローチャートの関連スナップショット、バックグラウンド/フォアグラウンド オートメーションのレベル、その他のあらゆる関連/未了の開発項目を記載します。

開発とコードのレビュー

RPA ソリューション アーキテクトは責任を持ち、常に開発者に対してベスト プラクティスについてのコーチングを行います。したがって、開発されたワークフローの高品質性を確保するために、頻繁かつ徹底したコードのレビューが不可欠です。これにより、堅牢なワークフローを構築し、ベスト プラクティス ガイドを遵守しようというモチベーションを開発者に与えます。

テスト

各コンポーネントの構築後にユニット テストを実施します。各コンポーネントを徹底的にテストすることで統合が円滑になり、デバッグにかかる時間が短縮されます。REFramework には、Test_Framework フォルダーが含まれており、すべてのテスト ファイルはこのフォルダーに格納されます。開発者は、RunAllTests.xaml ファイルを使用して多数の .xaml ファイルを含むシーケンスを自動的にテストできます。これにより、コンポーネント間の小規模な統合を試したり、ストレス テストを実施したりできます。各テストの最後にレポートが生成されます。通常、こうした種類のテストは、開発者の時間を有効に使うために、テスト環境で勤務時間外に実施します。

推奨される UiPath アーキテクチャには、開発およびテスト環境が含まれており、実稼働中の本番環境外でプロセスをテストできるようになっています。

場合によっては、開発環境とテスト環境、または本番環境でアプリケーションの挙動が異なる場合があるため、セレクターのサニタイズや一部のアクティビティの条件付き実行など、追加のテストを実施する必要があります。

UiPath.config ファイルまたは Orchestrator アセットを使用して、使用中の環境のフラグまたは設定を切り替えます。運用中のアプリケーションとやりとりを行う前に、テスト モード パラメーター (Boolean) をチェックできます。これは、アセット (または引数) の入力として受信できます。このパラメーターが True に設定されている場合は、デバッグおよび総合テストの間、テスト ルートに従い、ケース全体が完全に実行されることはありません。たとえば、テスト パッチは、通知の送信をスキップできます。[OK] ボタンまたは [保存] ボタンをスキップし、代わりに[キャンセル] ボタンまたは [閉じる] ボタンを押します。このパラメーターが False に設定されている場合は、標準の運用 モードのルートに従います。

これにより、変更を行い、実稼働中のシステム内で直接動作するプロセス内でテストすることができます。

リリース

インフラストラクチャの設定や役割の分離に関する問題などを考慮し、アーキテクチャとリリース フローのデザインにはさまざまな方法があります。

ここで提案されているモデルでは、UiPath 開発者がプロジェクトを構築し、Orchestrator 内の開発環境でこのプロジェクトをテストできます。Git、SVN、TFS などのバージョン コントロール システム (VCS) により管理されるドライブに、プロジェクトをチェックインできます。

パッケージをパブリッシュし、テスト環境および本番環境で利用できるようにする作業は、IT 部門など別の部門が担当します。

Orchestrator でのデプロイのパスは、[デプロイ] セクションにある UiPath.Orchestrator.dll.config ファイル内の Storage.Location 値を変更することにより、既定値から VCS が管理するフォルダーへと変更されています。

また、このモデルには、再利用可能なコンポーネントのリポジトリが含まれています。

プロジェクトのパブリッシュのフローについて順を追って説明します。

1. 開発者は、プロジェクトをローカル (Studio) で構築、テスト、デバッグします。
2. オートメーションの開発が完了すると、プロセスが開発の Orchestrator にパブリッシュされ、エンドツーエンドで再度テストされます。
3. プロジェクト フォルダーは、(VCS にある) Master Library フォルダーに (パッケージ化されることなく) コミットされます。
4. IT/RPA 業務部門は、QA 用プロジェクト パッケージを作成します。このステップは、追加の安全策を目的とするものです。オートメーションのソース コードは、パッケージ化される前に (別のエンティティにより) 検査され、ロボットにより実行されます。たとえば、パッケージ化されたプロセスは、VCS 上の Process Pckgs (QA) フォルダーに保存され、ここから QA ロボットにデプロイされて実行されます。
5. テスト中に問題を検出した場合は、上記のステップを繰り返します。
6. すべての QA テストに合格したパッケージは、運用環境 - Process Pckgs (Prod) にコピーされます。
7. このプロセスが実稼働中になると、プロセスパッケージは本番環境のロボットにデプロイされて実行されます。

再利用可能なコンテンツが UiPath コード (再利用可能コード ライブラリ) および呼び出し (呼び出しリポジトリ) として別途作成され、デプロイされます。

ソース コードを持つワークフローは、SAP へのログインなど、共通プロセスの自動化用アクティビティを含む .xaml ファイルです。

呼び出しは、上記のコード ワークフローのうち、1 つの呼び出しアクティビティのみで構成されるワークフローを表します。

再利用可能なコンテンツに簡単にアクセス (ドラッグアンドドロップ) できるようにするには、Studio 開発者の [スニペット] パネルで、この呼び出しリポジトリをポイントします。

再利用可能なコンテンツのメンテナンスを担当するローカルのデザイン責任者が (たとえばプロセスの変更により) コードを持つワークフローを更新します。呼び出しは変更されないままです。

このアプローチでは、プロジェクトには変更されたワークフローの呼び出し しか含まれていないため、再利用可能なコンポーネントへの変更が完了すると、実行中のプロジェクトすべてに同様に変更が反映されるという点がメリットになります (ソース コードのライブラリと直接やりとりする方法と比較した場合)。

監視

[メッセージをログ] アクティビティを使用して実行中プロセスの進化を追跡することは、プロセスの監視、診断、デバッグを行う上で重要です。メッセージは、トランザクション ID やステートなどを含む状況を正確に特定するための関連情報をすべて伝えるものです。

次のタイミングでログを使用します。

• 各ワークフローの最初および最後
• 外部ソースからのデータを受け取ったとき
• 最も高次なレベルで例外が検出された都度

メッセージは、指定された優先順位 (Info、Trace、Warning など) で Orchestrator に送信され、ローカルの .nlog ファイルにも保存されます。

カスタム ログ フィールド

レポートを目的として Kibana でデータを簡単に利用できるようにするために、ロボットは、[ログ フィールドを追加] アクティビティを使用して、追加の値でログ メッセージをタグ付けする場合があります。既定では、UiPath のログ出力フィールドは、message、timestamp、level、processName、fileName、およびロボットの Windows ID などが既に含まれています。ログ フィールドは永続的なものであるため、すべてのメッセージをタグでマークする必要がない場合には、[ログ フィールドを削除] アクティビティを使用して、ログ後直ちにフィールドを削除する必要があります。既に存在するフィールド名は使用しないでください。フィールドを追加する際には、正しい型の引数を指定することが重要です。以下に Elasticsearch がこれをどのようにインデックス化するかを示します。