통합 패턴 살펴보기

분석에 따라 통합을 계획하고 요구 사항에 가장 적합한 패턴을 식별합니다. 다음 통합 패턴 목록은 완전하지 않습니다. 이러한 패턴의 조합이 시나리오에 가장 적합할 수 있습니다.

각 패턴은 특정 비즈니스 시나리오 및 기술 제약 조건을 해결합니다.

• 인스턴트 트리거 패턴: 이 패턴은 사용자가 시스템과 상호 작용하는 방식을 반영합니다. 사용자 기반 작업은 미리 정의된 일련의 작업을 트리거합니다.
• 이벤트 기반 패턴: 이 패턴에는 지정된 시스템에서 발생하는 이벤트에 대한 응답과 같은 자동 트리거가 필요합니다.
• 데이터 통합 패턴: 이 패턴은 다양한 시스템에서 데이터를 완전히 파악해야 하는 여러 관리 시스템이 있는 조직에 필수적입니다.
• 서비스 지향 아키텍처 패턴: 이 패턴은 일반적으로 시스템 간에 여러 흐름을 포함하므로 복잡한 환경에서 모듈식으로 확장 가능한 통합을 가능하게 합니다.
• 동기화 패턴: 이 패턴은 여러 데이터베이스 간에 데이터를 동기화 상태로 유지하고 성능 및 규정 요구 사항을 해결합니다.

인스턴트 트리거 패턴

인스턴트 트리거 패턴은 사용자 중심이며 직관적입니다. 사용자가 Power App에서 단추를 누르는 등의 작업을 수행할 때 통합 흐름을 시작합니다. 이 패턴은 데이터가 지속적으로 필요하지 않고 요청 시 필요한 시나리오에 적합합니다.

예제 시나리오

Power App을 사용하면 제품 관리자가 고객 피드백을 검토하고 작업 계획을 만들 수 있습니다. 일부 기술 사양은 Oracle의 제품 수명 주기 관리 시스템에 저장됩니다. 앱에는 전체 데이터 세트를 Dataverse에 복사하는 대신 필요할 때 데이터를 가져오는 단추가 포함되어 있습니다.

사용자를 Oracle로 리디렉션하는 대신 통합해야 하는 이유는 다음과 같습니다.

• 사용자 환경이 좋지 않습니다.
• 보안 문제
• 라이선스 비용

Power Platform 통합의 비용 효율성을 고려할 때 이러한 이유 중 어느 것이라도 구현을 정당화할 수 있습니다.

흐름 디자인

애플리케이션에서 단추 누름으로 트리거되는 인스턴트 클라우드 흐름을 사용합니다.

이 다이어그램은 사용자가 시작한 작업이 외부 시스템에서 데이터를 검색하고 Dataverse에 기록하는 인스턴트 트리거 패턴을 보여 줍니다.

흐름에는 다음 단계가 포함됩니다.

1. 앱에서 제공하는 매개 변수(예: 제품 ID)를 사용하여 Oracle에서 레코드를 요청합니다.
2. Oracle에서 앱으로 레코드를 반환합니다.
3. Dataverse에 레코드를 씁니다.

그러면 이 데이터가 Power Apps 인터페이스에 반영됩니다.

고려 사항:

• Oracle과 Dataverse 간의 데이터 모델은 다를 수 있으므로 변환 단계가 요구됩니다.
• 인스턴트 트리거는 실제로 즉각적이지 않습니다. 실행 시간은 시스템 가용성 및 변환 복잡성에 따라 달라집니다.
• 앱에 시각적 표시기를 추가하여 진행률을 표시하고 작업이 너무 오래 걸리는 경우 취소를 허용합니다.
• 대규모 조직에서는 많은 사용자의 동시 요청이 시스템에 부담을 줄 수 있습니다.
• 여러 가지 이유로 통합이 실패할 수 있습니다. 앱이 실행 중에 사용자에게 피드백을 제공하는지 확인합니다. 사용자가 단추를 선택하고 응답을 받지 못하는 시나리오를 방지하면 사용자 환경이 저하됩니다.

이벤트 기반 패턴

이벤트 기반(자동 트리거라고도 함) 아키텍처는 직접 사용자 상호 작용 없이 시스템의 변경에 응답합니다. 예를 들어 트리거는 Dataverse에서 만든 레코드, 들어오는 전자 메일, OneDrive에 추가된 파일 및 기타 이벤트 수에 응답하도록 구성할 수 있습니다. 이 패턴은 직관적이고 확장 가능하므로 시스템 이벤트를 기반으로 비즈니스 프로세스를 자동화하는 데 이상적입니다.

예제 시나리오

