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

プロセスの理解

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

Attended ロボットが役立つ場合

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

Attended ロボットの再考

人間の入力を必要とするすべてのプロセスで Attended ロボットを使用する必要はありません。判断を下すことが避けられない場合は、プロセスを、無人で実行できる小さなサブプロセスに分割することを検討してください。

たとえば、あるサブプロセスでデータを収集し、人間による検証の後、2 番目のサブプロセスが自動的に続行されます。

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

利点と実際的な考慮事項

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

ただし、この決定にはいくつかの要因が影響します。

• Attended ロボットは通常、勤務時間中にのみ実行されます
• Attended ロボットは、実行が完了するまでマシンとユーザーをビジー状態に保ちます
• 入力の種類とトランザクション量
• 時間制限とスケジュール
• 利用可能なロボットの数

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

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

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

ランタイム ガイドには、高レベルのランタイム ダイアグラムと、ロボットの機能 (サブプロセス、スケジュール、構成設定、ファイル管理など) の詳細が記述されている必要があります。

前提条件、エラー処理、プロセスの再開、Orchestrator の使用状況、ログ、レポート、資格情報の管理に関する詳細を含めます。

[開発の詳細] には、パッケージ、開発環境、ログ レベル、ソース管理情報、ワークフロー コンポーネントとその説明を含める必要があります。

また、再利用可能なコンポーネント、呼び出しツリー、カスタム ログ、フローチャート スナップショット、オートメーション レベル、その他の開発の詳細も含まれます。

開発とコードのレビュー

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

テスト

各コンポーネントを構築したら、単体テストを実行します。徹底的なコンポーネントテストにより、よりスムーズな統合と迅速なデバッグが保証されます。

テスト ファイルには、 REFramework の Test_Framework フォルダーを使用します。RunAllTests.xaml ファイルを使用すると、複数の .xaml ファイルを自動テストできます。テスト環境で業務時間外にテストを実行して、開発者の時間を最適化します。

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

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

UiPath.config ファイルまたは Orchestrator アセットを使用して、環境固有のフラグを切り替えます。デバッグ中の動作を制御するテスト モードの Boolean パラメーターを定義します。

オン の場合は、オートメーションはテスト ルートをたどり、完全には実行されません。たとえば、通知をスキップして、[保存] ではなく [キャンセル] を使用します。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 がこれをどのようにインデックス化するかを示します。