다음을 통해 공유

Azure Logic Apps의 워크플로에 대한 인바운드 HTTPS 호출 수신 및 응답

  • 아티클

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

이 방법 가이드에서는 요청 기본 제공 트리거를 사용하여 다른 서비스에서 인바운드 HTTPS 요청 또는 호출을 수신하고 처리할 수 있는 논리 앱 워크플로를 만드는 방법을 보여 줍니다. 워크플로에서 이 트리거를 사용하면 응답 기본 제공 작업을 사용하여 HTTPS 요청에 응답할 수 있습니다.

참고 항목

응답 작업은 요청 트리거를 사용할 때만 작동합니다.

예를 들어, 다음 목록에서는 요청 트리거 및 응답 작업을 사용할 때 워크플로에서 수행할 수 있는 일부 작업을 설명합니다.

  • 온-프레미스 데이터베이스에서 데이터에 대한 HTTPS 요청을 수신하고 응답합니다.

  • 다른 논리 앱 워크플로에서 전송된 HTTPS 요청을 수신하고 응답합니다.

  • 외부 웹후크 이벤트가 발생하는 경우 워크플로 실행을 트리거합니다.

대신 나가는 또는 아웃바운드 요청을 전송하여 워크플로를 실행하려면 HTTP 기본 제공 트리거 또는 HTTP 기본 제공 작업을 사용합니다.

필수 조건

  • Azure 계정 및 구독 구독이 없는 경우 Azure 체험 계정에 가입할 수 있습니다.

  • 인바운드 HTTPS 요청을 수신하려는 논리 앱 워크플로. 요청 트리거를 사용하여 워크플로를 시작하려면 빈 워크플로로 시작해야 합니다. 응답 작업을 사용하려면 워크플로가 요청 트리거로 시작되어야 합니다.

  • 솔루션을 테스트하기 위해 HTTP 요청을 보낼 수 있는 도구를 설치하거나 사용합니다. 예를 들면 다음과 같습니다.

    주의

    자격 증명, 비밀, 액세스 토큰, API 키 및 기타 유사한 정보와 같은 중요한 데이터가 있는 시나리오의 경우 필요한 보안 기능으로 데이터를 보호하고, 오프라인 또는 로컬로 작동하며, 데이터를 클라우드에 동기화하지 않고, 온라인 계정에 로그인할 필요가 없는 도구를 사용해야 합니다. 이렇게 하면 중요한 데이터가 대중에게 노출되는 위험을 줄일 수 있습니다.

요청 트리거 추가