고객 서비스 부서는 Dataverse 연결 앱을 사용하여 사례를 작업하고 이메일을 수동으로 작성하지 않고 고객에게 자동으로 업데이트를 제공합니다. 메모 추가 또는 상태 변경과 같은 특정 변경 내용만 알림을 트리거해야 합니다.

Power Automate에서 자동 트리거를 사용하여 이러한 이벤트에 응답합니다. 흐름은 Dataverse 레코드의 변경 내용을 수신 대기하고 정의된 조건이 충족되면 알림을 보냅니다.

이 다이어그램은 Dataverse의 변경 내용이 관련 사례 정보로 고객을 업데이트하는 다운스트림 작업을 자동으로 시작하는 자동 트리거 패턴을 보여 줍니다.

트리거 구성

다음과 같이 흐름을 구성합니다.

• 모니터링할 변경 유형을 나타냅니다.
• 열 선택 매개 변수를 사용하여 응답할 열을 정의합니다.
• 필터 행 매개변수를 사용하여 고객 대상을 위한 상태 변경만 흐름을 트리거하도록 하고, 추가적인 필터링 요구 사항도 반영합니다.

If 작업을 사용하여 흐름 자체에서 이 논리를 구현하지 마십시오. 트리거 매개 변수를 사용하여 불필요한 실행을 줄이고 성능을 향상시킵니다.

논리적 충돌 방지

의도하지 않은 동작을 방지하기 위해 이벤트 논리를 평가합니다.

• 이벤트가 동일한 이벤트를 다시 시도 하는 작업을 트리거 하는 루프를 방지 합니다.
• 여러 업데이트가 신속하고 반복적인 알림을 발생시키는 것을 방지합니다.
• 에지 사례를 처리하고 과도한 실행을 방지하기 위한 흐름을 디자인합니다.

볼륨 및 빈도 고려 사항

트리거된 이벤트의 예상 볼륨을 이해합니다. 알림 서비스(전자 메일, SMS 등)는 지정된 시간 프레임에 보낼 수 있는 메시지 수를 제한합니다.

• 일별 또는 월의 이벤트 수를 예측합니다.
• 속도 제한 메커니즘을 구현합니다.
• 이벤트 빈도의 예기치 않은 급증에 대한 완화 계획을 준비합니다.

데이터 통합 패턴

데이터 통합(예약된 트리거라고도 함)은 조직이 보고 및 운영 프로세스를 지원하기 위해 여러 시스템에서 정보를 통합하는 데 도움이 됩니다. 분석에는 전체 데이터 세트가 필요한 경우가 많지만 운영 사용 사례는 비즈니스 작업을 완료하는 데 필요한 데이터만 검색하는 데 집중합니다.

예제 시나리오

회사는 세 가지 레거시 시스템을 사용하여 주문 및 계정 수취인을 위한 SAP, 제품 인벤토리용 Oracle, 고객 관련 콘텐츠 관리를 위한 IBM의 핵심 비즈니스 기능을 관리합니다. 조직은 AI를 사용하여 기록 데이터를 기반으로 각 고객에 대한 다음 최선의 조치를 예측하기 위해 새 Power Platform 앱을 의뢰했습니다. 앱은 세 시스템 모두에서 관련 정보를 수집하고 영업 관리자가 참여를 안내하기 위한 영업 작업 계획을 생성해야 합니다.

통합 접근 방식

통합에는 실시간 업데이트 또는 이벤트 기반 트리거가 필요하지 않습니다. 대신 영업 직원이 고객과 상호 작용하는 빈도에 따라 예약된 프로세스를 사용합니다.

이 사용 사례에서 예약된 트리거는 다음과 같이 데이터를 통합합니다.

• 각 시스템에서 필요한 데이터만 요청합니다.
• Dataverse와 호환되는 형식으로 데이터를 반환합니다.
• 분석을 위해 AI 모델에 데이터를 업로드합니다.

이 다이어그램은 되풀이 프로세스가 여러 시스템에서 정보를 수집하고 결합된 데이터 세트를 Dataverse에 업로드하는 예약된 데이터 통합 패턴을 보여 줍니다.

예약된 트리거 구성

예약된 트리거는 초당 1회에서 1년 1회까지 유연한 되풀이 옵션을 제공합니다. 타이밍에 예측 가능하지만 데이터 범위가 확장되거나 증가가 예상을 초과하는 경우 볼륨이 예측할 수 없게 될 수 있습니다.

• 흐름 실행 시간을 모니터링하여 겹침 또는 지연 방지
• 성능 저하를 방지하기 위한 세이프가드 구현
• Application Insights 또는 유사한 도구를 사용하여 흐름이 일관되게 실행되도록 합니다.

