BizTalk Server에서 Azure Logic Apps로 마이그레이션 방법

이 가이드에서는 성공적인 마이그레이션 솔루션을 제공하는 데 도움이 되는 마이그레이션 전략 및 리소스를 계획 고려 사항 및 모범 사례와 함께 설명합니다.

전략 옵션

다음 섹션에서는 다양한 마이그레이션 전략과 이점 및 단점에 대해 설명합니다.

빅뱅

"빅뱅" 또는 "직접 전환"은 많은 계획이 필요하고 Azure Logic Apps에 익숙하지 않거나 마이그레이션할 대규모 시스템 또는 솔루션이 있는 조직에는 권장되지 않는 접근 방식입니다. 조직에서 새 기술 스택을 구현하는 경우 일반적으로 새 학습이 필요한 경우가 많습니다. 너무 일찍 또는 너무 많이 투자하면 상당한 재작업 위험 없이 습득한 교훈을 활용하고 조정할 기회가 없습니다.

또한 이 접근 방식은 가치를 획득하거나 누적하는 데 더 오래 걸릴 수 있습니다. 일부 마이그레이션 작업을 이미 완료했지만 다른 보류 중 또는 진행 중인 작업으로 인해 아직 프로덕션으로 릴리스하지 않은 경우 마이그레이션된 아티팩트가 조직에 가치를 창출하지 않습니다.

이 방법은 작고 복잡성이 낮은 BizTalk 워크로드, BizTalk 환경을 알고 있는 SEM(실무 전문가) 및 현재 사용하는 BizTalk 기능과 Azure Logic Apps 간의 직접 매핑이 있는 경우에만 고려하는 것이 좋습니다. 또한 Azure Logic Apps를 사용하면 이 접근 방식을 따라 위험을 상당히 줄일 수 있습니다.

반복 또는 웨이브 기반(권장)

이 접근 방식은 조직이 점진적으로 그러나 다른 접근 방식보다는 더 신속하게 가치를 달성할 수 있는 기회를 제공합니다. 프로젝트 팀은 회고 미팅을 사용하여 조기에 기술 스택에 대해 알아볼 수 있습니다. 예를 들어 기존 BizTalk 인터페이스 또는 프로젝트를 프로덕션에 배포한 다음 관리, 확장성, 작업, 모니터링을 포함하는 솔루션의 요구 사항에 대해 알아볼 수 있습니다. 이 지식을 확보한 후에는 스프린트를 계획하여 기존 기능을 최적화하거나 이후 작업에서 사용할 수 있는 새 패턴을 도입할 수 있습니다.

접근 방식에 관계없이 일반적으로 Azure Logic Apps 또는 Azure로 이동하려는 경우 서버 인프라를 해제하기 전에 BizTalk Server 솔루션을 서버리스 또는 클라우드 네이티브 솔루션으로 리팩터링하는 것이 좋습니다. 조직이 비즈니스를 완전히 클라우드로 전환하려는 경우 이 선택은 훌륭한 전략입니다.

BizTalk Server와 Azure Logic Apps에는 서로 다른 아키텍처가 있습니다. 솔루션을 더욱 현대화하기 위해 Azure Integration Services를 사용하여 핵심 고객 통합 요구 사항을 해결하는 Azure Logic Apps의 기능을 확장할 수 있습니다.

ROI(투자 수익률)를 높이려면 BizTalk 마이그레이션에서 가능한 한 Azure Logic Apps(표준)의 핵심 네이티브 기능을 사용하고 필요에 따라 다른 Azure Integration Services로 확장하는 것이 좋습니다. 이 조합을 사용하면 다음과 같은 추가 시나리오를 사용할 수 있습니다.

• 하이브리드 배포를 사용하는 Azure Logic Apps(표준)를 사용하는 클라우드 네이티브 하이브리드 기능
• Azure Logic Apps(표준)의 상태 저장 또는 상태 비스테이션 워크플로 기능
• Azure Logic Apps(표준)의 커넥터와 기본 제공(앱 내) 메인프레임 및 미드레인지 통합
• Azure Service Bus를 사용하는 Pub-sub 메시징
• Azure API Management의 고급 SOAP 기능

BizTalk 마이그레이션 프로젝트 제공

