トリガーについて

トリガーを使用すると、事前に計画された方法で、定期的に (タイム トリガー)、または新しいアイテムがキューに追加されるたびに (キュー トリガー) ジョブを実行できます。[トリガー] ページでは、新しいトリガーの作成、既存トリガーの管理、既存トリガーのジョブの即座起動を実行できます。

重要:

トリガーのタイムゾーン

トリガーに設定されているタイム ゾーンは、テナントのタイム ゾーンに制限されません。ただし、非稼働日カレンダーを使用する場合は異なるタイムゾーンを設定できません。

タイム トリガーは、トリガー レベルで定義されたタイムゾーンに従って起動されます。キュー トリガーはキュー アイテムの処理に基づいて起動されます。

タイム トリガーとキュー トリガーは、どちらもトリガーのタイムゾーンに基づいて無効化されます。

重要:

トリガーの無効化

既定では、過去 1 日間正常に起動できていないトリガーが起動に 10 回失敗すると、そのトリガーは自動的に無効化されます。

この値は Triggers.DisableWhenFailedCount パラメーターを使用してカスタマイズできます。

タイム トリガー

ジョブを開始するための繰り返し時間をスケジュールできます。

プロセスにタイム トリガーを追加すると、以下が期待できます。

1. トリガーにより、選択した割り当て、アカウント、マシンのオプションを使用して、スケジュールされた時刻にジョブが作成されます。これは、ジョブを実際に実行することと同じではありません。
2. 手順 1 で作成されたジョブは、ロボットが利用可能になると実行されます。既定では、トリガーに既に保留中のジョブがある場合、最初のジョブが実行されるまで新しいジョブは作成されません。
   • トリガーで作成できる保留中のジョブの数は、Triggers.JobsCountStrategy パラメーターによって制御されます。

入力および出力パラメーターをサポートするプロセスの入力値も、このレベルで管理できます。

実行ターゲット

実行する関連プロセスに応じて、いくつかのルールを設定できます。

	説明
動的に割り当て	動的に割り当て 所定のトリガーに従ってプロセスを実行する回数を定義します。このオプションにより、リソースを最大限活用できるようになります。ロボットが使用可能になると、設定されたトリガーに従って対象のプロセスが実行されます。
	アカウント プロセスは、特定のアカウントにより実行されます。アカウントのみを指定すると、Orchestrator によりマシンが動的に割り当てられます。アカウントとマシンの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。
	マシン プロセスは、選択したマシン テンプレートに接続されたいずれかのホスト マシンで実行されます。マシンのみを指定すると、Orchestrator がアカウントを動的に割り当てます。アカウントとマシンの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。 注: ジョブの種類に一致したランタイムが、関連するマシン テンプレートに割り当てられていることを確認してください。アクティブなフォルダーに関連付けられた、接続済みのホスト マシンだけが表示されます。
有効なアカウントとマシンのマッピングを選択	プロセスは、複数のアカウントとマシンのペアで実行できます。

注: 何らかの理由で SQL データベースへの接続が失われた場合、その時点で発生されるはずのトリガーが失敗し、エラー レベルのアラートが生成されます。

キューに置かれたジョブがある場合

1. 同じロボット上に複数のトリガーを設定し、実行時間が少なくとも 1 度重複すると、ジョブが保留中のステートでキューに入ります。ロボットは、時間順にジョブを実行します。

2. 同じプロセスが同じロボット上に複数回スケジュールされていて、それらの実行時間が重複している場合は、1 つのプロセスのみが保留中ステートでキューに入ります。たとえば、ロボット X 上のプロセス A が 11:20、11:21、および 11:25 に実行されるようにスケジュールされている場合、その動作は次のようになります。

   • 11:20 に最初のプロセスが実行されます。

   • 最初の実行が 2 番目のトリガーの前に終了した場合:

     • 2 番目のトリガーが処理されます。

       • この実行が 11:25 のトリガーの前に終了した場合は、後者も実行されます。
       • 11:21 のトリガーの実行が 11:25 のトリガーの前に終了しない場合、後者は保留中のステートでキューに追加されます。
   • 最初の実行が 2 番目のトリガーの前に終了しない場合:

     • 11:21 のトリガーが、保留中のステートでキューに入ります。

       • 11:21 のトリガーの実行が 11:25 のトリガーの前に終了した場合は、後者も実行されます。
       • 11:21 のトリガーの実行が開始され、11:25 のトリガーの前に完了しない場合、後者は保留中のステートでキューに入ります。
       • 11:25 のトリガーが開始される際に 11:21 のトリガーがまだ保留中の場合は、11:25 のトリガーは実行されず、キューにも追加されません。そして、「ロボットには既にこのプロセスに対する保留中のジョブがあります」というメッセージが表示されます。

