워크플로우 스튜디오 플로우 트리거 유형
각 트리거 유형은 플로우가 시작되는 시점과 사용할 수 있는 시작 데이터를 정의합니다. 기록 작업, 날짜 및 애플리케이션 작업에 대한 트리거가 있습니다.
기록 트리거
기록이 생성되거나 업데이트되면 기록 트리거를 사용하여 플로우를 시작합니다.
| 트리거 | 설명 |
|---|---|
| 작성됨 | 특정 테이블에 기록이 생성되면 플로우를 시작합니다. |
| 업데이트됨 | 특정 테이블에서 기록이 업데이트되면 플로우를 시작합니다. 플로우를 실행할 시기를 선택해야 합니다.
|
| 생성 또는 업데이트됨 | 특정 테이블에서 기록이 생성되거나 업데이트되면 플로우를 시작합니다. 플로우를 실행할 시기를 선택해야 합니다.
|
주:
승인 작업을 포함한 플로우는 트리거를 한 번만 실행해야 합니다. 승인을 업데이트하고 다시 제출해야 하는 경우 a 플로우 논리로 다시 돌아가기 를 사용하여 승인을 다시 요청하는 것이 좋습니다.
REST 트리거
REST 트리거를 사용하여 특정 REST API 요청 후 플로우를 시작합니다.
주:
이 기능을 사용하려면 통합 허브 엔터프라이즈 구독이 필요합니다. 자세한 내용은 Request Integration Hub 문서를 참조하십시오.
| 트리거 | 설명 |
|---|---|
| REST API - 비동기식 | 외부 시스템의 인바운드 API 호출 또는 웹후크에서 플로우를 시작합니다. 사용자 지정 코드를 작성하거나 유지 관리할 필요 없이 트리거 시작 조건을 구성합니다. 자세한 내용은 REST API 트리거를 참조하세요. |
예약 트리거
특정 날짜 및 시간 이후에 또는 예약된 간격으로 반복적으로 플로우를 시작하려면 예약된 트리거를 사용합니다. 예약된 트리거는 인스턴스 시간대를 사용하여 플로우를 시작할 시기를 결정합니다.
주:
플로우는 비동기식으로 처리되기 때문에 예약된 트리거가 있는 플로우는 트리거 조건이 충족된 정확한 예약 시간에 실행되지 않을 수 있습니다. 예를 들어, 핵심 업무 시간 중에 예약된 플로우가 트리거되는 경우 시스템은 예약된 플로우를 실행하기 전에 큐의 다른 이벤트를 처리해야 할 수 있습니다.
| 트리거 | 설명 |
|---|---|
| 매일 | 매일 지정된 시간에 플로우를 시작합니다. |
| 주별 | 매주 지정된 시간에 플로우를 시작합니다. |
| 월별 | 매달 지정된 시간에 플로우를 시작합니다. |
| 한 번 실행 | 지정된 시간에 플로우를 한 번 시작하지만 반복하지는 않습니다. 과거의 날짜 또는 시간을 선택하면 플로우가 가능한 한 빨리 실행되도록 시스템이 예약합니다. |
| 반복 | 사용자가 정의한 일정한 간격으로 플로우를 시작합니다. |
애플리케이션 트리거
애플리케이션 트리거를 사용하여 애플리케이션별 조건이 충족되면 플로우를 시작합니다.
| 트리거 | 설명 |
|---|---|
| Kafka 메시지 | Kafka 환경의 주제에 메시지가 있을 때 플로우를 시작합니다. 자세한 내용은 Kafka 메시지 트리거를 사용하여 플로우 생성 문서를 참조하십시오. |
| MetricBase | 트리거가 충족되면 플로우를 MetricBase 시작합니다. MetricBase 애플리케이션이 필요합니다. 자세한 내용은 트리거를 MetricBase 사용하여 플로우 생성 문서를 참조하십시오. |
| 사전 예방적 분석 | 사전 예방적 분석 KPI 점수 또는 KPI 임계치 값이 충족되면 플로우를 시작합니다. 퍼포먼스 분석 사전 예방적 분석을 구독해야 합니다. 자세한 내용은 사전 예방적 분석 트리거를 사용하여 플로우 생성 문서를 참조하십시오. |
| 서비스 카탈로그 | 항목 요청에서 플로우를 서비스 카탈로그 시작합니다. 자세한 내용은 트리거를 서비스 카탈로그 사용하여 플로우 생성을(를) 참조하십시오. 주: 서비스 카탈로그 트리거는 카탈로그 변수를 트리거 조건의 일부로 지원하지 않습니다. 대신, 플로우의 본문에서 카탈로그 변수를 가져오거나 생성하십시오. |
| SLA 작업 | SLA 정의 기록에서 플로우를 시작합니다. 자세한 내용은 SLA 작업 트리거를 사용하여 플로우 생성을(를) 참조하십시오. |
인바운드 이메일 트리거
인스턴스가 이메일을 수신하면 플로우를 시작합니다.
인바운드 이메일 플로우는 인바운드 이메일 작업보다 우선합니다. 인바운드 이메일 트리거로 플로우를 생성하면 이메일은 인바운드 이메일 작업에 의해 처리되기 전에 인바운드 이메일 트리거에 의해 우선 처리됩니다.
인바운드 이메일 작업을 사용하면 이메일 첨부 파일 처리 또는 이메일의 대상 기록 할당을 완전히 제어할 수 없습니다. 인바운드 이메일 트리거를 사용하여 플로우를 생성할 때 및 기록을 이메일에 연결 작업를 사용하여 이메일 첨부 파일을 기록으로 이동 작업 이러한 작업을 수행할 수 있습니다. 이메일 첨부 파일을 보다 효과적으로 제어하려면 를 이메일 첨부 파일 조회 작업 사용하여 특정 첨부 파일에 데이터 알약으로 액세스할 수도 있습니다.
여러 인바운드 이메일 작업으로 인바운드 이메일을 처리할 수 있지만 기본적으로 여러 플로우가 있는 인바운드 이메일은 처리할 수 없습니다. 추가 구성이 필요합니다. 인바운드 이메일 작업에서 처리를 중지하는 방법에 대한 자세한 내용은 인바운드 이메일 처리 순서 지정을 참조하십시오.
인바운드 이메일에서 여러 플로우를 실행하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오 인바운드 이메일을 처리하도록 여러 트리거 허용.
다음 다이어그램은 인바운드 이메일 트리거에서 인바운드 이메일을 처리하는 방법을 보여줍니다. 이메일이 회신, 전달, 새 이메일로 분류되면 시스템은 해당 이메일을 활성 인바운드 이메일 트리거와 일치시키려고 시도합니다. 이메일이 인바운드 이메일 트리거의 조건을 충족하면 플로우가 실행됩니다. 플로우에서 '처리 중단'을 발행하면 이메일 처리가 종료됩니다. 플로우에서 '처리 중단'을 발행하지 않으면 시스템은 추가 인바운드 이메일 트리거의 조건을 평가합니다. 평가할 인바운드 이메일 트리거가 더 이상 없으면 시스템은 대신 활성 인바운드 이메일 작업과 이메일을 일치시키려고 시도합니다.
중요사항:
인바운드 이메일 플로우는 이메일 발신자를 세션을 시작하는 사용자로 사용합니다. 시스템에서 보낸 사람을 인식하지 못하면 인바운드 이메일 플로우가 게스트 사용자로 실행됩니다. 세션을 시작한 사용자로 실행되도록 인바운드 이메일 플로우를 설정하면 사용자 접근 제어에 의해 플로우 작업이 제한됩니다. 어떤 이유로 시작 사용자에게 상승된 권한이 필요한 경우 인바운드 이메일 플로우가 필요한 역할로 실행되는 하위 플로우를 호출하도록 합니다.
인바운드 이메일 플로우에 대한 접근 제어를 테스트하려면 일반 인바운드 이메일 사용자로 가장하여 플로우를 수동으로 트리거합니다.
스포크 트리거
스포크에는 외부 공급업체 애플리케이션에서 시작하는 조건부 및 이벤트 기반 외부 트리거 또는 웹후크가 있을 수 있습니다. 웹후크는 플로우에 데이터를 제공하는 트리거 역할을 합니다. 예를 들어 외부 공급업체 문제 추적 애플리케이션에서 P1 수준 문제를 만들면 인스턴스의 인시던트 데이터베이스 레코드가 ServiceNow 업데이트됩니다. 이 플로우를 구현하려면 다음 단계를 수행합니다 .
고급 옵션
고급 옵션 섹션에서 플로우를 시작하는 데 필요한 사용자 세션 요구 사항을 지정합니다.
- 플로우 실행 시기
-
플로우를 트리거할 수 있는 세션 유형, 특정 사용자에 의해 트리거될 때 플로우를 실행할지 여부, 플로우를 트리거할 수 있는 테이블을 결정합니다.
표 1. 대화형 세션 드롭다운 메뉴 옵션 옵션 설명 비대화형 세션에 대해서만 실행 비대화형 세션에서만 트리거되는 플로우입니다. 비대화형 세션을 참조하십시오. 사용자 대화형 세션에서만 실행 대화형 세션에서만 트리거되는 플로우입니다. 대화형 세션과 비대화형 세션 모두에 대해 실행 모든 세션에서 트리거되는 플로우입니다. 표 2. 사용자 드롭다운 메뉴 옵션 옵션 설명 다음 사용자에 의해 트리거된 경우 실행 안 함 선택한 사용자 목록에 대해 트리거되지 않는 플로우입니다. 사용자 추가 아이콘( 
)을 선택하여 사용자를 목록에 추가합니다.다음 사용자에 의해 트리거된 경우에만 실행 선택한 사용자 목록에 대해서만 트리거되는 플로우입니다. 사용자 추가 아이콘( )을 선택하여 사용자를 목록에 추가합니다.모든 사용자에 대해 실행 모든 사용자에 대해 실행되는 플로우입니다. 표 3. 테이블 드롭다운 메뉴 옵션 옵션 설명 현재 테이블에서만 실행 선택한 테이블에 대해서만 트리거되는 플로우입니다. 현재 및 확장 테이블에서 실행 선택한 테이블과 확장된 테이블에 대해 트리거되는 플로우입니다. - 플로우를 실행할 위치
-
플로우를 백그라운드에서 실행할지 또는 현재 세션에서 실행할지 결정합니다.
옵션 설명 백그라운드에서 플로우 실행(기본값) 백그라운드에서 비동기식으로 실행되는 플로우입니다. 즉각적인 업데이트가 필요하지 않고 다른 시스템 프로세스를 동시에 실행할 수 있는 플로우에 이 옵션을 사용합니다. 포그라운드에서 플로우 실행 현재 세션에서 동기식으로 실행되는 플로우입니다. 이 옵션을 사용하여 최종 사용자에게 즉시 업데이트를 제공합니다. 예를 들어, 이전 작업이 닫힌 후 플로우에서 작업이 열리는 경우, 사용자가 작업을 닫은 직후에 다음 작업을 열려면 이 옵션을 사용합니다. 주:포그라운드에서 플로우를 실행하면 현재 세션 스레드가 차단되고 플로우가 완료될 때까지 사용자 입력이 차단될 수 있습니다. 스크립트 실행 작업과 같이 중단할 수 없는 작업이 포함된 플로우는 포그라운드에서 실행하지 마십시오. 플로우를 일시 중지하는 작업 또는 플로우 로직은 세션을 차단하지 않습니다.
트리거 유형별 데이터 정제 사용 가능
Flow Designer는 트리거에서 데이터 알약에 액세스할 수 있습니다.
| 트리거 유형 | 데이터 정제 사용 가능 |
|---|---|
| 기록 |
|
| REST API - 비동기식 |
|
| 날짜 |
|
| SLA 작업 |
|
| 인바운드 이메일 |
|
| 메트릭 기본 |
|
| 서비스 카탈로그 |
|
| Kafka 메시지 |
|
일반 가이드라인
기록 트리거를 만들 때 다음과 같은 일반 가이드라인을 따르십시오.
- 플로우에 트리거 또는 변수 입력이 필요한지 여부를 결정합니다.
- 플로우는 트리거 조건이 충족될 때 항상 실행됩니다. 트리거는 항상 플로우에 대한 입력과 동일한 데이터를 제공합니다. 대신 플로우를 시작하기 위해 변수 입력이 필요한 경우 하위 플로우를 생성합니다.
- 플로우를 시작하는 기록 값을 지정하는 조건 추가
- 필요할 때만 플로우를 시작하면 플로우를 시작하고 일시 중지한 다음 특정 기록 조건이 적용될 때까지 플로우 재개를 기다리는 것보다 시스템 자원이 적게 소비됩니다. 대기 조건 동작으로 시작하는 플로우를 생성하는 대신, 대기 조건을 기록 트리거의 일부로 포함하도록 플로우를 다시 설계하십시오.
- 같은 테이블에서 기록 트리거에 대한 고유한 조건 생성
- 플로우가 서로 덮어쓰지 않게 하려면 동일한 테이블에서 실행 중인 각 플로우에 대해 고유한 조건을 생성합니다. 동일한 테이블의 여러 플로우에 동일한 필터 조건이 있는 경우 플로우가 실행되는 순서를 알 수 있는 방법이 없습니다. 조건을 사용하면 더 정확하고 작은 기록 세트를 반환하여 플로우 성능을 최적화하는 데도 도움이 됩니다.
- 임포트 및 업데이트 세트에서 추가 또는 업데이트된 기록 무시
- 기록 트리거는 업데이트 세트를 적용하거나 XML 파일을 임포트하여 추가 또는 업데이트된 기록을 무시합니다. 이러한 작업은 개별 기록이 아닌 전체 애플리케이션 또는 테이블에 적용됩니다.
- 서비스 카탈로그 테이블의 기록 트리거를 서비스 카탈로그 애플리케이션 트리거로 교체
- Flow Designer는 더 이상 Service Catalog 테이블을 기록 트리거에 대한 옵션으로 표시하지 않습니다. 대신 서비스 카탈로그 애플리케이션 트리거 유형을 사용하는 플로우를 생성하십시오.
- 플로우를 트리거하는 사용자에게 트리거 조건 데이터에 대한 액세스 권한이 있는지 확인
- 플로우는 일반적으로 트리거하는 사용자로 실행되므로 사용자가 트리거 조건에 지정된 모든 데이터에 액세스할 수 있는지 확인합니다. 일반 사용자가 액세스할 수 없는 관련 테이블에 대한 트리거 조건을 생성하지 않도록 합니다. 플로우 트리거 조건에 따라 역할 제한 데이터에 액세스해야 하는 경우 해당 데이터에 액세스하는 데 필요한 역할로 플로우를 실행합니다.