트리거를 사용하여 외부 이벤트 검색
Azure Logic Apps에서 트리거는 항상 워크플로를 첫 번째 단계로 시작합니다. 워크플로를 성공적으로 실행하려면 적절한 트리거를 찾고 시나리오에 대한 트리거 속성을 설정해야 합니다. 이 예제에서는 업계에 대한 문서가 게시될 때 Bing Search 트리거를 사용하여 워크플로를 실행합니다.
이 단원에서는 트리거 유형과 가장 많이 사용되는 두 옵션의 장점 및 약점, 트리거로 입력 및 출력을 처리하는 방법을 살펴보겠습니다.
트리거 유형
비즈니스에서 논리 앱 워크플로를 실행하는 데 사용할 수 있는 다양한 트리거 조건을 고려합니다. 우리가 본 대부분의 예는 서비스 또는 시스템의 데이터 또는 이벤트가 특정 조건을 충족하는지 여부를 감지하는 트리거입니다. 새 기사를 사용할 수 있게 될 때, 데이터베이스에 새 행이 추가될 때, 새 메일이 도착할 때 또는 클라우드 스토리지에 새 파일이 업로드될 때를 예로 들 수 있습니다. 데이터 또는 이벤트를 검색하는 트리거는 다음 기술 중 하나를 사용할 수 있습니다.
서비스 또는 시스템에서 특정 데이터 또는 조건을 충족하는 이벤트를 주기적으로 폴링 하거나 확인하는 트리거
특정 데이터 또는 이벤트가 조건을 충족하는 경우 서비스 또는 시스템에서 푸시 알림을 대기하고 수신하는 트리거
그러나 서비스 또는 시스템의 데이터 또는 이벤트에 바인딩되지 않은 트리거가 필요한 경우 어떻게 해야 할까요? 매주 토요일 자정 또는 다른 일정에 워크플로를 실행하려는 경우를 가정해 보겠습니다. 되풀이 트리거를 사용하여 워크플로에서 작업을 실행할 시기를 예약할 수 있습니다. 예를 들어 백업 실행 또는 이전 데이터 보관과 같은 관리 작업을 수행하는 워크플로를 예약할 수 있습니다.
코드 또는 다른 원본에서 호출된 경우에만 워크플로를 실행하려는 경우를 가정해 보겠습니다. 요청 또는 "수동" 트리거를 사용하여, 예를 들어 웹앱이나 모바일 앱의 코드에서 보낸 요청이 도착할 때까지 대기할 수 있습니다.
다음 다이어그램에서는 이전에 설명한 트리거 유형을 요약합니다.
다음 섹션에서는 폴링 트리거 및 푸시 트리거에 대한 자세한 정보를 제공합니다.
폴링 트리거란?
폴링 트리거는 서비스 또는 시스템에서 특정 조건을 충족하는 데이터 또는 이벤트를 주기적으로 확인합니다. 이 확인 후 트리거가 조건을 충족하는 데이터 또는 이벤트를 찾으면 트리거가 새 워크플로 실행을 시작합니다. 예를 들어 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을 구독 취소하고 등록을 취소합니다.
긍정적인 측면으로는, 사용할 수 있는 데이터나 이벤트가 없을 때 푸시 트리거가 실행되지 않습니다. 따라서 폴링만큼 많은 비용이 발생하지 않습니다. 또한 이러한 트리거는 새 데이터나 이벤트가 있을 때 즉시 응답합니다. 다음 다이어그램에서는 이 푸시 프로세스의 작동 방식을 보여 줍니다.
푸시 트리거가 폴링 트리거보다 더 빠르게 응답하고 비용이 적게 드는 경우 항상 푸시 트리거를 사용하지 않는 이유는 무엇인가요? 안타깝게도 모든 커넥터가 푸시 트리거를 제공하지는 않습니다. 서비스나 시스템은 푸시 트리거를 지원하지 않거나 커넥터 작성자가 푸시 트리거를 구현하도록 선택하지 않았을 수 있습니다. 일반적으로 커넥터는 폴링 트리거나 푸시 트리거 중 하나만 제공합니다. 드물지만 커넥터가 두 옵션을 모두 제공하는 경우에는 효율성이 더 좋고 더 저렴한 푸시 트리거를 사용하는 것이 좋습니다.
다음 스크린샷은 Bing Search 트리거가 첫 번째 단계로 표시되는 뉴스 모니터링 논리 앱 워크플로가 있는 디자이너를 보여줍니다.
트리거 매개 변수 및 반환 값
트리거 작업은 매개 변수 (입력) 및 반환 값 (출력)이 있는 함수 호출로 간주할 수 있습니다. 트리거 매개 변수를 통해 작업을 구성할 수 있습니다. 새 뉴스 문서에서 명명된 Bing Search 트리거에는 검색 쿼리라는 매개 변수가 있습니다. 이 트리거는 이 매개 변수를 사용하여 검색어와 일치하는 뉴스 기사를 찾습니다. 일부 작업은 필수 매개 변수와 선택적 매개 변수를 모두 사용합니다. 항목을 만들 때라는 SQL Server 트리거에는 테이블 이름이라는 하나의 필수 매개 변수와 Order By 및 쿼리 선택과 같은 몇 가지 선택적 매개 변수가 있습니다.
트리거의 반환 값은 트리거 작업의 결과 또는 출력입니다. 예를 들어 새 뉴스 기사에 이름이 지정된 Bing Search 트리거는 NewsArticle 개체를 반환합니다. 이 개체에는 Name, URL 및 Description과 같은 값이 포함 됩니다. Bitbucket 커넥터에는 끌어오기 요청이 병합될 때라는 트리거가 있습니다. 트리거는 리포지토리 ID 및 병합을 승인한 행위 자와 같은 데이터가 포함된 개체를 반환합니다.
일부 트리거는 단일 항목이 아닌 배열 또는 컬렉션을 반환합니다. 다음 다이어그램은 이 출력 배열 또는 컬렉션의 모양을 보여 줍니다.
각 항목을 처리하려면 For each 또는 Until 루프와 같은 루프를 사용할 수 있습니다.
일부 트리거는 배열 또는 컬렉션을 입력으로 허용합니다. 기본적으로 대부분의 트리거는 처리를 위해 배열을 자동으로 분할합니다. 하나의 워크플로 인스턴스가 전체 배열을 처리하는 대신, Azure Logic Apps 엔진은 각 항목에 대해 하나의 워크플로 인스턴스를 만들고 모든 인스턴스를 병렬로 실행합니다.
다음 다이어그램에서는 피드 항목이 게시될 때RSS 트리거가 배열을 분할하고 각 항목을 처리를 위해 개별 워크플로 인스턴스로 보내는 방법을 보여 줍니다.
디자이너의 트리거
워크플로 디자이너는 워크플로에서 사용할 수 있는 트리거 및 작업이 포함된 커넥터 갤러리를 포함합니다. 일반적으로 커넥터 갤러리 검색 상자를 사용하여 시나리오에 대한 커넥터를 찾아 선택합니다. 그런 다음 커넥터에서 제공하는 트리거를 검토합니다. 다음 스크린샷은 선택할 수 있는 커넥터를 워크플로 디자이너가 제공하는 방법을 보여 줍니다.
커넥터를 선택하면 해당 커넥터에 사용할 수 있는 트리거가 표시됩니다.
다음 단원에서는 워크플로 디자이너에서 트리거를 추가하고 구성하는 방법과 함께 Azure Portal에서 논리 앱 리소스 및 워크플로를 만드는 방법을 보여 줍니다.
커넥터 갤러리는 커넥터를 다음과 같은 일반 범주로 그룹화합니다.
| 커넥터 그룹 | 설명 |
|---|---|
| 기본 제공 (앱 내) | Azure Logic Apps 런타임에서 기본적으로 실행되는 트리거 및 동작 일부 작업은 연결을 만들지 않고도 특정 Azure 서비스에 직접 작용합니다(예: Azure Functions). 다른 작업은 변수 작업, 워크플로를 통한 경로 제어 또는 일반 데이터 작업 수행 등의 태스크를 수행합니다. |
| 관리형(공유) | 다중 테넌트 Azure에서 실행되고 Microsoft에서 관리하는 트리거 및 작업 이러한 작업은 일반적으로 단일 서비스 또는 시스템과 연결되며 특정 서비스 또는 시스템에 대한 호출을 받거나 보냅니다. 이러한 작업을 수행하려면 일반적으로 먼저 연결을 만들어야 합니다. |