Visual Studio Code를 사용하여 표준 논리 앱 워크플로 만들기

2025-04-12

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

이 가이드에서는 Visual Studio Code와 Azure Logic Apps(표준) 확장을 함께 사용할 때 단일 테넌트 Azure Logic Apps에서 실행할 수 있는 예 표준 논리 앱 워크플로를 로컬로 만드는 방법을 보여 줍니다.

이 가이드에서는 표준 논리 앱 작업 영역과 프로젝트를 만들고, 워크플로를 빌드하고, 프로젝트를 Azure의 표준 논리 앱 리소스로 배포합니다. 여기서 워크플로는 단일 테넌트 Azure Logic Apps 또는 App Service Environment v3(Windows 기반 App Service 요금제에만 해당)에서 실행될 수 있습니다. Azure Logic Apps(표준)의 컨테이너화된 런타임 덕분에 Azure, Azure Kubernetes Service, 온-프레미스 또는 다른 클라우드 공급자 등 Kubernetes를 실행할 수 있는 모든 곳에 워크플로를 배포하고 실행할 수 있습니다.

표준 논리 앱이 제공하는 몇 가지 이점은 다음과 같습니다.

로컬 Visual Studio Code 개발 환경에서 워크플로를 로컬로 만들고, 디버깅하고, 실행하고, 테스트할 수 있습니다. Azure Portal과 Visual Studio Code는 모두 표준 논리 앱 리소스와 워크플로를 빌드, 실행 및 배포하는 기능을 제공합니다. 하지만 Visual Studio Code를 사용하면 이러한 작업을 로컬에서 수행할 수 있습니다.
표준 논리 앱 프로젝트에는 상태 저장 워크플로와 상태 비저장 워크플로가 모두 포함될 수 있습니다.
동일한 표준 논리 앱 리소스 및 테넌트의 워크플로는 Azure Logic Apps(표준) 런타임과 동일한 프로세스에서 실행되므로 동일한 리소스를 공유하고 더 나은 성능을 제공합니다.

이 가이드의 예제 워크플로는 처음에 요청 트리거로 시작하여 그다음에 Office 365 Outlook 작업이 이어집니다. 요청 트리거는 호출 가능한 워크플로 엔드포인트를 만들고 호출자의 인바운드 HTTPS 요청을 기다립니다. 트리거가 요청을 받고 실행되면, 선택한 트리거 출력과 함께 지정된 수신자에게 이메일을 전송하여 다음 작업을 실행합니다. 나중에 발신자에게 회신과 처리된 데이터를 반환하는 응답 작업을 추가할 수 있습니다.

Visual Studio Code, 논리 앱 작업 영역, 프로젝트 및 워크플로를 보여 주는 스크린샷.

이 가이드의 예는 클라우드 기반이며 몇 단계만 있지만, 클라우드, 온-프레미스 및 하이브리드 환경에서 광범위한 서비스, 시스템, 앱 및 데이터를 통합하는 데 도움이 되는 1,400개 이상의 커넥터를 사용하여 워크플로를 만들 수 있습니다.

가이드를 진행하면서 다음과 같은 높은 수준의 작업을 완료하게 됩니다.

빈 상태 워크플로가 있는 표준 논리 앱 작업 영역과 프로젝트를 만듭니다.
워크플로에 트리거와 작업을 추가합니다.
로컬에서 실행, 디버깅, 테스트합니다.
워크플로 실행 기록을 검토합니다.
방화벽 액세스를 위한 도메인 이름 세부 정보를 찾습니다.
상태 비저장 워크플로에 실행 기록을 사용하도록 설정합니다.
필요에 따라 Application Insights를 사용하도록 설정하는 Azure에 배포합니다.
배포 후 Application Insights를 사용하도록 설정하거나 엽니다.
Visual Studio Code와 Azure Portal에서 배포된 논리 앱 리소스를 관리합니다.

필수 조건

액세스 및 연결 요구 사항

Azure Logic Apps(표준) 런타임에서 기본적으로 실행되는 네이티브 제공 작업만을 사용하여 워크플로를 로컬로 만들고 실행하려는 경우 이 섹션의 액세스 및 연결 요구 사항이 필요하지 않습니다. 하지만 다음 시나리오에서는 다음 요구 사항을 충족해야 합니다.

Visual Studio Code에서 Azure로 논리 앱을 배포합니다.
글로벌 Azure에서 실행되는 관리되는 커넥터 작업을 사용하는 워크플로를 빌드합니다.
Azure 또는 다른 배포된 Azure 리소스에서 기존 표준 논리 앱 리소스와 워크플로에 액세스합니다.

이러한 요구 사항에는 다음 항목이 포함됩니다.

Azure 계정 및 구독 구독이 없는 경우 Azure 체험 계정에 등록합니다.
필요한 확장을 다운로드하고, Visual Studio Code에서 Azure 계정에 연결하고, 관리되는 커넥터 작업이 포함된 워크플로를 테스트하고, Visual Studio Code에서 Azure에 배포할 수 있도록 인터넷에 액세스할 수 있어야 합니다.
이 가이드와 동일한 예제 워크플로를 만들려면 Microsoft 회사 또는 학교 계정을 사용하여 로그인하는 Office 365 Outlook 이메일 계정이 필요합니다.

Office 365 계정이 없으면 이메일 계정(예: Outlook.com)에서 메시지를 보낼 수 있는 사용 가능한 모든 다른 작업을 사용하면 됩니다. Outlook.com과 같은 다른 이메일 커넥터를 선택하면 계속 예제를 수행할 수 있으며 일반적인 전체 단계는 동일합니다. 하지만 여러분의 환경과 선택지는 어떤 면에서는 다를 수 있습니다. 예를 들어, Outlook.com 커넥터를 사용하면 개인 Microsoft 계정을 사용하여 로그인할 수 있습니다.

도구

무료인 Visual Studio Code를 다운로드하고 설치합니다.
다음 단계에 따라 Visual Studio Code용 Azure Logic Apps(표준) 확장을 다운로드하고 설치합니다.
1. Visual Studio Code의 작업 막대에서 확장을 선택합니다. (키보드: Ctrl+Shift+X 누르기)
2. 확장 검색 상자에서 azure logic apps standard를 입력합니다. 결과 목록에서 Azure Logic Apps(표준)>설치를 선택합니다.
  
  이 확장 기능은 다음 프레임워크에 필요한 모든 종속성과 올바른 버전을 다운로드하고 설치합니다.
  - Azure Functions 핵심 도구
  - .NET SDK
  - Node.js
  설치가 완료되면 확장이 확장: 설치됨 목록에 표시됩니다.
3. Visual Studio Code를 다시 로드하거나 다시 시작하여 확장 기능과 모든 종속성이 올바르게 설치되었는지 확인합니다.
4. 확장과 모든 종속성이 올바르게 설치되었는지 확인하려면 확장 설치 확인을 참조하세요.
현재 사용량(다중 테넌트) 및 표준(단일 테넌트) 확장은 동시에 설치할 수 있습니다. 개발 환경은 여러 면에서 서로 다르지만 Azure 구독에는 표준 및 사용량 논리 앱 리소스 종류가 모두 포함될 수 있습니다. Visual Studio Code에서 Azure 창에는 Azure 구독의 모든 Azure 배포 및 호스팅 논리 앱이 표시되지만 앱을 다음과 같은 방식으로 구성합니다.
- 리소스 섹션: 구독의 모든 표준 논리 앱입니다.
- Logic Apps(사용량) 섹션: 구독의 모든 사용량 논리 앱입니다.
로컬에서 기본 제공 HTTP 웹후크 트리거와 같은 웹후크 기반 트리거와 작업을 실행하려면 Visual Studio Code에서 콜백 URL의 착신 전환을 설정해야 합니다.
Application Insights를 사용하여 표준 논리 앱에 대한 진단 로깅 및 추적을 사용하도록 설정하려면 논리 앱 배포 중이나 배포 후에 이 작업을 완료할 수 있습니다. Application Insights 리소스가 필요하지만 배포 중이나 배포 후에 이 리소스를 미리 만들 수 있습니다.
샘플 워크플로를 테스트하기 위해 HTTP 요청을 보낼 수 있는 도구를 설치하거나 사용합니다. 예:
주의

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

확장 설치 확인

확장 기능과 모든 종속성이 올바르게 설치되었는지 확인하려면 Visual Studio Code를 다시 로드하거나 다시 시작합니다.
모든 확장에서 최신 업데이트를 가져올 수 있도록 Visual Studio Code가 확장 업데이트를 자동으로 찾고 설치하는지 확인합니다. 그렇지 않으면 오래된 버전을 수동으로 제거하고 최신 버전을 설치해야 합니다.
1. 파일 메뉴에서 기본 설정>설정으로 차례로 이동합니다.
2. 사용자 탭에서 기능>확장으로 차례로 이동합니다.
3. 자동 업데이트 확인이 선택되어 있고, 자동 업데이트가 모든 확장으로 설정되어 있는지 확인합니다.
Azure Logic Apps 표준: 프로젝트 런타임 설정이 올바른 버전으로 설정되었는지 확인합니다.
1. 사용자 탭에서 >확장>Azure Logic Apps(표준)로 차례로 이동합니다.
2. 프로젝트 런타임이 버전 ~4로 설정되어 있는지 확인합니다. 예:
  
  비고
  
  이 버전은 인라인 코드 작업을 사용하는 데 필요합니다.

Azure 계정에 연결

아직 Azure 계정에 연결하지 않은 경우 다음 단계에 따라 연결합니다.

Visual Studio Code의 작업 표시줄에서 Azure 아이콘을 선택하여 Azure 창을 엽니다.
Azure 창의 리소스에서 Azure에 로그인을 선택합니다. Visual Studio Code 인증 페이지가 표시되면 Azure 계정으로 로그인합니다.

로그인하면 Azure 창에 Azure 계정과 연결된 Azure 구독이 표시됩니다. 예상되는 구독이 표시되지 않거나 창에 특정 구독만 표시하려면 다음 단계를 수행합니다:
1. 구독 목록에서 구독 선택 단추(필터 아이콘)가 나타날 때까지 첫 번째 구독 옆으로 포인터를 이동합니다. 필터 아이콘을 선택합니다.
  
  또는 Visual Studio Code 상태 표시줄에서 Azure 계정을 선택합니다.