이러한 프로젝트를 완료하려면 반복 또는 웨이브 기반 접근 방식을 따르고 스크럼 프로세스를 사용하는 것이 좋습니다. 스크럼은 스프린트 전 활동에 대한 스프린트 제로(스프린트 0) 개념을 포함하지 않지만 팀 맞춤 및 기술 검색에 첫 번째 스프린트를 집중하는 것이 좋습니다. 스프린트 0 이후 여러 마이그레이션 스프린트의 실행을 따르고 MVP(실행 가능한 최소 제품)로 기능을 릴리스하는 데 집중합니다.

스프린트 0

이 스프린트 중에는 웨이브 계획을 사용하여 BizTalk Server Environments Discovery를 실행하는 것이 좋습니다. 프로젝트의 폭과 깊이를 이해하는 것은 성공에 매우 중요합니다. 다음 목록에는 스프린트 0 중에 해결해야 할 특정 영역이 포함되어 있습니다.

검색 도구

마이그레이션 검색을 돕기 위해 Microsoft 오픈 소스 프로젝트인 BizTalk 마이그레이션 도구라고도 하는 Azure Integration Migrator 명령줄 도구를 사용할 수 있습니다. 이 도구는 단계적 접근 방식을 사용하여 솔루션을 클라우드로 마이그레이션하기 위한 유용한 인사이트와 전략을 파악하는 데 도움이 됩니다. 검색 및 보고서 생성에만 마이그레이션기 도구를 사용하는 것이 좋습니다. 이 공간에서 솔루션을 제공하는 파트너의 검색을 위해 다른 제품을 사용하는 것도 고려할 수 있습니다.

BizTalk Server 요소를 사용하여 인벤토리를 생성하는 또 다른 방법은 Mark Brimble에서 개발한 BizTalk Documenter를 사용할 수 있습니다. 이 도구는 BizTalk Server 2016만 지원된다는 내용에도 불구하고 BizTalk Server 2020에서 작동합니다.

아키텍처 설계

Azure Logic Apps는 BizTalk Server 자산을 다시 사용할 수 있는 기능을 제공하지만 최신 기능의 이점을 수용하기 위한 최신 아키텍처 디자인이 있어야 합니다. 기능적 관점에서 비즈니스 논리를 최대한 많이 사용합니다. 제품 현대화 관점에서 Azure Integration Services를 최대한 많이 사용합니다. 품질 및 교차 절단 문제를 위해 Azure Well-Architected Framework를 사용하는 것이 좋습니다.

이 프레임워크에서 BizTalk 마이그레이션은 중요 업무용 워크로드입니다. 이 용어는 플랫폼에서 고가용성이 필요한 애플리케이션 리소스의 컬렉션을 설명합니다. 즉, 항상 오류에 대해 사용 가능하고, 작동하고, 복원력이 있어야 합니다.

BizTalk 마이그레이션을 위한 아키텍처 디자인을 완료하려면 Azure에서 중요 업무용 워크로드에 대한 디자인 방법론을 따릅니다. 초기 아키텍처 및 토폴로지의 경우 Azure 아키텍처 센터의 Azure에서 기본 엔터프라이즈 통합에 설명된 참조 아키텍처를 검토하고 사용합니다.

초기 환경을 설정하려면 일반적인 엔터프라이즈 랜딩 존 디자인을 사용하여 통합 플랫폼을 빌드하고 배포하는 것을 목표로 하는 Azure Integration Services 랜딩 존 가속기를 사용합니다.

MVP(실행 가능한 최소 프로젝트) 정의

MVP는 고객이 사용할 수 있는 기능이 충분한 제품 버전입니다. 이 버전은 고객의 피드백을 수집하고 작업을 계속할 수 있는 제품의 가능성과 잠재력을 보여줍니다. BizTalk 마이그레이션의 경우 MVP 정의는 작업 기능을 진행하고 초기 통합 워크로드를 충족하는 데 필요한 반복, 웨이브 또는 스프린트 그룹을 반영합니다.

MVP 정의에는 스크럼 용어에서 Epics로 표현되는 다음과 같은 비즈니스 결과가 포함되는 것이 좋습니다.

비즈니스 결과(에픽스)

• 달성하려는 기본 목표는 무엇인가요?
• 이 MVP에 대해 해결해야 하는 기능 또는 기능은 무엇인가요?
• 비즈니스 프로세스 흐름은 무엇인가요? 이 질문은 BizTalk Server에서 지원하는 기존 프로세스를 최적화할 수 있는 기회를 제공합니다.
• MVP에 영향을 주는 비즈니스 결과 또는 리소스 가용성과 같은 비즈니스 결정은 무엇인가요?

