このトピックでは、Bot 設計の一般的なガイドラインと標準について概要を提供します。以下の一般的な間違いを避け、以下のプロセスや考慮事項を Bot の設計標準に取り入れることで、Bot は読み取り、テスト、保守が容易で、安定したものになります。ガイドラインの大半は、実稼働環境のリソースの使用効率を高めること、または保守時間を短縮しエラーを減らすことを目的としています。

Bot 設計の考慮事項

• ベスト プラクティス

  原則として、Automation Anywhere タスク Bot のコードは 500 行未満、できれば数百行に留めてください。

• プロセスの分割: 巨大なビジネス プロセスを大きな Bot に分割

  ビジネスプロセスの Bot 開発を成功させるために欠かせない要素は、明確に定義され丹念に考案された戦略です。ビジネス プロセスが巨大でサブタスクが 8 個や 10 個も必要な場合、または 1 つのタスクが数千行にもなる場合は、プロセスへの Bot アプローチを再検討します。

  ビジネス プロセスを評価します。得られた知見を、関連する Bot アプローチを作成するときに反映します。

  • ビジネス プロセス自体を簡素化できないかどうか検討します。冗長な手順や回りくどい手順を特定します。

  • プロセス内の論理的な断絶や対立を特定します。

  • ビジネス プロセスの各部を個別の Bot に分割できないかどうか検討します。

• 繰り返しの削減

  繰り返さない (DRY) 原則と、ルール オブ スリーは、どちらも基本的に繰り返しを減らすことを意図しています。

  同じ少数のステップを別々に呼び出すのではなく、1 回で呼び出しを行うループを作成します。

  必要に応じて変数を使用します。

  ロジックやコマンドの繰り返し部分はサブタスクに分割します。コマンドのセットがタスク全体にわたって何回も繰り返されていると、保守が難しくなります。また、更新が必要なときに、すべてのインスタンスを見つけて正確に更新する必要があります。

• 保守計画

  ルールがエンコードされているタスクをレプリケートした後でルールの変更が発生した場合、コードの保守担当者はすべてのレプリケート先でルールを正確に変更する必要があります。このプロセスはミスが生じやすく、よく問題の原因となります。

  コマンドとルールのセットを 1 か所にまとめます。コマンドやルールのセットが 1 か所にだけあると、そこで簡単に変更できます。

• テスト駆動設計

  小さいタスクは、個別に単体テスト形式で簡単にテストできます。依存関係のないタスクには、自動テストを利用できます。タスクを機能別のサブタスクに分割すると、シーケンスの先頭で 1 回だけ実行されるタスクであっても、保守性が高まり、テストしやすくなります。

• ネットワーク障害の処理

  ネットワーク接続に依存する Bot を作成する場合は、ネットワークの遅延に適切に対応する手順を必ず組み込みます。たとえば、[名前をつけて保存] ダイアログを開く場合など、Bot が Web ページからのレスポンスを必要とするときに、ネットワークが切断されたとします。この場合、Bot で対処する方法として、再試行するか、メッセージを出力して終了するかを決めます。

サブタスクの概要

サブタスクは、そのサービスを必要とする親タスクから呼び出されます。サブタスクは、呼び出し元のタスクを補助することだけが目的であるため、ヘルパー タスクまたはユーティリティ タスクとも呼ばれます。

メリット:

• 実稼働タスクのコードが短くなります。

• 変更が必要なときに、サブタスクのみを探して分析し、編集するだけで済みます。これにより、Bot を保守しやすくなります。

• サブタスクは、できるだけ再利用できるようにします。

  適切に分割されたサブタスクは再利用可能にすることで、さらに生産性が高まります。サブタスクは、他のすべてのタスク (他の Bot も含む) から呼び出すことができます。

• サブタスクは、できるだけスタンドアロンにします。

  サブタスクは、完全なスタンドアロン型ではありません。単独で実行されることはありません。親タスクから呼び出す必要があります。ただし、他のタスクとの依存関係はできるだけ排除してください。

サブタスクに関する考慮事項

• 単一責務の原則

  各サブタスクには、1 つのタスクつまり責務を割り当てます。

  大きなタスクをサブタスクに分割すると便利ですが、同じような関連する小タスクをすべて 1 つのサブタスクに一括すると、やはり保守エラーが生じやすくなります。サブタスク内の 1 つの小タスクを変更すると、同じサブタスク内の他の小タスクに影響する場合があります。

  複数のサブタスクを作成して、それぞれに 1 つの専用の目的を持たせることをお勧めします。たとえば、PDF への出力、ファイルの移動、ファイルの保存を処理する大きなサブタスクが 1 つある場合は、これらの目的別に複数のサブタスクに分割します。サブタスク別に独自の責務を割り当てます。たとえば、1 つ目のサブタスクに PDF への出力、2 つ目にファイルの移動、3 つ目にファイルの保存を割り当てます。

• 依存関係の解除

  できれば、呼び出し元のタスクが情報を提供する必要がないようにサブタスクを定義します。情報が必要であることは、依存関係を意味します。依存関係を特定したら、サブタスクの中に取り込みます。これにより、サブタスクがスタンドアロンになり、単体テストを実行できます。また、依存関係を追加することなく他のタスクから呼び出すことができます。

  たとえば、ログイン サブタスクを呼び出すときに呼び出し元のタスクが URL を提供する必要がある場合は、依存関係が存在します。このサブタスクを呼び出すすべての親タスクは URL を提供する必要があります。URL が変更されると、複数のタスクを変更する必要があります。この URL がログイン サブタスクに含まれていると、サブタスクは親タスクから分離されます。URL が変更された場合は、1 つのサブタスクを更新するだけで済みます。

• 双方向の依存関係

  サブタスクを変更するために呼び出し元のタスクも変更する必要がある場合、両者は依存関係にあり、完全には分離されていません。呼び出し元のタスクを変更するためにすべてのサブタスクも変更する必要がある場合、両者は完全には分離されておらず、双方向の依存関係にあります。このように依存関係が相互に入り組んでいると、単体テストはほぼ不可能です。

• 多すぎるサブタスクの回避

  以上のすべての原則は、Bot 設計の優れた原則ですが、サブタスクが多すぎても保守の問題や混乱が生じやすくなります。サブタスクの数は管理可能な範囲に収める必要があります。

  Bot が 30 個のサブタスクを含んでいる場合や、サブタスクなしで数千行に及ぶ場合は、ビジネス プロセスが 1 つの Bot には大きすぎると考えられます。大きなプロセスをいくつかに分割し、それぞれを独自の Bot にカプセル化します。

サブタスクの例

たとえば、Bot でメモ帳のドキュメントを PDF ファイルとして出力する必要があるとします。このタスクは、次のようになります。

この例では、ファイルを PDF ドキュメントとして 3 回出力する必要があります。この例の開発マシンでは、PDF 印刷用ドライバー名は Pdf995 です。

推奨事項:

• 実稼働環境の PDF 印刷用ドライバーは名前が異なる可能性があるため、現実的なオプションとして変数の使用を検討します。

• このタスクは実稼働環境に昇格されて、複数回繰り返されることが考えられるため、これをサブタスクにすることが推奨されます。

この例をサブタスクにした場合:

この特定のコマンド セットに変更が必要になった場合は、このヘルパー タスクのみを編集し、このヘルパー タスクのみを再テストするだけで済みます。