Azure Logic Apps에서 호출할 수 있는 사용자 지정 API 만들기Create custom APIs you can call from Azure Logic Apps

Azure Logic Apps는 논리 앱 워크플로에서 사용할 수 있는 수백 개의 커넥터 를 제공 하지만, 커넥터로 사용할 수 없는 api, 시스템 및 서비스를 호출 하는 것이 좋습니다.Although Azure Logic Apps offers hundreds of connectors that you can use in logic app workflows, you might want to call APIs, systems, and services that aren't available as connectors. 논리 앱에서 사용할 동작과 트리거를 제공하는 자체 API는 직접 만들 수 있습니다.You can create your own APIs that provide actions and triggers to use in logic apps. 논리 앱 워크플로에서 호출할 수 있는 API를 직접 만들려는 다른 이유는 다음가 같습니다.Here are other reasons why you might want to create your own APIs that you can call from logic app workflows:

  • 현재의 시스템 통합 및 데이터 통합 워크플로를 확장합니다.Extend your current system integration and data integration workflows.
  • 고객이 서비스를 사용하여 전문적이거나 개인적인 작업을 관리할 수 있도록 지원합니다.Help customers use your service to manage professional or personal tasks.
  • 서비스에 대한 범위, 검색 기능 및 사용을 확장합니다.Expand the reach, discoverability, and use for your service.

기본적으로 커넥터는 플러그형 인터페이스에 대한 REST, 문서에 대한 Swagger 메타데이터 형식 및 JSON(데이터 교환 형식)을 사용하는 웹 API입니다.Basically, connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. 커넥터는 HTTP 끝점을 통해 통신 하는 REST Api 이므로 .NET, Java, Python 또는 node.js와 같은 모든 언어를 사용 하 여 커넥터를 빌드할 수 있습니다.Because connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building connectors. API 호스팅을 위한 가장 쉽고, 확장성 있는, 최상의 방법 중 하나를 제공하는 PaaS(Platform-as-a-Service) 제품인 Azure App Service에서 API를 호스팅할 수도 있습니다.You can also host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides one of the best, easiest, and most scalable ways for API hosting.

사용자 지정 API가 논리 앱에서 작동하려면 API가 논리 앱 워크플로에서 특정 작업을 수행하는 동작을 제공할 수 있습니다.For custom APIs to work with logic apps, your API can provide actions that perform specific tasks in logic app workflows. 또한 API는 트리거의 역할을 수행하여 새 데이터 또는 이벤트가 지정된 조건을 충족할 때 논리 앱 워크플로를 시작할 수도 있습니다.Your API can also act as a trigger that starts a logic app workflow when new data or an event meets a specified condition. 이 항목에서는 API에서 제공할 동작에 따라 API에서 동작과 트리거를 빌드할 때 따라야 하는 일반적인 패턴에 대해 설명합니다.This topic describes common patterns that you can follow for building actions and triggers in your API, based on the behavior that you want your API to provide.

확장성이 뛰어나고 쉬운 API 호스팅을 제공하는 PaaS(Platform-as-a-Service) 제품인 Azure App Service에서 API를 호스트할 수 있습니다.You can host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides highly scalable, easy API hosting.

API를 웹앱으로 배포할 수 있지만 API 앱으로 배포하는 것이 좋습니다. 이렇게 하면 클라우드에서 API를 빌드, 호스트 및 사용할 때 작업을 더 쉽게 수행할 수 있습니다.Although you can deploy your APIs as web apps, consider deploying your APIs as API apps, which can make your job easier when you build, host, and consume APIs in the cloud and on premises. API에서 코드를 변경할 필요가 없이 API 앱에 코드를 배포하기만 하면 됩니다.You don't have to change any code in your APIs -- just deploy your code to an API app. 예를 들어 다음 언어를 사용하여 만든 API 앱을 빌드하는 방법을 알아봅니다.For example, learn how to build API apps created with these languages:

논리 앱용으로 빌드된 API 앱 샘플은 Azure Logic Apps GitHub 리포지토리 또는 블로그를 방문하세요.For API App samples built for logic apps, visit the Azure Logic Apps GitHub repository or blog.