MVP는 스크럼 용어의 기능으로 표현되는 다음과 같은 범위 내 프로세스를 포함하는 것이 좋습니다.

범위 내 프로세스(기능)

또한 MVP 작업의 범위를 형성하는 다양한 범위를 벗어난 변수를 식별하고 나열하려고 합니다. 예를 들면 다음과 같습니다.

• 사용 가능한 리소스
• 위험
• 설명서
• 출시 기간

초기 백로그

초기 백로그는 MVP에 대한 범위 내 프로세스를 빌드하기 위해 기능으로 그룹화한 사용자 스토리 집합입니다. 즉, MVP는 에픽, 기능 및 사용자 스토리라고 하는 스크럼 항목으로 표현됩니다. 이상적으로 각 에픽은 BizTalk 애플리케이션 또는 BizTalk 프로젝트 그룹을 포함합니다. 하나의 BizTalk 애플리케이션 또는 BizTalk 프로젝트를 기능과 연결하는 간단한 규칙을 사용할 수 있습니다.

예를 들어 고객이 은행 대출을 요청하는 데 사용하는 "LoanRequests"라는 오케스트레이션이 있는 BizTalk Server 프로젝트가 있다고 가정해 보겠습니다. 따라서 다음과 같이 제안된 기능 및 사용자 스토리가 있습니다.

• 기능: 대출 처리

• 사용자 스토리: "고객으로서 은행이 내 보안 계정에 자금을 추가할 수 있도록 대출 신청서를 제출하려고 합니다."

  현재 BizTalk Server에서 구현으로 존재할 수 있는 이 사용자 스토리에는 Azure Logic Apps 및 Azure Integration Services를 사용하여 구현하는 다음 작업이 있습니다.

  • BizTalk 재사용 가능한 아티팩트 수집
  • Azure Logic Apps를 사용하여 대출 요청 워크플로를 만듭니다.
  • Azure Service Bus 또는 IBM MQ를 사용하여 비동기 메시징을 구성합니다.
  • Azure Logic Apps 워크플로를 사용하여 JSON을 XML 데이터에 매핑합니다.
  • 메시징 패턴에 필요한 대로 Azure Integration Services를 사용자 지정합니다.

다음 다이어그램에서는 사용자 스토리를 세분화하는 Epics, Features, User Stories 및 Tasks에 대해 제안된 기간을 보여 줍니다. 구현 결정은 이러한 기간에 영향을 주지만 Azure Logic Apps에서 기존 BizTalk 아티팩트 사용 중이라고 가정합니다. 미리 빌드된 워크플로 템플릿을 최대한 많이 사용하여 표준 워크플로를 만듭니다 .

마이그레이션 웨이브(스프린트)

팀이 스프린트 0을 완료한 후에는 빌드할 MVP를 명확하게 볼 수 있어야 합니다. 웨이브는 스프린트 세트입니다. 초기 백로그에는 다음 다이어그램을 따르는 작업 항목이 가능한 한 많이 포함되어야 합니다.

웨이브 중에 팀은 프로덕션으로 마이그레이션, 테스트 및 릴리스하는 작업을 완료합니다. 각 웨이브에서 발생하는 일을 좀 더 자세히 살펴보겠습니다.

마이그레이션

각 웨이브 동안 마이그레이션은 합의된 사용자 스토리에 중점을 둡니다. 첫 번째 웨이브의 경우 팀은 초기 백로그에 중점을 둡니다. 기술 결정은 기능 매치업에 설명 된 BizTalk Server 기능 매핑의 정보를 사용해야 합니다. - BizTalk Server에서 Azure Logic Apps로 마이그레이션하는 이유는 무엇인가요?

다음 다이어그램은 마이그레이션 웨이브 중에 발생해야 하는 이벤트를 보여 줍니다.

다음 다이어그램은 API, 서비스, 하이브리드 솔루션 및 온-프레미스 리소스와 통신하는 워크플로를 오케스트레이션하는 표준 논리 앱의 초기 마이그레이션 환경 예제를 보여 줍니다.

테스트

각 웨이브 에는 각 사용자 스토리에 포함된 자체 테스트 작업이 있습니다. 왼쪽 시프트 테스트를 사용하려면 다음 작업을 완료해야 합니다.