위험 완화

예약된 흐름이 예상보다 오래 걸리면 비즈니스 프로세스가 중단될 수 있습니다. 예를 들어 완료하는 데 10분 이상 걸리기 시작하면 10분마다 실행되도록 설계된 흐름이 실패할 수 있습니다.

• 런타임 모니터링 및 변칙 경고 설정
• 데이터 볼륨이 증가함에 따라 확장성 계획
• 눈에 띄지 않는 오류를 방지하기 위해 흐름 상태에 대한 가시성 보장

서비스 지향 통합 패턴

대규모 조직은 부서 간에 여러 시스템을 운영하는 경우가 많습니다. 이러한 시스템은 비즈니스 프로세스를 완료하기 위해 서로 의존하도록 진화합니다. 통합 계층은 이러한 시스템을 연결하여 시스템 간 통신을 사용하도록 설정하면서 각 시스템이 핵심 기능을 수행할 수 있도록 합니다.

다시 검토된 예제 시나리오

조직에서 여러 시스템을 사용하여 비즈니스의 여러 부분을 관리하는 예제 시나리오를 계속해 보겠습니다. SAP는 주문 및 계정 수취인을 처리하고, Oracle은 제품 인벤토리를 관리하며, IBM은 내부 재무 문서를 저장합니다. Dataverse는 판매, 고객 서비스 및 제품 관리를 위한 앱을 실행합니다. SharePoint는 내부 공동 작업 및 기술 자료 관리를 지원하고 Maersk API는 물류 프로세스를 자동화합니다.

이 다이어그램은 다양한 엔터프라이즈 시스템의 업데이트가 데이터와 작업 간의 작업을 조정하는 자동화된 흐름을 트리거하는 다중 시스템 환경의 이벤트 기반 패턴을 보여 줍니다.

각 시스템은 예약된 이벤트 또는 수동 사용자 작업을 통해 다른 사용자와 상호 작용합니다. 모든 사용 사례를 제공하는 단일 흐름은 없습니다. 대신 솔루션에는 특정 트리거 및 비즈니스 프로세스에 맞게 조정된 여러 흐름이 필요합니다.

모놀리식 흐름 방지

모든 통합을 처리하는 하나의 큰 흐름을 만드는 것은 실용적이지 않습니다. 성능, 보안 및 유지 관리 문제를 소개합니다. 대신:

• 각 트리거 및 프로세스에 대한 모듈식 흐름 빌드
• 특정 사용 사례에 대한 흐름 최적화
• 관리 가능한 구성 요소를 사용하여 통합 환경 크기 조정

시스템 간 프로세스 최적화

적절한 경우 논리를 통합할 기회를 찾습니다. 예를 들어 동일한 이벤트 중에 SharePoint의 문서를 SAP와 Oracle 모두에 보내야 하는 경우 파일을 한 번 읽고 두 시스템에 쓰는 흐름을 하나 만드려고 할 수 있습니다. 먼저, 당신이 만드는 논리가 너무 엄격한지 고려하세요. 대규모 환경에서는 시스템 간에 비즈니스 프로세스가 작동하는 방식의 변경이 해당 시스템의 변경만큼 자주 발생합니다.

과도하게 통합하지 마십시오. 비즈니스 프로세스 및 시스템 구성은 자주 변경됩니다. 엄격한 중앙 집중식 논리는 유연성을 줄이고 유지 관리 오버헤드를 증가시킵니다.

다음과 같은 디자인 흐름:

• 모듈식 및 유지 관리 가능
• 부서 및 시스템에서 확장 가능
• 비즈니스 논리 및 시스템 동작의 변화에 대한 복원력

이 패턴은 서비스 지향 아키텍처(때로는 유머러스하게 "스파게티 아키텍처"라고도 함)를 생성합니다. 여기서 시스템은 잘 정의된 용도로 빌드된 흐름을 통해 상호 연결됩니다.

데이터 동기화 패턴

동일한 시스템이 별도의 데이터베이스에 데이터를 저장할 때 데이터 동기화를 사용합니다. 동일한 데이터를 두 번 저장하는 것은 비효율적인 것처럼 보일 수 있지만 이 패턴은 성능 및 규정 준수와 같은 특정 비즈니스 요구를 지원합니다.

• 성능: 로컬 데이터 액세스는 특히 대기 시간에 민감한 산업에서 응답성을 향상시킵니다.
• 규정 준수: 법률 규정에 따라 데이터를 국경 내에 저장해야 할 수 있습니다. 조직에서는 이러한 요구 사항을 충족하기 위해 동기화 프로세스를 사용하여 로컬 인스턴스를 배포하는 경우가 많습니다.