3. 使用可能な任意のロボットでプロセスを複数回実行する場合、[実行ターゲット] タブで [動的に割り当て] オプションを使用することでそれを実現できます。これらのジョブは、該当のロボット グループでキューに置かれ、保留中のステートになります。ロボットが使用可能になるたびに、保留中のステートの最初のジョブがそのロボットで実行されます。このように、保留中のジョブが存在する間は、ロボットに空きができません。

   それでは、プロセスを 7 回実行する場合を考えてみましょう。トリガーが起動されると、7 つの保留中のジョブがロボット グループのワークロードに追加されます。このとき、特定のロボットへの割り当ては行われません。いくつかのシナリオが考えられます。

   • トリガー時に 7 台以上のロボットが使用可能な場合には、1 台のロボットが 1 つのジョブに割り当てられ、すべてのジョブが一度に処理されます。
   • トリガー時に 7 台未満のロボット、たとえば 4 台しか使用可能にならなかった場合には、4 台のロボットが 1 台ずつ 1 つのジョブに割り当てられ、新たなロボットまたは 4 台のうちの 1 台が使用可能になると、残りの 3 つのジョブのうち 1 つを引き受けます。残りのジョブがなくなるまで、使用可能なロボットのそれぞれでこのような処理が発生します。

4. 同じプロセスが複数のトリガーによって異なる回数実行される場合、次回のトリガーが起動されるときにロボット グループのワークロードに置かれるジョブの数は、各トリガーに設定されている中で最も大きい実行回数までに限られます。ジョブは蓄積されません。たとえば、トリガー A ではプロセスを 13 回実行し、トリガー B では 20 回実行するとします。これにより、次のシナリオが考えられます。

   • A と B が同時にトリガーされた場合 - 20 個のジョブ (13 と 20 のうちの最大数) が環境ワークロードのキューに置かれます。

   • B が最初にトリガーされた場合 - 20 個のジョブがキューに置かれます。

     • B のトリガー時刻と A のトリガー時刻の間に、7 個以上のジョブ、たとえば 9 個のジョブが実行されたとします (残りのジョブは 11 個になります)。この場合、13 個のジョブ (11 と 13 の間の最大値) が環境ワークロードのキューに置かれます。
     • B のトリガー時刻と A のトリガー時刻の間に、7 個未満のジョブ、たとえば 5 個のジョブが実行されたとします (残りのジョブは 15 個になります)。この場合、13 個超のジョブが既に保留中となっているため、これ以上のジョブがキューに置かれることはありません。また、次のメッセージが表示されます。「The Robots already have pending jobs for this process.」(ロボットには、既にこのプロセスで保留中のジョブがあります。)

   • A が最初にトリガーされた場合 - 13 個のジョブがキューに置かれます。

     • A の実行中に B がトリガーされるたびに、進行中または実行された A のジョブの数に応じて、最大 20 個のジョブが環境に追加されます。たとえば、6 個のジョブが実行されたとします。B がトリガーされると、最大数である 20 個が達成されるように、13 個のジョブが追加されます。

5. トリガーで同じプロセスを複数回実行する場合、キューに置かれる関連ジョブの数は、トリガーの定義時に [実行ターゲット] タブで指定した実行回数までに制限されます。これらのジョブは、それぞれのトリガーが起動するたびに蓄積されることはありません。

   それでは、30 分ごとに同じプロセスを 10 回実行する場合を考えてみましょう。初めてトリガーが起動されると、10 件のジョブがキューに入ります。次のトリガーの前に実行されたジョブが 10 件未満である場合 (たとえば 4 件)、次のトリガーが起動されるときは、新しいジョブは 6 件しかキューに入りません。保留中のジョブの数は最大で 10 件までであるからです。