• 테스트를 자동화합니다.

  Azure Logic Apps(표준)에는 자동화된 테스트를 수행하는 기능이 포함되어 있습니다. 다음 목록에는 GitHub에서 자유롭게 사용할 수 있는 추가 정보 및 리소스가 포함되어 있습니다.

  • Azure Logic Apps 팀의 Azure Logic Apps(표준)를 사용하여 자동화된 테스트

    Azure Logic Apps(표준)를 사용하면 Azure Functions 런타임을 기반으로 하고 Azure Functions를 실행할 수 있는 모든 위치에서 실행할 수 있는 기본 아키텍처 때문에 자동화된 테스트를 더 이상 수행하기가 어렵습니다. 로컬 또는 CI/CD 파이프라인에서 실행되는 워크플로에 대한 테스트를 작성할 수 있습니다. 자세한 내용은 Azure Logic Apps 테스트 프레임워크용 샘플 프로젝트를 참조하세요.

    이 테스트 프레임워크에는 다음과 같은 기능이 포함됩니다.

    • Azure Logic Apps에서 엔드투엔드 기능에 대한 자동화된 테스트를 작성합니다.
    • 워크플로 실행 및 작업 수준에서 세분화된 유효성 검사를 수행합니다.
    • Git 리포지토리에 대한 테스트를 확인하고 로컬 또는 CI/CD 파이프라인 내에서 실행합니다.
    • HTTP 작업 및 Azure 커넥터에 대한 테스트 기능을 모의합니다.
    • 프로덕션과 다른 설정 값을 사용하도록 테스트를 구성합니다.

  • Michael Stephenson(Microsoft MVP)의 통합 플레이북: Logic Apps 표준 테스트

    이 통합 플레이북 테스트 프레임워크는 Microsoft에서 제공하는 테스트 프레임워크를 기반으로 빌드되어 추가 시나리오를 지원합니다.

    • 표준 논리 앱의 워크플로에 연결합니다.
    • 테스트에서 워크플로를 트리거할 수 있도록 콜백 URL을 가져옵니다.
    • 워크플로 실행의 결과를 확인합니다.
    • 워크플로의 실행 기록에서 작업 입력 및 출력을 확인합니다.
    • 논리 앱 개발자가 사용할 수 있는 자동화된 테스트 프레임워크에 연결합니다.
    • SpecFlow에 연결되어 논리 앱에 대한 BDD(동작 기반 개발)를 지원합니다.

  사용하는 자동화 접근 방식이나 리소스에 관계없이 반복 가능하고 일관되며 자동화된 통합 테스트를 수행할 수 있습니다.

• 정적 결과를 사용하여 모의 응답 테스트를 설정합니다.

  자동화된 테스트를 설정했는지 여부에 관계없이 Azure Logic Apps에서 정적 결과 기능을 사용하여 작업 수준에서 일시적으로 모의 응답을 설정할 수 있습니다. 이 기능을 사용하면 호출하려는 특정 시스템에서 동작을 에뮬레이트할 수 있습니다. 그런 다음, 몇 가지 초기 테스트를 격리하여 수행하고 비즈니스 시스템에서 만들 데이터의 양을 줄일 수 있습니다.

• 병렬 테스트를 실행합니다.

  이상적으로는 BizTalk Server 환경에 대한 기준 통합 테스트와 Azure Logic Apps에 대한 자동화된 테스트가 이미 있습니다. 그런 다음 동일한 데이터 세트를 사용하여 인터페이스를 확인하고 전반적인 테스트 정확도를 향상시키는 방식으로 테스트를 병렬로 실행할 수 있습니다.

프로덕션으로 릴리스

팀이 완료되고 사용자 스토리에 대한 "완료 정의"를 충족한 후 다음 작업을 고려합니다.

1. 프로덕션에 대한 릴리스에 대한 통신 계획을 만듭니다.

2. "컷오버" 계획을 수립합니다.

   컷오버 계획은 팀이 실행하려는 단계를 포함하여 현재 플랫폼에서 새 플랫폼으로 전환하는 데 필요한 작업 및 활동에 대한 세부 정보를 다룹니다. 컷오버 계획에 다음 고려 사항을 포함합니다.

   • 필수 단계
   • 드레스 리허설
   • 사람
   • 예상 일정
   • 이전 플랫폼에서 인터페이스를 사용하지 않도록 설정
   • 새 플랫폼에서 인터페이스를 사용하도록 설정
   • 유효성 검사 테스트

3. 롤백 계획을 결정합니다.

4. 유효성 검사 테스트를 실행합니다.

5. 운영 또는 프로덕션 지원을 계획합니다.