사용자 지정 API는 사용자 지정 커넥터와 어떻게 다른가요?How do custom APIs differ from custom connectors?

사용자 지정 API 및 사용자 지정 커넥터는 플러그형 인터페이스에 대한 REST, 문서에 대한 Swagger 메타데이터 형식 및 JSON(데이터 교환 형식)을 사용하는 웹 API입니다.Custom APIs and custom connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. 그리고 이러한 Api 및 커넥터는 HTTP 끝점을 통해 통신 하는 REST Api 이므로 .NET, Java, Python 또는 node.js와 같은 언어를 사용 하 여 사용자 지정 Api 및 커넥터를 빌드할 수 있습니다.And because these APIs and connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building custom APIs and connectors.

사용자 지정 API는 커넥터가 아닌 API를 호출할 수 있도록 하고, HTTP + Swagger, Azure SAPI Management 또는 App Services를 사용하여 호출할 수 있는 엔드포인트를 제공합니다.Custom APIs let you call APIs that aren't connectors, and provide endpoints that you can call with HTTP + Swagger, Azure API Management, or App Services. 사용자 지정 커넥터는 사용자 지정 API처럼 작동하지만 다음과 같은 특성도 있습니다.Custom connectors work like custom APIs but also have these attributes:

  • Azure에서 Logic Apps 커넥터 리소스로 등록됩니다.Registered as Logic Apps Connector resources in Azure.
  • Logic Apps 디자이너에서 Microsoft 관리 커넥터와 함께 아이콘으로 표시됩니다.Appear with icons alongside Microsoft-managed connectors in the Logic Apps Designer.
  • 커넥터의 작성자와 논리 앱이 배포된 지역에서 동일한 Azure Active Directory 테넌트 및 Azure 구독을 가지는 논리 앱 사용자만 사용할 수 있습니다.Available only to the connectors' authors and logic app users who have the same Azure Active Directory tenant and Azure subscription in the region where the logic apps are deployed.

Microsoft 인증에 대해 등록된 커넥터를 지정할 수도 있습니다.You can also nominate registered connectors for Microsoft certification. 이 프로세스는 등록된 커넥터가 공용 사용 조건을 충족하는지 확인하고 사용자가 Microsoft Flow 및 Microsoft PowerApps에서 해당 커넥터를 사용할 수 있도록 합니다.This process verifies that registered connectors meet the criteria for public use and makes those connectors available for users in Microsoft Flow and Microsoft PowerApps.

사용자 지정 커넥터에 대한 자세한 내용은 다음을 참조하세요.For more information about custom connectors, see

유용한 도구Helpful tools

API 작업 및 매개 변수를 설명하는 Swagger 문서도 API에 있으면 사용자 지정 API가 논리 앱에서 가장 잘 작동합니다.A custom API works best with logic apps when the API also has a Swagger document that describes the API's operations and parameters. 많은 라이브러리(예: Swashbuckle)에서 Swagger 파일을 자동으로 생성할 수 있습니다.Many libraries, like Swashbuckle, can automatically generate the Swagger file for you. 또한 Swagger 파일에 표시 이름, 속성 형식 등에 주석을 달려면 TRex를 사용하여 Swagger 파일이 논리 앱에서 잘 작동하도록 할 수도 있습니다.To annotate the Swagger file for display names, property types, and so on, you can also use TRex so that your Swagger file works well with logic apps.

동작 패턴Action patterns

논리 앱에서 작업을 수행하려면 사용자 지정 API에서 동작을 제공해야 합니다.For logic apps to perform tasks, your custom API should provide actions. API 작업 각각은 동작에 맵핑됩니다.Each operation in your API maps to an action. 기본 동작은 HTTP 요청을 받아들이고 HTTP 응답을 반환하는 컨트롤러입니다.A basic action is a controller that accepts HTTP requests and returns HTTP responses. 예를 들어 논리 앱은 웹앱 또는 API 앱에 HTTP 요청을 보냅니다.So for example, a logic app sends an HTTP request to your web app or API app. 그런 다음 앱은 논리 앱에서 처리할 수 있는 내용과 함께 HTTP 응답을 반환합니다.Your app then returns an HTTP response, along with content that the logic app can process.

