트리거

코드를 작성하지 않고 트리거를 사용하여 앱 내 로직을 구축하는 방법을 알아보세요.

이 기사에서는 다음 내용을 다룹니다:

• 트리거 명령어, 논리, 실행 동작
• 트리거 구축 및 구성에 대한 모범 사례
• 일반적인 사용 사례

트리거를 사용하면 앱에 논리를 추가할 수 있습니다. 트리거를 활용하면 단 한 줄의 코드도 작성하지 않고도 기기와 상호작용하고, 알림을 전송하며, 데이터를 기록하고, 백엔드 시스템과 통신하는 등의 작업을 수행할 수 있습니다.

트리거의 일반적인 사용 사례는 다음과 같습니다:

• 앱 내 이동: 전환 기능을 사용하여 다른 단계로 이동합니다.
• 앱 완료: 앱의 메타데이터를 기록합니다.
• 백엔드 시스템에 액세스하기 위해커넥터 함수 실행: 커넥터를 사용하여 Tulip이 타사 시스템과 상호 작용할 수 있도록 하고, 트리거를 통해 커넥터 함수를 실행합니다.
• 알림 전송: 앱에서 관리자에게 이메일이나 SMS 알림을 보냅니다. 이 메시지에는 이미지, 프로세스 상태 정보 또는 기타 관련 정보가 포함될 수 있습니다.
• 데이터 저장: 앱에서 입력된 데이터를 변수나 테이블에 저장합니다.
• 장치 사용: 프로세스 진행 중 양손을 모두 사용해야 하는 작업자의 경우, 풋페달과 같은 장치 이벤트에 대한 트리거를 추가하여 다음 단계로 진행할 수 있습니다.

트리거는 어떻게 작동하나요?

논리

트리거는 ‘when, if, then, else’ 논리 구조를 사용합니다:

• when "Tulip에 이벤트가 등록되면"
• then "조치 수행" 또는 "전환".

트리거에는 조건부 논리도 포함될 수 있습니다:

• when "Tulip에 이벤트가 등록되면"
• if "조건이 충족되면"
• 그때 "조치를 취한다"
• 그렇지 않으면 "다른 조치를 취한다"

조건부 트리거 논리에 대한 자세한 내용은 여기에서 확인하세요.

트리거는 Trigger Event로 묶여 있으며, 액션과 조건문으로 구성됩니다.

트리거는 아래 예시와 같이 간단할 수 있습니다:

버튼이눌 리면 다음 단계로 이동합니다.

또는 바코드를 스캔하여 백엔드 데이터베이스에 쿼리를 보내 주문 정보를 변수로 반환하는 것과 같이 더 복잡한 트리거도 가능합니다.

현재 스테이션에서 바코드 스캐너가 데이터를출력하면 , (커넥터 함수를 통해 실행)이 외부 데이터베이스에서 주문 세부 정보를 가져와 해당 값을 변수에 저장합니다. 또한 트리거는 다음 단계로 전환 됩니다.

명령어 유형

트리거에서는 두 가지 유형의 명령을 사용할 수 있습니다:

1. 액션(Action): 단계 변경과 관련이 없는 앱 내의 변경 사항(예: 오류 메시지 표시, 이메일 전송, 앱 스크린샷 캡처)
2. 전환: 앱 내의 탐색 이벤트(예: 다음 단계로 이동, 앱 완료, 앱 취소). 전환은 다른 트리거를 발동(즉, 시작)시킬 수 있습니다. 예를 들어, 앱이 완료될 때마다 발동되는 앱 수준 트리거를 생성할 수 있습니다.

트리거 대기열

Trigger Event(예: 버튼 클릭)는 Tulip Player에서 실행될 트리거를 순차적인 단일 스레드 Trigger Queue에 추가합니다.

은 다음 요소에 영향을 미칩니다: 1. 함수: * 함수는 트리거 대기열에 포함됩니다. 2. 사용자 정의 위젯: * 사용자 정의 위젯 내 로직의 실행은 트리거 대기열에 영향을 미칠 수 있습니다.

실행 순서

트리거는 Trigger Event (예: 버튼 클릭, 타이머, 테이블 행 선택)에 따라 순차적으로 실행됩니다.

