再利用可能な Bot のビルド

ガイドラインを見直して、設計や作成から再利用まで、再利用するための Bot の開発またはサブタスクの方法について理解を深めます。

前提条件、入力、出力、変数の定義
再利用のために Bot をビルドする場合は、次を定義します。
  • Bot を単独で、またはサブタスクとして使用する方法について、必要なすべての前提条件を文書化します。
  • Bot を作成するときに、入力、出力、またはローカルとして値を定義します。入力変数と出力変数は、Bot がサブタスクとして使用されるよう設計されている場合に使用され、別の Bot を呼び出す値を送受信できます。
  • 入力変数と出力変数を定義する際に意味のある変数の説明を行い、他の開発者がサブタスクの操作方法を理解できるようにします。
  • 変数の命名ガイドラインについて確立されている基準に従います。変数の命名ガイドラインについては、Automation Anywhere ユーザー定義の変数を確認してください。自分で作成した変数 (ユーザー定義)
単一責務の原則に従う
再利用するために開発された Bot は単一責務の原則に従う必要があります。これは、各サブタスクまたはコンポーネントが全体の Bot の機能の 1 つの部分に対して責任を負うべきであり、その責任は、そのサブタスクまたはコンポーネントによって完全に包含されるべきであるというものです。

単一責務のその他の例

  • 1 つのトランザクションを処理するサブタスク。ただし、リスト上の各トランザクションに対して複数回呼び出すことができます。
  • Web サイトの単一ページに画面表示データを収集するサブタスク。ただし、Bot の改ページを通して複数回呼び出すことができます。
Bot 設計の考慮事項
テンプレートの利用を前提に、以下のパターンを検討します。
  1. プライマリ、メイン、サブの Bot
    • プライマリ Bot: この Bot は、Control Room や API コールによるスケジューリングなどのメカニズムにより、直接呼び出されて処理を開始します。[試行] セクションには以下の主要なプロセス ステップが含まれます。
      1. プロセスの初期設定。
      2. 初期設定が正常に行われたことを検証します。たとえば、必要なファイルやフォルダーがすべて存在するか、変数値の初期値が必要なだけ入力されているかを確認します。
      3. デスクトップの [プロセス前のクリーンアップ] を実行します。
      4. メイン Bot を呼び出して、プロセスのビジネス ロジックを実行します。

      [最終] セクションで、デスクトップの [プロセス後のクリーンアップ] を実行します。

    • メイン Bot: この Bot は必要に応じてサブ Bot を呼び出して、プロセスのビジネス ロジックを実行します。[試行] セクションには以下の主要なプロセス ステップが含まれます。
      1. 入力の検証。例: プライマリ Bot から入力された変数値。
      2. サブ Bot の実行。
      3. 出力の検証。
      4. メイン Bot の実行に基づいて、すべての出力変数の値を確保し、プライマリ Bot に返します。

      [キャッチ] セクションで、エラーを記録し、たとえば [oStrResult] のような出力変数の値を確保して、プライマリ Bot に返します。

    • サブ Bot
      • サブ Bot はプライマリ Bot またはメイン Bot によって呼び出され、オートメーションに必要な実際のビジネス ロジックを実行します。呼び出し元のタスクを補助することだけが目的であるため、ヘルパー タスクまたはユーティリティ タスクとも呼ばれます。
      • 出力変数を使用して、呼び出し元の Bot (メインまたは別のサブ Bot) に結果インジケーターを返します。たとえば、[outStrResult] です。エラーや例外が発生して処理が正常に行われなかった場合は、値にエラーメッセージが含まれます。
  2. メインおよびサブの Botこのパターンでは、プライマリとメイン Bot を 1 つのメイン Bot に含めています。サブ Bot のデザイン パターンは、上記で説明したデザイン パターンに類似しています。