2. 업데이트된 구독 목록이 나타나면 원하는 구독을 선택하고 확인을 선택합니다.

로컬 작업 영역 만들기

논리 앱 프로젝트에는 항상 작업 영역이 필요합니다. 따라서 논리 앱을 만들기 전에 논리 앱 프로젝트를 보관할 작업 영역을 만들어야 합니다. 나중에 이 작업 영역과 프로젝트를 사용하여 Visual Studio Code에서 배포 환경으로 논리 앱을 관리, 실행하고 배포합니다. 기본 프로젝트는 함수 앱 프로젝트라고도 하는 Azure Functions 프로젝트와 비슷합니다.

컴퓨터에서 나중에 작업 영역과 프로젝트에 사용할 빈 로컬 폴더를 만듭니다.

이 예에서는 fabrikam-workflows라는 이름의 폴더를 만듭니다.
Visual Studio Code에서 열려 있는 모든 폴더를 닫습니다.
Azure 창의 작업 영역 섹션 도구 모음에 있는 Azure Logic Apps 메뉴에서 새 논리 앱 작업 공간 만들기를 선택합니다.

Windows Defender 방화벽에서 Visual Studio Code인 Code.exe와 Azure Functions Core Tools인 func.exe에 대한 네트워크 액세스 권한을 부여하라는 메시지가 표시되면 개인 네트워크(예: 홈 또는 회사 네트워크)>액세스 허용을 선택합니다.
폴더 선택 창에서 폴더를 만든 위치로 이동하여 폴더를 선택하고 선택을 선택합니다(폴더를 두 번 선택하지 마세요).

Visual Studio Code 도구 모음에서 작업 영역의 이름을 지정하라는 메시지가 나타납니다.
작업 영역 이름 제공에 사용할 작업 영역 이름을 입력합니다.

이 예에서는 Fabrikam-Workflows를 사용합니다.

다음으로, 논리 앱 프로젝트를 만듭니다.

논리 앱 프로젝트 만들기

필요한 작업 영역을 만든 후, 프롬프트에 따라 프로젝트를 만듭니다.

프로젝트 템플릿으로 논리 앱을 선택합니다. 사용할 프로젝트 이름을 입력합니다.

이 예에서는 Fabrikam-Workflows를 사용합니다.
워크플로 템플릿의 경우 시나리오에 따라 상태 저장 워크플로 또는 상태 비저장 워크플로를 선택합니다. 사용할 워크플로 이름을 입력합니다.

이 예에서는 워크플로 기록, 입력 및 출력을 저장하는 상태 저장 워크플로를 선택하고 이름으로 Stateful-Workflow를 사용합니다.

상태 비저장 워크플로는 이 데이터를 저장하지 않으며 현재 트리거가 아닌 관리되는 커넥터 작업만 지원합니다. 상태 비저장 워크플로에 대해 Azure에서 커넥터를 사용하도록 설정하는 옵션이 있지만 사용자가 선택할 수 있는 관리되는 커넥터 트리거가 디자이너에 표시되지 않습니다.

비고

azureLogicAppsStandard.createNewProject라는 오류와 함께 azureFunctions.suppressProject가 등록된 구성이 아니므로 작업 영역 설정에 쓸 수 없습니다라는 오류 메시지가 나타나면 Visual Studio Marketplace에서 직접 또는 Visual Studio Code 내에서 Visual Studio Code용 Azure Functions 확장을 다시 설치해 보세요.
이제 현재 Visual Studio Code 창에서 프로젝트를 열지, 아니면 새 창에서 열지 선택합니다. 기본 설정에 따라 현재 창에서 열기 또는 새 창에서 열기를 선택합니다.

탐색기 창이 열리고 작업 영역, 프로젝트 및 자동으로 열린 workflow.json 파일이 표시됩니다. 이 파일은 Stateful-Workflow라는 폴더에 있으며 디자이너에서 빌드하는 워크플로에 대한 기본 JSON 정의를 저장합니다. 프로젝트 구조에 대한 자세한 내용은 표준 논리 앱 프로젝트 구조를 참조하세요.

또한 다음과 같이 다중 테넌트 Azure 호스트된 "공유" 커넥터를 사용하도록 설정하라는 메시지가 표시됩니다.
다중 테넌트 Azure에서 실행되는 모든 관리되는 "공유" 커넥터를 사용하도록 설정하여 워크플로에서 이를 보고 사용하도록 선택하려면 Azure의 커넥터 사용을 선택합니다.

비고

이 옵션을 선택하지 않고 나중에 워크플로를 빌드할 때 관리되는 커넥터 작업을 추가하려고 하면 작업 정보 창에 멈추지 않는 회전 원이 표시되어 계속 진행할 수 없습니다.
Azure 리소스 그룹의 경우 새 리소스 그룹 만들기를 선택합니다. 사용할 리소스 그룹 이름을 입력합니다.

이 예에서는 Fabrikam-Workflows-RG를 사용합니다.
구독의 경우 논리 앱 프로젝트에 사용할 Azure 구독을 선택합니다.
그룹과 리소스를 만들 위치로 Azure 지역을 선택합니다.

이 예제에서는 미국 중서부를 사용합니다.

프로젝트에 개발을 위한 다른 설정이 필요하거나 워크플로를 빌드하기 위한 지원 아티팩트가 필요한 경우 다음 시나리오와 관련 작업을 참조하세요.

시나리오	과업
로컬에서 웹후크 기반 트리거나 작업을 실행합니다.	웹후크 콜백 URL에 대한 전달을 설정합니다.
상태 비저장 워크플로 실행 기록을 설정합니다.	상태 비저장 워크플로에 대한 실행 기록을 사용하도록 설정합니다.
맵, 스키마, 어셈블리 등의 아티팩트와 종속성을 추가합니다.	아티팩트 및 종속성을 추가합니다.
NuGet 기반(.NET) 프로젝트 작업	확장 기반 번들(Node.js) 프로젝트를 NuGet 패키지 기반(.NET) 프로젝트로 변환합니다. 참고: 어셈블리 지원이 존재하기 전에 만든 확장 번들 기반(Node.js) 프로젝트를 변환하려면 lib 폴더의 어셈블리를 사용하도록 NuGet 패키지 기반 프로젝트 마이그레이션도 참조하세요.
자체 기본 제공 커넥터를 만듭니다.	1. 확장 번들 기반(Node.js) 프로젝트를 NuGet 패키지 기반(.NET) 프로젝트로 변환합니다. 2. 기본 제공 커넥터 제작을 사용하도록 설정합니다.

이제 워크플로 디자이너를 엽니다.

워크플로 디자이너 열기

탐색기 창에서 프로젝트가 열리면 디자이너를 열어 워크플로를 빌드할 수 있습니다.

workflow.json 파일 바로 가기 메뉴에서 디자이너 열기를 선택합니다.

탐색기 창, workflow.json 파일 바로 가기 메뉴, 선택한 디자이너 열기를 보여 주는 스크린샷

비고

이 옵션을 선택하면 "워크플로 디자인 타임 API 시작"으로 인해 시작하는 데 몇 초가 걸릴 수 있다는 메시지가 나타날 수 있습니다. 이 메시지를 무시하거나 확인을선택할 수 있습니다.

Visual Studio Code는 워크플로 디자이너를 열고 트리거 추가 프롬프트를 표시합니다. 예:

이 빈 워크플로를 사용하는 디자이너를 보여 주는 스크린샷.

비고

디자이너가 열리지 않으면 문제 해결 섹션인 디자이너가 열리지 않음을 참조하세요.

다음으로, 트리거와 작업을 추가하여 워크플로를 만듭니다.

트리거 및 작업 추가

워크플로를 만들려면 트리거로 워크플로를 시작한 다음 처음에 단일 작업을 추가합니다. 이렇게 하면 다음 작업을 추가하기 전에 워크플로를 테스트할 수 있습니다. 예제 워크플로는 다음 트리거와 작업을 사용하며 이를 통칭하여 작업이라고 합니다.

커넥터 또는 운영 그룹	작업 이름	작업 유형	설명
요청	HTTP 요청을 받은 경우	트리거(기본 제공)	다른 서비스나 논리 앱 워크플로에서 인바운드 호출이나 요청을 수신하기 위해 워크플로에 엔드포인트 URL을 만듭니다. 자세한 내용은 워크플로에 대한 인바운드 HTTP 호출 수신 및 응답을 참조하세요.
Office 365 Outlook	전자 메일 보내기	작업(관리됨)	Office 365 Outlook 계정을 사용하여 이메일을 보냅니다. 이 가이드의 단계를 따르려면 Office 365 Outlook 이메일 계정이 필요합니다. 자세한 내용은 Azure Logic Apps에서 Office 365 Outlook에 연결을 참조하세요. 참고: 다른 커넥터에서 지원하는 이메일 계정이 있는 경우 해당 커넥터를 사용할 수 있지만 해당 커넥터의 사용자 환경은 이 예의 단계와 다릅니다.
요청	응답	작업(기본 제공)	회신을 보내고 발신자에게 데이터를 다시 반환합니다. 자세한 내용은 응답 작업 추가를 참조하세요.

요청 트리거 추가

워크플로 디자이너에서 아직 선택하지 않은 경우 트리거 추가를 선택합니다.

트리거 추가 창이 열리고 사용 가능한 커넥터와 작업 그룹 중에서 선택할 수 있는 갤러리가 표시됩니다. 예:
트리거 추가 창에서 HTTP 요청을 수신할 때라는 이름의 요청 트리거를 추가하려면 다음 일반 단계를 따릅니다.

다음 예제에서는 기본 제공 트리거만 표시되도록 기본 제공 옵션을 선택합니다.

디자이너에서 트리거가 표시되면 트리거의 정보 창이 열리고 트리거의 매개 변수, 설정 및 기타 관련 작업이 표시됩니다.

비고

트리거 정보 창이 나타나지 않으면 디자이너에서 트리거가 선택되었는지 확인합니다.
워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

Office 365 Outlook 작업 추가