표준 동작의 경우 API에 HTTP 요청 메서드를 작성하고 해당 메서드를 Swagger 파일에 설명할 수 있습니다.For a standard action, you can write an HTTP request method in your API and describe that method in a Swagger file. 그런 다음 HTTP 동작 또는 HTTP + Swagger 동작을 사용하여 API를 직접 호출할 수 있습니다.You can then call your API directly with an HTTP action or an HTTP + Swagger action. 기본적으로 응답은 요청 시간 제한 내에 반환되어야 합니다.By default, responses must be returned within the request timeout limit.

표준 동작 패턴

API에서 장기 실행 작업을 완료하는 동안 논리 앱이 대기하도록 하려면 API가 이 항목에서 설명하는 비동기 폴링 패턴 또는 비동기 웹후크 패턴을 따르면 됩니다.To make a logic app wait while your API finishes longer-running tasks, your API can follow the asynchronous polling pattern or the asynchronous webhook pattern described in this topic. 이러한 패턴의 특이한 동작을 시각화할 수 있도록 유추하기 위해 빵집에서 사용자 지정 케이크 주문을 처리하는 프로세스를 가정해 봅니다.For an analogy that helps you visualize these patterns' different behaviors, imagine the process for ordering a custom cake from a bakery. 폴링 패턴은 케이크가 준비되었는지 여부를 확인하기 위해 20분마다 고객이 빵집에 전화하는 동작을 미러링합니다.The polling pattern mirrors the behavior where you call the bakery every 20 minutes to check whether the cake is ready. 웹후크 패턴은 케이크가 준비되었을 때 고객에게 전화를 걸도록 하기 위해 빵집에서 고객의 전화 번호를 요구하는 동작을 미러링합니다.The webhook pattern mirrors the behavior where the bakery asks you for your phone number so they can call you when the cake is ready.

샘플은 Logic Apps GitHub 리포지토리를 참조하세요.For samples, visit the Logic Apps GitHub repository. 또한 동작 사용량 측정에 대해서도 자세히 알아보세요.Also, learn more about usage metering for actions.

폴링 동작 패턴으로 장기 실행 작업 수행Perform long-running tasks with the polling action pattern

API에서 요청 시간 제한보다 더 오래 실행될 수 있는 작업을 수행하도록 하려면 비동기 폴링 패턴을 사용할 수 있습니다.To have your API perform tasks that could run longer than the request timeout limit, you can use the asynchronous polling pattern. 이 패턴에서는 API가 별도의 스레드에서 작동하지만 Logic Apps 엔진에 대한 활성 연결을 유지합니다.This pattern has your API do work in a separate thread, but keep an active connection to the Logic Apps engine. 이렇게 하면 API에서 작업을 완료하기 전에 논리 앱에서 시간 초과하지 않거나 워크플로의 다음 단계로 계속 진행합니다.That way, the logic app does not time out or continue with the next step in the workflow before your API finishes working.

다음은 일반적인 패턴입니다.Here's the general pattern:

  1. 엔진에서 API가 요청을 수락하고 작업을 시작했는지 확인합니다.Make sure that the engine knows that your API accepted the request and started working.
  2. 엔진에서 작업 상태에 대한 후속 요청을 하면 API에서 작업을 완료할 때 엔진에 알립니다.When the engine makes subsequent requests for job status, let the engine know when your API finishes the task.
  3. 논리 앱 워크플로를 계속할 수 있도록 관련 데이터를 엔진에 반환합니다.Return relevant data to the engine so that the logic app workflow can continue.

이제 폴링 패턴에 앞서의 빵집 유추를 적용하고, 빵집에 전화를 걸어 배달용 사용자 지정 케이크를 주문한다고 가정합니다.Now apply the previous bakery analogy to the polling pattern, and imagine that you call a bakery and order a custom cake for delivery. 케이크를 만드는 과정에 시간이 걸리고, 빵집에서 케이크를 만드는 동안은 빵집의 전화를 기다리지 않으려고 합니다.The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. 빵집에서 주문을 확인하고 케이크 상태에 대해 20분마다 고객에게 전화를 겁니다.The bakery confirms your order and has you call every 20 minutes for the cake's status. 20분이 지나면 빵집에 전화를 걸지만, 케이크가 아직 완성되지 않았고 20분 후에 고객이 다시 전화해야 한다고 알려줍니다.After 20 minutes pass, you call the bakery, but they tell you that your cake isn't done and that you should call in another 20 minutes. 이 앞뒤 과정은 고객이 전화할 때까지 계속되며, 빵집에서는 주문이 준비되어 케이크를 배달한다고 알려줍니다.This back-and-forth process continues until you call, and the bakery tells you that your order is ready and delivers your cake.