트리거는 순차적으로 실행되므로, 일련의 트리거 중 첫 번째 트리거가 완료되어야 두 번째 트리거의 실행이 시작됩니다. 이러한 트리거 실행 순서를 트리거 큐라고 합니다.

트리거 큐는 변수 상호작용(예: 텍스트 입력, 체크박스), 사용자 정의 위젯, 사용자 정의 위젯 자바스크립트와 같은 앱 내의 다른 작업들과는 별개입니다.

트리거에서 입력 값은 어떻게 사용됩니까?

입력 값(즉, 변수)은 참조 방식으로 트리거에 전달됩니다.

트리거는 트리거 실행 시점의 변수 입력값을 참조합니다. 트리거가 실행되기 전에 입력값이 변경되면, 트리거는 가장 최신 값을 참조합니다.

변수는 앱 전체에 적용되는 전역 변수이므로, 앱 내의 다른 로직에 의해 변경될 수 있습니다.

:

트리거는 언제 취소되나요?

다음과 같은 경우 트리거 대기열에 있는 트리거가 취소되어 실행되지 않습니다.

1. **전환 후 트리거가 대기열에 추가된 경우:**전환(예: 다음, 앱 완료, 이름으로 단계 이동 등)이 실행되면 대기열에 남아 있는 모든 트리거가 취소됩니다.
2. Tulip Player 강제 종료:운영자가 플레이어를 강제 종료하는경우(예: 앱이 응답하지 않는 경우), 실행 중인 트리거에 남아 있는 모든 작업과 대기열에 남아 있는 모든 트리거가 취소됩니다.

오류 처리

다음과 같은 상황에서는 트리거 오류가 발생하고 이에 따른 취소가 이루어집니다:

1. 트리거 액션 오류
2. 트리거 시간 초과

트리거 작업 오류

트리거 내의 작업에서 오류가 발생하면, 해당 트리거에 남아 있는 나머지 작업들은 건너뛰거나 취소됩니다:

오류 발생 후, 기본적으로 대기열 및 트리거 이벤트에 남아 있는 나머지 트리거는 다음 앱 및 단계 수준 트리거에 대해 실행되지 않습니다:* 앱 시작* 앱 완료* 앱 취소* 단계 진입 시* 단계 종료 시

그 외 모든 유형의 트리거(예: 버튼이 눌렸을 때)의 경우, “오류 발생 시 나머지 트리거 중지” 토글은 기본적으로 비활성화되어 있습니다.

트리거 타임아웃

트리거가 타임아웃된 경우( 트리거 타임아웃 참조), 큐에 남아 있는 모든 트리거가 취소됩니다.

기술적 동작

트리거 실행 시간

• 트리거는 단일 트리거 실행 시간 내에 순차적으로 실행됩니다. 트리거 실행 시간이란 Tulip에서 트리거가 활발하게 실행되는 기간을 의미합니다.
• 트리거는 절대 병렬로 실행되거나 다른 트리거의 백그라운드에서 실행되지 않습니다. 현재 실행 중인 트리거가 완료되기 전까지는 새로운 트리거의 실행이 시작될 수 없습니다.
• 트리거가 실행되는 동안에도 운영자는 앱과 상호 작용할 수 있습니다(예: 버튼 클릭, 테이블 조작). 이러한 버튼 클릭 및 기타 트리거 이벤트는 트리거 대기열에 새로운 트리거를 추가합니다.

트리거 타임아웃 - LTS15 / r332 기준 업데이트됨

기본 트리거 타임아웃 기간은 10분이며, 이 시간이 지나면 트리거와 남아 있는 모든 작업이 취소되고, 대기열에 있는 다른 모든 트리거도 취소됩니다.

이 10분 타임아웃 기간은 Trigger Event에 적용됩니다. 예를 들어, 버튼 클릭에 5개의 트리거가 연결된 경우, 트리거 대기열에 있는 5개의 트리거와 각 트리거에 해당하는 작업은 모두 10분 이내에 실행되어야 합니다.

트리거 실행 시간이 30초가 지나면 앱은 운영자에게 다음 메시지를 표시합니다:

트리거 실행 시간이 100초가 지나면 앱은 운영자에게 다음 메시지를 표시합니다:

10분이 지나면 트리거가 취소되고 앱은 운영자에게 다음 오류 메시지를 표시합니다:

선택적 타임아웃 설정

아래 방법을 통해 인스턴스의 타임아웃 설정을 편집할 수 있습니다:

1. Tulip은 운영자가 처음 100초가 지난 후 장시간 실행 중인 트리거를 수동으로 취소할 수 있도록 하는 설정을 활성화하거나 비활성화할 수 있습니다. 이 기능을 활성화하려면 Tulip 지원팀에 문의하십시오.

2. Tulip 지원팀은 타임아웃 기간을 단축하거나 연장할 수 있습니다. 단 , 로직이 정상적으로 완료될 가능성을 높이기 위해 Tulip에서는 10분 타임아웃 기간을 기본값으로 권장합니다. 트리거 실행에 지속적으로 몇 분 이상 소요되는 경우 다음 사항을 고려해 보십시오:

   • 트리거 로직을 단순화하여 운영자의 사용자 경험을 개선하고 트리거 실패 가능성을 줄이십시오.
   • 가능하다면 백그라운드에서 자동화를 시작하여 로직 실행을 분산시키고, 운영자의 후속 작업이 차단되는 것을 방지하십시오.
   • 트리거 로직 내의 타사 시스템에 대한 종속성(예: 느린 커넥터 함수, 비최적 API 사용)을 검토하고 최적화하십시오.

테이블 레코드 작업

테이블 레코드 생성

새 테이블 레코드를 생성할 때, 모범 사례는 테이블 레코드/레코드 생성 작업 직후에 해당 데이터 조작 작업을 수행하여 새로 생성된 테이블 레코드의 다른 열을 채우는 것입니다.

테이블 레코드/생성 작업과 다른 열을 채우는 작업 사이에 다른 작업이 있는 경우, 해당 테이블 레코드의 생성은 레코드 기록 위젯에 별도의 이벤트로 표시됩니다.

테이블 레코드 생성 – LTS15 / r332 기준

LTS15부터 ‘테이블 레코드 / 레코드 생성 ’ 및 ‘데이터 조작 / 저장 ’과 같은 순차적인 테이블 작업은 동일한 레코드에 대해 묶여 처리됩니다. 즉, 트리거 내의 ‘생성’ 및 ‘데이터 조작’ 작업이 하나의 트랜잭션으로 실행됩니다.

'레코드 생성'과 '데이터 조작 / 저장' 작업 사이에 다른 작업 (예: 변수 또는 다른 테이블 레코드에 대한 데이터 조작, 커넥터 함수 등) 이 존재하는 경우, 이 두 작업은 하나의 트랜잭션으로 묶이지 않습니다.

다음 예제 트리거에서 ‘레코드 생성’ 작업과 ‘데이터 조작 / 저장’ 작업은 묶여 처리되며, 모두 성공하거나 모두 실패하게 됩니다. 작업이 모두 실패할 경우, 복원력 있는 재시도(resilient retries)를 통해 함께 재시도됩니다.

예제 1: 동일한 테이블 레코드에 대한 순차적인 레코드 생성 및 데이터 조작LTS15에서는이작업들이 모두 성공하거나 모두 실패하지만, LTS12 이전 버전에서는 그렇지 않습니다.

예제 2: 동일한 테이블 레코드에 대한 순차적인 생성 및 데이터 조작 작업 후 커넥터 함수 작업이 이어지는 경우LTS15에서는 테이블 레코드 생성 및 데이터 조작 작업 자체가 묶입니다. 커넥터 함수 작업은 테이블 작업의 성공 여부와 관계없이 실패할 수 있습니다.

다음 트리거에서는 두 개의 서로 다른 테이블 레코드에 대해 데이터 조작/저장 작업이 수행되므로, 해당 작업들은 단일 트랜잭션으로 묶이지 않습니다.

예 3: 다른 데이터 조작 액션으로 분리된 동일한 테이블 레코드에 대한 테이블 레코드/생성 및 데이터 조작/저장. 이 액션들은단일 트랜잭션으로 묶이지 않습니다.

