Azure Logic Apps의 워크플로에서 외부 HTTP 또는 HTTPS 엔드포인트 호출

아티클
04/08/2024

적용 대상: Azure Logic Apps(사용량 + 표준)

일부 시나리오에서는 HTTP 또는 HTTPS를 통해 다른 서비스 또는 시스템의 엔드포인트에 아웃바운드 요청을 보내는 논리 앱 워크플로를 만들어야 할 수 있습니다. 예를 들어 특정 일정에 따라 해당 엔드포인트를 확인하여 웹 사이트의 서비스 엔드포인트를 모니터링하려는 경우를 가정해 보겠습니다. 웹 사이트 가동 중단과 같은 특정 이벤트가 해당 엔드포인트에서 발생하면 해당 이벤트는 워크플로를 트리거하고 해당 워크플로에서 작업을 실행합니다.

참고 항목

대신 인바운드 HTTPS 호출을 수신하고 응답하는 워크플로를 만들려면 Azure Logic Apps에서 HTTPS 엔드포인트를 사용하여 호출, 트리거 또는 중첩할 수 있는 워크플로 만들기 및 기본 제공 요청 트리거 및 응답 작업을 참조하세요.

이 가이드에서는 워크플로가 다른 서비스 및 시스템에 아웃바운드 호출을 보낼 수 있도록 HTTP 트리거 및 HTTP 작업을 사용하는 방법을 보여 줍니다. 예를 들면 다음과 같습니다.

반복되는 일정으로 엔드포인트를 검사하거나 폴링하려면 워크플로에서 첫 번째 단계로 HTTP 트리거를 추가합니다. 트리거가 엔드포인트를 검사할 때마다 트리거는 엔드포인트에 대해 요청을 호출하거나 보냅니다. 엔드포인트의 응답은 워크플로가 실행될지 여부를 결정합니다. 트리거는 엔드포인트의 응답에서 모든 콘텐츠를 워크플로의 작업으로 전달합니다.
워크플로의 다른 위치에서 엔드포인트를 호출하려면 HTTP 작업을 추가합니다. 엔드포인트의 응답은 워크플로의 나머지 작업을 실행하는 방법을 결정합니다.

필수 조건

Azure 계정 및 구독 Azure 구독이 없는 경우 체험 Azure 계정에 등록합니다.
호출하려는 대상 엔드포인트의 URL
대상 엔드포인트를 호출하려는 논리 앱 워크플로입니다. HTTP 트리거를 시작하려면 빈 워크플로가 필요합니다. HTTP 작업을 사용하려면 원하는 트리거를 사용하여 워크플로를 시작합니다. 이 예제에서는 첫 번째 단계로 HTTP 트리거를 사용합니다.

커넥터 기술 참조

트리거 및 작업 매개 변수에 대한 기술 정보는 다음 섹션을 참조하세요.

HTTP 트리거를 추가합니다.

이 기본 제공 트리거는 엔드포인트에 대해 지정된 URL로 HTTP 호출을 수행하고 응답을 반환합니다.

Standard
소비

Azure Portal의 디자이너에서 표준 논리 앱 리소스와 빈 워크플로를 엽니다.
워크플로에 HTTP라는 기본 제공 트리거를 추가하려면 다음 일반 단계를 따릅니다.

이 예제에서는 트리거의 이름을 HTTP 트리거 - 엔드포인트 호출 URL로 변경하여 트리거에 보다 설명적인 이름을 지정합니다. 또한 이 예제에서는 나중에 HTTP 작업을 추가하고 워크플로의 작업 이름은 고유해야 합니다.
대상 엔드포인트에 대한 호출에 포함하려는 HTTP 트리거 매개 변수에 대해 값을 제공합니다. 트리거로 대상 엔드포인트를 검사하려는 빈도에 대해 되풀이를 설정합니다.