디자이너의 요청 트리거에서 다음 일반 단계에 따라 Office 365 Outlook 작업인 이메일 보내기(V2)를 추가합니다..

해당 작업이 초기 결과에 나타나지 않으면 커넥터 이름 옆에 있는 자세히 보기를 선택합니다. 예:
작업의 인증 창이 나타나면 로그인을 선택하여 이메일 계정에 대한 연결을 만듭니다.
다음 메시지에 따라 자격 증명을 인증하고 액세스를 허용한 다음 Visual Studio Code로 돌아갈 수 있도록 허용합니다.

비고

프롬프트를 완료하기 전에 너무 많은 시간이 경과하면 인증 프로세스 시간이 초과되고 실패합니다. 이 경우 디자이너로 돌아가서 로그인을 다시 시도하여 연결을 만듭니다.
1. Microsoft 인증 프롬프트가 나타나면 Office 365 Outlook에 대한 사용자 계정을 선택합니다. 확인이 필요한 페이지가 열리면 액세스 허용을 선택합니다.
2. Azure Logic Apps에서 Visual Studio Code 링크를 열라는 메시지가 표시되면 열기를 선택합니다.
3. Visual Studio Code에서 확장이 Microsoft Azure 도구를 열라는 메시지가 표시되면 열기를 선택합니다.
Visual Studio Code에서 연결이 만들어지면 일부 커넥터에서 연결이 <n>일 동안만 유효합니다라는 메시지를 표시합니다. 이 시간 제한은 Visual Studio Code에서 논리 앱 워크플로를 작성하는 기간에만 적용됩니다. 배포되면 워크플로에서 자동으로 사용하도록 설정된 시스템이 할당한 관리 ID를 사용하여 런타임에 인증할 수 있으므로 이 제한이 더 이상 적용되지 않습니다. 이 관리 ID는 연결을 만들 때 사용하는 인증 자격 증명이나 연결 문자열과는 다릅니다. 이 시스템이 할당한 관리 ID를 사용하지 않도록 설정하면 런타임에 연결이 작동하지 않습니다.

열리는 이메일 보내기 정보 창의 매개 변수 탭에서 작업에 필요한 정보를 제공합니다.

비고

작업 정보 창이 자동으로 열리지 않으면 디자이너에서 이메일 보내기 작업을 선택합니다.

재산	필수	가치	설명
에서	예	< 이메일 주소>	이메일을 받는 사람. 테스트 목적의 이메일 주소를 사용할 수 있습니다. 이 예제에서는 가상의 이메일 주소 sophia.owen@fabrikam.com을 사용합니다.
주제	예	예제 워크플로의 메일	이메일 제목
본문	예	예제 워크플로의 Hello!	이메일 본문 내용

다음은 그 예입니다.

메일 보내기라는 Office 365 Outlook 작업에 대한 정보를 보여 주는 스크린샷

워크플로를 저장합니다. 디자이너에서 저장을 선택합니다.

표준 논리 앱 프로젝트 구조

Visual Studio Code에서 논리 앱 프로젝트에는 다음 형식 중 하나가 있습니다.

기본 형식인 확장 번들 기반(Node.js)
기본 형식에서 변환할 수 있는 NuGet 패키지 기반(.NET)

이러한 형식에 따라 프로젝트에 약간 다른 폴더나 파일이 포함될 수 있습니다. 예를 들어, Nuget 패키지 기반 프로젝트에는 패키지와 기타 라이브러리 파일이 포함된 .bin 폴더가 있습니다. 확장 번들 기반 프로젝트에는 이 .bin 폴더가 포함되지 않습니다.

일부 시나리오에서는 사용자 지정 기본 제공 작업을 개발하고 실행하려는 경우와 같이 앱을 실행하기 위해 NuGet 패키지 기반 프로젝트가 필요합니다. NuGet을 사용하도록 프로젝트를 변환하는 방법을 자세히 알아보려면 기본 제공 커넥터 작성 사용을 검토하세요.

기본 확장 번들 기반 프로젝트에는 다음 예와 유사한 폴더 및 파일 구조가 있습니다.

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

프로젝트의 루트 수준에서는 다음 폴더와 파일 및 기타 항목을 찾을 수 있습니다.

이름	폴더 또는 파일	설명
.vscode	폴더	extensions.json, launch.json, settings.json 및 tasks.json 파일과 같은 Visual Studio Code 관련 설정 파일을 포함합니다.
아티팩트	폴더	B2B(Business-to-Business) 시나리오를 지원하는 워크플로에서 정의하고 사용하는 통합 계정 아티팩트를 포함합니다. 예를 들어, 샘플 구조에는 다음 폴더가 포함됩니다. - 맵: XML 변환 작업에 사용할 맵을 포함합니다. - 스키마: XML 유효성 검사 작업에 사용할 스키마를 포함합니다. - 규칙: 규칙 기반 엔진 프로젝트의 비즈니스 규칙에 대한 아티팩트입니다.
리브	폴더	논리 앱에서 사용하거나 참조할 수 있는 지원되는 어셈블리를 포함합니다. Visual Studio Code에서 이러한 어셈블리를 프로젝트에 업로드할 수 있지만, 프로젝트의 특정 폴더에 추가해야 합니다. 예를 들어, 이 폴더에는 다음 폴더가 포함되어 있습니다. - builtinOperationSdks: 각각 Java 및 .NET Framework 어셈블리에 대한 JAR 및 net472 폴더가 포함되어 있습니다. - custom: .NET Framework 사용자 지정 어셈블리를 포함합니다. 지원되는 어셈블리 형식과 이를 프로젝트에 배치할 위치에 대한 자세한 내용은 프로젝트에 어셈블리 추가를 참조하세요.
*< WorkflowName>*	폴더	각 워크플로에 대한 <WorkflowName> 폴더에는 워크플로의 기본 JSON 정의를 포함하는 workflow.json 파일이 포함됩니다.
workflow-designtime	폴더	개발 환경 관련 설정 파일을 포함합니다.
.funcignore	파일	설치된 Azure Functions Core Tools 관련 정보를 포함합니다.
connections.json	파일	워크플로에서 사용하는 관리형 연결 및 Azure 함수에 대한 메타데이터, 엔드포인트 및 키를 포함합니다. 중요: 각 환경에 대해 서로 다른 연결과 함수를 사용하려면 이 connections.json 파일을 매개 변수화하고 엔드포인트를 업데이트해야 합니다.
host.json	파일	런타임 관련 구성 설정 및 값(예: 단일 테넌트 Azure Logic Apps 플랫폼, 논리 앱, 워크플로, 트리거 및 작업에 대한 기본 제한)이 포함되어 있습니다. 논리 앱 프로젝트의 루트 수준에서 host.json 메타데이터 파일에는 로컬 또는 Azure에 상관없이 동일한 논리 앱의 모든 워크플로가 실행되는 동안 사용하는 구성 설정 및 기본값이 포함됩니다. 참조 정보는 앱 설정 및 호스트 설정 편집을 참조하세요. 참고: 논리 앱을 만들 때 Visual Studio Code는 스토리지 컨테이너에 backup *host.snapshot..json 파일을 만듭니다. 논리 앱을 삭제해도 이 백업 파일은 삭제되지 않습니다. 이름이 같은 다른 논리 앱을 만들면 다른 스냅샷 파일이 만들어집니다. 동일한 논리 앱에 대해 최대 10개의 스냅샷만 포함할 수 있습니다. 이 제한을 초과하면 다음 오류가 발생합니다. `Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))`** 이 오류를 해결하려면 스토리지 컨테이너에서 추가 스냅샷 파일을 삭제합니다.
local.settings.json	파일	로컬에서 실행하는 동안 워크플로에 사용되는 앱 설정, 연결 문자열 및 기타 설정을 포함합니다. 이러한 설정과 값은 로컬 개발 환경에서 프로젝트를 실행할 때만 적용됩니다. Azure에 배포하는 동안 파일 및 설정이 무시되고 배포에 포함되지 않습니다. 이 파일은 로컬 개발 도구가 값에 사용하는 `appSettings`로 설정 및 값을 저장합니다. 앱 설정 및 매개 변수를 사용하여 런타임 및 배포 시에 이러한 환경 변수를 호출하고 참조할 수 있습니다. 중요: local.settings.json 파일은 비밀을 포함할 수 있으므로 프로젝트 원본 제어에서 이 파일을 제외해야 합니다. 이 파일에는 논리 앱이 제대로 작동하는 데 필요한 앱 설정도 포함되어 있습니다. 참조 정보는 앱 설정 및 호스트 설정 편집을 참조하세요.

기타 개발 설정 작업

프로젝트를 만든 후에도 Visual Studio Code를 사용하여 표준 논리 앱을 빌드, 실행 및 배포하는 특정 로컬 개발 시나리오를 지원하기 위한 다른 설정 작업이 남아 있을 수 있습니다. 다음 섹션에서는 이러한 시나리오에 대한 작업을 설명합니다.

로컬로 실행하는 웹후크 사용

웹후크 작업은 작업이 실행되기 전에 이벤트가 발생할 때까지 기다리는 워크플로 트리거 또는 작업입니다. 구체적으로, 웹후크 작업은 작업을 계속하기 전에 발신자 서비스나 워크플로에서 HTTPS 요청이 도착할 때까지 기다립니다. 예를 들어, 웹후크에는 요청 트리거 및 HTTP + 웹후크 트리거와 같은 작업이 포함됩니다.

Azure Portal에서 Azure Logic Apps 런타임은 자동으로 발신자 서비스 또는 워크플로에 웹후크를 구독합니다. 런타임은 발신자 서비스나 워크플로에 웹후크의 콜백 URL을 등록합니다. 그런 다음 웹후크는 발신자가 콜백 URL을 사용하여 요청을 보낼 때까지 기다립니다.

