トリガー

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

重要:

• トリガーの実行時間は、特定のタイム ゾーンに合わせて調整できます。トリガーに設定されているタイム ゾーンは、テナントのタイム ゾーン ([設定 ] ページで設定します) と連携していません。

タイム トリガー

ジョブを開始するための繰り返し時間をスケジュールできます。入力および出力パラメーターをサポートするプロセスの入力値も、このレベルで管理できます。実行する関連プロセスに応じて、いくつかのルールを設定できます。

すべてのロボット	特定のロボット	動的に割り当て
特定のロボット グループのすべてのロボットで、トリガーされたジョブが開始されます。	ユーザーが選択したロボットによって、トリガーされたジョブが実行されます。	所定のトリガーに従ってプロセスを実行する回数を定義します。このオプションにより、リソースを最大限活用できるようになります。ロボットが使用可能になると、設定されたトリガーに従って対象のプロセスが実行されます。

注: 何らかの理由で 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 つを引き受けます。残りのジョブがなくなるまで、使用可能なロボットのそれぞれでこのような処理が発生します。

     注: [動的に割り当て] オプションを使用すれば、1 つのジョブでプロセスを最高 10,000 回実行できます。

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 がトリガーされた場合は常に、20 個以下のジョブが環境に追加されます。追加されるジョブ数は、A で進行中のジョブ数および実行済みのジョブ数によって変わります。たとえば、6 個のジョブが実行されたとします。B がトリガーされると、最大数である 20 個が達成されるように、14 個のジョブが追加されます。

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

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

   注: 特定のロボットに直接割り当てられたジョブは、動的に割り当てられたジョブに優先してされます。また、ロボットが 2 つ以上の環境に属する場合、ジョブは作成された順に実行されます。

キュートリガー

新しいキュー アイテムがキューに置かれるたびにプロセスをトリガーできます。このトリガーは、選択したプロセスに関連付けられている環境で実行されます。

プロセス トリガーのルールをパラメーター化するのに役立つ 3 つのオプションがあります。

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

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

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

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

  注: 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 秒です。

非稼働日

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

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

注: カレンダーの制限は異なるタイムゾーンに適用できないため、テナント レベル ([設定] ページ > [全般] タブ) で設定されたタイムゾーンとは異なるタイムゾーンではトリガーを保存できません。タイムゾーンが明示的に定義されていないテナントは、ホストからタイムゾーンを継承します。

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