이제 폴링 패턴을 다시 매핑해 보겠습니다.So let's map this polling pattern back. 빵집은 사용자 지정 API를 나타내고, 케이크를 주문한 고객은 Logic Apps 엔진을 나타냅니다.The bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. 엔진에서 요청을 통해 API를 호출하면, API는 요청을 확인하고 엔진에서 작업 상태를 확인할 수 있는 간격으로 응답합니다.When the engine calls your API with a request, your API confirms the request and responds with the time interval when the engine can check job status. API에서 작업을 완료했다고 응답하고 논리 앱에 데이터를 반환할 때까지 엔진에서는 작업 상태를 계속 확인한 다음 워크플로를 계속 진행합니다.The engine continues checking job status until your API responds that the job is done and returns data to your logic app, which then continues workflow.

폴링 동작 패턴

API의 관점에서 설명하는 API의 구체적인 수행 단계는 다음과 같습니다.Here are the specific steps for your API to follow, described from the API's perspective:

  1. API에서 작업을 시작하라는 HTTP 요청을 받으면 이 단계의 뒷부분에서 설명하는 location 헤더가 있는 HTTP 202 ACCEPTED 응답을 즉시 반환합니다.When your API gets an HTTP request to start work, immediately return an HTTP 202 ACCEPTED response with the location header described later in this step. Logic Apps 엔진에서는 이 응답을 통해 API가 요청을 받고 요청 페이로드(데이터 입력)를 수락하여 현재 처리 중임을 확인할 수 있습니다.This response lets the Logic Apps engine know that your API got the request, accepted the request payload (data input), and is now processing.

    202 ACCEPTED 응답에는 다음과 같은 헤더가 포함되어야 합니다.The 202 ACCEPTED response should include these headers:

    • 필수: Logic Apps 엔진이 API의 작업 상태를 확인할 수 있는 URL의 절대 경로를 지정하는 location 헤더Required: A location header that specifies the absolute path to a URL where the Logic Apps engine can check your API's job status

    • 선택 사항: 작업 상태에 대해 location URL을 확인하기 전에 엔진에서 대기해야 하는 시간(초)을 지정하는 retry-after 헤더Optional: A retry-after header that specifies the number of seconds that the engine should wait before checking the location URL for job status.

      기본적으로 엔진은 매 20초마다 확인합니다.By default, the engine checks every 20 seconds. 다른 간격을 지정하려면 retry-after 헤더와 다음 폴링까지의 시간(초)을 포함합니다.To specify a different interval, include the retry-after header and the number of seconds until the next poll.

  2. 지정된 시간이 지나면 Logic Apps 엔진에서 location URL을 폴링하여 작업 상태를 확인합니다.After the specified time passes, the Logic Apps engine polls the location URL to check job status. API는 이러한 검사를 수행하고 다음과 같은 응답을 반환해야 합니다.Your API should perform these checks and return these responses:

    • 작업이 완료되면 응답 페이로드(다음 단계에 대한 입력)와 함께 HTTP 200 OK 응답을 반환합니다.If the job is done, return an HTTP 200 OK response, along with the response payload (input for the next step).

    • 작업이 아직 처리 중인 경우 원래 응답과 동일한 헤더가 포함된 다른 HTTP 202 ACCEPTED 응답을 반환합니다.If the job is still processing, return another HTTP 202 ACCEPTED response, but with the same headers as the original response.