하지만 Visual Studio Code에서는 웹후크 작업이 올바르게 작동하도록 몇 가지 설정 작업을 완료해야 합니다. 이 시나리오에서 콜백 URL은 비공개인 localhost 서버(http://localhost:7071/...)를 사용하므로 발신자는 인터넷을 통해 이 URL로 직접 요청을 보낼 수 없습니다.

로컬에서 실행되는 워크플로에서 웹후크 작업을 수행하려면 localhost 서버를 노출하고 발신자에서 콜백 URL로 호출을 안전하게 전달하는 공용 URL을 설정해야 합니다. localhost 포트에 대한 HTTP 터널을 여는 ngrok과 같은 전달 서비스 및 도구를 사용하거나 동등한 자체 도구를 사용할 수 있습니다.

ngrok을 사용하여 착신 전환 설정

ngrok 웹 사이트로 이동합니다. 새 계정에 가입하거나, 이미 계정이 있는 경우 해당 계정에 로그인합니다.
ngrok 클라이언트가 연결 및 액세스를 인증하는 데 필요한 개인 인증 토큰을 가져옵니다.
1. 인증 토큰 페이지를 찾으려면 계정 대시보드 메뉴에서 인증을 펼쳐서 인증 토큰을 선택합니다.
2. Authtoken 상자에서 토큰을 안전한 위치에 복사합니다.
ngrok 다운로드 페이지 또는 계정 대시보드에서 원하는 ngrok 버전을 다운로드하고 .zip 파일을 추출합니다.

자세한 내용은 1단계: 설치를 위해 압축 해제를 참조하세요.
컴퓨터에서 명령 프롬프트 도구를 엽니다. ngrok.exe 파일이 있는 위치로 이동합니다.
다음 명령을 실행하여 ngrok 클라이언트를 ngrok 계정에 연결합니다.

ngrok authtoken <your-authentication-token>

자세한 내용은 2 단계: 계정 연결을 참조하세요.
다음 명령을 실행하여 localhost 포트 7071에 대한 HTTP 터널을 엽니다.

ngrok http 7071

자세한 내용은 3 단계: 실행을 참조하세요.
출력에서 다음 줄을 찾습니다:

http://<___domain>.ngrok.io -> http://localhost:7071
다음 형식의 URL을 복사하여 저장합니다: http://<___domain>.ngrok.io

앱 설정에서 전달 URL 설정

Visual Studio Code의 디자이너에서 워크플로에 사용할 웹후크 작업을 추가합니다.

이 예에서는 HTTP + 웹후크 트리거를 계속 사용합니다.
호스트 엔드포인트에 대한 프롬프트가 표시되면 이전에 만든 전달 URL(리디렉션)을 입력합니다.

비고

프롬프트를 무시하면 전달 URL을 입력해야 한다는 경고가 표시되므로 구성을 선택하고 URL을 입력합니다. 이 단계를 완료한 후에는 이후에 추가할 수 있는 웹후크 작업에 대한 메시지가 나타나지 않습니다.

프롬프트를 표시하려면 프로젝트 루트 수준에서 local.settings.json 파일의 바로 가기 메뉴를 열고 웹후크 리디렉션 엔드포인트 구성을 선택합니다. 이제 전달 URL을 입력할 수 있는 프롬프트가 표시됩니다.

Visual Studio Code는 프로젝트 루트 폴더에 있는 local.settings.json 파일에 전달 URL을 추가합니다. 이제 Values개체 속성Workflows.WebhookRedirectHostUri에 표시되고 전달 URL로 설정됩니다. 예를 들어 다음과 같습니다:
```
{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "FUNCTIONS_V2_COMPATIBILITY_MODE": "true",
      <...>
      "Workflows.WebhookRedirectHostUri": "http://xxxXXXXxxxXXX.ngrok.io",
      <...>
   }
}
```
이러한 앱 설정에 대한 자세한 내용은 표준 논리 앱에 대한 앱 설정 및 호스트 설정 편집을 참조하세요.

로컬 디버깅 세션을 처음 시작하거나 디버깅 없이 워크플로를 실행하면 Azure Logic Apps 런타임은 발신자에게 워크플로를 등록하고 웹후크 작업을 알리는 발신자 엔드포인트를 구독합니다. 다음에 워크플로를 실행하면 구독 등록이 이미 로컬 스토리지에 있기 때문에 런타임이 등록되거나 재구독되지 않습니다.

로컬에서 실행되는 웹후크 작업을 사용하는 워크플로에 대한 디버깅 세션을 중지하면 기존 구독 등록은 삭제되지 않습니다. 등록을 취소하려면 구독 등록을 수동으로 제거하거나 삭제해야 합니다.

비고

워크플로가 실행되기 시작하면 터미널 창에 다음 예제와 같은 오류가 표시될 수 있습니다:

message='Http request failed with unhandled exception of type 'InvalidOperationException' and message: 'System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'

이 경우 프로젝트 루트 폴더에서 local.settings.json 파일을 열고 속성이 true로 설정되었는지 확인합니다:

"FUNCTIONS_V2_COMPATIBILITY_MODE": "true"

상태 비저장 워크플로에 대한 실행 기록 사용 설정

상태 비저장 워크플로를 보다 쉽게 디버그하려면 해당 워크플로에 실행 기록을 사용하도록 설정한 다음, 완료되면 실행 기록을 사용하지 않도록 설정하면 됩니다. Visual Studio Code에 다음 단계를 수행합니다. 또는 Azure Portal에서 작업하는 경우에는 Azure Portal에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.

Visual Studio Code 프로젝트의 루트 폴더 수준에서 local.settings.json 파일을 엽니다.

Workflows.<workflow-name>.operationOptions 속성을 추가하고 값을 WithStatelessRunHistory로 설정합니다. 예를 들어 다음과 같습니다.

Windows

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.<workflow-name>.OperationOptions": "WithStatelessRunHistory"
   }
}

macOS 또는 Linux

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=fabrikamstorageacct; \
          AccountKey=<access-key>;EndpointSuffix=core.windows.net",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.<workflow-name>.OperationOptions": "WithStatelessRunHistory"
   }
}

workflow-designtime이라는 프로젝트 폴더에서 local.settings.json 파일을 열고 동일하게 변경합니다.
작업을 마친 후 실행 기록을 사용하지 않도록 설정하려면 Workflows.<workflow-name>.OperationOptions 속성을 None으로 설정하거나 이 속성과 해당 값을 삭제합니다.

프로젝트에 아티팩트와 종속성을 추가합니다.

특정 시나리오에서는 워크플로에 어셈블리와 같은 종속성이나 맵, 스키마, 규칙과 같은 아티팩트가 필요한 작업이 포함될 수 있습니다. Visual Studio Code에서는 다음과 같이 프로젝트의 해당 폴더에 다음 항목을 추가할 수 있습니다.

항목	파일 형식	설명
지도	.xslt	자세한 내용은 워크플로에서 변환에 대한 맵 추가를 참조하세요.
스키마	.xsd	자세한 내용은 유효성 검사를 위한 스키마 추가를 참조하세요.
규칙	.xml	자세한 내용은 Azure Logic Apps 규칙 엔진 프로젝트 만들기를 참조하세요.
어셈블리	- .dll(.NET Framework 또는 .NET 8) - .jar(Java)	표준 논리 앱 리소스는 Visual Studio Code에서 프로젝트에 업로드할 수 있는 특정 종류의 어셈블리를 사용하거나 참조할 수 있습니다. 하지만 특정 프로젝트 폴더에 추가해야 합니다. 자세한 내용은 참조된 어셈블리 추가를 참조하세요. 참고: 어셈블리 지원이 제공되기 전에 NuGet 패키지 기반(.NET) 논리 앱 프로젝트가 있는 경우 NuGet 패키지 기반 프로젝트를 마이그레이션하여 lib 폴더의 어셈블리 사용을 참조하세요.

프로젝트를 NuGet 패키지 기반(.NET)으로 변환

기본적으로 Visual Studio Code는 논리 앱 프로젝트를 확장 번들 기반(Node.js) 프로젝트로 만듭니다. 예를 들어, NuGet 패키지 기반(.NET) 프로젝트가 필요하여 자체 기본 제공 커넥터를 만들려면 기본 프로젝트를 NuGet 패키지 기반(.NET) 프로젝트로 변환해야 합니다.

중요합니다

이 작업은 단방향 작업으로 실행 취소할 수 없습니다.

탐색기 창에서 프로젝트 폴더와 파일 아래의 빈 영역으로 마우스 포인터를 이동하고 바로 가기 메뉴를 열고 NuGet 기반 논리 앱 프로젝트로 변환을 선택합니다.
프롬프트가 표시되면 프로젝트 변환을 확인합니다.

"lib" 폴더의 어셈블리를 사용하도록 NuGet 패키지 기반 프로젝트 마이그레이션

중요합니다

이 작업은 어셈블리 지원이 가능해지기 전에 만들어진 NuGet 패키지 기반(.NET) 논리 앱 프로젝트에만 필요합니다.

어셈블리 지원을 표준 논리 앱 워크플로에 사용할 수 없을 때 논리 앱 프로젝트를 만든 경우 어셈블리를 사용하는 프로젝트에서 사용할 <project-name>.csproj 파일에 다음 줄을 추가할 수 있습니다.

  <ItemGroup>
    <LibDirectory Include="$(MSBuildProjectDirectory)\lib\**\*"/>
  </ItemGroup>
  <Target Name="CopyDynamicLibraries" AfterTargets="_GenerateFunctionsExtensionsMetadataPostPublish">
    <Copy SourceFiles="@(LibDirectory)" DestinationFiles="@(LibDirectory->'$(MSBuildProjectDirectory)\$(PublishUrl)\lib\%(RecursiveDir)%(Filename)%(Extension)')"/>
  </Target>

중요합니다

Linux 또는 macOS에서 실행되는 프로젝트의 경우 디렉터리 구분 기호를 업데이트해야 합니다. 예를 들어 <project-name>.csproj 파일에 추가된 이전 코드를 보여주는 다음 이미지를 검토하세요.

마이그레이션된 어셈블리 및 CSPROJ 파일에 추가된 코드를 보여 주는 스크린샷

기본 제공 커넥터 제작 사용

단일 테넌트 Azure Logic Apps 확장성 프레임워크를 사용하여 필요한 모든 서비스에 자체적인 기본 제공 커넥터를 만들 수 있습니다. Azure Service Bus 및 SQL Server와 같은 기본 제공 커넥터와 마찬가지로, 이러한 커넥터는 더 높은 처리량, 짧은 대기 시간, 로컬 연결을 제공하고 기본적으로 단일 테넌트 Azure Logic Apps 런타임과 동일한 프로세스에서 실행됩니다.