예제 시나리오

의료 기기 회사는 지역 의료 기관과 협력하여 유럽의 여러 지역에서 운영됩니다. 각 지역의 법률은 의료 데이터에 대해 명확합니다. 해당 지역의 테두리 내에 저장되어야 합니다. 주문, 제품 및 배송에 대한 정보는 국경을 넘어 저장할 수 있습니다. 규정 요구 사항을 해결하기 위해 회사는 각 지역에 Power Platform 고객 관리 앱 및 Dataverse 인스턴스를 만들었습니다.

영업 작업을 지원하기 위해 회사는 모든 인스턴스에서 연락처 세부 정보, 주문 및 배송과 같은 민감하지 않은 데이터를 동기화하려고 합니다. 의료 데이터는 동기화에서 제외됩니다.

통합 접근 방식

계정 레코드에 대한 업데이트로 트리거되는 자동 클라우드 흐름을 사용합니다. 필터를 구성하여 다음을 수행합니다.

• 허용되는 필드만 모니터링
• 제한된 데이터의 동기화 방지

이 방법을 사용하면 규정 준수 및 운영 효율성을 지원하는 대상 이벤트 기반 통합이 생성됩니다.

이 다이어그램은 한 Dataverse 환경의 업데이트가 다른 데이터 버스 환경에서 해당 업데이트를 자동으로 트리거하는 이벤트 기반 동기화 패턴을 보여 줍니다.

응답 시간 예상

동기화 속도에 대한 현실적인 기대치를 설정합니다. Power Automate는 비동기적이며 실시간 성능을 보장하지 않습니다. 비즈니스 사용자가 즉각적인 데이터 가용성을 기대하는 경우 디자인 프로세스 초기에 제한 사항을 명확히 합니다.

• Power Automate가 성능 요구 사항을 충족하는지 평가
• 비즈니스 요구 사항에 의해 정당화되지 않는 한 실시간 액세스를 위한 오버 엔지니어링 방지

실시간 액세스에 대한 많은 요청은 강력한 비즈니스 사례가 부족합니다. 통합 디자인에서 명확성, 확장성 및 유지 관리 효율성의 우선 순위를 지정합니다.

클라우드 흐름 외

통합 도구를 선택할 때 Power Automate를 기본 옵션으로 시작합니다. 개발 및 유지 관리 모두에 타의 추종을 불허하는 비용 효율성을 제공합니다.

Power Automate는 다음과 같은 이유로 많은 시나리오에서 선호되는 통합 도구입니다.

• 저코드 커넥터를 사용하여 신속한 개발 제공
• 장기 유지 관리 비용 최소화
• 광범위한 트리거 및 시스템을 지원합니다.
• 대부분의 비즈니스 시나리오에 맞게 확장

사용자 지정 코드, Azure Functions, Data Factory 또는 Service Bus는 더 많은 제어 또는 성능 향상을 제공할 수 있지만 복잡성과 비용이 추가됩니다. Power Automate가 비즈니스 또는 기술 요구 사항을 충족하지 않는 경우에만 이러한 옵션을 사용합니다.

예제 시나리오

온라인 뱅킹 서비스는 고객에게 더 빨리 대출을 받을 자격을 갖추기를 원합니다. 자격 프로세스에는 최종 위험 점수에 도달하기 위해 여러 시스템에서 복잡한 계산 및 데이터 검색이 포함됩니다. 초기 평가 후 은행 서비스는 계산의 복잡성을 고려할 때 클라우드 흐름이 적합하지 않다고 간주했습니다.

그러나 이 경우 하이브리드 접근 방식이 답입니다.

• 기본 제공 커넥터를 사용하여 데이터 수집을 처리하는 Power Automate
• Azure Function으로 실행되는 사용자 지정 코드에 캡슐화된 복잡한 계산은 독립적으로 크기 조정 가능하며, 사용자 지정 커넥터로 실행될 수도 있습니다.

이 하이브리드 접근 방식은 성능, 확장성 및 비용의 균형을 조정합니다.

통합 전략

격리된 도구를 선택하지 마세요. 대신, 그들의 강점을 결합합니다. 다음은 그 예입니다.

• 오케스트레이션 및 연결에 Power Automate 사용
• 계산 집약적 작업에 Azure Functions 사용
• 사용자 지정 커넥터를 사용하여 필요한 경우 기능 확장

모든 통합 결정은 총 소유 비용을 고려해야 합니다. 사용자 지정 솔루션은 강력해 보일 수 있지만 개발, 라이선스 및 지원을 위해 더 큰 예산이 필요한 경우가 많습니다. 명확한 비즈니스 가치로 더 높은 비용을 정당화합니다.