요청 트리거는 HTTPS를 통한 인바운드 요청만 처리하는 수동으로 호출 가능한 엔드포인트를 만듭니다. 호출자가 이 엔드포인트에 요청을 보내면 요청 트리거가 발생하고 워크플로가 실행됩니다. 이 트리거를 호출하는 방법에 대한 자세한 내용은 Azure Logic Apps의 HTTPS 엔드포인트를 통해 워크플로 호출, 트리거 또는 중첩을 참조하세요.

  1. Azure Portal의 디자이너에서 사용량 논리 앱과 빈 워크플로를 엽니다.

  2. 디자이너에서 다음 일반 단계에 따라 HTTP 요청이 수신될 때라는 요청 기본 제공 트리거를 찾아서 추가합니다.

  3. 트리거 정보 상자가 나타나면 필요에 따라 다음 정보를 제공합니다.

    Property name JSON 속성 이름 Required 설명
    HTTP POST URL {없음} 예 워크플로를 저장한 후 생성되고 워크플로를 트리거하는 요청을 보내는 데 사용되는 엔드포인트 URL입니다.
    요청 본문 JSON 스키마 schema 아니요 들어오는 요청 본문의 속성 및 값을 설명하는 JSON 스키마입니다. 디자이너는 이 스키마를 사용하여 요청에서 속성에 대한 토큰을 생성합니다. 이렇게 하면 워크플로가 요청 트리거의 출력을 구문 분석하고, 사용하고, 워크플로로 전달할 수 있습니다.

    JSON 스키마가 없을 경우 샘플 페이로드를 사용하여 스키마 생성 기능을 사용하여 샘플 페이로드에서 스키마를 생성할 수 있습니다.

    다음 예제에서는 샘플 JSON 스키마를 보여 줍니다.

    예제 JSON 스키마가 있는 사용량 워크플로 및 요청 트리거를 보여 주는 스크린샷

    다음 예제에서는 전체 샘플 JSON 스키마를 보여 줍니다.

    {
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

    JSON 스키마를 입력하면 요청에 Content-Type 헤더를 포함하고 해당 헤더 값을 application/json으로 설정하라는 미리 알림이 디자이너에 표시됩니다. 자세한 내용은 콘텐츠 유형 처리를 참조하세요.

    사용량 워크플로, 요청 트리거 및

    다음 예제에서는 Content-Type 헤더가 JSON 형식으로 표시되는 방식을 보여 줍니다.

    {
   "Content-Type": "application/json"
}

    예상 페이로드(데이터)를 기반으로 하는 JSON 스키마를 생성하려면 JSONSchema.net과 같은 도구를 사용하거나 다음 단계를 수행합니다.

    1. 요청 트리거에서 샘플 페이로드를 사용하여 스키마 생성을 선택합니다.

      사용량 워크플로, 요청 트리거 및

    2. 샘플 페이로드를 입력하고 완료를 선택합니다.

      사용량 워크플로, 요청 트리거 및 스키마 생성을 위해 입력된 샘플 페이로드를 보여 주는 스크린샷

      다음 예제에서는 샘플 페이로드를 보여 줍니다.

      {
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

  4. 인바운드 호출에 특정 스키마와 일치하는 요청 본문이 있는지 확인하려면 다음 단계를 수행합니다.

    1. 인바운드 메시지가 스키마에서 설명하는 것과 동일한 필드를 갖도록 하려면 스키마에서 required 속성을 추가하고 필수 필드를 지정합니다. addtionalProperties 속성을 추가하고 값을 false로 설정합니다.

      예를 들어 다음 스키마는 인바운드 메시지에 다른 필드가 아닌 msg 필드가 있어야 한다고 지정합니다.

      {
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}

    2. 요청 트리거의 제목 표시줄에서 줄임표 단추(...)를 선택합니다.

    3. 트리거의 설정에서 스키마 유효성 검사를 켜고 완료를 선택합니다.

      인바운드 호출의 요청 본문이 스키마와 일치하지 않는 경우 트리거가 HTTP 400 잘못된 요청 오류를 반환합니다.

  5. 트리거에 다른 속성 또는 매개 변수를 추가하려면 새 매개 변수 추가 목록을 열고 추가하려는 매개 변수를 선택합니다.

    Property name JSON 속성 이름 Required 설명
    방법 method 아니요 들어오는 요청에서 논리 앱을 호출하는 데 사용해야 하는 메서드
    상대 경로 relativePath 아니요 논리 앱의 엔드포인트의 URL이 수락할 수 있는 매개 변수에 대한 상대 경로입니다.

    다음 예제에서는 메서드 속성을 추가합니다.

    사용량 워크플로, 요청 트리거 및

    목록에서 메서드를 선택할 수 있도록 메서드 속성이 트리거에 표시됩니다.

    사용량 워크플로, 요청 트리거 및 메서드가 선택된 상태로 열려 있는

  6. 준비되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

    이 단계에서는 워크플로를 트리거하는 요청을 전송하는 데 사용할 수 있는 URL을 생성합니다.

  7. 생성된 URL을 복사하려면 URL 옆에 있는 복사 아이콘을 선택합니다.

    사용량 워크플로, 요청 트리거 및 URL 복사 단추가 선택된 것을 보여 주는 스크린샷

    참고 항목

    요청 트리거를 호출할 때 URI에 해시 또는 파운드 기호(#)를 포함하고자 하는 경우 대신 인코딩된 버전(%25%23)을 사용합니다.

이제 다음 단계로 다른 작업을 추가하여 워크플로를 계속 빌드합니다. 예를 들어 사용자 지정된 응답을 반환하는 데 사용할 수 있으며 이 문서의 뒷부분에서 설명하는 응답 작업을 추가하여 요청에 응답할 수 있습니다.

참고 항목

워크플로는 제한된 시간 동안만 인바운드 요청을 열어 둡니다. 워크플로에 응답 작업도 포함되어 있다고 가정하고, 이 시간이 만료된 후 워크플로가 호출자에게 응답을 반환하지 않으면 워크플로는 504 게이트웨이 시간 초과 상태를 호출자에게 반환합니다. 워크플로에 응답 작업이 포함되지 않은 경우 워크플로는 호출자에게 202 수락됨 상태를 즉시 반환합니다.

이전에 SSL(Secure Sockets Layer),Microsoft Entra ID를 사용하는 OAuth, SAS(공유 액세스 서명)로 알려진 TLS(전송 계층 보안), AZURE API Management를 사용하여 논리 앱 리소스 노출 또는 인바운드 호출을 시작하는 IP 주소 제한과 같은 워크플로에 대한 인바운드 호출에 대한 보안, 인증 및 암호화에 대한 자세한 내용은 보안 액세스 및 데이터 - 요청 기반 트리거에 대한 인바운드 호출에 대한 액세스를 참조하세요.

트리거 출력

다음 표에는 요청 트리거의 출력이 나와 있습니다.

JSON 속성 이름 데이터 형식 설명
headers Object 요청의 헤더를 설명하는 JSON 개체입니다.
body Object 요청의 본문 콘텐츠를 설명하는 JSON 개체입니다.

응답 작업 추가

요청 트리거를 사용하여 인바운드 요청을 수신하는 경우 요청 트리거와만 함께 작동하는 응답 기본 제공 작업을 사용하여 응답을 모델링하고 페이로드 결과를 다시 호출자에게 보낼 수 있습니다. 이 조합은 요청 트리거 및 응답 작업과 함께 요청-응답 패턴을 만듭니다. Foreach 루프와 Until 루프, 병렬 분기를 제외하면 워크플로의 어디에서나 응답 작업을 추가할 수 있습니다.

Important

  • 응답 작업에 다음과 같은 헤더가 포함된 경우 Azure Logic Apps는 경고 또는 오류를 표시하지 않고 생성된 응답 메시지에서 이러한 헤더를 자동으로 제거합니다. 이러한 헤더가 포함된 응답 작업이 있는 워크플로를 저장하지 못하는 것은 아니지만 Azure Logic Apps에는 이러한 헤더가 포함되지 않습니다.

    • Allow
    • POST 및 PUT 작업을 사용하지만 GET 작업에는 포함되지 않는 경우의 Content-Disposition, Content-Encoding, Content-Type을 제외한 Content-* 헤더
    • Cookie
    • Expires
    • Last-Modified
    • Set-Cookie
    • Transfer-Encoding

  • 분기가 있는 복잡한 워크플로에 하나 이상의 응답 작업이 있는 경우 워크플로가 런타임 중에 하나 이상의 응답 작업을 처리하는지 확인합니다. 그렇지 않고 모든 응답 작업을 건너뛰면 워크플로가 성공적으로 완료되더라도 호출자는 502 잘못된 게이트웨이 오류를 수신합니다.

  • 표준 논리 앱 상태 비저장 워크플로에서 응답 작업은 워크플로에 마지막으로 표시되어야 합니다. 작업이 다른 곳에 표시되면 Azure Logic Apps는 다른 모든 작업의 실행이 완료될 때까지 작업을 실행하지 않습니다.

  1. 워크플로 디자이너에서 다음 일반 단계에 따라 응답이라는 응답 기본 제공 작업을 찾아서 추가합니다.

    간단한 설명을 위해 다음 예제에서는 축소된 요청 트리거를 보여 줍니다.

  2. 작업 정보 상자에 응답 메시지에 필요한 값을 추가합니다.

    Property name JSON 속성 이름 Required 설명
    상태 코드 statusCode 예 응답에 반환할 상태 코드
    헤더 headers 아니요 응답에 포함할 하나 이상의 헤더를 설명하는 JSON 개체입니다.
    본문 body 아니요 응답 본문

    텍스트 필드 내부를 선택하면 동적 콘텐츠 목록이 자동으로 열립니다. 그런 다음, 워크플로의 이전 단계에서 사용 가능한 출력을 나타내는 토큰을 선택할 수 있습니다. 지정한 스키마의 속성도 이 동적 콘텐츠 목록에 나타납니다. 워크플로에서 사용할 속성을 선택할 수 있습니다.

    예를 들어, 헤더 필드에 키 이름으로 Content-Type을 포함하고 이 문서 앞부분에서 언급한 대로 키 값을 application/json으로 설정합니다. 본문 상자의 경우 동적 콘텐츠 목록에서 트리거 본문 출력을 선택할 수 있습니다.

    Azure Portal, 사용량 워크플로 및 응답 작업 정보를 보여 주는 스크린샷

    헤더를 JSON 형식으로 보려면 텍스트 뷰로 전환를 선택합니다.

    Azure Portal, 사용량 워크플로 및

  3. 응답 본문의 JSON 스키마와 같은 작업에 대한 추가 속성을 추가하려면 새 매개 변수 추가 목록에서 추가하려는 매개 변수를 선택합니다.

  4. 완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

워크플로 테스트

워크플로를 트리거하려면 HTTP 요청 도구 및 해당 지침을 사용하여 요청트리거가 예상하는 메서드를 포함하여 요청 트리거에 대해 생성된 URL로 HTTP 요청을 보냅니다.

트리거의 기본 JSON 정의 및 이 트리거를 호출하는 방법에 대한 자세한 내용은 요청 트리거 형식 및 Azure Logic Apps의 HTTP 엔드포인트를 통해 워크플로 호출, 트리거 또는 중첩을 참조하세요.

보안 및 인증

요청 트리거(웹후크 트리거 아님)로 시작하는 표준 논리 앱 워크플로에서는 관리 ID를 사용하여 해당 트리거에서 만든 엔드포인트로 전송된 인바운드 호출을 인증하기 위해 Azure Functions 프로비전을 사용할 수 있습니다. 이 프로비전을 "Easy Auth"라고도 합니다. 자세한 내용은 간편한 인증을 사용하여 표준 논리 앱에서 트리거 워크플로를 검토하세요.

이전 명칭이 SSL(Secure Sockets Layer)이었던 TLS(전송 계층 보안), 논리 앱을 Azure API Management에 노출시키는 Microsoft Entra ID OAuth(Microsoft Entra ID Open Authentication) 같은 논리 앱 워크플로에 대한 인바운드 호출의 보안, 인증, 그리고 암호화, 혹은 인바운드 호출을 시작하는 IP 제한에 대한 자세한 정보는 액세스 및 데이터 보안 - 요청 기반 트리거의 인바운드 호출 액세스를 참조하세요.

다음 단계