없음 이외의 인증 유형을 선택한 경우 인증 설정은 선택에 따라 달라집니다. HTTP에 사용할 수 있는 인증 유형에 대한 자세한 내용은 다음 토픽을 참조하세요.
- 아웃바운드 호출에 인증 추가
- 관리 ID를 사용하여 리소스에 대한 액세스 인증
다른 사용 가능한 매개 변수를 추가하려면 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
트리거가 실행되면 실행할 다른 작업을 추가합니다.
완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

HTTP 작업 추가

이 기본 제공 작업은 엔드포인트에 대해 지정된 URL로 HTTP 호출을 수행하고 응답을 반환합니다.

Standard
소비

Azure Portal에서 디자이너를 통해 사용량 논리 앱 및 워크플로를 엽니다.

이 예제에서는 이전 섹션에서 추가된 HTTP 트리거를 첫 번째 단계로 사용합니다.
워크플로에 HTTP라는 기본 제공 작업을 추가하려면 다음 일반 단계를 따릅니다.

이 예제에서는 작업 이름을 HTTP 작업 - 엔드포인트 호출 URL로 변경하여 단계에 보다 설명적인 이름을 지정합니다. 또한 워크플로의 작업 이름은 고유해야 합니다.
대상 엔드포인트에 대한 호출에 포함하려는 HTTP 작업 매개 변수에 대해 값을 제공합니다.

없음 이외의 인증 유형을 선택한 경우 인증 설정은 선택에 따라 달라집니다. HTTP에 사용할 수 있는 인증 유형에 대한 자세한 내용은 다음 토픽을 참조하세요.
- 아웃바운드 호출에 인증 추가
- 관리 ID를 사용하여 리소스에 대한 액세스 인증
다른 사용 가능한 매개 변수를 추가하려면 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

트리거 및 작업 출력

다음 정보를 반환하는 HTTP 트리거 또는 작업의 출력에 대한 자세한 내용은 다음과 같습니다.

속성	Type	설명
`headers`	JSON 개체	요청의 헤더
`body`	JSON 개체	요청의 본문 콘텐츠가 포함된 개체
`status code`	정수	요청의 상태 코드

상태 코드	Description
200	OK
202	Accepted
400	Bad request
401	Unauthorized
403	금지
404	Not Found
500	내부 서버 오류입니다. 알 수 없는 오류 발생.

아웃바운드 호출에 대한 URL 보안

이전에 SSL(Transport Layer Security)로 알려진 TLS(전송 계층 보안), 자체 서명된 인증서 또는 Microsoft Entra ID OAuth(Microsoft Entra ID Open Authentication)와 같이 워크플로에서의 아웃바운드 호출에 대한 암호화, 보안 및 권한 부여에 대한 자세한 내용은 보안 액세스 및 데이터 - 다른 서비스 및 시스템에 대한 아웃바운드 호출 액세스를 참조하세요.

단일 테넌트 환경에 대한 인증

단일 테넌트 Azure Logic Apps에 표준 논리 앱 리소스가 있고 다음 인증 유형과 함께 HTTP 작업을 사용하려는 경우 해당 인증 유형에 대한 추가 설정 단계를 완료해야 합니다. 그러지 않으면 호출이 실패합니다.

TLS/SSL 인증서: 앱 설정, WEBSITE_LOAD_ROOT_CERTIFICATES를 추가하고 값을 TLS/SSL 인증서의 지문으로 설정합니다.
"인증서" 자격 증명 유형이 있는 클라이언트 인증서 또는 Microsoft Entra ID OAuth(Microsoft Entra ID Open Authentication): 앱 설정(WEBSITE_LOAD_USER_PROFILE)을 추가하고 값을 1로 설정합니다.

TLS/SSL 인증서 인증

논리 앱 리소스의 앱 설정에서 앱 설정을 추가 또는 업데이트(WEBSITE_LOAD_ROOT_CERTIFICATES)합니다.
설정 값의 경우 신뢰할 수 있는 루트 인증서로 TLS/SSL 인증서에 대한 지문을 제공합니다.

