어댑터 디자인 팁
이 섹션에서는 어댑터 개발자가 어댑터를 디자인하는 동안 얻은 힌트와 팁을 제공합니다.
기본 구성으로 사용하는 경우 핸들러 속성이 문자열이어야 함
위치에서 값이 설정되지 않은 경우 런타임은 처리기에서 설정된 값을 자동으로 사용하므로 XSD에서 생성된 처리기 속성 시트의 속성을 해당 Location 속성의 기본값으로 사용하는 것이 매력적으로 보입니다. 그러나 이 작업은 몇 가지 문제로 인해 유용성이 떨어집니다.
런타임에 제공되는 값의 재정의 여부를 알 수 없다는 점에서 문제가 발생합니다. 이 작업을 수행하는 일반적인 방법은 값에 NULL을 정의한 다음 해당 값에 대해 테스트를 실행하는 것입니다. BizTalk Server에서 XSD 기반 속성 시트를 사용할 때의 문제는 NULL이 문자열에 대해서만 지원된다는 것입니다. 이 NULL 테스트를 통해 어댑터에서 기본 설정을 사용하려고 하고 어댑터를 문자열 유형으로 제한해도 비정상적인 사용자 인터페이스에 노출됩니다.
XSD 생성 속성 시트는 속성을 마우스 오른쪽 단추로 클릭하여 속성의 설정을 NULL로 다시 설정하는 것만 지원합니다. 이때 nullify? 상황에 맞는 메뉴가 나타나고 속성을 NULL로 설정할 수 있습니다. 속성이 NULL인지 여부에 대한 시각적 피드백은 없습니다.
스키마 생성 마법사 구현 시 고려할 사항
프로그래머는 강력한 형식의 개체 모델에 대해 코딩하려고 합니다. 처음에는 코드에서 XML을 조작하는 것이 어렵고 오류가 발생하기 쉬워 보일 수 있습니다. 그러나 몇 가지 트릭을 알고 .NET Framework에서 제공하는 지원을 현명하게 사용하면 문제가 훨씬 간단해집니다.
문자열 연결을 사용하여 XML 문서를 만들지 않음
XML에서 발생하는 최대 실수 중 하나는 문자열 연결을 통해 XML을 생성하고 메모리에 문을 출력하는 것입니다. 이렇게 하면 많은 양의 CPU 시간과 메모리가 사용됩니다. 가장 사소한 XML 조각에 대해서도 XmlWriter 또는 DOM(Document Object Model)과 같은 도구를 사용하는 것이 더 쉽습니다. XmlWriter를 사용하는 경우 문서 상태가 손실되므로 원시 쓰기 기능을 사용하지 마십시오.
런타임에는 DOM과 관련된 많은 메모리 사용량 문제로 인해 XML DOM보다 XmlWriter를 사용하는 것이 좋습니다. 그러나 구성 또는 디자인 타임에는 많은 메모리 사용량이 문제가 되지 않습니다. DOM을 사용하면 유용한 추가 도구가 될 수 있는 XPATH 쿼리 사용이 편리합니다.
XML 문서의 골격을 리소스로 정의
디자인 도구에서 큰 XML 문서를 생성하고 있으며 생성된 해당 문서가 항상 동일한 기본 구조를 따르는 경우 편집이 필요할 때 변경할 수 있도록 전체 기본 XML 파일을 프로젝트에 리소스로 배치합니다.
코드를 DOM에 로드한 다음 XPATH를 사용하여 코드를 추가할 노드를 선택함으로써 문서 골격에 필요한 내용을 추가합니다. 이 경우 WSDL(웹 서비스 기술 언어) 파일을 만듭니다. 마법사는 기본 WSDL 파일을 리소스에 저장하고 생성된 XSD(XML 스키마 정의) 자식 파트를 추가합니다. 또한 selectNode에 xpath를 사용하여 올바른 부모를 찾습니다. 이는 사용자 인터페이스 코드이므로 성능이 문제가 되지 않으며 결과로 생성된 구현이 깔끔하고 강력하며 유지 가능합니다.
BizTalk 파이프라인에 처리 단계 배치
일반적으로 Microsoft에서 개발된 어댑터는 메시지 형식 기반의 처리를 어댑터에서 BizTalk 파이프라인으로 이동합니다. 예를 들어 구조화된 비-XML 데이터 소스에 대한 어댑터가 있습니다.
이 경우 어댑터는 데이터를 가져오기만 하고 BizTalk 파이프라인에서 데이터를 구문 분석하고 해당 XML로 변환합니다. 이렇게 하면 파이프라인 구성 요소 자체가 재사용 가능한 아키텍처 부분이 되는 이점이 있습니다.
어댑터 동작을 구성 가능하게 설정
MQSeries 어댑터 베타 프로그램에서 얻은 교훈 중 하나는 모든 고객이 동일한 동작에 만족하지는 않는다는 것입니다. 이는 특히 오류 처리와 정렬의 경우에서 확실하게 드러납니다. 솔루션은 동작을 구성 가능하게 설정하는 것입니다. 어댑터의 정렬 지원 여부, 실패를 일시 중단된 큐로 이동할지 여부 또는 실패 시 어댑터의 처리를 중지하고 어댑터 자체를 해제할지 여부를 지정할 수 있습니다. 이러한 동작을 구성 가능하게 설정하면 고객이 BizTalk Server 외부에서 복잡한 오케스트레이션이나 스크립트를 작성하여 동일한 결과를 얻어야 하는 경우 훨씬 편리할 수 있습니다.
메시지 큐와의 상관 관계 지원
많은 메시징 플랫폼이 응용 프로그램 수준의 요청-응답 시나리오를 지원하기 위해 메시지 헤더의 상관 관계 ID를 지원합니다. 예를 들어 MQSeries, MSMQ, SQL Service Broker 등이 있습니다. 외부 메시징 시스템의 요청-응답 패턴을 BizTalk Server의 송신-응답 어댑터에 매핑하는 것이 편리해 보일 수 있습니다. 그러나 트랜잭션이 있는 위치 때문에 이 작업은 올바르지 않습니다. 특히 외부 메시징 시스템에 송신하는 경우 트랜잭션 커밋을 수행해야만 큐의 반대쪽 끝에 데이터가 표시됩니다. 또한 수신이 별도 트랜잭션이어야 합니다.
BizTalk Server의 솔루션은 다음과 같습니다.
오케스트레이션에서 상관 관계 집합 사용
두 개의 개별 포트를 구성합니다. 하나는 송신용이고 다른 하나는 수신 포트에 대해 구성됩니다.
단순한 경우에서는 오케스트레이션이 어댑터에 의해 메시지와 연결되는 상관 관계 ID를 지정합니다. 이 ID는 메시지의 컨텍스트 속성으로 어댑터에 전달됩니다. 더 복잡한 경우 시나리오에서는 외부 메시징 시스템이 ID를 할당하도록 요구합니다. 이 경우 응답 메시지를 사용하여 송신 포트에서 오케스트레이션으로 다시 전달할 수 있습니다. 이 응답 메시지는 ID를 다시 전달하기 위한 것이며 실제 메시지 응답이 아닙니다.
참고
오케스트레이션 엔진에는 메시지에 대한 실제 응답이 송신의 ID 응답보다 우선할 수 있도록 하는 경합 상태가 있습니다. 이 경합 상태는 오케스트레이션 자체에서 처리되어야 합니다.