API가 이 패턴을 따르는 경우 작업 상태를 계속 확인하기 위해 논리 앱 워크플로 정의에서 어떤 작업도 수행할 필요가 없습니다.When your API follows this pattern, you don't have to do anything in the logic app workflow definition to continue checking job status. 엔진이 HTTP 202 ACCEPTED 응답과 유효한 location 헤더를 가져오면 비동기 패턴을 고려하여 API에서 202가 아닌 응답을 반환할 때까지 엔진에서 location 헤더를 확인합니다.When the engine gets an HTTP 202 ACCEPTED response and a valid location header, the engine respects the asynchronous pattern and checks the location header until your API returns a non-202 response.

비동기 패턴 예제는 GitHub의 비동기 컨트롤러 응답 샘플(영문)을 검토하세요.For an example asynchronous pattern, review this asynchronous controller response sample in GitHub.

웹후크 동작 패턴으로 장기 실행 작업 수행Perform long-running tasks with the webhook action pattern

대안으로 장기 실행 작업과 비동기 처리에 대해 웹후크 패턴을 사용할 수 있습니다.As an alternative, you can use the webhook pattern for long-running tasks and asynchronous processing. 이 패턴에는 논리 앱이 일시 중지되고 워크플로를 계속하기 전에 API로부터 "콜백"할 때까지 기다립니다.This pattern has the logic app pause and wait for a "callback" from your API to finish processing before continuing workflow. 이 콜백은 이벤트 발생 시 URL에 메시지를 보내는 HTTP POST입니다.This callback is an HTTP POST that sends a message to a URL when an event happens.

이제 웹후크 패턴에 앞서의 빵집 유추를 적용하고, 빵집에 전화를 걸어 배달용 사용자 지정 케이크를 주문한다고 가정합니다.Now apply the previous bakery analogy to the webhook pattern, and imagine that you call a bakery and order a custom cake for delivery. 케이크를 만드는 과정에 시간이 걸리고, 빵집에서 케이크를 만드는 동안은 빵집의 전화를 기다리지 않으려고 합니다.The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. 빵집에서 주문을 확인하지만, 이번에는 케이크가 완성되었을 때 빵집에서 전화할 수 있도록 고객이 자신의 전화 번호를 빵집에 알려줍니다.The bakery confirms your order, but this time, you give them your phone number so they can call you when the cake is done. 이번에는 주문이 준비되어 케이크를 배달할 때 빵집에서 고객에게 알려줍니다.This time, the bakery tells you when your order is ready and delivers your cake.

이 웹후크 패턴을 다시 매핑하는 경우 빵집은 사용자 지정 API를 나타내고, 케이크를 주문한 고객은 Logic Apps 엔진을 나타냅니다.When we map this webhook pattern back, the bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. 엔진에서 요청을 통해 API를 호출하고 "콜백" URL을 포함합니다.The engine calls your API with a request and includes a "callback" URL. 작업이 완료되면 API에서 URL을 사용하여 엔진에 알리고, 논리 앱에 데이터를 반환하고, 워크플로를 계속 진행합니다.When the job is done, your API uses the URL to notify the engine and return data to your logic app, which then continues workflow.

이 패턴의 경우 컨트롤러에 두 개의 엔드포인트(subscribeunsubscribe)를 설정합니다.For this pattern, set up two endpoints on your controller: subscribe and unsubscribe

  • subscribe 엔드포인트: 실행이 워크플로의 API 동작에 도달하면 Logic Apps 엔진에서 subscribe 엔드포인트를 호출합니다.subscribe endpoint: When execution reaches your API's action in the workflow, the Logic Apps engine calls the subscribe endpoint. 이 단계에서는 논리 앱이 API에서 저장하는 콜백 URL을 만든 다음, 작업이 완료될 때 API로부터 콜백을 기다립니다.This step causes the logic app to create a callback URL that your API stores and then wait for the callback from your API when work is complete. 그런 다음 API에서 URL에 대한 HTTP POST를 통해 콜백하고 반환된 모든 내용과 헤더를 논리 앱에 대한 입력으로 전달합니다.Your API then calls back with an HTTP POST to the URL and passes any returned content and headers as input to the logic app.

  • unsubscribe 엔드포인트: 논리 앱이 실행 취소되면 Logic Apps 엔진에서 unsubscribe 엔드포인트를 호출합니다.unsubscribe endpoint: If the logic app run is canceled, the Logic Apps engine calls the unsubscribe endpoint. 그런 다음 API에서 콜백 URL을 등록 취소하고 필요에 따라 모든 프로세스를 중지할 수 있습니다.Your API can then unregister the callback URL and stop any processes as necessary.