다음 트리거에서, 이전 작업에서 생성된 테이블 레코드의 메타데이터가 데이터 조작 / 저장 작업의 데이터 입력으로 사용되므로 테이블 레코드 작업과 데이터 조작 / 저장 작업은 하나의 트랜잭션으로 묶이지 않습니다.

예 4: 자체 데이터를 읽어와 생성 및 업데이트하기. 이 작업들은 단일 트랜잭션으로 묶이지 않습니다.

묶인 테이블 업데이트 작업에서 집계 기능을 사용할 경우, 집계 값은 업데이트가 발생하기 전에 산출됩니다. 집계 값에는 묶인 테이블 레코드 업데이트 내용이 반영되지 않습니다.

예 5: 집계 기능을 사용한 생성 및 업데이트: 이 작업들은 묶여 처리되며, 집계 값은 생성 작업이 수행되기 전에 산출됩니다.

테이블 레코드 업데이트

동일한 테이블 레코드에 대한 순차적인 데이터 조작 작업은 하나의 네트워크 요청으로 묶여 실행되므로, 모두 동시에 수행됩니다.

테이블 레코드와 관련된 트리거 작업은 작업 유형과 순서에 따라 그룹화됩니다. 저장 위치가 동일한 저장 작업은 하나의 네트워크 요청으로 그룹화됩니다. 반면, 레코드 로드나 레코드 생성 같은 작업은 개별 트랜잭션으로 처리됩니다.

최상의 성능을 위해, 동일한 레코드에 대한 업데이트는 연속적으로 수행할 것을 권장합니다. 즉, 동일한 레코드에 대한 업데이트를 다른 테이블 또는 데이터 작업과 분리하지 마십시오.

예 1: 동일한 레코드에 대한 순차적 업데이트 다음작업들은 하나의 트랜잭션으로 묶입니다:

예 2: 다른 작업으로 분리된 동일한 레코드에 대한 업데이트: 동일한 테이블 레코드가 순차적이지 않으므로, 다음 작업들은 하나의 트랜잭션으로 묶이지 않습니다:

다음 트리거에서는 두 개의 서로 다른 테이블 레코드에 대해 데이터 조작/저장 작업이 발생하므로, 해당 작업들은 단일 트랜잭션으로 묶이지 않습니다.

예 3: 서로 다른 두 레코드에 대한 업데이트: 이러한 작업들은 단일 트랜잭션으로 묶이지 않습니다.

묶인 테이블 업데이트 작업에서 집계 기능을 사용할 경우, 집계 값은 업데이트가 발생하기 전에 산출됩니다. 집계 값에는 묶인 테이블 레코드 업데이트 내용이 반영되지 않습니다.

**예 4: 집계 연산을 포함하는 업데이트:**이러한 작업은 묶이게 되며, 이는 업데이트가 발생하기 전에 집계 값이 계산됨을 의미합니다.

트리거(테이블 작업) 재시도 - LTS15 / r332부터 새로 추가됨

트리거는 테이블 작업 (예: 테이블 데이터 쓰기, 테이블 데이터 업데이트, 테이블 상호작용 등)만 재시도합니다.

트리거 실행 시간 10분 이내에 단일 테이블 작업이 실패하면 최대 2분 동안 재시도됩니다. 2분이 지나도 작업이 실행되지 않으면 트리거 대기열에 남아 있는 나머지 작업과 트리거는 모두 취소됩니다.

네트워크 내성을 갖춘 트리거를 사용하려면, 트리거의 작업에 테이블 상호작용 및 데이터 업데이트만 포함되도록 하십시오. 내성 있는 테이블 작업에 대한 지침은 '테이블 레코드 작업'을 참조하십시오.

트리거 작업 재시도 시, 작업이 실수로 두 번 실행되더라도 결과가 중복되지 않습니다. 이를 통해 테이블 작업이 동일한 데이터를 여러 번 기록하는 일이 없도록 보장합니다.

제한 사항 및 시간 초과

트리거 유형

트리거에는 세 가지 유형이 있습니다.

앱 수준 트리거

앱 수준 트리거는 다음 이벤트에 적용할 수 있습니다:

• 앱 시작
• 앱 완료
• 앱 취소

'앱' 탭에서 앱 수준 트리거에 액세스할 수 있습니다.

