프로세스 관리자를 통한 주문 흐름
이 섹션에서는 Southridge 비디오 주문 프로세스 관리자인 OrderManager 오케스트레이션이 주문을 처리하는 방법을 설명합니다. 이때 오케스트레이션 전체에서 새로운 주문을 따릅니다. 또한 오케스트레이션이 주문 업데이트를 처리하는 방법에 대해서도 설명합니다.
참고
비즈니스 프로세스 관리자 솔루션은 프로세스 관리자를 하나만 포함하지만, 여러 관리자 유형을 사용할 수 있도록 작성됩니다.
OrderManager 오케스트레이션은 주문을 처리하기 위해 비즈니스 프로세스를 구현하는 종속 오케스트레이션을 조정합니다. OrderManager는 두 단계를 통해 주문을 보내 주문의 유효성을 검사하고, 시설 그룹에 정보를 보내고, 원격 구성 요소를 통해 주문 시스템에 주문을 보내고, 주문 기록을 업데이트합니다. OrderManager를 변경하지 않고도 이러한 단계를 추가, 삭제 또는 수정할 수 있습니다.
참고
OrderManager 오케스트레이션의 크기 및 scope 인해 Microsoft Visual Studio에서 오케스트레이션이 열려 있는 이 섹션을 읽을 수 있습니다.
주문 관리자 구조
OrderManager 오케스트레이션은 오케스트레이션을 활성화하는 수신 셰이프로 시작합니다. 다음 다이어그램에서는 OrderManager 오케스트레이션의 일반적인 구조를 보여 있습니다.
Order Manager
첫 번째 수신 셰이프는 두 개의 주 분기에 연결됩니다. 두 분기 중 오른쪽의 분기는 새 주문을 처리하고, 왼쪽의 분기는 주문 취소를 처리합니다. 사용자 입력을 허용하므로 주문이 이미 완료된 후 OrderManager 가 주문 취소를 받을 수 있습니다. 왼쪽의 주 분기는 이러한 사례를 처리합니다. 이 분기는 처리 종료를 위한 플래그를 설정하고 이벤트 로그에 경고를 추가하여 격리된 취소를 처리합니다. 오케스트레이션은 오른쪽 분기에서 주문을 처리하는 중에 도착하는 주문 취소를 처리합니다.
주문 처리 분기는 초기화를 수행한 다음 두 중첩된 반복으로 진입합니다. 외부 반복은 각 주문 처리 단계에 대해 한 번 실행되고 내부 반복은 단계 처리 중에 실행됩니다. 주문 관리자는 내부 반복 내에서 가능한 주문 업데이트도 수신 대기합니다. 반복이 종료되고 나면 주문 관리자는 완료 메시지를 보냅니다.
주문 처리 단계에서는 동적 자체 상관 관계 포트를 사용하여 OrderManager 오케스트레이션에 다시 통신합니다. 이렇게 하면 상관 관계 집합을 사용할 필요가 없으므로 OrderManager 와 스테이지 인스턴스의 상관 관계가 간소화됩니다. 자체 상관 관계에 대한 자세한 내용은 포트 바인딩을 참조하세요.
주문 수신
OrderManager는 FromBrokerPort 포트를 통해 OrderBroker 오케스트레이션에서 주문 메시지를 받습니다. 이 포트는 MessageBox 데이터베이스에 직접 바인딩됩니다. 오케스트레이션에는 포트에 연결된 두 개의 수신 셰이프가 있습니다. 하나는 새 주문용이고 다른 하나는 업데이트된 주문용입니다.
OrderManger는 필터 식을 기반으로 처리할 메시지를 결정합니다. 필터 식은 메시지 상태 필드의 값과 OrderMgrType 주문 관리자 유형 필드를 테스트합니다. 상태 필드가 ACCEPTED와 같고 OrderMgrType이 CABLEORDER인 경우 주문은 새로운 주문이며 이 프로세스 관리자를 위한 것입니다.
새 주문은 새 오케스트레이션 인스턴스를 활성화합니다. OrderManager는 다음으로 의사 결정 셰이프에서 요청 유형을 확인합니다. 요청 유형이 종료이면 오케스트레이션은 왼쪽 분기를 실행하여 주문을 종료하고 그렇지 않으면 주문 처리를 계속합니다. 이 과정에서 이 특정 주문과 관련된 후속 메시지를 수신 대기합니다.
새 주문 초기화
OrderManager 오케스트레이션이 초기 메시지를 수신하고 기본 오른쪽 분기를 시작하면 SSOConfigStore에서 해당 구성 정보를 가져옵니다. 유틸리티 어셈블리에 정의된 단일 개체를 통해 이 작업을 수행 합니다 . 구성 값은 개체의 속성입니다. 개체는 서비스 지향 아키텍처 솔루션과 비슷한 구성 값의 로컬 캐시를 관리합니다. Singleton 개체에 대한 자세한 내용은 비즈니스 프로세스 관리 솔루션에서 SSO를 효율적으로 사용을 참조하세요.
서비스 지향 솔루션과 마찬가지로 비즈니스 프로세스 관리 솔루션도 암호 저장소를 사용합니다. 암호 저장소는 BizTalk를 설치할 때마다 생성되고, 값을 즉시 사용할 수 있도록 SSO가 구성 정보를 캐시하며, 데이터베이스 연결 문자열 및 암호 등의 정보를 보호할 수 있기 때문입니다. 이러한 모든 이유로 인해 Single Sign-On을 사용하여 백 엔드 응용 프로그램에 대한 연결을 관리하지 않는 경우에도 암호 저장소에 구성 정보를 저장하는 것이 좋습니다.
참고
오케스트레이션은 처리를 시작하기 전에 구성 정보를 검색합니다. 따라서 오케스트레이션이 디하이드레이션되었다가 나중에 리하이드레이션될 때 같은 구성을 사용하게 됩니다. 탈수에 대한 자세한 내용은 오케스트레이션 탈수 및 리하이드레이션을 참조하세요.
주문 관리자는 구성 데이터에서 하나의 값인 TotalStages를 사용합니다. 주문 처리 프로세스의 총 단계 수입니다. 관리자는 이 값을 numStages 지역 변수에 할당합니다. 또한 외부 루프, 스테이지 및 중지에 연결된 두 개의 변수를 더 설정합니다. 스테이지는 현재 스테이지를 나타내고 는 외부 루프의 카운터입니다. 중지 값을 중지합니다.
마지막으로, 관리자는 orderStatus 변수를 STARTED로 설정하고 외부 처리 루프를 입력합니다.
새 주문 처리 반복
스테이지 변수의 값이 numStages 변수 값보다 작은 경우 외부 루프가 실행됩니다. 각 단계의 처리를 진행합니다. 내부 반복은 단계가 계속 처리 중이면 실행되며 가능한 주문 변경 내용도 수신 대기합니다.
외부 반복
오케스트레이션은 받은 메시지(NewOrderMgrMsg)를 변수 OrderMgrMsg에 할당하여 외부 루프를 시작합니다. 단계와 상태를 메시지의 라우팅 부분에 복사합니다. 또한 오케스트레이션은 메시지의 반환 주소를 StageCompletionPort의 주소로 설정합니다.
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
그런 다음 오케스트레이션은 순서를 요청 응답 포트인 StagePort로 보냅니다. 주문 처리가 시작된 단계의 승인을 기다립니다. 스테이지는 주문 처리를 시작할 때 OrderAck 메시지를 보냅니다.
참고
OrderAck 메시지는 스키마가 아닌 .NET 클래스로 정의된 솔루션의 여러 메시지 중 하나입니다. .NET 클래스를 사용하여 메시지를 정의하는 방법에 대한 자세한 내용은 사용자 코드에서 메시지 생성을 참조하세요.
오케스트레이션이 승인을 받으면 현재Stage 변수에 스테이지를 할당하고 내부 루프에 들어갑니다.
내부 반복
내부 루프는 currentStage 변수가 stage 변수와 같을 때 실행됩니다. 즉, 현재 단계가 처리되는 한 입니다. 루프의 본문은 수신 셰이프 3개가 있는 수신 셰이프입니다. 오케스트레이션의 맨 왼쪽 셰이프인 주문 요청은 다음 섹션에 설명된 주문 업데이트 메커니즘의 일부입니다.
주문 처리 단계가 완료되면 OrderManager 오케스트레이션의 StageCompletion 포트에 메시지를 보냅니다. 오류로 인해 스테이지가 갑자기 종료되면 TerminatedMessage를 보냅니다. 이 경우 OrderManager 는 예외를 throw합니다. 가장 바깥쪽 예외 처리기는 예외를 catch하고 OperatorPort에 오류 메시지를 보냅니다.
스테이지가 OrderMgrMsg를 보내는 경우 OrderManager 는 스테이지 변수를 증가합니다. 더 많은 스테이지(numStages보다 작거나 같은 스테이지)가 있는 경우 오케스트레이션은 OrderMgrMsg의 순서 상태 현재 스테이지의 수인 STAGE_n_COMPLETED 설정합니다. 단계가 더 없으면 주문 상태가 COMPLETED로 설정되고 두 반복이 모두 종료됩니다.
주문 업데이트
OrderManager 오케스트레이션은 내부 처리 루프 내에서 주문 업데이트를 수신 대기합니다. 이를 위해 사용하는 Receive 셰이프 인 OrderRequest도 FromBrokerPort를 사용합니다. 반복 내의 같은 포트에서 두 번째 수신 셰이프를 사용하고 여기에 상관 관계 집합을 조합하면 일반적인 BizTalk Server 패턴인 호위(convoy) 패턴이 형성됩니다. 호위(convoy) 패턴을 사용하면 같은 오케스트레이션 인스턴스가 특정 작업에 연결된 첫 번째 및 후속 메시지를 처리하도록 할 수 있습니다.
주문 관리자는 주문에 연결된 첫 메시지를 받으면 두 상관 관계 집합을 초기화합니다. 첫 번째 OrderCorrelation은 고객 ID(CustID) 및 OrderID(주문 ID)를 사용합니다. 주문 관리자는 이 상관 관계를 주문 처리 단계와 공유합니다. 두 번째 상관 관계는 고객 ID 및 주문 ID 외에도 주문 상태(상태)를 사용하는 호송 상관 관계인 OrderConvoyCorrelation입니다. OrderRequestReceive 셰이프는 OrderConvoyCorrelation을 다음 상관 관계 집합으로 사용합니다. 이러한 방식으로 상관 관계 집합을 설정하면 특정 주문에서 작업 중인 주문 관리자 인스턴스가 모든 변경 내용을 받을 수 있습니다.
참고
상관 관계 집합은 메시지가 지정된 오케스트레이션 인스턴스에 속하는지 여부를 확인하는 데 사용되는 메시지 속성의 그룹입니다. 자세한 내용은 오케스트레이션에서 상관 관계 사용을 참조하세요.
OrderManager가 주문에 대한 후속 메시지를 받으면 먼저 요청 유형을 테스트합니다. 요청 유형이 TERMINATE이면 판단 셰이프가 종료 분기를 실행하고, 그렇지 않으면 오케스트레이션에서 새 메시지가 업데이트인지 확인하기 위해 새 메시지를 테스트합니다. 업데이트 메시지에는 원래 요청보다 시퀀스 번호(SeqNum)가 더 높습니다. 새 메시지의 일련 번호가 원래 요청보다 더 크면 오케스트레이션은 새 메시지에 대한 주문 처리를 시작합니다. 업데이트 메시지의 일련 번호가 원래 메시지와 같거나 더 작으면 시퀀스 오류가 발생합니다. 일련 번호가 같은 경우 중복 주문이므로 중복 오류 플래그가 지정됩니다.
SeqNum에 대한 자세한 내용은 키 메시지 및 필드를 참조하세요.
최종 단계
루프를 종료한 후 주문 관리자는 동적 포트 CSRCompletionPort에 회신 주소를 할당합니다. 완료 상태 메시지를 생성해 보낸 다음 오류가 있는지 테스트합니다. 오류가 있는 경우 오케스트레이션은 종료 셰이프를 실행하고 그렇지 않으면 오케스트레이션이 종료됩니다.
단계 조정
OrderBroker 오케스트레이션과 두 번째 처리 단계 오케스트레이션(CableOrder2)은 모두 기록 데이터베이스에 항목을 만듭니다. CableOrder2 오케스트레이션은 OrderBroker 오케스트레이션에서 입력한 기록 정보를 업데이트합니다. 업데이트할 데이터베이스에 항목이 있는지 확인하기 위해 OrderBroker 는 데이터베이스에 사용하는 포트에서 배달 알림을 사용합니다.
구성은 기록 데이터베이스의 OrderBroker 송신 포트를 테스트 구성용 포트(HistoryInsert-Test-SP)에 대한 포트 1개(HistoryInsert-Test-SP)를 포함하는 송신 포트 그룹에 매핑합니다(HistoryInsert-SP). 그룹에서 두 포트를 모두 활성 상태로 유지하면 솔루션이 두 포트에서 모두 메시지를 보냅니다. 따라서 요청되는 배달 알림은 두 개이지만 처리되는 알림은 하나뿐입니다.
이러한 상황을 방지하려면 테스트 포트(HistoryInsert-Test-SP)의 목록을 해제하거나 애플리케이션의 테스트 버전을 중지합니다. 배달 알림에 대한 자세한 내용은 승인 사용을 참조하세요.
오류 및 라우팅 복구 메시지 - 디자인 선택 사항
주문 처리 단계에서 사용하는 예외 처리기 오케스트레이션 및 오케스트레이션은 오류 처리 오케스트레이션(ErrorHandlerOrch)을 사용하여 잘못된 복구 주문을 라우팅합니다. 솔루션은 필요한 형식으로 주문을 수정하는 부서나 그룹이 있다는 가정 하에 디자인됩니다. 복구된 주문은 Order Broker 오케스트레이션(OrderBroker)을 통해 다시 제출되지 않습니다. 정규화된 주문이 정규화된 형식으로 복구됩니다. 현재 솔루션 디자인에서는 핸들러 오케스트레이션이 오류 메시지를 원래 주문의 출처로 다시 라우팅합니다. 그러나 복구된 주문은 오류 핸들러 오케스트레이션의 MSMQ 포트로 라우팅해야 합니다. (솔루션의 테스트 버전은 파일 폴더를 사용합니다.) 그런 다음 오류 처리기는 복구된 메시지를 호출 오케스트레이션에 반환합니다.
이 솔루션에서 이러한 디자인을 사용하는 이유는 주문 브로커가 주문 메시지의 중요한 유효성 검사 및 정규화를 수행하기 때문입니다. 또한 복구해야 하는 주문 메시지 역시 정규화된 형식입니다. 메시지의 정규화된 형식을 유지 관리하면 전송된 메시지 형식과 정규화된 메시지 형식 간의 차이를 해결할 필요가 없습니다.