웹후크 동작 패턴

참고

현재 Logic App Designer는 Swagger를 통한 웹후크 엔드포인트 검색을 지원하지 않습니다.Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. 따라서 이 패턴의 경우 웹후크 동작을 추가하고 요청에 대한 URL, 헤더 및 본문을 지정해야 합니다.So for this pattern, you have to add a Webhook action and specify the URL, headers, and body for your request. 워크플로 작업 및 트리거도 참조하세요.See also Workflow actions and triggers. 콜백 URL을 전달하려면 필요에 따라 이전 필드 중 하나에서 @listCallbackUrl() 워크플로 함수를 사용할 수 있습니다.To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

웹후크 패턴 예제는 GitHub의 웹후크 트리거 샘플(영문)을 검토하세요.For an example webhook pattern, review this webhook trigger sample in GitHub.

트리거 패턴Trigger patterns

사용자 지정 API는 트리거의 역할을 수행하여 새 데이터 또는 이벤트가 지정된 조건을 충족할 때 논리 앱을 시작할 수 있습니다.Your custom API can act as a trigger that starts a logic app when new data or an event meets a specified condition. 이 트리거는 서비스 엔드포인트에서 새 데이터 또는 이벤트를 정기적으로 확인하거나 대기 및 수신 대기할 수 있습니다.This trigger can either check regularly, or wait and listen, for new data or events at your service endpoint. 새 데이터 또는 이벤트가 지정된 조건을 충족하면 트리거가 시작되고 해당 트리거를 수신하는 논리 앱이 시작됩니다.If new data or an event meets the specified condition, the trigger fires and starts the logic app, which is listening to that trigger. 이러한 방식으로 논리 앱을 시작하려면 API에서 폴링 트리거 또는 웹후크 트리거 패턴을 따르면 됩니다.To start logic apps this way, your API can follow the polling trigger or the webhook trigger pattern. 이러한 패턴은 폴링 동작웹후크 동작의 해당 패턴과 비슷합니다.These patterns are similar to their counterparts for polling actions and webhook actions. 또한 트리거 사용량 측정에 대해서도 자세히 알아보세요.Also, learn more about usage metering for triggers.

폴링 트리거 패턴으로 정기적인 새 데이터 또는 이벤트 확인Check for new data or events regularly with the polling trigger pattern

폴링 트리거는 이 항목의 앞부분에서 설명한 폴링 동작과 매우 비슷하게 작동합니다.A polling trigger acts much like the polling action previously described in this topic. Logic Apps 엔진에서는 새 데이터 또는 이벤트에 대한 트리거 엔드포인트를 정기적으로 호출하고 확인합니다.The Logic Apps engine periodically calls and checks the trigger endpoint for new data or events. 엔진에서 지정된 조건을 충족하는 새 데이터 또는 이벤트를 발견하면 트리거가 실행됩니다.If the engine finds new data or an event that meets your specified condition, the trigger fires. 그런 다음 엔진에서 데이터를 입력으로 처리하는 논리 앱 인스턴스를 만듭니다.Then, the engine creates a logic app instance that processes the data as input.

폴링 트리거 패턴

참고

논리 앱 인스턴스를 만들지 않은 경우에도 각 폴링 요청은 동작 실행으로 간주됩니다.Each polling request counts as an action execution, even when no logic app instance is created. 동일한 데이터를 여러 번 처리하지 않도록 방지하려면 트리거에서 이미 읽고 논리 앱에 전달된 데이터를 정리해야 합니다.To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

API의 관점에서 설명하는 폴링 트리거의 구체적인 단계는 다음과 같습니다.Here are specific steps for a polling trigger, described from the API's perspective:

새 데이터 또는 이벤트가 있습니까?Found new data or event? API 응답API response
찾음Found 응답 페이로드(다음 단계의 입력)와 함께 HTTP 200 OK 상태를 반환합니다.Return an HTTP 200 OK status with the response payload (input for next step).
이 응답은 논리 앱 인스턴스를 만들고 워크플로를 시작합니다.This response creates a logic app instance and starts the workflow.
찾을 수 없음Not found location 헤더 및 retry-after 헤더와 함께 HTTP 202 ACCEPTED 상태를 반환합니다.Return an HTTP 202 ACCEPTED status with a location header and a retry-after header.
트리거의 경우 location 헤더에 triggerState 쿼리 매개 변수(일반적으로 "timestamp")도 있어야 합니다.For triggers, the location header should also contain a triggerState query parameter, which is usually a "timestamp." API에서는 이 식별자를 사용하여 논리 앱이 트리거된 마지막 시간을 추적할 수 있습니다.Your API can use this identifier to track the last time that the logic app was triggered.

예를 들어 새 파일에 대한 서비스를 정기적으로 확인하려면 다음과 같은 동작을 포함하는 폴링 트리거를 빌드할 수 있습니다.For example, to periodically check your service for new files, you might build a polling trigger that has these behaviors:

요청에 triggerState가 있습니까?Request includes triggerState? API 응답API response
아니요No HTTP 202 ACCEPTED 상태 및 현재 시간으로 설정된 triggerState와 15초로 설정된 retry-after 간격이 포함된 location 헤더를 반환합니다.Return an HTTP 202 ACCEPTED status plus a location header with triggerState set to the current time and the retry-after interval to 15 seconds.
Yes triggerState에 대한 DateTime 이후에 추가된 파일에 대한 서비스를 확인합니다.Check your service for files added after the DateTime for triggerState.
검색된 파일의 수Number of files found API 응답API response
단일 파일Single file HTTP 200 OK 상태와 콘텐츠 페이로드를 반환하고, triggerState를 반환된 파일에 대한 DateTime으로 업데이트하고, retry-after 간격을 15초로 설정합니다.Return an HTTP 200 OK status and the content payload, update triggerState to the DateTime for the returned file, and set retry-after interval to 15 seconds.
여러 파일Multiple files 한 번에 파일 하나씩 및 HTTP 200 OK 상태를 반환하고, triggerState를 업데이트하고, retry-after 간격을 0초로 설정합니다.Return one file at a time and an HTTP 200 OK status, update triggerState, and set the retry-after interval to 0 seconds.
이러한 단계를 통해 더 많은 데이터를 사용할 수 있고 엔진이 location 헤더의 URL에서 데이터를 즉시 요청해야 한다고 엔진에 알립니다.These steps let the engine know that more data is available, and that the engine should immediately request the data from the URL in the location header.
파일 없음No files HTTP 202 ACCEPTED 상태를 반환하고, triggerState를 변경하지 않고, retry-after 간격을 15초로 설정합니다.Return an HTTP 202 ACCEPTED status, don't change triggerState, and set the retry-after interval to 15 seconds.

폴링 트리거 패턴 예제는 GitHub의 폴 트리거 컨트롤러 샘플(영문)을 검토하세요.For an example polling trigger pattern, review this poll trigger controller sample in GitHub.

웹후크 트리거 패턴으로 새 데이터 또는 이벤트 대기 및 수신 대기Wait and listen for new data or events with the webhook trigger pattern