제작 기능은 현재 Visual Studio Code에서만 사용할 수 있지만, 기본적으로 사용하도록 설정되어 있지 않습니다. 이러한 커넥터를 만들려면 다음 단계를 수행합니다.

아직 변환하지 않았다면 확장 번들 기반(Node.js) 프로젝트를 NuGet 패키지 기반(.NET) 프로젝트로 변환합니다.
어디서나 실행되는 Azure Logic Apps: 기본 제공 커넥터 확장성 문서의 단계를 검토하고 수행합니다.

로컬에서 워크플로 실행, 디버깅 및 테스트

다음 섹션에서는 중단점을 설정하고 디버깅 세션을 시작하여 로컬에서 워크플로를 실행하고 테스트하는 방법을 보여 줍니다.

디버깅을 위한 중단점 설정

디버깅 세션을 시작하여 논리 앱 워크플로를 실행하고 테스트하기 전 각 워크플로의 workflow.json 파일에 중단점을 설정할 수 있습니다. 다른 설정은 필요하지 않습니다.

현재 중단점은 트리거가 아닌 작업에 대해서만 지원됩니다. 각 작업 정의에는 다음과 같은 중단점 위치가 있습니다:

작업 이름을 표시하는 줄에 시작 중단점을 설정합니다. 디버깅 세션 중에 이 중단점이 적중하면 작업 입력을 평가하기 전에 검토할 수 있습니다.
작업의 닫는 중괄호 (})를 표시하는 줄에 종료 중단점을 설정합니다. 디버깅 세션 중에 이 중단점이 적중하면 작업 실행이 완료되기 전에 작업 결과를 검토할 수 있습니다.

중단점을 추가하려면 다음 단계를 수행하세요:

디버그할 워크플로의 workflow.json 파일을 엽니다.
중단점을 설정하려는 줄의 왼쪽 열에서 해당 열 내부를 선택합니다. 중단점을 제거하려면 해당 중단점을 선택합니다.

디버깅 세션을 시작하면 실행 보기가 코드 창의 왼쪽에 표시되고 디버그 도구 모음은 위쪽 근처에 표시됩니다.

비고

실행 보기가 자동으로 표시되지 않으면 Ctrl+Shift+D를 누릅니다.
중단점이 적중할 때 사용 가능한 정보를 검토하려면 실행 보기에서 변수 창을 검사합니다.
워크플로 실행을 계속하려면 디버그 도구 모음에서 계속(재생 단추)을 선택합니다.

워크플로를 실행하는 동안 언제든지 중단점을 추가하고 제거할 수 있습니다. 그러나 실행 시작 후 workflow.json 파일을 업데이트하면 중단점이 자동으로 업데이트되지 않습니다. 중단점을 업데이트하려면 논리 앱을 다시 시작합니다.

일반 정보는 중단점 - Visual Studio Code를 참조하세요.

워크플로 디버깅 및 테스트

워크플로를 테스트하려면 다음 단계에 따라 디버깅 세션을 실행하고 요청 트리거에서 만들어진 엔드포인트의 URL을 찾습니다. 나중에 해당 엔드포인트에 요청을 보낼 수 있도록 이 URL이 필요합니다.

상태 비저장 워크플로가 있는 경우 디버깅을 더 쉽게 하기 위해 워크플로에 대한 실행 기록을 사용하도록 설정합니다.
실행 메뉴에서 디버깅 시작(F5)을 선택합니다.

디버깅 세션을 검토할 수 있는 터미널 창이 열립니다.

비고

"preLaunchTask 'generateDebugSymbols' 실행 후 오류가 발생했습니다" 오류가 발생하면 문제 해결 섹션의 디버깅 세션을 시작하지 못했습니다를 참조하세요.
이제 요청 트리거에서 만들어진 엔드포인트에 대한 콜백 URL을 찾습니다.
1. 프로젝트를 보려면 탐색기 창을 다시 엽니다.
2. workflow.json 파일 바로 가기 메뉴에서 개요를 선택합니다.
3. 이 예에서 HTTP 요청이 수신될 때 트리거에 대한 다음 URL과 유사한 콜백 URL을 복사하여 저장합니다.
  
  http://localhost:7071/api/<workflow-name>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>
콜백 URL을 테스트하고 워크플로를 트리거하려면 HTTP 요청 도구와 해당 지침을 사용하여 트리거가 예상하는 메서드를 포함하여 URL에 HTTP 요청을 보냅니다.

이 예에서는 다음 샘플과 같이 복사된 URL과 함께 GET 메서드를 사용합니다.

GET http://localhost:7071/api/Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>

트리거가 실행되면 이 예제 워크플로가 실행되고 다음과 비슷한 이메일을 보냅니다.

Visual Studio Code에서 워크플로의 개요 페이지로 돌아갑니다. 실행 기록에서 워크플로 실행 상태를 확인합니다.

팁 (조언)

실행 상태가 표시되지 않으면 새로 고침을 선택하여 개요 페이지를 새로 고칩니다. 충족되지 않은 기준이나 데이터를 찾지 못해 건너뛴 트리거의 경우 실행이 발생하지 않습니다.

실행 상태 및 기록이 포함된 워크플로의 개요 페이지를 보여주는 스크린샷.

다음 표에서는 각 워크플로 실행이 Visual Studio Code에서 가질 수 있고 표시할 수 있는 가능한 최종 상태를 보여 줍니다.

실행 상태	설명
중단됨	시스템이 중단되거나 Azure 구독이 만료되는 등의 외부 문제로 인해 실행이 중지되었거나 완료되지 않았습니다.
취소	실행이 트리거되고 시작되었지만 취소 요청이 수신되었습니다.
실패	실행에서 하나 이상의 작업이 실패했습니다. 실패를 처리하는 워크플로의 후속 작업이 설정되지 않았습니다.
실행 중	실행이 트리거되어 현재 진행 중이지만, 작업 제한 또는 현재 가격 책정 계획으로 인해 제한된 실행에도 이 상태가 표시될 수 있습니다. 팁: 진단 로깅을 설정한 경우 발생하는 모든 제한된 이벤트에 대한 정보를 얻을 수 있습니다.
성공함	실행이 성공했습니다. 작업이 실패하면 워크플로의 후속 작업에서 실패를 처리합니다.
시간 초과	현재 기간이 실행 기간 제한을 초과했기 때문에 런타임이 초과되었습니다. 실행 기간 제한은 실행 기록 보존 기간(일)이라는 설정에 의해 제어됩니다. 실행의 기간은 실행의 시작 시간과 해당 시작 시간의 실행 기간 제한을 사용하여 계산됩니다. 참고: 실행 기간이 현재 실행 기록 보존 제한을 초과하는 경우(또한 실행 기록 보존 기간(일) 설정에 의해 제어됨) 일간 정리 작업을 통해 실행 기록에서 실행이 지워집니다. 실행 시간이 초과되건 실행이 완료되건 보존 기간은 항상 실행의 시작 시간과 현재 보존 제한을 사용하여 계산됩니다. 따라서 진행 중인 실행의 기간 제한을 낮추면 실행 시간이 초과됩니다. 그러나 실행 기간이 보존 제한을 초과했는지 여부에 따라 실행이 유지되거나 실행 기록에서 지워집니다.
대기 중	예를 들어 아직 실행 중인 이전 워크플로 인스턴스 때문에 실행이 시작되지 않았거나 일시 중지되었습니다.

특정 워크플로 실행에 대한 각 단계의 상태, 입력 및 출력을 보려면 다음 단계 중 하나를 선택합니다.