앱 수준 트리거에 대한 자세한 내용은 여기에서 확인하세요.

단계 수준 트리거

다음 이벤트에 단계 수준 트리거를 적용할 수 있습니다:

• 정기적인 시간 간격 (“시간 기반 트리거”)
• 기계 또는 장치에서 입력이 있을 때(“기계 및 장치”)
• 단계가 열릴 때
• 스텝이 닫힐 때

‘스텝’ 탭에서 스텝 수준 트리거에 액세스할 수 있습니다.

사용 가능한 스텝 수준 트리거에 대한 자세한 내용은 여기에서 확인하세요

위젯 트리거

위젯 트리거는 버튼이 눌릴 때 활성화됩니다. 하나의 스텝에 여러 개의 버튼 트리거가 있을 수 있으며, Tulip Player에서 운영자가 해당 버튼을 누르면 트리거가 실행됩니다.

원하는 위젯을 선택한 다음, ‘위젯’ 탭에서 위젯 트리거에 액세스할 수 있습니다.

위젯 트리거에 대한 자세한 내용은 여기에서 확인하세요.

트리거 생성

1. Side Pane에서 '트리거' 섹션의 +를 클릭합니다. 트리거 편집기가 열립니다.
2. 앱에서 해당 트리거가 어떤 역할을 하는지 알 수 있도록 이름을 지정하세요. 자세한 내용을 설명하는 설명도 추가할 수 있습니다.

모범 사례

• 오류발생 시대응할 수 있도록 트리거 구성: 트리거는오류 발생 시 진행하거나 중지되도록 구성해야 합니다. 트리거는 잘못된 입력, 실행 오류, 커넥터 함수 실패 또는 테이블 쓰기 시도 실패로 인해 오류가 발생할 수 있습니다.
• 트리거가 계속 진행되도록 설정된 경우, 오류가 발생한 트리거는 중지되지만 다음 트리거는 계속 진행됩니다.
• 트리거가 중지되도록 구성된 경우, 해당 트리거 이벤트에 포함된 다른 트리거들은 모두 취소됩니다.

• 대화형 위젯이 포함된 단계에서는 실행 시간이 긴 트리거를 피하십시오. 위젯은상호작용이 발생하면 즉시 상태가 시각적으로 변경됩니다. 운영자는 위젯에서 동작이 즉시 일어나는 것을 볼 수 있지만, 네트워크 속도가 느리거나 실행 시간이 긴 커넥터로 인해 로직이 약간 지연되어 실행될 수 있습니다.
• 운영자에게 전환(예: 다음 단계)을 클릭한 후 기다리도록 교육하십시오. 단계에서 전환 후 대기열에 추가된 트리거는 실행되지 않습니다. 운영자가 전환 기능이 있는 위젯과 상호작용하면, 전환이 실행될 때까지 해당 단계에 머물게 됩니다. 예를 들어, 운영자가 “다음 단계”를 클릭한 후 대기 중에 다른 트리거를 실행하면, 전환 후 남은 트리거는 실행되지 않습니다.
• 오래 걸리는 커넥터 및 데이터 업데이트는 별도의 단계에서 수행하십시오. 민감한 데이터에 대한 상호 작용은 오래 걸리는 커넥터 로직과 동일한 단계에서 수행해서는 안 됩니다. 운영자가 오래 걸리는 트리거나 전환을 클릭한 후 해당 단계와 상호 작용할 경우, 중요한 데이터가 저장되지 않을 위험이 있습니다.
• 각 단계마다 변수에 대한 입력은 하나만 있도록 하십시오. 경합 조건을 방지하기 위해변수를경쟁하는 입력 로직(예: 앱 내의 여러 버튼이 동일한 변수를 업데이트하는 경우)과 공유해서는 안 됩니다. 예를 들어, 트리거가 변수의 현재 값을 캡처한다고 가정해 보겠습니다. 트리거가 값을 캡처하기 전에 변수의 값이 변경되면 데이터가 부정확해집니다.

추가 자료

• 트리거 액션 및 전환 목록
• 조건부 트리거 로직
• 고성능 앱을 위한 모범 사례

{{snippet.원하는 정보를 찾으셨나요?}}