アプリケーションを開く/閉じる
Bot またはサブタスクが開くアプリケーション、ファイル、またはウィンドウは、同じ Bot またはサブタスクによって閉じられる必要があります。
  • たとえば、Bot が Microsoft Excel を開いてスプレッドシート操作を実行する場合、Bot が処理を終了したときにスプレッドシートと Excel が閉じていることを確認します。
  • Bot の実行が成功または失敗したときはアプリケーションを閉じます。
  • [試行/キャッチ/最終] 操作の [最終] ブロックを使用して、タスク処理の成功に関係なくアプリケーションが閉じられるようにします。
  • アプリケーションがテスト中に応答しない場合は、コマンド プロンプトを使用して強制的にアプリケーションを閉じる (強制終了する) ことを検討してください。たとえば、強制的に PowerPoint を閉じるには、コマンド ライン操作は次のようになります。
    Taskkill /IM powerpnt.exe /F
エラー処理
タスクを完了した後、Bot がすべての障害または例外を正常に処理していることを確認します。
  • 各タスクまたはサブタスクは、独自のエラーを処理する必要があります。
  • サブタスクで処理されない例外が発生すると、親タスクで問題を引き起こす可能性があります。
  • すべての Bot のルート レベルで、[試行/キャッチ/最終] ブロックを使用します。
  • 障害を報告する前に操作を複数回試行する場合は、ループ内の [試行/キャッチ] ブロックを使用します。
イベントや例外の処理
[試行/キャッチ] でキャプチャされるアクション エラーを除いて、イベントや例外などの他の処理についてもコード チェックを行う必要があります。特定のプロセス条件が発生した場合、その条件を通知するか、または記録して追加分析を行います。
  • アクションが変わってもコード変更の必要性を最小化する、設定可能なイベント ハンドラー タスク Bot を開発します。たとえば、起こりうるすべてのイベントや例外の定義と、それらのイベントや例外が発生した場合の通知要件を含む XML ファイルを維持します。
  • コード上では、このようなイベントや例外が発生した場合、その情報をイベント ログに書き込みます。また、メモリ使用量の追加やスクリーンショットのキャプチャも可能です。
  • イベント ハンドラー タスク Bot を実行して、イベントや例外を処理します。たとえば、XML ファイルからメール受信者、CC 受信者、件名などのパラメーターを使用して通知を発行します。
  • 環境ごとに通知要件が異なる場合や、時間の経過とともに通知要件が変化する場合にも、コードを変更することなく設定ファイルを更新することが可能です。
他のコンピューターで Bot を実行
Bot を設計する場合は、Bot が作成されたコンピューター以外のコンピューターで実行されるように Bot を有効にします。
  • ローカル ファイル パス、ネットワーク共有、またはウィンドウ タイトルに変数を使用して、Bot を他のマシンから正常に実行できるようにします。
  • 複数の Bot がアクセスを必要としている環境マーカーまたはネットワーク共有にグローバル値を使用することを検討してください。
  • 特定の環境やターゲット アプリケーションのバージョンに関係なく Bot を実行できるように、必要に応じてウィンドウ タイトルにワイルドカード文字を使用します。たとえば、以下の代わりに、
    Salesforce - Professional Edition - Internet Explorer
    以下を使用します。
    Salesforce - * - Internet Explorer
プロンプト、メッセージ ボックス、および無限ループの使用
プロンプトやメッセージ ボックスのアクションは、ユーザーの入力待ちの間は Bot の実行を停止させます。ユーザーの入力が必須の場合を除いて、プロンプト ステートメントを使用しないよう Bot を設計します。
  • ループを使用する場合は、ループの反復回数を明確に定義するか、ブレーク ループ アクションが必要な箇所を指定して、すべてのループに明確な終了があることを確認します。
  • Bot を Unattended Bot として実行する場合は、プロンプトまたはメッセージ ボックスのアクションを削除または無効にします。
  • Attended オートメーションのシナリオで Bot をビルドする場合、メッセージ ボックスとプロンプトは、通常、想定どおりに Bot を実行するために妥当なものであり、必要なものです。メッセージ ボックスを使用して、レスポンス、出力、値などのさまざまな変数を表示します。