식별자 열에서 워크플로 실행 ID를 선택합니다.
기간 열 옆에 있는 워크플로 실행에 대한 줄임표(...) 메뉴를 열고 실행 표시를 선택합니다(예:

Visual Studio Code에서는 실행 세부 정보 보기가 열리고 워크플로 실행의 각 단계에 대한 상태가 표시됩니다.

워크플로 실행의 각 단계와 상태를 보여 주는 스크린샷

비고

실행이 실패하고 실행 세부 정보 보기의 단계에서 400 잘못된 요청 오류가 표시되는 경우 이 문제는 긴 트리거 이름 또는 작업 이름으로 인해 기본 URI(Uniform Resource Identifier)에서 기본 문자 제한을 초과함으로써 발생할 수 있습니다. 자세한 내용은 "400 잘못된 요청"을 참조하세요.

다음 표에서는 각 워크플로 작업이 Visual Studio Code에서 가질 수 있고 표시할 수 있는 가능한 상태를 보여 줍니다.

작업 상태	설명
중단됨	시스템이 중단되거나 Azure 구독이 만료되는 등의 외부 문제로 인해 작업이 중지되었거나 완료되지 않았습니다.
취소	작업이 실행 중이지만 취소 요청이 수신되었습니다.
실패	작업이 실패했습니다.
실행 중	작업이 현재 실행 중입니다.
생략	바로 이전 작업이 실패하여 작업을 건너뛰었습니다. 작업에는 이전 작업이 성공적으로 완료되어야 현재 작업을 실행할 수 있는 `runAfter` 조건이 있습니다.
성공함	작업이 성공했습니다.
다시 시도하여 성공함	한 번 이상 다시 시도한 후 작업이 성공했습니다. 다시 시도 기록을 검토하려면 실행 기록 세부 정보 보기에서 해당 작업을 선택합니다. 그러면 입력 및 출력을 볼 수 있습니다.
시간 초과	해당 작업의 설정에 지정된 시간 초과로 인해 작업이 중지되었습니다.
대기 중	호출자의 인바운드 요청을 기다리는 웹후크 작업에 적용됩니다.

각 단계의 입력과 출력을 보려면 원하는 단계를 선택합니다. 예:

원시 입력 및 출력을 보려면 원시 입력 표시 또는 원시 출력 표시를 선택합니다.
디버깅 세션을 중지하려면 실행 메뉴에서 디버깅 중지(Shift + F5)를 선택합니다.

응답 반환

HTTP 요청이 수신되면 트리거로 시작하는 워크플로가 있는 경우 워크플로는 응답이라는 요청 작업을 사용하여 초기 요청을 보낸 발신자에게 응답을 반환할 수 있습니다.

워크플로 디자이너의 이메일 보내기 작업에서 다음 일반 단계에 따라 응답이라는 요청 작업을 추가합니다.
응답 작업의 정보 창에 있는 매개 변수 탭에서 발신자에게 응답하는 데 필요한 정보를 제공합니다.

이 예에서는 이메일 보내기 작업의 출력인 본문 매개 변수 값을 반환합니다.
1. 본문 매개 변수의 경우 편집 상자 내에서 선택하고 번개 모양 아이콘을 선택합니다. 그러면 동적 콘텐츠 목록이 열립니다. 이 목록에는 워크플로의 이전 트리거 및 작업에서 사용 가능한 출력 값이 표시됩니다.
2. 동적 콘텐츠 목록의 이메일 보내기에서 본문을 선택합니다.
  
  완료되면 응답 작업의 본문 속성이 이제 이메일 보내기 작업의 본문 출력 값으로 설정됩니다. 예:
워크플로를 저장합니다.

워크플로 다시 테스트

업데이트를 테스트하려면 디버거를 다시 실행하고 워크플로를 트리거하는 다른 요청을 보낼 수 있습니다. 이는 워크플로를 로컬로 실행, 디버그 및 테스트의 단계와 유사합니다.

Visual Studio Code 도구 모음의 실행 메뉴에서 디버깅 시작(F5)을 선택합니다.
요청을 만들고 보내는 도구에서 워크플로를 트리거하는 또 다른 요청을 보냅니다.
워크플로 개요 페이지의 실행 기록에서 가장 최근 실행의 상태를 확인하고 실행 세부 정보 보기를 엽니다.

예를 들어 예제 워크플로가 응답 작업으로 업데이트된 후 실행에 대한 단계별 상태는 다음과 같습니다.
디버깅 세션을 중지하려면 실행 메뉴에서 디버깅 중지(Shift + F5)를 선택합니다.

배포 준비

Azure Portal에 표준 논리 앱을 배포하기 전에 이 섹션을 검토하여 준비해야 할 사항이 있는지 확인합니다.

방화벽 액세스 설정

환경에 엄격한 네트워크 요구 사항이나 트래픽을 제한하는 방화벽이 있는 경우 Azure에서 관리, 호스트된 및 공유 커넥터를 통해 만들어지고 워크플로에서 사용되는 모든 연결에 대한 권한을 설정해야 합니다.

해당 연결에 대한 FQDNs(정규화된 도메인 이름)을 찾으려면 다음 단계를 수행합니다:

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

만든 각 연결에 대해 다음 구문을 사용하는 <connection-name>-ConnectionRuntimeUrl이라는 속성을 찾습니다.

"<connection-name>-ConnectionRuntimeUrl": <connection-runtime-URL>

예를 들어, Office 365 연결과 AS2 연결을 포함하는 샘플 local.settings.json 파일이 있다고 가정해 보겠습니다. 이러한 연결은 <connection-name>-ConnectionRuntimeUrl 속성에 대해 다음의 각 샘플 값을 사용합니다.

Office 365: "office365-ConnectionRuntimeUrl": https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/office365/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1"
AS2: "as2-ConnectionRuntimeUrl": https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/as2/b1b1b1b1-cccc-dddd-eeee-f2f2f2f2f2f2

샘플 local.settings.json 파일은 다음 버전과 유사합니다.

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "node",
      "APP_KIND": "workflowapp",
      "ProjectDirectoryPath": "c:\\Users\\<local-username>\\Desktop\\Visual Studio Code projects\\Azure Logic Apps\fabrikam-workflows\\Fabrikam-Workflows\\Fabrikam-Workflows",
      "WORKFLOWS_TENANT_ID": "<Microsoft-Entra-tenant-ID>",
      "WORKFLOWS_SUBSCRIPTION_ID": "<Azure-subscription-ID>",
      "WORKFLOWS_RESOURCE_GROUP_NAME": "Fabrikam-Workflows-RG",
      "WORKFLOWS_LOCATION_NAME": "westcentralus",
      "WORKFLOWS_MANAGEMENT_BASE_URI": "https://management.azure.com/",
      "as2-connectionKey": "<connection-key>",
      "as2-ConnectionRuntimeUrl": "https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/as2/b1b1b1b1-cccc-dddd-eeee-f2f2f2f2f2f2",
      "office365-connectionKey": "<connection-key>",
      "office365-ConnectionRuntimeUrl": "https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/office365/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
   }
}

이러한 연결 런타임 URL을 복사하여 안전한 곳에 저장해 두면 이 정보로 방화벽을 설정할 수 있습니다.
준비가 되면 저장된 URL을 사용하여 방화벽을 설정합니다. 자세한 내용은 다음 설명서를 참조하세요.
- Azure Firewall Manager 정책 개요
- Azure Portal - 클래식을 사용하여 Azure Firewall을 배포하고 구성합니다.

Azure에 배포

Visual Studio Code에서 표준 논리 앱을 배포하려면 프로젝트를 Azure에 직접 게시하면 됩니다. 논리 앱을 새 리소스로 게시하면 함수 앱 요구 사항과 유사한 Azure Storage 계정과 같은 필수 리소스가 자동으로 만들어집니다. 또는 이전에 배포된 표준 논리 앱 리소스에 논리 앱을 게시하여 배포된 버전을 덮어쓸 수 있습니다.

표준 논리 앱 리소스 배포에는 배포 중에 선택하는 호스팅 계획과 가격 책정 계층이 필요합니다. 자세한 내용은 호스팅 플랜 및 가격 책정 계층을 참조하세요.

새 표준 논리 앱 리소스에 게시

탐색기 창에서 프로젝트 폴더와 파일 아래의 빈 영역으로 마우스 포인터를 이동하고 바로 가기 메뉴를 열고 논리 앱에 배포를 선택합니다.

배포하는 데 파일을 열 필요는 없지만 배포하려는 모든 파일을 저장했는지 확인합니다.

대상 표준 논리 앱 리소스에 대해 다음 옵션이 표시됩니다. Azure에서 새로운 표준 논리 앱을 만들거나 기존에 배포된 표준 논리 앱을 선택할 수 있습니다.
- Azure에서 새 Logic App(표준) 만들기(빠른 버전)
- Azure에서 새 Logic App(표준) 만들기
- 이전에 배포된 표준 논리 앱 리소스가 있는 경우 해당 리소스에서 선택합니다.
배포 옵션의 경우 대상 논리 앱 리소스를 만들지 아니면 기존 리소스를 사용할지 선택합니다.

이 예제에서는 Azure Advanced에서 새 Logic App(표준) 만들기를 계속 진행합니다.

새로운 대상 논리 앱 리소스를 만들려면 다음 단계를 따릅니다.

대상 논리 앱에 대한 전역적으로 고유한 이름을 입력합니다.

이 예에서는 Fabrikam-Workflows-App을 사용합니다.
배포할 위치로 Azure 지역을 선택합니다.

이 예제에서는 미국 중서부를 사용합니다.

호스팅 플랜의 경우 다음 옵션 중에서 선택합니다.

호스팅 계획	설명
워크플로 표준	단일 테넌트 Azure Logic Apps에 호스트되는 새로운 표준 논리 앱 리소스로 배포합니다.
하이브리드.	자체 인프라에 호스트된 표준 논리 앱으로 배포합니다. 참고: 이 옵션을 선택하기 전에 필요한 인프라를 설정했는지 확인합니다. 자세한 내용은 하이브리드 배포를 사용하여 표준 논리 앱에 대한 자체 인프라 설정을 참조하세요.

Windows App Service 요금제의 경우 다음 옵션 중 하나를 선택합니다.
- 새 App Service 요금제 만들기
- 선택한 Azure 지역에 기존 App Service 요금제가 있는 경우 해당 플랜에서 선택합니다(Windows 기반 플랜만 해당).
이 예제에서는 새 App Service 요금제 만들기를 선택합니다.
새로운 플랜의 경우, 전역적으로 고유한 이름을 제공하고 가격 책정 계층을 선택합니다.

이 예에서는 Fabrikam-Workflows-App-Service-Plan을 사용하고 WS1 워크플로 표준 계층을 선택합니다.

자세한 내용은 호스팅 플랜 및 가격 책정 계층을 참조하세요.
최적의 성능을 위해 대상 Azure 리소스 그룹의 경우 프로젝트와 동일한 리소스 그룹을 선택합니다.

이 예에서는 Fabrikam-Workflows-RG라는 이전에 만들어진 동일한 그룹을 사용합니다.

비고

다른 리소스 그룹을 만들거나 사용할 수 있지만 그러면 성능에 영향을 줄 수 있습니다. 다른 리소스 그룹을 만들거나 선택하고 확인 프롬프트가 표시된 후 취소하면 배포도 취소됩니다.
실행 기록 정보를 저장할 수 있는 워크플로와 함께 Azure Storage 계정을 사용하려면 다음 옵션 중에서 선택합니다.
- 새 스토리지 계정 만들기
- 기존 Azure Storage 계정이 있는 경우 해당 계정에서 선택합니다.
이 예에서는 새 스토리지 계정 만들기를 선택합니다.
스토리지 계정에 대해 전역적으로 고유한 이름을 입력합니다. 소문자와 숫자만 사용할 수 있습니다.

이 예에서는 fabrikamstorageaccount<number>를 사용합니다.
이 예에서 SQL 스토리지를 사용하는 옵션에 대해 아니요를 선택합니다.

