OrderBroker 오케스트레이션에서 처리
이 섹션에서는 OrderBroker 오케스트레이션이 주문을 받아 프로세스 관리자를 위해 준비하는 방법을 설명합니다. 이 섹션은 오케스트레이션의 일반 작업에 대한 내용으로 시작하여 오케스트레이션이 메시지를 처리하는 방법과 원자성 트랜잭션을 사용하여 성능을 향상하는 방법을 차례로 설명합니다.
참고
OrderBroker 코드의 길이로 인해 Microsoft® Visual Studio에서 오케스트레이션이 열려 있는 이 섹션을 읽을 수 있습니다.
주문 브로커를 사용하는 이유
OrderBroker 오케스트레이션의 목적은 주문을 전처리하고 올바른 프로세스 관리자에게 라우팅하는 것입니다. 여기서의 전처리는 기록 데이터베이스, 서비스 제공 시스템 및 주문 승인 확인에 대한 정보 메시지 생성으로 구성됩니다. 또한 OrderBroker는 고객 서비스 요청에서 일반 주문 메시지를 만듭니다. 이 주문 정규화는 비즈니스 프로세스 요소에 의한 일반적인 주문 사용을 허용합니다.
주문 메시지는 주문 정보에서 분리된 라우팅 정보를 가진 다중 파트 메시지입니다. 라우팅 정보 또한 일반적이며 주문 관리자에서 사용하도록 디자인되었습니다. 따라서 솔루션을 확장하기 쉽습니다. 다중 파트 메시지에 대한 자세한 내용은 다중 파트 메시지 형식을 사용하는 방법을 참조하세요.
또한 브로커 격리 기능을 사용하면 브로커를 다른 BizTalk 그룹으로 이동할 수 있습니다. OrderBroker는 MessageBox 데이터베이스( 즉, 직접 바인딩)에 게시되므로 브로커를 다른 그룹에 더 쉽게 배치할 수 있으므로 오케스트레이션을 변경하지 않고 브로커를 이동할 수 있습니다. OrderBroker를 다른 그룹에 배치하는 방법에 대한 자세한 내용은 OrderBroker와 OrderManager 간의 통신을 참조하세요.
참고
OrderBroker 오케스트레이션은 통신할 OrderManager가 하나뿐이므로 주문 관리자 메시지의 OrderMgrType 필드에 상수 문자열을 할당하기만 하면 됩니다. 일반적으로 여러 주문 관리자가 있었던 응용 프로그램에서는 비즈니스 규칙 엔진을 사용하여 이 필드 및 주문 라우팅에 대한 적절한 값을 결정합니다. 비즈니스 규칙 엔진에 대한 자세한 내용은 비즈니스 규칙 만들기 및 사용을 참조하세요.
주문 처리
OrderBroker 오케스트레이션은 수신 셰이프 내에서 두 개의 수신 셰이프로 시작합니다. One Receive 셰이프는 고객 지원 시스템에서 메시지를 받습니다. 다른 하나는 공급업체 시스템의 메시지입니다. 두 소스로부터의 메시지는 동일한 스키마를 갖습니다.
오케스트레이션은 메시지에서 반환 주소를 추출하고 이를 사용하여 동적 포트 인 CSRPort의 주소를 설정합니다. 오케스트레이션은 이 포트를 사용하여 승인 및 오류 메시지를 보냅니다.
OrderBroker 오케스트레이션의 다음 단계에서는 기록 메시지, 서비스 메시지, 확인 메시지 및 OrderManager 오케스트레이션으로 보낼 주문 메시지를 만듭니다. 오케스트레이션은 InsertOrderBody 유틸리티 함수를 사용하여 기록 메시지에 주문 메시지를 추가합니다.
참고
일부 상황에서 솔루션은 배달되기는 하지만 사용되지 않는 메시지를 생성할 수도 있습니다. 주문 브로커 오케스트레이션은 송신 포트를 사용하여 기록 데이터베이스에서 정보를 삽입하며, 이 송신 포트는 배달 알림을 사용합니다. 구성은 전송 포트를 두 개의 포트(테스트 구성에 대한 하나의 포트(HistoryInsert-Test-SP)를 포함하는 송신 포트 그룹에 매핑하고, 하나는 일반 구성(HistoryInsert-SP)에 매핑합니다. 그룹 내에서 두 포트가 모두 실행되는 상태로 두면 솔루션은 두 포트 모두에 메시지를 보냅니다. 따라서 요청되는 배달 알림은 두 개이지만 처리되는 알림은 하나뿐입니다.
이 상황을 방지하려면 테스트 포트(HistoryInsert-Test-SP)를 선택 취소하거나 애플리케이션의 테스트 버전 인 BTSScn.BPM.OrderBrokerApp.Test를 중지합니다. 배달 알림에 대한 자세한 내용은 승인 사용을 참조하세요.
OrderManager 오케스트레이션으로 보낼 메시지를 생성할 때 OrderBroker 오케스트레이션은 두 부분으로 구성된 다중 파트 메시지를 만듭니다. 한 파트에는 라우팅 정보가, 다른 파트에는 주문 자체가 포함되어 있습니다. 메시지의 라우팅 부분인 OrderMgrMsg.Routing은 SchemaClasses 어셈블리에서 C# 클래스로 정의된 스키마를 사용합니다. broker는 메시지의 순서 부분을 제네릭 또는 형식에 구애받지 않는 XML 문서(System.Xml로 처리합니다. XmlDocument) 및 는 OrderMgrMsg.Order에 할당합니다.
라우팅 정보에는 OrderMgrMsg.Routing.OrderMgrType 및 OrderMgrMsg.Routing.Status 에 특히 중요한 두 필드가 있습니다. 브로커는 OrderMgrType 을 주문을 처리할 주문 관리자 유형으로 설정합니다. 솔루션에서는 하나의 주문 관리자와 필드만 CABLEORDER로 설정됩니다. 또한 브로커는 상태 필드를 ACCEPTED로 설정합니다. 이것은 주문 관리자에게 메시지가 새로운 주문임을 알려주는 값입니다. 솔루션의 주문 관리자인 OrderManager 오케스트레이션은 CABLEORDER와 같고 ACCEPTED와 같은 상태 순서 유형을 필터링하는 Receive 셰이프를 사용합니다.
OrderBroker 오케스트레이션의 나머지 단계에서는 다른 메시지를 적절한 포트로 보냅니다.
중첩된 범위를 사용하여 성능 향상
OrderBroker 오케스트레이션에서 눈에 띄는 것 중 하나는 중첩된 범위를 사용하는 것입니다. 중첩된 범위는 지속성 포인트를 제한하여 성능을 어느 정도 향상하는 것입니다.
오케스트레이션 엔진은 지속성 포인트라는 실행 지점에 정기적으로 전체 오케스트레이션의 상태를 저장합니다. 오케스트레이션 엔진은 셰이프 보내기 를 비롯한 여러 오케스트레이션 셰이프를 지속성 지점으로 자동으로 처리합니다. 지속성 지점 목록 및 해당 항목에 대한 자세한 내용은 지속성 및 오케스트레이션 엔진을 참조하세요.
5개의 보내기 셰이프를 사용하는 OrderBroker 오케스트레이션에는 5개의 지속성 지점이 있어야 합니다. 그러나 원자성 트랜잭션 scope 내에 셰이프 보내기를 그룹화하면 엔진은 scope 하나의 지속성 지점만 필요하다는 것을 인식합니다. OrderBroker 오케스트레이션의 Send 셰이프 중 4개는 예외 처리기의 일부가 아니며 보내기 후에는 아무 작업도 수행할 필요가 없으므로 원자성 트랜잭션 scope 사용할 수 있습니다. 이에 따라 지속성 포인트의 수가 줄어듭니다. 원자성 트랜잭션에 대한 자세한 내용은 원자성 트랜잭션을 참조하세요.
또한 오케스트레이션 엔진은 트랜잭션이 모두 동시에 종료될 경우 중첩된 트랜잭션에 대해 하나의 지속성 포인트를 사용합니다. 따라서 OrderBroker 오케스트레이션이 트랜잭션을 중첩하는 방식은 지속성 지점을 더욱 줄입니다. 오케스트레이션에는 범위 셰이프의 사용으로 인해 단일 지속성 지점이 있습니다.
팁
오케스트레이션에서 지속성 포인트의 수를 최소화하여 성능을 향상할 수 있습니다. 원자성 트랜잭션에서 셰이프 보내기 를 그룹화하여 모든 보내기 셰이프에 대한 단일 지속성 지점을 생성할 수 있습니다. 중첩된 트랜잭션 범위가 동시에 종료되면 해당 트랜잭션에 대해 하나의 지속성 포인트가 생성됩니다.
원자성 트랜잭션 범위에는 예외 처리기가 있을 수 없습니다. 따라서 오케스트레이션은 장기 실행 트랜잭션 내부에서 원자성 범위를 중첩합니다. 이 외부 트랜잭션에는 예외 처리기가 있을 수 있으며 보내기 셰이프에서 예외를 처리하는 것은 이 처리기입니다.
팁
장기 실행 트랜잭션 내부에서의 원자성 트랜잭션 중첩은 예외 처리를 허용하기 위한 일반적인 패턴입니다.
참고 항목
비즈니스 프로세스 관리 솔루션에서 처리
프로세스 관리자 논리
비즈니스 프로세스 관리 솔루션의 인터럽트 처리
ExceptionHandler 오케스트레이션