웹후크 트리거는 서비스 엔드포인트에서 새 데이터 또는 이벤트를 대기하고 수신 대기하는 푸시 트리거입니다.A webhook trigger is a push trigger that waits and listens for new data or events at your service endpoint. 새 데이터 또는 이벤트가 지정된 조건을 충족하면 트리거가 실행되고, 논리 앱 인스턴스가 만들어지고, 데이터가 입력으로 처리됩니다.If new data or an event meets the specified condition, the trigger fires and creates a logic app instance, which then processes the data as input. 웹후크 트리거는 이 항목의 앞부분에서 설명한 웹후크 동작과 매우 비슷하게 작동하며 subscribeunsubscribe 엔드포인트로 설정됩니다.Webhook triggers act much like the webhook actions previously described in this topic, and are set up with subscribe and unsubscribe endpoints.

  • subscribe 엔드포인트: 논리 앱에 웹후크 트리거를 추가하고 저장하면 Logic Apps 엔진에서 subscribe 엔드포인트를 호출합니다.subscribe endpoint: When you add and save a webhook trigger in your logic app, the Logic Apps engine calls the subscribe endpoint. 이 단계에서는 논리 앱이 API에서 저장하는 콜백 URL을 만듭니다.This step causes the logic app to create a callback URL that your API stores. 지정된 조건을 충족하는 새 데이터 또는 이벤트가 있으면 API에서 URL에 대한 HTTP POST를 통해 콜백합니다.When there's new data or an event that meets the specified condition, your API calls back with an HTTP POST to the URL. 콘텐츠 페이로드와 헤더는 입력으로 논리 앱에 전달됩니다.The content payload and headers pass as input to the logic app.

  • unsubscribe 엔드포인트: 웹후크 트리거 또는 전체 논리 앱이 삭제되면 Logic Apps 엔진에서 unsubscribe 엔드포인트를 호출합니다.unsubscribe endpoint: If the webhook trigger or entire logic app is deleted, the Logic Apps engine calls the unsubscribe endpoint. 그런 다음 API에서 콜백 URL을 등록 취소하고 필요에 따라 모든 프로세스를 중지할 수 있습니다.Your API can then unregister the callback URL and stop any processes as necessary.

웹후크 트리거 패턴

참고

현재 Logic App Designer는 Swagger를 통한 웹후크 엔드포인트 검색을 지원하지 않습니다.Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. 따라서 이 패턴의 경우 웹후크 트리거를 추가하고 요청에 대한 URL, 헤더 및 본문을 지정해야 합니다.So for this pattern, you have to add a Webhook trigger and specify the URL, headers, and body for your request. HTTPWebhook 트리거도 참조하세요.See also HTTPWebhook trigger. 콜백 URL을 전달하려면 필요에 따라 이전 필드 중 하나에서 @listCallbackUrl() 워크플로 함수를 사용할 수 있습니다.To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

동일한 데이터를 여러 번 처리하지 않도록 방지하려면 트리거에서 이미 읽고 논리 앱에 전달된 데이터를 정리해야 합니다.To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

웹후크 패턴 예제는 GitHub의 웹후크 트리거 컨트롤러 샘플(영문)을 검토하세요.For an example webhook pattern, review this webhook trigger controller sample in GitHub.

논리 앱에서의 API 호출에 대해 보안 유지Secure calls to your APIs from logic apps

사용자 지정 API를 만든 후 논리 앱에서 안전하게 호출할 수 있도록 API에 대한 인증을 설정합니다.After creating your custom APIs, set up authentication for your APIs so that you can call them securely from logic apps. 논리 앱에서의 사용자 지정 API 호출에 대해 보안을 유지하는 방법을 알아봅니다.Learn how to secure calls to custom APIs from logic apps.

API 배포 및 호출Deploy and call your APIs

인증을 설정한 후에 API에 대한 배포를 설정합니다.After you set up authentication, set up deployment for your APIs. 논리 앱에서 사용자 지정 API를 배포 및 호출하는 방법을 알아봅니다.Learn how to deploy and call custom APIs from logic apps.

Azure에 사용자 지정 API 게시Publish custom APIs to Azure

사용자 지정 API를 Azure의 다른 Logic Apps 사용자가 사용할 수 있게 하려면 보안을 추가하고 Logic Apps 커넥터로 등록해야 합니다.To make your custom APIs available for other Logic Apps users in Azure, you must add security and register them as Logic App connectors. 자세한 내용은 사용자 지정 커넥터 개요를 참조하세요.For more information, see Custom connectors overview.

사용자 지정 API를 Logic Apps, Microsoft Flow 및 Microsoft PowerApps의 모든 사용자가 사용할 수 있게 하려면 보안을 추가하고, API를 Logic Apps 커넥터로 등록하고, Microsoft Azure 인증 프로그램에 대한 커넥터로 지정해야 합니다.To make your custom APIs available to all users in Logic Apps, Microsoft Flow, and Microsoft PowerApps, you must add security, register your APIs as Logic App connectors, and nominate your connectors for the Microsoft Azure Certified program.

지원 받기Get support

다음 단계Next steps