표준 논리 앱 워크플로에 대한 SQL 데이터베이스 스토리지 설정에 따라 스토리지로 사용할 SQL 데이터베이스를 이미 설정한 경우 예를 선택할 수 있습니다.
논리 앱에 대한 진단 로깅 및 추적을 사용하도록 설정하는 Application Insights 리소스의 경우 다음 옵션 중에서 선택합니다.
- 새 Application Insights 리소스 만들기
- 지금은 건너뛰기. 배포 후에 Application Insights를 설정할 수 있습니다.
- 기존 Application Insights 리소스가 있으면 선택합니다.
이 예에서는 지금은 건너뛰기를 선택합니다.
비고
- 사용하려는 Application Insights 리소스가 있는 경우 해당 리소스를 선택할 수 있습니다.
- 이때 진단 로깅 및 추적을 사용하도록 설정할 수 있도록 새 Application Insights 리소스를 만들려면 배포 중에 Application Insights 사용을 참조하세요.
Application Insights에 대한 자세한 내용은 다음 설명서를 참조하세요.
- Application Insights 개요
- Application Insights 리소스 만들기 및 구성
지금은 건너뛰기 또는 기존 Application Insights 리소스를 선택하면 Visual Studio Code에서 배포를 시작하라는 확인 메시지가 표시됩니다. 또한 이 메시지에서는 최상의 성능을 위해 관리되는 작업에 대한 연결 리소스를 논리 앱 리소스 및 워크플로와 동일한 리소스 그룹에 넣을 것이 좋습니다. Azure Logic Apps에서 관리되는 작업 연결은 개별 Azure 리소스로 존재합니다.

배포할 준비가 되면 확인 메시지에서 배포를 선택합니다.

Visual Studio Code는 논리 앱을 Azure에 게시하는 데 필요한 리소스를 만들고 배포하기 시작합니다.
배포 프로세스를 보고 모니터링하려면 보기 메뉴에서 출력을 선택합니다.
출력 창 도구 모음의 범위 목록에서 Azure Logic Apps(표준)를 선택합니다.

Visual Studio Code가 논리 앱을 Azure에 배포하는 작업을 마치면 논리 앱 만들기가 성공적으로 완료되었다는 메시지가 나타납니다. 예:

이제 논리 앱 리소스와 워크플로가 사용하도록 설정되어 Azure에서 실행됩니다.

배포 중에 Application Insights 사용

논리 앱에 대한 배포 중에 Application Insights를 사용하여 진단 로깅 및 추적을 사용하도록 설정하려면 다음 단계를 따릅니다.

기존 Application Insights 리소스를 선택하거나 새 Application Insights 리소스를 만듭니다.
Azure Portal에서, Application Insights 리소스로 이동합니다.
리소스 메뉴에서 개요를 선택합니다. 계측 키 값을 찾아 복사합니다.

Visual Studio Code의 프로젝트 루트 폴더에서 local.settings.json 파일을 엽니다.

Values개체에서APPINSIGHTS_INSTRUMENTATIONKEY 속성을 추가하고 계측 키에 값을 설정합니다. 예를 들면 다음과 같습니다:

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "APPINSIGHTS_INSTRUMENTATIONKEY": <instrumentation-key>
   }
}

Application Insights 인스턴스에 워크플로 트리거와 작업 이름이 올바르게 나타나는지 확인합니다.
1. Azure Portal에서, Application Insights 리소스로 이동합니다.
2. 리소스 메뉴의 조사 아래에서 애플리케이션 맵을 선택합니다.
3. 맵에 표시되는 작업 이름을 검토합니다.
  
  기본 제공 트리거의 인바운드 요청 일부는 애플리케이션 맵에서 중복으로 나타날 수 있습니다. 이러한 중복 항목은 WorkflowName.ActionName 형식을 사용하는 대신 워크플로 이름을 작업 이름으로 사용하며 Azure Functions 호스트에서 시작됩니다.

논리 앱이 수집하고 Application Insights 인스턴스로 보내는 추적 데이터의 심각도 수준을 선택적으로 조정할 수 있습니다.

워크플로가 트리거되고 작업이 실행될 때 같이 워크플로 관련 이벤트가 발생할 때마다 런타임은 다양한 추적을 내보냅니다. 해당 추적은 워크플로의 수명을 다루고 다음 이벤트 유형을 포함하지만 이에 국한되지는 않습니다:

시작, 중지 및 오류와 같은 서비스 활동입니다.
작업 및 디스패처 활동입니다.
트리거, 동작 및 실행 등의 워크플로 활동입니다.
성공 또는 실패와 같은 스토리지 요청 활동입니다.
인바운드, 아웃 바운드, 성공 및 실패 등의 HTTP 요청 작업입니다.
디버그 메시지와 같은 모든 개발 추적입니다.

각 이벤트 유형은 심각도 수준에 할당됩니다. 예를 들어 Trace 수준은 가장 자세한 메시지를 캡처하는 반면 Information 수준은 논리 앱, 워크플로, 트리거 및 작업이 시작 및 중지되는 시기와 같은 워크플로의 일반 활동을 캡처합니다.

다음 표에서는 심각도 수준과 해당 추적 형식을 설명합니다.

심각도 수준	추적 형식
중요	논리 앱 워크플로에서 복구할 수 없는 오류를 설명하는 로그입니다.
디버그	개발 중에 조사용으로 사용할 수 있는 로그입니다(예: 인바운드 및 아웃바운드 HTTP 호출).
오류	워크플로 실행 실패를 나타내는 로그이지만, 논리 앱의 일반적인 실패는 아닌 로그입니다.
정보	논리 앱 또는 워크플로의 일반 활동을 추적하는 로그입니다. 예를 들면 다음과 같습니다: - 트리거, 동작 또는 실행이 시작되고 끝나는 경우. - 논리 앱이 시작되거나 종료되는 경우.
흔적	스토리지 요청 또는 디스패처 활동과 같이 가장 자세한 메시지와 워크플로 실행 활동과 관련된 모든 메시지가 포함된 로그입니다.
경고	논리 앱에서 비정상적인 상태를 강조하지만 실행을 방해하지는 않는 로그입니다.

심각도 수준을 설정하려면 프로젝트 루트 수준에서 host.json 파일을 열고 logging 개체를 찾습니다. 이 개체는 논리 앱의 모든 워크플로에 대한 로그 필터링을 제어하고 로그 유형 필터링을 위한 ASP.NET Core 레이아웃을 수행합니다.

{
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      }
   }
}

logging 개체에 logLevel 속성을 포함하는 Host.Triggers.Workflow 개체가 포함되지 않은 경우 해당 항목을 추가합니다. 원하는 추적 유형의 심각도 수준으로 속성을 설정합니다. 예를 들면 다음과 같습니다:

{
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      },
      "logLevel": {
         "Host.Triggers.Workflow": "Information"
      }
   }
}

배포 후 작업

다음 섹션에서는 논리 앱 배포가 완료된 후 수행해야 할 작업을 설명합니다.

Azure Portal에서 배포 확인

Visual Studio Code에서 Azure Portal로 논리 앱을 배포한 후 포털에 논리 앱이 나타나는지 확인합니다. Azure 리소스는 리소스 종류를 기준으로 포털에서 구성되고 그룹화됩니다. 표준 논리 앱을 찾으려면 다음 단계를 수행합니다.

Azure 계정을 사용하여 Azure Portal 에 로그인합니다.
Azure 제목 검색 상자에 논리 앱 이름을 입력합니다. 그러면 리소스 섹션에 결과가 표시됩니다. 리소스를 열려면 논리 앱을 선택합니다.
논리 앱 메뉴의 워크플로에서 워크플로를 선택합니다.
워크플로 페이지에서 워크플로를 선택합니다.
워크플로 메뉴의 도구에서 디자이너를 선택합니다. 워크플로가 예상대로 나타나는지 확인합니다.

이제 Azure Portal에서 이 워크플로를 변경할 수 있습니다.
워크플로 실행 기록, 입력, 출력 및 기타 관련 정보를 볼 수 있도록 배포된 논리 앱에 대한 모니터링 환경을 사용하도록 설정해야 합니다.

배포된 논리 앱에 대한 모니터링 환경 사용

Azure Portal에서 모니터링 환경을 사용하여 배포된 표준 논리 앱 리소스에 대한 워크플로 실행 기록, 입력, 출력 및 관련 정보를 검토하려면 먼저 논리 앱 리소스에서 해당 환경을 사용하도록 설정해야 합니다.

Azure Portal에서 배포된 표준 논리 앱 리소스를 엽니다.
리소스 메뉴의 API에서 CORS를 선택합니다.
CORS 창의 허용된 원본에서 와일드카드 문자(*)를 추가합니다.
완료되면 CORS 도구 모음에서 저장을 선택합니다.

배포 후 Application Insights를 사용하도록 설정하거나 열기

워크플로 실행 중에 논리 앱 워크플로는 다른 이벤트와 함께 원격 분석 데이터를 내보냅니다. 이 원격 분석을 사용하면 워크플로가 얼마나 잘 실행되는지, Azure Logic Apps 런타임이 어떻게 작동하는지에 대한 표시 여부를 높일 수 있습니다. Application Insights는 실시간에 가까운 원격 분석(라이브 메트릭)을 사용하여 논리 앱에 대한 진단 로깅, 추적 및 모니터링을 사용하도록 설정하는 기능을 제공합니다. 이 기능을 사용하면 원격 분석 데이터를 사용하여 문제를 진단하고, 경고를 설정하고, 차트를 작성할 때 발생하는 오류와 성능 문제를 보다 쉽게 조사할 수 있습니다.

이전에 Application Insights를 설정하지 않은 경우 Visual Studio Code에서 논리 앱을 배포한 후 Azure Portal에서 이 기능을 사용하도록 설정할 수 있습니다. Azure에 Application Insights 리소스가 있어야 하지만 이 리소스를 사전에 별도로 만들거나 배포 후 이 기능을 사용하도록 설정할 때 만들 수 있습니다.
이전에 Visual Studio Code에서 배포하는 동안 Application Insights를 설정한 경우 Azure Portal의 논리 앱에서 Application Insights 리소스를 열면 됩니다.

배포된 논리 앱에 대해 Application Insights 사용

Azure Portal에서 배포된 논리 앱을 찾아서 엽니다.
논리 앱 메뉴의 모니터링에서 Application Insights를 선택합니다.
Application Insights 창에서 Application Insights 켜기를 선택합니다.

Application Insights 페이지가 업데이트된 후 리소스 변경 섹션에서 다음 옵션 중에서 선택합니다.

새 리소스 만들기