"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>"

예를 들어 Visual Studio Code 작업하는 경우 다음 단계를 수행합니다.

논리 앱 프로젝트의 local.settings.json 파일을 엽니다.
ValuesJSON 개체에서 설정을 추가하거나 업데이트WEBSITE_LOAD_ROOT_CERTIFICATES합니다.
```
{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>",
      <...>
   }
}
```
참고 항목

지문을 찾으려면 다음 단계를 수행합니다.
1. 논리 앱 리소스 메뉴의 설정에서 TLS/SSL 설정>프라이빗 키 인증서(.pfx) 또는 공개 키 인증서(.cer)를 선택합니다.
2. 사용하려는 인증서를 찾아 지문을 복사합니다.
자세한 내용은 지문 찾기 - Azure App Service를 검토하세요.

자세한 내용은 다음 설명서를 검토하세요.

클라이언트 인증서 또는 "인증서" 자격 증명 유형 인증을 사용하는 Microsoft Entra ID OAuth

논리 앱 리소스의 앱 설정에서 앱 설정을 추가 또는 업데이트(WEBSITE_LOAD_USER_PROFILE)합니다.
설정 값에 대해 1을 지정합니다.

"WEBSITE_LOAD_USER_PROFILE": "1"

예를 들어 Visual Studio Code 작업하는 경우 다음 단계를 수행합니다.

논리 앱 프로젝트의 local.settings.json 파일을 엽니다.

ValuesJSON 개체에서 설정을 추가하거나 업데이트WEBSITE_LOAD_USER_PROFILE합니다.

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_USER_PROFILE": "1",
      <...>
   }
}

자세한 내용은 다음 설명서를 검토하세요.

multipart/form-data 형식의 콘텐츠

HTTP 요청에 multipart/form-data 유형이 포함된 콘텐츠를 처리하려면 다음 형식을 사용하여 $content-type 및 $multipart 특성이 포함된 JSON 객체를 HTTP 요청의 본문에 추가할 수 있습니다.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

예를 들어 multipart/form-data 유형을 지원하는 해당 사이트의 API를 사용하여 Excel 파일에 대한 HTTP POST 요청을 웹 사이트로 전송하는 워크플로가 있다고 가정해보세요. 다음 샘플에서는 이 작업이 표시되는 방법을 보여 줍니다.

표준 워크플로

사용량 워크플로

다음은 기본 워크플로 정의에서 HTTP 작업의 JSON 정의를 보여 주는 동일한 예제입니다.

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

application/x-www-form-urlencoded 유형의 콘텐츠

HTTP 요청에 대해 form-urlencoded 데이터를 본문에 제공하려면 application/x-www-form-urlencoded 콘텐츠 형식을 포함하는 데이터를 지정해야 합니다. HTTP 트리거 또는 작업에서 content-type 헤더를 추가합니다. 헤더 값을 application/x-www-form-urlencoded로 설정합니다.

예를 들어 HTTP POST 요청을 웹 사이트로 전송하고 application/x-www-form-urlencoded 유형을 지원하는 논리 앱이 있다고 가정해보세요. 이 작업의 모양은 다음과 같습니다.

표준 워크플로

사용량 워크플로

비동기 요청-응답 동작

