トリガー

トリガーは、コネクタプラットフォームからのイベントをサブスクライブするための統一されたメカニズムを提供します。Orchestrator でオートメーションを自動的に開始する柔軟性があります。

Orchestrator のトリガー

重要:

2025 年 4 月下旬より、新しい Integration Service トリガーを作成できるのは Orchestrator 内のみです。Orchestrator で作成したトリガーは、Integration Service の [ トリガー] タブに表示されません。既存の Integration Service のトリガーは引き続き実行され、2025 年 7 月 31 日まで [Integration Service の トリガー ] タブに表示され続けます (この日付は延長される可能性があります)。この日以降に、Integration Service の既存のトリガーは Orchestrator に移行され、Integration Service の [ トリガー ] タブは削除されます。この変更は、組織やテナントのリージョンに応じて、まずコミュニティ ユーザーが利用可能になり、その後エンタープライズ ユーザーが段階的に利用可能になる予定です。変更が最初に告知される時期については、 Integration Service のリリース ノートのガイド に従ってください。

Orchestrator のトリガーがもたらす主な利点

Integration Service のトリガーを Orchestrator に移行することは大きな変更ですが、多くのメリットがあります。このアップデートを推進する主な理由は次のとおりです。

1. アカウントとマシンのマッピング: Orchestrator では、Integration Service によってトリガーされるプロセスをマシンレベルで制御できます。
2. ボット固有のプロセス実行制御: Orchestrator では、複数のボットが割り当てられているフォルダー内のプロセスを実行するロボットを指定できます。これにより、トリガーされたプロセスを実行するボットを正確に制御でき、単一のボットフォルダーなどの回避策が不要になり、実行制御を失うことなく複数のボットを許可することでスケーラビリティが向上します。
3. 入力引数と動的なプロセス割り当て: Orchestrator では動的な入力引数を有効化でき、アクティブなプロセスのインスタンスの最大数を定義できます。これにより、動的な引数を許可してプロセスの重複が減るほか、アクティブなプロセスを制限することでリソースの使用を最適化したり、要求を順次管理するプロセスの効率が向上します。
4. 長期実行プロセスの管理の改善: Orchestrator で作成されたトリガーでは、[指定の経過後に停止] オプションと [終了するまで強制終了] オプションがサポートされており、指定した期間または条件の後にプロセスを自動的に終了できます。これにより、長期実行プロセスを終了させることでリソースの過剰使用を防ぎ、応答しないワークフローを停止させることでタイムリーな実行を保証します。
5. 編集機能: Orchestrator では既存のトリガーを編集できます。
6. 統一されたトリガー エクスペリエンス: あらゆる種類のトリガーを 1 か所で作成および管理できます。
7. 単一のトリガー ビュー: トリガーの作成を Orchestrator に移動すると、Integration Service ベースのすべてのトリガーで単一のビューが維持されます。Integration Service ベースのトリガーを Integration Service から特定のコネクタのトリガーを作成する方法と、Studio でトリガー アクティビティを使用してオートメーションを開始する方法の 2 つの方法で作成できるようになりました。2 つのトリガーに表示される設定情報は、同じイベントをキャプチャしていても若干異なる場合があります。

概要

Integration Service のコネクションに基づくイベント トリガーには、次の 2 つの種類があります。

• 接続済み – Studio のトリガー アクティビティで作成され、プロセス内で使用されます。
• 切断済み – Orchestrator または Integration Service で作成され、オートメーションの開始に使用します。

注:

トリガーはコネクションによって異なります。コネクションを削除すると、関連付けられているトリガーもすべて削除されます。

前提条件

トリガーを設定する前に、次の条件が満たされていることを確認してください。

• Integration Service はテナントに対して有効化され、プロビジョニングされている。
• Orchestrator インスタンスで Unattended または NonProduction ロボットが設定済みである。
• モダン フォルダーを使用している (クラシック フォルダー内のプロセスは、トリガーを定義するときに表示されない)
• トリガーを操作するユーザーは、Orchestrator で必要な権限を持っています。トリガーを作成するには、ユーザーは対象のフォルダーで トリガー - 作成 権限を持っている必要があります。権限の詳細については、『Orchestrator ガイド』の「 アカウントのアクセス権を設定する 」をご覧ください。