Azure는 현재 구독 및 리소스 그룹을 사용하여 Application Insights 및 Log Analytics 작업 영역에 대한 리소스를 만듭니다. 다른 구독 및 리소스 그룹을 사용하려면 새 Application Insights 리소스 만들기를 참조한 다음 이 페이지로 돌아옵니다.

재산	설명
새 리소스 이름	생성된 이름을 수락하거나 다른 이름을 제공합니다.
위치	Azure 지역을 선택합니다.
Log Analytics 작업 영역	기존 작업 영역이 있으면 선택합니다. 그렇지 않으면 기본 작업 영역이 만들어집니다. 자세한 내용은 Log Analytics 작업 영역 개요를 참조하세요.

기존 리소스 선택:
1. Application Insights 리소스에 대한 Azure 구독을 선택합니다.
2. Application Insights 리소스를 선택합니다.

완료되면 페이지 하단에서 적용을 선택합니다.

논리 앱에서 Application Insights를 엽니다.

Azure Portal에서 배포된 논리 앱을 찾아서 엽니다.
논리 앱 메뉴의 모니터링에서 Application Insights를 선택합니다.
Application Insights 페이지에서 Application Insights 리소스에 대한 링크를 선택합니다.

Application Insights가 열리면 논리 앱에 대한 다양한 메트릭을 검토할 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

오류 및 문제 해결

디자이너 열기 실패

디자이너를 열려고 하면 "워크플로 디자인 타임을 시작할 수 없습니다"라는 오류 메시지가 표시됩니다. 이전에 디자이너를 열려고 했지만 프로젝트를 중단하거나 삭제한 경우 확장 번들이 올바르게 다운로드되지 않을 수 있습니다. 이 이유가 원인인지 확인하려면 다음 단계를 따릅니다.

Visual Studio Code에서 출력 창을 엽니다. 보기 메뉴에서 출력을 선택합니다.
출력 창의 제목 표시줄에 있는 목록에서 Azure Logic Apps(표준)를 선택합니다. 그러면 확장의 출력을 검토할 수 있습니다. 예를 들면 다음과 같습니다.

출력을 검토하고 다음 오류 메시지가 표시되는지 확인합니다:

A host error has occurred during startup operation '<operation-ID>'.
System.Private.CoreLib: The file 'C:\Users\<user-name>\AppData\Local\Temp\Functions\
ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows\1.1.7\bin\
DurableTask.AzureStorage.dll' already exists.
Value cannot be null. (Parameter 'provider')
Application is shutting down...
Initialization cancellation requested by runtime.
Stopping host...
Host shutdown completed.

이 오류를 해결하려면 위치에서 < 폴더를 삭제하고 디자이너에서 > 파일을 다시 열어 보세요.

이전에 만든 워크플로의 디자이너 선택기에 새 트리거 및 작업이 없음

단일 테넌트 Azure Logic Apps는 Azure Function 작업, Liquid 작업 및 XML 작업(예: XML 유효성 검사 및 XML 변환)의 기본 제공 작업을 지원합니다. 그러나 이전에 만든 논리 앱의 경우 Visual Studio Code에서 오래된 버전의 확장 번들 Microsoft.Azure.Functions.ExtensionBundle.Workflows을(를) 사용하기 때문에 이러한 작업이 디자이너 선택기에 표시되지 않을 수 있습니다.

또한 논리 앱을 만들 때 Azure 커넥터 사용을 사용하도록 설정하거나 선택하지 않으면 Azure Function 작업 커넥터 및 작업이 디자이너 선택기에 표시되지 않습니다. 앱을 만들 때 Azure 배포 커넥터를 사용하도록 설정하지 않은 경우 Visual Studio Code의 프로젝트에서 사용하도록 설정할 수 있습니다. 바로 가기 메뉴에서 workflow.json을 열고 Azure 커넥터 사용을 선택합니다.

오래된 번들을 수정하려면, 다음 단계를 수행하여 오래된 번들을 삭제하면 Visual Studio Code에서 확장 번들을 최신 버전으로 자동 업데이트합니다.

비고

이 솔루션은 Azure Portal을 사용하여 만든 논리 앱이 아닌 Azure Logic Apps(표준) 확장과 함께 Visual Studio Code를 사용하여 만들고 배포하는 논리 앱에만 적용됩니다. 지원되는 트리거 및 작업이 Azure portal 디자이너에 없음을 참조하세요.

손실하지 않으려는 작업을 저장하고 Visual Studio Code를 닫습니다.
컴퓨터에서 기존 번들의 버전 폴더가 들어 있는 다음 폴더로 이동합니다:

...\Users\<user-name>\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows
이전 번들 버전 폴더를 삭제합니다(예: 1.1.3 버전 폴더가 있는 경우 해당 폴더 삭제).
이제 필수 NuGet 패키지의 버전 폴더가 포함된 다음 폴더로 이동합니다:

...\Users\<user-name>\.nuget\packages\microsoft.azure.workflows.webjobs.extension
이전 패키지의 버전 폴더를 삭제합니다.
디자이너에서 Visual Studio Code, 프로젝트 및 workflow.json 파일을 다시 엽니다.

누락된 트리거와 작업이 이제 디자이너에 표시됩니다.

트리거 또는 작업에 "400 잘못된 요청"이 표시됨

실행이 실패하고 모니터링 보기에서 실행을 검사하면 이 오류가 긴 이름을 가진 트리거 또는 작업에 표시될 수 있으며, 이로 인해 기본 URI(Uniform Resource Identifier)가 기본 문자 제한을 초과하게 됩니다.

이 문제를 해결하고 긴 URI를 조정하려면 아래 단계를 수행하여 컴퓨터에서 UrlSegmentMaxCount 및 UrlSegmentMaxLength 레지스트리 키를 편집합니다. 이러한 키의 기본값은 이 문서 Windows용 Http.sys 레지스트리 설정에 설명되어 있습니다.

중요합니다

시작하기 전에 작업 내용을 저장했는지 확인합니다. 이 솔루션을 사용하려면 변경 사항을 적용하기 위해 작업을 마친 후 컴퓨터를 다시 시작해야 합니다.

컴퓨터에서 실행 창을 열고 레지스트리 편집기를 여는 regedit 명령을 실행합니다.
사용자 계정 컨트롤 상자에서 예를 선택하여 컴퓨터에 대한 변경 사항을 허용합니다.
왼쪽 창의 컴퓨터에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters 경로를 따라 노드를 확장하고 매개 변수를 선택합니다.
오른쪽 창에서 UrlSegmentMaxCount 및 UrlSegmentMaxLength 레지스트리 키를 찾습니다.
URI가 사용하려는 이름을 수용할 수 있도록 해당 키 값을 충분히 늘립니다. 해당 키가 없으면 다음 단계를 수행하여 매개 변수 폴더에 추가합니다:
1. 매개 변수 바로 가기 메뉴에서 새>DWORD (32-비트) 값을 선택합니다.
2. 표시되는 편집 상자에 새 키 이름으로 UrlSegmentMaxCount을 입력합니다.
3. 새 키의 바로 가기 메뉴를 열고 수정을 선택합니다.
4. 표시되는 문자열 편집 상자에 원하는 값 데이터 키 값을 16진수 또는 10진수 형식으로 입력합니다. 예를 들어 16진수의 400은 10진수의 1024와 동일합니다.
5. UrlSegmentMaxLength 키 값을 추가하려면 다음 단계를 반복합니다.
해당 키 값을 늘리거나 추가하면 레지스트리 편집기가 다음과 같이 표시됩니다:
준비가 되면 변경 사항을 적용하도록 컴퓨터를 다시 시작합니다.

디버깅 세션이 시작되지 않음

디버깅 세션을 시작하려 할 때 "preLaunchTask 'generateDebugSymbols'실행 후 오류가 발생했습니다" 오류가 발생합니다. 이 문제를 해결하려면 프로젝트에서 tasks.json 파일을 편집하여 기호 생성을 건너뜁니다.

프로젝트에서 .vscode 폴더를 확장하고 tasks.json 파일을 엽니다.

다음 작업에서 앞 줄을 종료하는 쉼표와 함께 "dependsOn: "generateDebugSymbols" 줄을 삭제합니다. 예를 들면 다음과 같습니다:

전에:

 {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true,
   "dependsOn": "generateDebugSymbols"
 }

이후:

 {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true
 }

다음을 통해 공유

Visual Studio Code를 사용하여 표준 논리 앱 워크플로 만들기

필수 조건

액세스 및 연결 요구 사항

도구

확장 설치 확인

Azure 계정에 연결

로컬 작업 영역 만들기

논리 앱 프로젝트 만들기

워크플로 디자이너 열기

트리거 및 작업 추가

요청 트리거 추가

Office 365 Outlook 작업 추가

표준 논리 앱 프로젝트 구조

기타 개발 설정 작업

로컬로 실행하는 웹후크 사용

ngrok을 사용하여 착신 전환 설정

앱 설정에서 전달 URL 설정

상태 비저장 워크플로에 대한 실행 기록 사용 설정

프로젝트에 아티팩트와 종속성을 추가합니다.

프로젝트를 NuGet 패키지 기반(.NET)으로 변환

"lib" 폴더의 어셈블리를 사용하도록 NuGet 패키지 기반 프로젝트 마이그레이션

기본 제공 커넥터 제작 사용

로컬에서 워크플로 실행, 디버깅 및 테스트

디버깅을 위한 중단점 설정

워크플로 디버깅 및 테스트

응답 반환

워크플로 다시 테스트

배포 준비

방화벽 액세스 설정

Azure에 배포

새 표준 논리 앱 리소스에 게시

배포 중에 Application Insights 사용

배포 후 작업

Azure Portal에서 배포 확인

배포된 논리 앱에 대한 모니터링 환경 사용

배포 후 Application Insights를 사용하도록 설정하거나 열기

배포된 논리 앱에 대해 Application Insights 사용

논리 앱에서 Application Insights를 엽니다.

오류 및 문제 해결

디자이너 열기 실패

이전에 만든 워크플로의 디자이너 선택기에 새 트리거 및 작업이 없음

트리거 또는 작업에 "400 잘못된 요청"이 표시됨

디버깅 세션이 시작되지 않음

관련 콘텐츠

피드백

추가 리소스