다중 테넌트 및 단일 테넌트 Azure Logic Apps의 상태 저장 워크플로의 경우 모든 HTTP 기반 작업은 기본 동작으로 표준 비동기 작업 패턴을 따릅니다. 이 패턴은 HTTP 작업이 요청을 호출하거나 엔드포인트, 서비스, 시스템 또는 API로 요청을 전송한 후 수신기가 즉시 "202 ACCEPTED" 응답을 반환하도록 지정합니다. 이 코드는 수신기에서 요청을 수락했지만 처리가 완료되지 않았음을 확인합니다. 응답에는 수신기에서 처리를 중지하고 ‘200 정상’ 성공 응답 또는 202가 아닌 다른 응답을 반환할 때까지 호출자가 비동기 요청의 상태를 폴링하거나 확인하는 데 사용할 수 있는 URI 및 새로 고침 ID를 지정하는 location 헤더가 포함될 수 있습니다. 하지만 호출자가 요청 처리가 완료될 때까지 기다릴 필요가 없고 계속 다음 작업을 실행할 수 있습니다. 자세한 내용은 비동기 마이크로서비스 통합에 마이크로서비스 자율성 적용을 참조하세요.

단일 테넌트 Azure Logic Apps의 상태 비정상 워크플로의 경우 HTTP 기반 작업은 비동기 작업 패턴을 사용하지 않습니다. 대신 동기적으로만 실행되고 "202 ACCEPTED" 응답을 있는 그대로 반환하고 워크플로 실행의 다음 단계를 진행합니다. 응답에 location 헤더가 포함된 경우 상태 비저장 워크플로는 지정된 URI를 폴링하여 상태를 확인하지 않습니다. 표준 비동기 작업 패턴을 따르려면 상태 저장 워크플로를 대신 사용합니다.

HTTP 작업의 기본 JSON(JavaScript Object Notation) 정의는 암시적으로 비동기 작업 패턴을 따릅니다.
트리거가 아닌 HTTP 작업에는 기본적으로 사용하도록 설정된 비동기 패턴 설정이 있습니다. 이 설정은 호출자에서 처리가 완료될 때까지 기다리지 않고 다음 작업으로 이동할 수 있지만 처리가 중지될 때까지 상태를 계속 확인하도록 지정합니다. 이 설정이 사용하지 않도록 설정되면 호출자에서 처리가 완료될 때까지 기다린 후에 다음 작업으로 이동하도록 지정합니다.

비동기 패턴 설정을 찾으려면 표준 또는 사용량 워크플로가 있는지 여부에 따라 다음 단계를 수행합니다.

표준 워크플로*
1. 워크플로 디자이너에서 HTTP 작업을 선택합니다. 열리는 정보 창에서 설정을 선택합니다.
2. 네트워킹 아래에서 비동기 패턴 설정을 찾습니다.
사용량 워크플로
1. 워크플로 디자이너의 HTTP 작업의 제목 표시줄에서 줄임표(...) 단추를 선택하여 작업의 설정을 엽니다.
2. 비동기 패턴 설정을 찾습니다.

비동기 작업을 사용하지 않도록 설정

일부 경우에는 다음과 같은 특정 시나리오에서 HTTP 작업의 비동기 동작을 사용하지 않도록 설정할 수 있습니다.

장기 실행 작업에 대한 HTTP 시간 제한 방지
위치 헤더 확인을 사용하지 않도록 설정

워크플로 디자이너에서 HTTP 작업을 선택하고 열리는 정보 창에서 설정을 선택합니다.
네트워킹 아래에서 비동기 패턴 설정을 찾습니다. 사용하도록 설정된 경우 설정을 끄기로 전환합니다.

작업의 JSON 정의에서 비동기 패턴을 사용하지 않도록 설정

HTTP 작업의 기본 JSON 정의에서 작업이 대신 동기 작업 패턴을 따르도록 작업 정의에 "DisableAsyncPattern" 작업 옵션을 추가합니다. 또한 자세한 내용은 동기 작업 패턴으로 작업 실행을 참조하세요.

장기 실행 작업에 대한 HTTP 시간 제한 방지

HTTP 요청에는 제한 시간 제한이 있습니다. 이 제한으로 인해 제한 시간에 걸리는 장기 실행 HTTP 작업이 있으면 다음 옵션을 사용할 수 있습니다.

