タイム トリガー

重要:

Trigger time zones: The time zone set on a trigger is not restricted by the time zone of the tenant. However, if you use non-working days calendars, you cannot set different time zones.

Time triggers are launched according to the time zone defined on the trigger level. Time triggers are disabled based on the trigger time zone.

繰り返し実行用に設定されたタイム トリガーでは、作成時刻の秒数も考慮されます。変更が cron 式に変換される方法は次のとおりです。

• 12:23:34 に作成され、cron 式　0 * * ? * * (つまり、毎分ごとに実行) が設定されたタイム トリガーの場合、次回の実行時刻は 12:24:34 です。
• 12:23:34 に作成され、cron 式　1 * * ? * * (つまり、毎分一秒が経つごとに実行する設定) が設定されたタイム トリガーの場合、次回の実行時刻は 12:24:01 です。

トリガーの無効化

既定では、トリガーの起動に 10 回連続で失敗し、過去 24 時間以内に正常に起動されていない場合、トリガーは自動的に無効化されます。ただし、これらの条件のいずれかが満たされない場合、たとえばトリガーが 1 日に少なくとも 1 回正常に起動したり、連続する失敗の回数が 10 回に届かなかったりする場合は、トリガーはアクティブなままになります。

注:

トリガーが自動的に非アクティブ化された場合、そのアクションは監査ログに「User System Administrator deactivated trigger」として記録されます。

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

推奨

• トリガーが無効化されている場合は、監査ログでジョブの失敗の理由を確認します。
• 実行時間の長いジョブがある場合は、許可する保留中ジョブの件数を増やすようにトリガーを設定するか、トリガーの実行頻度を減らすようにスケジュールしてみてください。

実行ターゲット

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

	説明
動的に割り当て	動的に割り当て 所定のトリガーに従ってプロセスを実行する回数を定義します。このオプションにより、リソースを最大限活用できるようになります。ロボットが利用可能になるとすぐに、設定されたトリガーに従って対象のプロセスが実行されます。
	アカウント プロセスは、特定のアカウントにより実行されます。アカウントのみを指定すると、Orchestrator によりマシンが動的に割り当てられます。アカウントとマシン テンプレートの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。
	マシン プロセスは、選択したマシン テンプレートに接続されたホスト マシンのいずれかで実行されます。マシン テンプレートのみを指定すると、Orchestrator によりアカウントが動的に割り当てられます。アカウントとマシン テンプレートの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。 注: ジョブの実行に必要なランタイム ライセンスが、関連するマシン テンプレートに割り当てられていることを確認してください。
	ホスト名 マシン テンプレートを選択すると、[ホスト名] オプションが表示され、プロセスを実行する任意のワークステーション/ロボット セッションを選択できます。 アクティブなフォルダーで利用可能なすべてのセッション (未接続、切断、または接続済み) が表示されます。 注: マッピングの設定に使用できるのは Unattended ランタイムのみです。ジョブの実行に必要なランタイム ライセンスが、関連するマシン テンプレートに割り当てられていることを確認してください。
有効なアカウントとマシンのマッピングを選択	プロセスは、複数のアカウントとマシンのペアで実行できます。アカウントとマシンのマッピングの詳細については、こちらをご覧ください。 注: アクティブでない (応答なしまたは切断ステータス) ホスト名を選択すると警告が表示されます。 トリガーに使用されるマッピングの一部であるアカウントを削除したり、トリガーが存在するフォルダーへの割り当てを解除したりすることはできません。アカウントがトリガーで実行ターゲットとして設定されておらず、削除できるようになっていることを確認します。

注:

アクティブでない (応答なしまたは切断ステータス) ホスト名を選択すると警告が表示されます。非アクティブなセッションによって実行されるようにスケジュールされたジョブは、Orchestrator への接続が確立されるまで、保留中ステートのままになります。

• 非アクティブなホスト名の選択に同意するには、[確認] をクリックします。
• 前に戻って別のホスト名を選択するには、[キャンセル] をクリックします。

同じトリガーを同じアカウントとマシンのマッピングで、ただしホスト名を追加で選択して設定すると、実行するジョブの数が 2 倍になります。

• たとえば、アカウント A1 をマシン テンプレート MT1 にマッピングしてトリガー T1 を設定したとします。この設定では、10 個のジョブがキューに登録されます。

その後、同じトリガー T1 を、アカウント A1 をマシン テンプレート MT1 にマッピングして、ただし今回はホスト名 H1 も選択して設定するとします。この場合、同じ 10 個のジョブが再びキューに登録されます。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 件までであるからです。

UiPath Activities を使用して作成されたタイム トリガー

タイム トリガーは、Studio での設計時に UiPath.Core.Activities パッケージの [タイム トリガー] アクティビティを使用して RPA 開発者が作成することもできます。

Orchestrator では、これらの種類のトリガーはパッケージ要件として識別されるので、Orchestrator にこれらのトリガーを追加する場合、[パッケージ要件] ページから追加する方法しかありません。

設計時に設定した構成はすべて Orchestrator に反映され、変更できません。

例: 毎稼働日の午後 6 時に、新しい Excel ファイルをすべてクラウド ドライブに自動的にアップロードしたいと考えています。ここでの違いは、このタイム トリガーはワークフローの内部からオートメーションに開始を指示するのに対し、Orchestrator のタイム トリガーはワークフローの外部から開始を指示するところです。