6. 프로덕션으로 릴리스하려면 "이동 또는 이동 안 함" 조건을 선택합니다.

7. 팀의 성공을 축하합니다.

8. 회고 미팅을 개최합니다.

BizTalk 마이그레이션에 대한 모범 사례

모범 사례는 조직마다 다를 수 있지만 "바퀴를 다시 발명"하는 불필요한 노력과 유사한 공통 구성 요소의 중복성을 줄이는 데 도움이 되는 일관성을 높이기 위한 의식적인 노력을 고려합니다. 재사용 가능성을 높이면 조직에서 더 쉽게 지원할 수 있는 인터페이스를 더 빠르게 빌드할 수 있습니다. 출시 시간은 디지털 변환의 핵심 요소이므로 최우선 순위는 개발자와 지원 팀의 불필요한 마찰을 줄이는 것입니다.

자체적으로 모범 사례를 설정하는 경우 다음 지침에 부합하는 것이 좋습니다.

Azure 리소스에 대한 일반 명명 규칙

리소스 그룹에서 각 리소스 종류에 이르기까지 모든 Azure 리소스에서 효과적인 명명 규칙을 설정하고 일관되게 적용해야 합니다. 검색 가능성 및 지원 가능성을 위한 견고한 기반을 마련하기 위해 효과적인 명명 규칙은 용도를 전달합니다. 명명 규칙에서 가장 중요한 점은 규칙이 마련되어 있고 조직이 이를 이해한다는 것입니다. 모든 조직에는 고려해야 할 미묘한 차이가 있습니다.

이 관행에 대한 지침은 다음 Microsoft 권장 사항 및 리소스를 검토하세요.

• Azure 리소스에 대한 약어 예제
• Azure 준수 이름을 생성하는 Azure 명명 도구는 이름을 표준화하고 명명 프로세스를 자동화하는 데 도움이 됩니다.

Azure Logic Apps 리소스에 대한 명명 규칙

논리 앱 및 워크플로에 대한 디자인은 개발자가 고유한 이름을 만들 수 있는 유연성을 제공하기 때문에 주요한 시작점을 제공합니다.

논리 앱 리소스 이름

사용량 및 표준 논리 앱 리소스를 구분하기 위해 다음과 같이 다른 약어를 사용할 수 있습니다.

• 사용량: LACon
• 표준: LAStd

조직의 관점에서 사업부, 부서, 애플리케이션 그리고 필요에 따라 배포 환경(예: DEV, UAT, PROD 등)을 포함하는 명명 패턴을 디자인할 수 있습니다.

LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>

회사 서비스 사업부의 HR 부서에 대한 워크플로를 구현하는 표준 논리 앱이 개발 중이라고 가정해 보겠습니다. 이 논리 앱 리소스의 이름을 LAStd-CorporateServices-HR-DEV로 지정하고 일관성에 적합한 경우 파스칼 표기법을 사용할 수 있습니다.

논리 앱 워크플로 이름

사용량 논리 앱 리소스는 항상 하나의 워크플로에만 매핑되므로 단일 이름만 필요합니다. 표준 논리 앱 리소스는 여러 워크플로를 포함할 수 있으므로 멤버 워크플로에도 적용할 수 있는 명명 규칙을 디자인합니다. 이러한 워크플로의 경우 프로세스 이름에 따라 명명 규칙을 고려합니다. 예를 들면 다음과 같습니다.

Process-<*process-name*>

따라서 직원 레코드 만들기와 같은 직원 온보딩 작업을 구현하는 워크플로가 있는 경우 워크플로 이름을 Process-EmployeeOnboarding으로 지정할 수 있습니다.

워크플로 명명 규칙을 디자인하기 위한 추가 고려 사항은 다음과 같습니다.

• 하나 이상의 워크플로 간의 관계를 강조 표시하려는 워크플로의 부모-자식 패턴을 따릅니다.
• 워크플로가 메시지를 게시하는지 아니면 소비하는지를 고려합니다.

워크플로 작업 이름

워크플로에 트리거 또는 작업을 추가하면 디자이너는 해당 작업의 기본 제네릭 이름을 자동으로 할당합니다. 그러나 작업 이름은 워크플로 내에서 고유해야 하므로 디자이너는 후속 작업 인스턴스에 순차적인 숫자 접미사를 추가하게 되어 개발자의 원래 의도를 읽고 이해하기 어렵게 됩니다.