Credential Vault への機密データの格納
Control Room には、ユーザー名、パスワード、API キー、トークンなどの機密情報を格納するために使用できる Credential Vault が含まれています。
  • Bot をビルドするときは、Credential Vault を使用して Control Room にロッカーを作成し、資格情報を格納し、必要に応じて資格情報と属性を参照して取得します。これにより、ユーザーは、Bot ビルダーに Bot 内で必要な資格情報を直接ハードコードしてもらう必要なく、API を使用したり、ログインを実行したりする Bot を作成することができます。
  • Bot 内のハードコード化されたストレージはセキュリティ リスクをもたらすため、機密の資格情報を Bot やサブタスクにハードコードしないでください。
  • Bot 内で Credential Vault の値を使用する必要がある場合は、すべての ロッカー 名と資格情報が Bot のドキュメントで明確に定義されていることを確認します。必要に応じて、API キーやトークンなどの資格情報の取得方法の詳細を含めます。
独立したタスクのテスト
再利用のために Bot を作成する場合は、他のサブタスクとは別に独立してテストできるように設計します。
  • テスト駆動開発 (TDD) アプローチの実践: 新しい Bot、またはアプリケーションの新機能を追加する場合は、そのテスト ケースを記述します。
  • テスト ケースでは、その特徴や機能を検証する特定の機能を定義します。
  • 単一責務の原則と再利用のために、独立してテストできる多くの小さなタスクを作成します。
コメントと手順の使用
コメントを使用することで、開発者は Bot 内で説明を入力できるため、他の Bot 開発者は、各セクション、コードのブロック、またはサブタスクが何の目的で設計されているかをより良く理解できます。開発者が指定のコード ブロックの機能の目的を理解できるように、明確なコメントを含めます。
  • Bot が Bot Store に送信されると、コメントは Bot のカスタマイズ方法を示します。
  • コメントを使用すると、開発者が問題を迅速に解決するために変更が必要な箇所をセクションの説明で特定できるため、コードのメンテナンスが容易になります。
  • 作業中の Bot についてのコメントは、将来の作業のプレースホルダーを作成する際に役立ちます。Bot にロジックを追加するための通知として TODO コマンドを使用することを検討してください。ただし、作業が完了したらコメントを更新します。
  • Automation 360 には、読みやすさと流れを改善するために、コードを論理グループにまとめる機能を提供する ステップ アクションが含まれています。
  • 空のラベル付けされた手順のアクションを使用して、Bot の主な目標の概要を作成します。完了したら、各手順に戻り、手順のロジックを完了します。
ログ ファイルの作成
Bot が任意の数の Bot Runner でサーバーから実行を指示して動作している場合、ログなしで問題を特定することは困難な場合があります。ソフトウェア開発者、サポート チーム、および Bot 所有者は、自動化のどこに問題があるか、またどのように問題を診断するかを理解するためにログに依存しています。エラーの詳細を取得するには、Bot がエラーをログする必要があります。
  • Bot やサブタスクでエラーが発生した場合、エラー処理と画面キャプチャを使用して、より理解を深めることができます。
  • 基本的なエラー処理、ログ記録、および古いログ ファイルを保持するためのカスタマイズ可能なルート ログの場所が記載されたスナップショットの各機能を含む A2019 Bot Store のテンプレートを使用します。

    Bot Store Bot テンプレート

  • 必要に応じて、追加のログ ファイルを作成し、Bot またはサブタスクが行ったすべての完全な監査履歴を含めます。追加のログ ファイルには、Bot に関する監査、デバッグ、およびパフォーマンスの各情報のほか、次の情報が含まれます。
    • メイン Bot の開始時刻と終了時刻。
    • サブタスクの開始時刻と終了時刻。
    • Bot 内で定義された特定のマイルストーンの完了時間。
    • 入力ファイルで受信したトランザクションの数。
    • 正常に処理されたトランザクションまたは失敗したトランザクションの数。
See also: ベスト プラクティス: 再利用可能で安全な Automation 360 Bot およびパッケージのビルド