キュートリガー

トリガーの作成時またはキューに新しいアイテムを追加するたびに、プロセスを即座に開始できます。このトリガーは、選択したプロセスに関連付けられている環境で実行されます。

重要: キュー トリガーを実装するのに最適なケースは、処理可能なすべてのキュー アイテムを内部ループで処理してからループを抜けるプロセスを実行する場合です。プロセスにこのストラテジが実装されていない場合、得られる結果は最適なものではなく、求められるビジネス要件を満たさない可能性があります。

プロセス トリガーのルールを設定するときには、以下の 3 つのオプションが役立ちます。

フィールド	説明
最初のジョブをトリガーするアイテムの最小数	アイテム処理ジョブは、ターゲット キューに少なくともこの数の新しいアイテムが追加された後にのみ開始されます。 延期済みのキュー アイテムはカウントされません。
同時に許可される保留中および実行中のジョブの最大数	一緒にカウントされる、許可された保留中および実行中のジョブの最大数。 同時に 2 つ以上のジョブを許容する場合は、次に示す 3 番目のオプションを定義する必要があります。
指定した数のアイテムが追加されるたびにジョブをトリガー	最初のオプションで定義されたアイテムの数に追加された新しいアイテムごとに、新しいジョブがトリガーされます。 2 つ以上のジョブの同時実行が許可されている場合にのみ有効化されます（上記のオプションを使用して定義）。

最適なリソースの割り当てに必要なジョブの数を計算するときに、Orchestrator では新規と処理中の両方のキュー アイテムが考慮されます。

例

1. キューにキュー アイテムを 3 個追加するとします。その場合、Orchestrator は、新しいアイテムと処理中のアイテムの合計数に基づいて必要なジョブの数を算出します。この場合はジョブが 3 つ必要です。Orchestrator は、キュー アイテムを 3 個処理するためにジョブを 3 つ開始します。3 個のアイテムのステータスが [処理中] に変わります。
2. キューに新しいアイテムをさらに 2 個追加します。Orchestrator は、新しいアイテムと進行中のアイテムの合計数に基づいて必要なジョブの数を算出します。この場合はジョブが 5 つ (3+2) 必要です。Orchestrator は、必要なジョブの数 (5 つ) に到達するためにジョブを 2 つ開始します。

キューに登録する段階で処理できないキュー アイテム (リトライ アイテムを含む) を処理するために、未処理のアイテムがないかのチェックが既定で 30 分ごとに実行され、トリガーの条件が満たされると再度トリガーが起動されます。これにより、以下の状況でもキュー内のすべてのアイテムが確実に処理されるようになります。

• キュー アイテムがキューに追加されるタイミングが、利用可能なリソースでアイテムを処理できるタイミングより早すぎる場合。
• 非稼働日にキュー アイテムがキューに追加されたが、それらが処理されるのが稼働時間に限られる場合。

• キュー アイテムの処理が一定期間延期された場合。その期間が経過すれば、それらのキュー アイテムは 30 分ごとのチェックで検出され次第、処理が可能になります。

  注: 既定の 30 分間隔のチェックのため、営業時間外はリソース障害が発生する危険があります。これを避けるために、営業日の終業時に未処理アイテムが存在しないようにしてください。それが不可能な場合は、トリガーされたプロセスがユーザーの介入を必要としないようにしてください。
  注: Queue.ProcessActivationSchedule パラメーターを使用すれば、既定の 30 分のチェック間隔を調整できます。

例

次の 2 つのジョブがあるとします。

• 20 秒間にわたって秒ごとに 3 つのアイテム (合計 60 アイテム) をターゲット キューに追加するジョブ
• ターゲット キューのアイテムを秒ごとに 1 つ処理するジョブ

トリガーを次のように定義します。

• 最初のジョブをトリガーするアイテムの最小数: 31
• 同時に存在してよい保留中および実行中のジョブの最大数: 3
• 10 個の新しいアイテムごとに別のジョブがトリガーされます。

キューにアイテムを追加するジョブを起動します。

1. 11 秒後 (33 アイテムの追加後) に 1 番目のアイテム処理ジョブがトリガーされます。
2. 4 秒後 (12 アイテムの追加後) に 2 番目のアイテム処理ジョブがトリガーされます。
3. 4 秒後 (12 アイテムの追加後) に 3 番目のアイテム処理ジョブがトリガーされます。

