트리거를 사용하여 외부 이벤트 검색
Azure Logic Apps에서 트리거는 항상 워크플로를 첫 번째 단계로 시작합니다. 워크플로를 올바르게 실행하려면 최상의 트리거를 찾고 시나리오에 대한 트리거 속성을 설정해야 합니다. 이 예제에서는 제품 이름의 트윗이 게시될 때 워크플로를 실행하는 Twitter 트리거를 사용합니다.
이 단원에서는 트리거 유형과 가장 많이 사용되는 두 옵션의 장점 및 약점을 살펴보겠습니다. 그런 다음 Azure Portal을 사용하여 논리 앱 워크플로를 만드는 방법과 워크플로 디자이너에서 트리거를 추가하는 방법을 알아보겠습니다.
트리거 유형
비즈니스에서 논리 앱 워크플로를 실행하는 데 사용할 수 있는 다양한 트리거 조건을 고려합니다. 우리가 본 대부분의 예는 서비스 또는 시스템의 데이터 또는 이벤트가 특정 조건을 충족하는지 여부를 감지하는 트리거입니다. 새 트윗이 게시될 때, 데이터베이스에 새 행이 삽입될 때, 새 메일이 도착할 때 또는 클라우드 스토리지에 새 파일이 업로드될 때를 예로 들 수 있습니다. 데이터 또는 이벤트를 검색하는 트리거는 다음 기술 중 하나를 사용할 수 있습니다.
- 조건을 충족하는 특정 데이터 또는 이벤트에 대해 서비스 또는 시스템을 주기적으로 폴링하거나 확인하는 트리거
- 특정 데이터 또는 이벤트가 조건을 충족하는 경우 서비스 또는 시스템에서 푸시 알림을 대기하고 수신하는 트리거
그러나 서비스 또는 시스템의 데이터 또는 이벤트에 바인딩되지 않은 트리거가 필요한 경우 어떻게 해야 할까요? 매주 토요일 자정 또는 다른 일정에 워크플로를 실행하려는 경우를 가정해 보겠습니다. 워크플로에서 되풀이 트리거를 사용하여 어떤 작업이나 예약하고 실행할 수 있습니다. 예를 들어 백업 실행 또는 이전 데이터 보관과 같은 관리 작업을 수행하는 워크플로를 예약할 수 있습니다. 코드 또는 다른 원본에서 호출된 경우에만 워크플로를 실행하려는 경우를 가정해 보겠습니다. 요청 또는 “수동” 트리거를 사용하여 웹앱 또는 모바일 앱의 코드에서 전송된 요청을 대기할 수 있습니다.
다음 다이어그램에서는 이전에 설명한 트리거 유형을 요약합니다.
다음 섹션에서는 폴링 트리거 및 푸시 트리거에 대한 자세한 정보를 제공합니다.
폴링 트리거란?
폴링 트리거는 서비스 또는 시스템에서 특정 조건을 충족하는 데이터 또는 이벤트를 주기적으로 확인합니다. 이 확인 후 트리거가 조건을 충족하는 데이터 또는 이벤트를 찾으면 트리거가 새 워크플로 실행을 시작합니다. 예를 들어 RSS 커넥터에는 RSS 피드에서 새 게시물을 정기적으로 확인할 수 있는 폴링 트리거가 있습니다.
워크플로에 폴링 트리거를 추가할 때 빈도 및 간격을 설정하여 트리거가 실행되는 빈도를 제어합니다. 빈도는 초, 분, 시간, 일, 주 또는 월과 같은 시간 단위입니다. 간격은 트리거가 데이터 또는 이벤트를 다시 확인하기 전에 경과하는 시간 단위의 수입니다. 예를 들어 빈도가 분이고 간격이 5인 폴링 트리거는 5분마다 확인합니다.
폴링 트리거를 사용하려면 트리거 실행 빈도와 비용 중에서 선택해야 합니다. 새 데이터나 이벤트가 발생하는 시기와 트리거가 해당 데이터나 이벤트를 검색하는 시점 사이에 자주 지연이 발생합니다. 예를 들어 폴링 트리거가 5분마다 데이터를 확인한다고 가정합시다. 새 데이터는 7분 후에 사용할 수 있게 됩니다. 트리거는 10분 후에 발생하는 다음 폴링까지 새 데이터를 검색하지 않습니다. 다음 다이어그램은 이 폴링의 작동 방식을 보여 줍니다.
최악의 경우 새 데이터를 감지할 때의 잠재적 지연이 폴링 간격과 같을 수 있습니다. 그렇다면 더 짧은 간격을 사용하지 않는 이유는 무엇일까요? 새 데이터를 확인하려면 Azure Logic Apps 엔진이 워크플로를 실행해야 하므로 비용이 발생합니다. 일반적으로 간격이 짧을수록 비용이 크지만 트리거는 새 데이터나 이벤트에 더 빠르게 응답합니다. 트리거에 가장 적합한 폴링 간격은 비즈니스 프로세스 및 지연 허용 범위에 따라 달라집니다.
푸시 트리거란?
푸시 트리거는 데이터나 이벤트가 특정 조건을 충족하는 경우 서비스나 시스템의 알림을 기다립니다. 트리거는 외부 서비스나 시스템의 엔드포인트를 구독합니다. 새 데이터나 이벤트가 조건을 충족하는 경우 서비스나 시스템은 트리거에 알려 새 워크플로를 즉시 실행하기 시작합니다. 예를 들어 Azure Service Bus 커넥터에는 메시지가 Azure Service Bus 큐에 추가되는 시기를 감지하는 푸시 트리거가 있습니다.
참고
푸시 트리거는 웹후크를 사용하여 트리거가 외부 서비스이나 시스템을 구독할 수 있게 합니다. 구독 시 Azure Logic Apps는 트리거에 대한 콜백 URL을 생성하고 외부 서비스나 시스템에 URL을 등록합니다. 마찬가지로 Azure Logic Apps는 더 이상 구독이 필요하지 않은 경우(예: 워크플로를 사용하지 않도록 설정하거나 삭제하는 경우) 콜백 URL을 구독 취소하고 등록을 취소합니다.
긍정적인 측면으로는, 사용할 수 있는 데이터나 이벤트가 없을 때 푸시 트리거가 실행되지 않습니다. 따라서 폴링 비용이 발생하지 않습니다. 또한 이러한 트리거는 새 데이터나 이벤트가 있을 때 즉시 응답합니다. 다음 다이어그램에서는 이 푸시 프로세스의 작동 방식을 보여 줍니다.
푸시 트리거가 폴링 트리거보다 더 빠르게 응답하고 비용이 적게 드는 경우 항상 푸시 트리거를 사용하지 않는 이유는 무엇인가요? 안타깝게도 모든 커넥터가 푸시 트리거를 제공하지는 않습니다. 외부 서비스는 푸시 트리거를 지원하지 않거나 커넥터 작성자가 푸시 트리거를 구현하도록 선택하지 않았을 수 있습니다. 일반적으로 커넥터는 푸시 트리거나 폴링 트리거 중 하나만 제공합니다. 드물지만 커넥터가 두 옵션을 모두 제공하는 경우에는 효율성이 더 좋은 푸시 트리거를 사용하는 것이 좋습니다.
이 모듈에서는 폴링 트리거를 집중적으로 살펴보겠습니다. 이런 트리거는 가장 널리 사용되며 아직 우리가 살펴본 “데이터 라우팅 및 처리” 시나리오에 적합합니다.
트리거 매개 변수 및 반환 값
트리거 작업이란 매개 변수와 반환 값이 있는 함수 호출이라고 생각하시면 됩니다. 트리거 매개 변수를 통해 작업을 구성할 수 있습니다. 새 트윗이 게시될 때라는 Twitter 트리거에 검색 텍스트라는 매개 변수가 있습니다. 트리거는 이 매개 변수를 사용하여 일치하는 트윗을 선택합니다. 일부 작업은 필수 매개 변수와 선택적 매개 변수를 모두 사용합니다. 항목이 생성될 때라는 SQL Server 트리거에는 테이블 이름이라는 필수 매개 변수 하나와 정렬 기준 및 쿼리 선택 등의 여러 선택적 매개 변수가 있습니다.
트리거 반환 값은 작업의 결과입니다. 예를 들어 Bitbucket 커넥터에는 끌어오기 요청이 병합될 때라는 트리거가 있습니다. 트리거는 리포지토리 ID 및 병합을 승인한 작업자 같은 데이터가 포함된 개체를 반환합니다. 대부분의 트리거는 실제로 단일 개체가 아닌 개체 컬렉션을 반환합니다. 예를 들어 새 트윗이 게시될 때라는 Twitter 트리거는 TweetModel 개체의 배열을 반환합니다. 각 개체에는 트윗 텍스트, 사용자 이름, 팔로워 수 등의 값이 포함되어 있습니다. 다음 다이어그램은 트리거에서 반환되는 컬렉션을 보여 줍니다.
루프를 사용하여 각 항목을 처리할 수도 있고, 프로세스를 위한 배열을 분할하라고 트리거를 설정할 수도 있습니다. Twitter 트리거를 비롯한 대부분의 트리거의 경우 기본 동작은 배열을 자동 분할합니다. Azure Logic Apps 엔진은 각 항목에 대해 하나의 워크플로 인스턴스를 생성하고 모든 인스턴스를 병렬로 실행합니다. 다음 다이어그램은 반환된 배열의 각 항목이 처리를 위해 다른 워크플로 인스턴스로 가는 방법을 보여 줍니다.
Azure Portal에서 논리 앱 워크플로 만들기
Azure Portal에서 논리 앱 리소스 유형을 찾아서 선택하고 이름, 구독, 리소스 그룹, 위치와 같은 리소스에 대한 정보를 제공합니다. 배포가 완료되면 논리 앱 리소스로 이동할 수 있습니다.
새 논리 앱 리소스를 열면 “시작” 페이지가 표시됩니다. 이 페이지에는 일반적으로 사용되는 트리거와 일반 워크플로 패턴 및 앱 유형이 있는 템플릿 갤러리가 포함되어 있습니다. 예를 들어 새 트윗이 일부 해시태그와 일치하면 Slack에 게시 및 메일로 일별 미리 알림 받기 같은 워크플로 템플릿을 찾을 수 있습니다.
“시작” 페이지에서 워크플로에 추가할 일반 트리거를 선택하거나 템플릿을 선택하여 전체 워크플로를 생성할 수 있습니다. 시나리오에 맞는 템플릿이 있으면 앱을 설정하는 시간을 절약할 수 있습니다. 모든 작업을 직접 수행하려면 빈 논리 앱 템플릿을 선택하면 됩니다.
템플릿을 선택하면 워크플로 디자이너가 자동으로 열립니다.
디자이너를 사용하여 트리거 추가
워크플로 디자이너는 워크플로에서 사용할 수 있는 트리거 및 작업이 포함된 커넥터 갤러리를 보여 줍니다. 일반적으로 빈 워크플로로 시작하면 검색 상자를 사용하여 관심 있는 커넥터를 찾습니다. 그런 다음 커넥터에서 제공하는 트리거를 검토합니다. 이 예제에서는 새 트윗이 게시될 때라는 Twitter 트리거를 선택합니다. Twitter의 경우 Twitter 계정에 로그인하여 연결을 만들어야 합니다.
트리거를 추가하고 필요한 경우 서비스 또는 시스템에 대한 연결을 만든 후 디자이너는 트리거 속성을 표시합니다. Twitter의 경우에는 Search text, Frequency 및 Interval 매개 변수를 설정하겠습니다. 다음 스크린샷은 Twitter 트리거가 첫 번째 단계로 표시되는 디자이너의 소셜 미디어 모니터링 논리 앱 워크플로를 보여 줍니다.