トリガーの仕組み

[レコードの作成時] や [インシデントの作成時] などのポーリングベースのトリガーは、複数の UiPath コネクタで使用できます。この種類のトリガーは、対象のアプリケーションのパブリック API に対するポーリング メカニズムを使用して、新しいレコードを検出します。

トリガーは次のように動作します。

1. ポーリング間隔 - Integration Service は、設定された間隔 (既定では 5 分ごと) でターゲット システムをポーリングします。ポーリング間隔は接続レベルで設定されるため、ポーリング間隔を変更すると、その接続に関連付けられているすべてのトリガーに影響します。

2. API ベースの検出 - 各ポーリング サイクル中に、Integration Service はベンダーの標準の REST API を使用して、関連するオブジェクト/テーブルに対してクエリを実行します。

3. 増分レコードの識別 - 新しいレコードは API クエリ パラメーターを使用して識別されます。通常は以下に基づきます。

   • レコードの作成タイムスタンプ (例: sys_created_on
   • 一部のシナリオでは、変更のタイムスタンプ

   Integration Service は、最後に成功したポーリング サイクルの最新の作成タイムスタンプ (または同等のマーカー) を保存します。次回のポーリング時に、クエリはその格納された値から再開されるため、継続性が確保され、重複処理が防止されます。

   たとえば、ServiceNow で新しいインシデントをポーリングするクエリは次のようになります GET https://{instance}.service-now.com/api/now/v1/table/incident?sysparm_query=sys_created_on>={last_max_created_date}

   注:

   フィルター処理やデータ シェイプをサポートするために、ページネーション、制限、オフセット、フィールド展開などの追加のパラメーターが含まれている場合があります。これらは、核となる世論調査の論理を変えるものではありません。

トリガーを作成する

接続していないイベント トリガーは Orchestrator から直接作成できます。詳細については、『Orchestrator ユーザー ガイド』の「 イベント トリガー 」をご覧ください。

Orchestrator では、これらのトリガーを直接管理できます。Integration Service では、トリガーを変更するための唯一の選択肢はポーリング間隔を調整することです。ポーリング間隔はコネクション レベルで設定されます。

ポーリング間隔の更新

コネクタはポーリング メカニズムを通じてイベントをサポートしています。

コネクションにイベント トリガーを設定すると、ポーリング間隔は既定で 5 分に設定されます。

ポーリング間隔は接続レベルで設定されます。つまり、1 つの接続に複数のトリガーを作成する場合でも、1 つの接続につき 1 つのポーリング間隔しか設定できません。ポーリング間隔を変更すると、コネクションに関連付けられているすべてのトリガーに影響します。

ポーリングは、選択した間隔でコネクションに実行されます。データが取得されると、そのコネクションに対するアクティブなトリガーはすべてデータ セットに適用されます。ポーリング間隔の変更時にポーリングが実行されている場合は、サービスは既存のポーリングが終了するまで待機してから、新しいポーリングを開始します。

ポーリング間隔を更新するには、次のようにします。

1. 製品ランチャーから [Orchestrator] を選択します。
2. フォルダーを選択して [ コネクション ] タブに移動します。
3. コネクションの右側にある [ その他のアクション ] > [表示/編集 ] を選択して、コネクションの編集ページを開きます。
4. [ イベントを確認する頻度] で、時間間隔を分または時間で選択します。ポーリング間隔は 1 分より長く、24 時間または 1440 分以内である必要があります。
5. [更新] を選択します。

トリガーの実行履歴を表示する

重要:

試行の履歴テーブルは、Integration Service で作成され、[トリガー] タブに一覧表示されるトリガー専用です。試行の履歴 は、Orchestrator で作成されたトリガーでは利用できません。

トリガーの実行履歴を表示するには、以下の手順を実行します。

1. Integration Service で [ トリガー] タブを選択します。
2. 一覧表示されているトリガーで、[その他のアクション] メニューを使用して [トリガーを表示] を選択します

Attemptsの履歴表には、次の情報が表示されます。

• イベント時刻 – イベントがキャプチャされた日時
• 試行回数
• トリガーの状態 – プロセスが正常に起動されたかどうかを示します。

注:

[成功] ステートは、ジョブが正常に起動されたことを示します。ジョブが最後まで正常に実行されたかどうかを反映するものではありません。 ジョブの開始に失敗した場合、[ステート] には [失敗] と表示されます。[失敗] ステートの上にマウス カーソルを置くと、エラー メッセージが表示されます。

ジョブが正常に実行されたかどうかを確認するには、[ ジョブのログを表示 ] ボタンを選択します。この操作を行うと Orchestrator にリダイレクトされ、ジョブの実行に必要なすべての情報を確認できます。

トリガーを管理する

Integration Service で作成されたトリガーに対しては、以下の操作を実行できます。

Orchestrator で直接作成したトリガーは、Orchestrator から管理できます。

トリガーの名前を変更する

トリガーの名前を変更するには、次の手順に従います。

1. [トリガー] タブを開きます。
2. 変更するトリガーの名前の上にマウス カーソルを置きます。[編集] ボタンが表示されます。または、リストからトリガーを選択して詳細を表示することもできます。[編集] ボタンはトリガー名の右側にあります。
3. [ 編集 ] ボタンを選択すると、トリガーの新しい名前を選択できます

トリガーを削除する

[Integration Service] ウィンドウの [トリガー] タブに移動します。トリガーに対応する [ その他のアクション ] ボタンを選択し、[ 削除] を選択します。

トリガーのアクティブ化または非アクティブ化

トリガーをアクティブ化または非アクティブ化するには、まずトリガーを選択して詳細を表示する必要があります。 次に、ウィンドウの左上隅にあるスイッチを選択します。

イベントの引数

切断されたトリガーを使用すると、プロセスをトリガーするコネクタとイベントに関するデータを取得できます。

ワークフローでプロセスを実際にトリガーした、コネクタ、イベント、レコードの種類、またはレコードを確認する場合は、プロセス内で String 型の以下の入力引数を定義します。Integration Service は、ジョブの開始時に自動的に値を設定します。

• UiPathEventConnector - オートメーションを開始したコネクタを特定します。
• UiPathEvent - 発生したイベントの種類を特定します。
• UiPathEventObjectType - イベントによって生成される特定のレコードの種類を定義します。
• UiPathEventObjectId - イベントに関係するオブジェクトの一意の識別子を提供します。

注:

これは接続していないトリガーにのみ適用されます。接続トリガーの場合は、プロセスの設計時にオブジェクト全体が使用可能になっている必要があります。

これらの引数に値を割り当てることはできません。引数はトリガーの実行時に自動的に設定され、Studio の [ 引数 ] パネルから表示または編集することはできません。引数の動作と管理方法の詳細については、Studio のドキュメント「引数を管理する」をご覧ください。

ジョブ実行時にトリガーされたレコードを取得して操作するには、 UiPathEventObjectId 入力引数を使用してソース システムからレコードを取得します。

以下に、Integration Service が入力引数の値を Orchestrator のログに渡す方法の例を示します。

トリガー固有の出力

接続トリガーには、オブジェクト固有の出力があります。たとえば、Microsoft OneDrive & SharePoint の [メールの受信 時] トリガーは、種類が Office365Messageのオブジェクトを出力し、 AttachmentsNamesList、 FromAddress、 InternetMessageId、 SentDateTime などのプロパティを出力します。詳しくは、「 Microsoft OneDrive & SharePoint events」をご覧ください。

Studio の [ 式エディター ] を使用して、任意のトリガー出力オブジェクトで利用可能なすべてのプロパティを表示します。

制限事項

トリガーの制限事項については、このガイドの 「トラブルシューティング 」をご覧ください。詳しくは、「トリガーの制限事項」をご覧ください。

よくある質問

コネクションが切断された場合、そのコネクションに関連付けられているトリガーはどうなりますか?

接続が切断されると、関連付けられたトリガーは一時的に実行を停止します。接続が正常に再接続されると、トリガーは自動的に実行を再開します。追加の手順として、トリガーが無効 ステートになっていないことを確認します。

接続していないトリガーの場合、トリガーの出力をプロセスに関連付けるにはどうすればよいですか?

コネクタおよびプロセスをトリガーするイベントに関するデータの取得方法の詳細については、「 イベントの引数 」セクションをご覧ください。

UiPathEventObjectId 引数を使用することで、 [レコードを取得] または [HTTP アクティビティ] の呼び出しをプロセスに追加して、対応するレコード データを取得できます。

注:

これは接続していないトリガーにのみ適用されます。接続トリガーの場合は、プロセスの設計時にオブジェクト全体が使用可能になっている必要があります。

トリガーのポーリング間隔を変更するにはどうすればよいですか?

ポーリング間隔は、トリガーの設定から直接変更できます。詳細な手順については、このガイド「 ポーリング間隔の更新」をご覧ください。

オートメーションをトリガーするレコードをフィルター処理できますか?

はい。データ フィルター (このアクティビティをサポートするコネクタ用) を追加して、最終的にプロセスを開始するレコードを制御できます。

注:

フィルターは、Integration Service によってレコードが取得された後に適用されます。

例:

• Studio Web でフィルターを作成します。

  

• Orchestrator でフィルターを作成します。

  

トリガーがすぐに起動しないのはなぜですか?

トリガーの実行タイミングは、 トリガーの種類、 データの量、 ロボットの利用可否によって異なります。

ポーリングベースのトリガーの場合:

• トリガーは、Integration Service で設定された ポーリング間隔 に基づいて、新しいレコードまたは更新されたレコードをフェッチします。

• Integration Service は、取得したデータの量に応じて、対象となるイベントを Orchestrator に渡す前に、定義済みのフィルターまたはトリガー条件を適用します。

• この処理では、特にサイズの大きいデータセットや複雑なフィルターを処理する場合に、 わずかな待機時間が発生することがあります。

• イベントが Orchestrator に引き渡されると、その時点で Unattended ロボットが利用可能な場合にのみ オートメーションが開始されます。

• ポーリング間隔の設定が長すぎると、一度に大量のデータが取得され、プロセスの速度が低下する可能性があります。このような場合は、 間隔を短く してパフォーマンスを向上させることを検討してください。

  注:

  トリガーの実行が遅れているように見える場合は、ポーリング間隔を確認し、フィルターの効率性を確認して、Unattended ロボットがジョブの実行に利用できることを確認します。

Webhook ベースのトリガー (例: HTTP Webhook) の場合:

• Webhook トリガーは、イベントが外部アプリケーションから Integration Service に直接送信されるため、 ほぼ瞬時に起動するように設計されています。
• Webhook は通常、 1 つのトランザクションにつき 1 つのレコードを処理するため、待機時間は最小限に抑えられます。
• ただし、イベントが Orchestrator に引き渡される前に トリガー フィルターまたは処理ロジック が適用されていた場合は、わずかな遅延が生じる可能性があります。

起動しないトリガーのトラブルシューティングを行うにはどうすればよいですか?

• 関連付けられているコネクションがアクティブであることを確認します。
• トリガーが 有効化されていることを確認します。
• ポーリング対象のターゲット API エンドポイントにアクセスするために、特定の スコープまたはロール がコネクションに必要かどうかを確認します。
• フィルターが予期されるデータと一致することを確認します。
• Webhook トリガーの場合は、外部アプリケーションで Webhook の登録が有効であることを確認します。

トリガーが初めて記録を取得するのはいつですか?

トリガー の最初の実行 は 、トリガーが作成された時点から始まります。

トリガーが作成される前に作成されたレコードは検出されず、トリガーの作成タイムスタンプより後に作成/更新されたすべてのレコードが、トリガーのフィルターに従って処理対象となります。

デバッグ モードで、トリガーが初めてレコードを取得するのはいつですか?

デバッグ モードでは、開始イベント トリガー (プロセスを開始するトリガー) では、過去 1 時間の イベントが構成時刻を基準として考慮されます。