キュー アイテムの追加が終了するまでに、1 番目のジョブでは 9 アイテム、2 番目のジョブでは 5 アイテム、3 番目のジョブでは 1 アイテムが処理されています。つまり、これら 3 つのジョブで 20 秒間に 15 アイテムを処理することになります。

これは、45 アイテム (60-15) が未処理で残っていることを意味します。3 つのジョブがあり、それぞれ秒ごとに 1 アイテムが処理されるので、残りのアイテムの処理に 15 秒を要することになります。

処理に要する時間は合計で 35 秒です。

実行ターゲット

実行する関連プロセスに応じて、いくつかのルールを設定できます。

説明
アカウント	プロセスは、特定のアカウントにより実行されます。アカウントのみを指定すると、Orchestrator によりマシンが動的に割り当てられます。アカウントとマシンの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。
マシン	プロセスは、選択したマシン テンプレートに接続されたいずれかのホスト マシンで実行されます。マシンのみを指定すると、Orchestrator がアカウントを動的に割り当てます。アカウントとマシンの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。 注: ジョブの種類に一致したランタイムが、関連するマシン テンプレートに割り当てられていることを確認してください。アクティブなフォルダーに関連付けられた、接続済みのホスト マシンだけが表示されます。

ジョブのカウント方法

Triggers.JobsCountStrategy パラメーターを使用すると、トリガーによるジョブの開始方法を選択できます。次のオプションが利用できます。

• PerProcess (プロセスごと) - 必要な数のジョブをトリガーが開始するにあたって、指定したプロセスで保留中のジョブの数が考慮されます。たとえば、同じプロセスに対して定義された 2 つのトリガーが、それぞれ 3 個のジョブと 5 個のジョブを開始するよう設定されているとします。ある時点で 1 つ目のトリガーが 3 個のジョブを開始している場合、2 つ目のトリガーが実行される際は、必要なジョブ数 (5 個) に達するように 2 個のジョブが開始されます。
• PerTrigger (トリガーごと) - 必要な数のジョブをトリガーが開始するにあたって、同じトリガーによってこれまでに開始された既存のジョブの数が考慮されます。たとえば、あるトリガーがある時点で 9 個のジョブを開始するよう定義されているとします。既に 2 個のジョブが正常に完了している状態でトリガーが再び実行されると、必要なジョブ数 (9 個) に達するようにさらに 2 個のジョブが開始されます。
• NoLimit (制限なし) - 必要な数のジョブをトリガーが開始するにあたって、既存のジョブや保留中のジョブは考慮されません。たとえば、あるトリガーがある時点で 5 個のジョブを開始するよう定義されているとします。同じトリガーが 2 度目に実行される際は、さらに 5 個のジョブが開始されます。

非稼働日

それぞれが独自の日付セットを持つ非稼働日の複数のリストをテナントごとに定義し、必要に応じてトリガーを実行しないように設定できます。つまり、祝日、土日など、通常業務がない日には、長期トリガーが起動されないように設定できます。[設定] ページの [非稼働日] タブでは、そのようなカレンダーを定義またはアップロードできます。既定では、BankHoliday カレンダーが作成され、最初の非稼働日を簡単に定義できます。選択されたカレンダーで定義された非稼働日を過ぎると、通常どおりにトリガーが起動されます。

トリガーにこのような制限を適用するには、新規トリガーの作成時または既存トリガーの編集時に、[非稼働日の制限] ドロップダウンから希望するカレンダーを選択する必要があります。トリガーにはカレンダーを 1 つだけ選択できます。[非稼働日] タブでカレンダーの編集を行うと、[非稼働日の制限] ドロップダウン内で既に選択されているトリガーにも影響します。

注: 非稼働日を使用する場合、トリガーのタイム ゾーンはテナントのタイム ゾーン ([テナント] > [設定] > [全般] タブ) と同じである必要があります。カレンダーの制限は別々のタイムゾーンで適用できないためです。タイム ゾーンが明示的に定義されていないテナントは、ホストからタイム ゾーンを継承します。

注:

非稼働日の追加/削除は、テナント レベルで監査されます。