작업 이름을 더 의미 있고 이해하기 쉽게 만들려면 기본 텍스트 뒤에 간단한 작업 설명자를 추가하고 일관성을 위해 파스칼 표기법을 사용할 수 있습니다. 예를 들어 JSON 구문 분석 작업의 경우 JParse JSON-ChangeEmployeeRecord와 같은 이름을 사용할 수 있습니다. 이 방법 또는 다른 유사한 접근 방식을 사용하면 이 작업의 이름인 Parse JSON과 이 작업의 특정 용도를 계속 기억할 것입니다. 따라서 나중에 다운스트림 워크플로 작업에서 이 작업의 출력을 사용해야 하는 경우 해당 출력을 보다 쉽게 식별하고 찾을 수 있습니다.

작업 출력을 사용할 때 생성되는 다운스트림 종속성에서 나중에 발생할 수 있는 재작업 및 문제를 방지하려면 워크플로에 추가하는 즉시 작업의 이름을 바꿉니다. 일반적으로 다운스트림 작업은 작업의 이름을 바꾸면 자동으로 업데이트됩니다. 그러나 이름 바꾸기를 수행하기 전에 만든 사용자 지정 식의 이름은 Azure Logic Apps에서 자동으로 바꾸지 않습니다.

연결 이름

워크플로에서 연결을 만들 때 기본 연결 리소스는 sql 또는 office365와 같은 제네릭 이름을 자동으로 가져옵니다. 작업 이름과 마찬가지로 연결 이름도 고유해야 합니다. 동일한 유형의 후속 연결은 sql-1, sql-2 등과 같은 순차적인 숫자 접미사를 부여받습니다. 이러한 이름은 컨텍스트를 제공하지 않으므로 특히 솔루션 공간을 모르고 이러한 워크플로를 유지 관리해야 하는 개발자에게 워크플로에 대한 연결을 차별화하고 매핑하는 것이 매우 어렵습니다.

따라서 의미 있고 일관된 연결 이름은 다음과 같은 이유로 중요합니다.

• 가독성
• 더 쉬운 지식 이전 및 지원 가능성
• 거버넌스

형식이 지나치게 중요하지는 않지만 명명 규칙을 갖는 것은 매우 중요합니다. 예를 들어 다음 패턴을 지침으로 사용할 수 있습니다.

CN-<*connector-name*>-<*logic-app-or-workflow-name*>

구체적인 예로, CN-ServiceBus-OrderQueue를 새 이름으로 사용하여 OrderQueue 논리 앱 워크플로에서 Service Bus 연결의 이름을 바꿀 수 있습니다. 자세한 내용은 Turbo360(이전의 Serverless360) 블로그 게시물, 논리 앱 모범 사례, 팁 및 요령을 참조하세요. #11 커넥터 명명 규칙.

범위 및 "실행 후" 옵션을 사용하여 예외 처리

범위는 Try-Catch-Finally 동작을 구현할 수 있도록 여러 작업을 그룹화하는 기능을 제공합니다. 디자이너에서 범위의 콘텐츠를 축소하고 확장하여 개발자 생산성을 향상시킬 수 있습니다.

이 패턴을 구현할 때 이전 작업의 실행 상태에 따라 범위 작업 및 내부의 작업을 실행할 시기를 지정할 수도 있습니다. 실행 상태는 성공, 실패, 건너뜀 또는 시간 초과일 수 있습니다. 이 동작을 설정하려면 범위 작업의 실행 후(runAfter) 옵션을 사용합니다.

• Is successful
• Has failed
• Is skipped
• Has timed out

공유 서비스 통합

통합 솔루션을 빌드할 때 일반적인 작업에 대한 공유 서비스를 만들고 사용하는 것이 좋습니다. 팀이 프로젝트 팀 및 다른 사용자가 사용할 수 있는 공유 서비스 컬렉션을 빌드하고 노출하도록 할 수 있습니다. 모든 사용자는 생산성, 균일성 그리고 조직의 솔루션에 거버넌스를 적용하는 기능을 향상합니다. 다음 섹션에서는 공유 서비스 도입을 고려할 수 있는 몇 가지 영역에 대해 설명합니다.

다음 단계

이제 BizTalk Server 워크로드를 Azure Logic Apps로 이동하기 위한 사용 가능한 마이그레이션 방법 및 모범 사례에 대해 자세히 알아보았습니다. 이 가이드에 대한 자세한 피드백을 제공하려면 다음 양식을 사용할 수 있습니다.