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

プロセスの理解

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

When Attended Robots Make Sense

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

Reconsidering Attended Robots

Not all processes requiring human input must use Attended Robots. If a judgmental decision is unavoidable, consider splitting the process into smaller sub-processes that can run unattended.

For example, one sub-process could collect data, and after human validation, a second sub-process continues automatically.

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

Benefits and Practical Considerations

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

However, several factors affect this decision:

• Attended Robots typically run only during working hours
• Attended Robots keep machines and users busy until execution completes
• Input types and transaction volumes
• Time restrictions and scheduling
• Number of available Robots

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

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

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

The Runtime Guide should contain a high-level runtime diagram and details about Robot functionality, including sub-processes, schedules, configuration settings, and file management.

Include details on prerequisites, error handling, process resumption, Orchestrator usage, logging, reporting, and credential management.

The Development Details should include packages, development environment, logging levels, source control information, and workflow components with descriptions.

Also include reusable components, invoke trees, custom logs, flowchart snapshots, automation levels, and other development details.

開発とコードのレビュー

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

テスト

After each component is built, conduct unit testing. Thorough component testing ensures smoother integration and faster debugging.

Use the REFramework’s Test_Framework folder for test files. The RunAllTests.xaml file enables automated testing of multiple .xaml files. Run tests outside office hours in testing environments to optimize developer time.

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

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

Use the UiPath.config file or Orchestrator assets to switch environment-specific flags. Define a test mode Boolean parameter to control behavior during debugging.

When True, the automation follows test routes and doesn't execute fully. For example, skip notifications and use Cancel instead of Save. When False, follow normal production routes.

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

リリース

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

ここで提案されているモデルでは、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 開発者の [スニペット] パネルで、この呼び出しリポジトリをポイントします。

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

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

監視

Use Log Message activities to trace process execution for supervision, diagnosis, and debugging. Messages should include transaction IDs and state information for accurate identification.

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

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

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

カスタム ログ フィールド

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