작업이 지속적으로 요청 상태를 폴링하거나 확인하지 않도록 HTTP 작업의 비동기 작업 패턴을 사용하지 않도록 설정합니다. 대신 요청 처리가 완료된 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.
HTTP 작업을 HTTP 웹후크 작업으로 바꿉니다. 이렇게 하면 요청 처리가 완료된 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.

Retry-After 헤더를 사용하여 다시 시도 사이의 간격 설정

다시 시도 사이의 시간(초)을 지정하려면 HTTP 작업 응답에 Retry-After 헤더를 추가할 수 있습니다. 예를 들어 대상 엔드포인트가 429 - Too many requests 상태 코드를 반환하는 경우 재시도 사이에 더 긴 간격을 지정할 수 있습니다. Retry-After 헤더는 202 - Accepted 상태 코드에서도 작동합니다.

다음은 Retry-After를 포함하는 HTTP 작업 응답을 보여 주는 동일한 예제입니다.

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

페이지 매김 지원

경우에 따라 대상 서비스는 결과를 한 번에 한 페이지씩 반환하여 응답합니다. 응답이 nextLink 또는 @odata.nextLink 속성을 사용하여 다음 페이지를 지정하는 경우 HTTP 작업에서 페이지 매김 설정을 켤 수 있습니다. 이 설정을 사용하면 HTTP 작업이 이러한 링크를 자동으로 따르고 다음 페이지를 가져옵니다. 그러나 응답이 다른 태그가 있는 다음 페이지를 지정하는 경우 워크플로에 루프를 추가해야 할 수 있습니다. 이 루프가 해당 태그를 따르고 태그가 null이 될 때까지 각 페이지를 수동으로 가져옵니다.

위치 헤더 확인을 사용하지 않도록 설정

일부 엔드포인트, 서비스, 시스템 또는 API는 location 헤더가 없는 202 ACCEPTED 응답을 반환합니다. location 헤더가 존재하지 않을 때 HTTP 작업이 지속적으로 요청 상태를 확인하도록 하지 않으려면 다음 옵션을 사용할 수 있습니다.

작업이 지속적으로 요청 상태를 폴링하거나 확인하지 않도록 HTTP 작업의 비동기 작업 패턴을 사용하지 않도록 설정합니다. 대신 요청 처리가 완료된 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.
HTTP 작업을 HTTP 웹후크 작업으로 바꿉니다. 이렇게 하면 요청 처리가 완료된 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.

알려진 문제

생략된 HTTP 헤더

HTTP 트리거 또는 작업에 이러한 헤더가 포함된 경우 Azure Logic Apps는 경고 또는 오류를 표시하지 않고 생성된 요청 메시지에서 이러한 헤더를 제거합니다.

Accept-version을 제외한 Accept-* 헤더
Allow
Content-Disposition, Content-Encoding 및 Content-Type을 제외한 Content-* 헤더이며, POST 및 PUT 작업을 사용할 때 적용됩니다. 하지만 Azure Logic Apps는 GET 작업을 사용할 때 이러한 헤더를 삭제합니다.
Cookie 헤더이지만 Azure Logic Apps는 쿠키 속성을 사용하여 지정하는 모든 값을 적용합니다.
Expires
Host
Last-Modified
Origin
Set-Cookie
Transfer-Encoding

Azure Logic Apps로 인해 이러한 헤더와 함께 HTTP 트리거 또는 작업을 사용하는 논리 앱을 저장하는 것이 방해되지는 않지만, Azure Logic Apps에서 이러한 헤더가 무시됩니다.

응답 콘텐츠가 예상 콘텐츠 형식과 일치하지 않음

HTTP 작업은 Content-Type 헤더가 애플리케이션/json으로 설정된 백 엔드 API를 호출하지만 백 엔드의 응답에 실제로 JSON 형식의 콘텐츠가 포함되어 있지 않아 내부 JSON 형식 유효성 검사가 실패하는 경우 BadRequest 오류를 throw합니다.

다음을 통해 공유