메시지 처리
이제까지 설명한 모든 구성 요소는 메시지가 BizTalk Server를 통해 전달될 때 메시지 처리 작업에 참여합니다. 이 섹션에서는 이러한 구성 요소가 기능적으로 서로 상호 작용하는 방법에 대해 메시지 수신을 시작으로 자세히 설명합니다. 다음 그림은 수신 포트의 구성과 수신 프로세스를 통한 메시지 흐름을 보여 줍니다.
수신 포트 는 하나 이상의 수신 위치와 0개 이상의 맵으로 구성됩니다. 맵은 XML 메시지를 다른 구조나 형식으로 변환하는 데 사용되는 XSLT(Extensible Stylesheet Language Transformations) 스타일시트이며 메시지를 내부 형식으로 정규화하기 위해 수신 프로세스에 사용되는 경우가 많습니다. 수신 위치는 메시지를 받는 엔드포인트를 제어합니다. 수신 위치는 수신 어댑터의 엔드포인트 구성과 수신 파이프라인으로 구성됩니다.
어댑터의 역할
수신 어댑터는 데이터 스트림을 읽고 메시지를 만들어 메시지 수신 프로세스를 시작합니다. 예를 들어 FILE 어댑터는 파일이 해당 구성 위치에 저장되었음을 확인하고 스트림에서 해당 파일을 읽습니다. 이 어댑터는 메시지를 만들고(Microsoft.BizTalk.Message.Interop.IBaseMessage 인터페이스의 구현), 해당 메시지에 파트를 추가하고(Microsoft.BizTalk.Message.Interop.IBasePart 인터페이스의 구현), 데이터 스트림을 파트 콘텐츠로 제공합니다.
또한 이 어댑터는 위치, 어댑터 유형 및 기타 어댑터 관련 사항과 연관된 메시지 컨텍스트 속성에 쓰고 이 속성을 승격시킵니다. 메시지와 해당 컨텍스트를 만든 다음 이 어댑터는 해당 메시지를 엔드포인트 관리자로 전달합니다. 그러면 메시지가 수신 위치에 대해 구성된 수신 파이프라인을 통해 처리됩니다. 메시지가 파이프라인에 의해 처리된 다음에는 엔드포인트 관리자가 메시지 에이전트를 사용하여 메시지를 게시하기 전에 맵을 사용하여 해당 메시지를 원하는 형식으로 변환할 수 있습니다.
파이프라인의 역할
초기 메시지를 만드는 것은 어댑터이지만 수신된 메시지에 수행되는 대부분의 처리 작업은 수신 파이프라인에서 발생합니다. 파이프라인은 메시지 콘텐츠뿐만 아니라 메시지 컨텍스트도 처리합니다. 메시지 콘텐츠는 일반적으로 디코딩, 디스어셈블 및 유효성 검사 단계에서 처리되는 반면 메시지 컨텍스트는 모든 단계에서 처리될 수 있습니다. 그러나 파이프라인이 콘텐츠나 컨텍스트에 대한 작업을 반드시 수행해야 하는 것은 아닙니다. 예를 들어 기본 통과 파이프라인에는 구성된 구성 요소가 없으며 메시지 콘텐츠나 메시지 컨텍스트에 아무런 처리 작업도 수행하지 않습니다. 이해를 돕기 위해 이 문서에서는 일반적으로 메시지 라우팅에 가장 큰 영향을 미치는 디스어셈블 구성 요소를 중점적으로 다룹니다.
디스어셈블러 는 어댑터에서 들어오는 메시지를 처리하고, 해당 메시지를 여러 메시지로 디스어셈블하고, 메시지 데이터를 구문 분석하는 작업을 수행합니다. 들어오는 메시지에 더 작은 메시지가 여러 개 포함되어 있는 경우 이를 교환이라고 합니다. Flat File Disassembler 및 XML Disassembler는 모두 개발자가 래핑 콘텐츠(Flat File Disassembler에 대한 헤더 스키마 및 후행 스키마와 XML Disassembler에 대한 봉투(Envelope) 스키마) 및 반복될 가능성이 있는 본문 콘텐츠에 대한 정보를 구성할 수 있도록 허용하여 교환을 처리합니다. 또한 이러한 디스어셈블러는 모두 원본 메시지를 XML 콘텐츠로 구문 분석합니다. 사용자 지정 디스어셈블러는 BizTalk Server에서 XML을 추가적으로 처리할 필요가 없을 경우 콘텐츠를 XML로 구문 분석하지 않을 수 있습니다. 예제 시나리오에서는 특정 수신 위치에서 시스템으로 들어가는 메시지가 매핑이나 기타 XML 기반 처리 없이 특정 송신 포트로 전송되는 단순한 라우팅 상황을 보여 줄 수 있습니다.
메시지 유형이 있는 라우팅
라우팅에 사용되는 가장 일반적인 메시지 속성 중 하나는 메시지 유형입니다. 개발자가 메시지 구조를 정의하는 스키마를 만드는 경우 이 스키마는 해당 메시지의 메시지 유형을 정의합니다. 메시지 유형은 스키마 정의에 있는 루트 노드 및 네임스페이스에 의해 결정됩니다. 예를 들어 다음과 같은 XML 문서에는 메시지 형식이 있습니다. http://tempuri.org/samples/MessageType#Message
<Message xmlns=http://tempuri.org/samples/MessageType>
<SomeOtherElement type="sample"/>
</Message>
라우팅에 메시지 유형을 사용하려면 해당 유형을 컨텍스트로 승격시켜야 합니다. 디스어셈블러를 사용하면 이 값을 메시지 컨텍스트로 승격시킬 수 있을 뿐만 아니라 메시지 구조에 대한 가장 명확한 정보가 있는 파이프라인 구성 요소로도 승격시킬 수 있습니다. XML Disassembler 및 Flat File Disassembler는 메시지를 처리할 때 메시지 유형을 승격시킵니다. 모든 사용자 지정 디스어셈블러에서도 적절한 라우팅을 위해 이 속성을 승격시켜야 합니다.
메시지에는 유형을 지정할 필요가 없습니다. 앞에서 언급했듯이 메시지 파트는 임의의 이진 데이터일 수 있으며 해당 구조를 정의하는 스키마를 가질 필요가 없습니다. 사용자 지정 파이프라인 구성 요소, 어댑터 또는 오케스트레이션에서 호출된 코드가 이러한 유형의 메시지 파트와 상호 작용할 수도 있지만 일반적으로 이러한 파트는 BizTalk Server에 의해 거의 처리되지 않은 채로 BizTalk Server를 통해 전달됩니다.
어댑터와 같은 파이프라인 구성 요소도 속성을 메시지 컨텍스트에 쓰고 승격시킵니다. 실제로 파이프라인 구성 요소는 대부분의 개발자가 속성을 메시지 컨텍스트로 가져오기 위해 가장 많이 사용하는 메커니즘입니다. 개발자는 스키마를 만들고 스키마에 있는 속성을 승격시킬 수 있습니다. 이 정보는 파이프라인 구성 요소가 사용할 수 있는 주석으로 스키마에 저장됩니다. FlatFile, XML 및 BizTalk Framework와 같은 모든 기본 제공 디스어셈블러 및 어셈블러 구성 요소는 문서 스키마를 사용하여 승격될 속성에 대한 정보를 검색합니다. 디스어셈블러는 주석의 XPath(XML Path Language) 문을 사용하여 문서에서 승격될 요소의 위치를 파악합니다. 문서를 스트리밍하는 동안 디스어셈블러는 XPath 문 중 하나와 일치하는 요소를 찾고 해당 값을 적절하게 컨텍스트에 쓰거나 승격시킵니다.
송수신된 메시지에 있는 임의의 데이터에 대한 컨텍스트로 속성을 가져오는 작업을 처리하기 위해 사용자 지정 파이프라인 구성 요소를 작성할 수도 있습니다. 속성을 컨텍스트로 승격시키고 라우팅에 유용하도록 만들려면(값을 승격시키는 이유) 속성에 대한 정의가 있는 속성 스키마를 만들고 BizTalk Server에 배포해야 합니다. 사용자 지정 구성 요소에서 사용할 속성 스키마를 정의하기 전에는 승격 속성의 여러 유형에 대해 알고 있어야 합니다. 속성 스키마에 정의된 승격 속성은 다음과 같은 두 가지 기본 유형 중 하나일 수 있습니다.
Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase
기본 유형이 MessageDataPropertyBase인 속성의 경우 속성 값이 메시지 콘텐츠에서 도출됩니다. 이 유형은 속성 스키마에 정의된 속성의 기본 값이며 가장 많이 사용됩니다. MessageContextPropertyBase는 메시지 컨텍스트 파트용으로 만들어졌지만 메시지 데이터에서 직접 도출되지 않을 수 있는 속성을 나타냅니다. 기본 유형이 MessageContextPropertyBase인 속성은 어댑터와 디스어셈블러에 의해 승격되는 경우가 많으며 메시지 유형 및 어댑터 유형과 같은 공용 속성을 포함합니다.
여러 유형을 이해하여 속성을 정의할 때 이러한 유형을 적절하게 사용하는 것이 중요합니다. 오케스트레이션에서 메시지의 컨텍스트 속성에 액세스할 때는 가장 중요한 영향을 미치는 사항 중 하나가 발생합니다. 속성이 MessageDataPropertyBase로 식별될 경우 오케스트레이션 디자이너는 수신하는 메시지의 스키마를 검사하여 일치하는 승격 속성을 정의하는지 확인합니다. 액세스하는 승격 속성에 연결된 스키마에 속성이 없는 경우에는 해당 속성에 액세스할 수 없습니다. 반면 속성이 MessageContextPropertyBase로 정의된 경우 메시지 유형은 중요하지 않으며 해당 속성에 액세스할 수 있습니다.
사용자 지정 파이프라인에서 속성을 컨텍스트에 쓰거나 승격시키는 메커니즘은 매우 유사합니다. 속성을 쓰려는 경우 IBaseMessageContext Write 메서드를 호출하여 컨텍스트에 값을 저장합니다. 승격 속성의 경우에는 IBaseMessageContext Promote 메서드를 대신 사용합니다. 이러한 메서드 각각에는 속성 이름, 네임스페이스 및 값이 사용됩니다. 승격 속성의 경우 이름 및 네임스페이스는 속성 스키마에 정의된 속성의 이름 및 네임스페이스이며 속성 스키마 어셈블리를 참조하고 해당 속성에 대해 만들어진 클래스의 속성을 사용하여 가장 쉽게 액세스할 수 있습니다. 고유 필드는 공통 네임스페이스 를
http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields사용하며 값을 검색하는 데 사용되는 XPath 식은 일반적으로 이름으로 사용됩니다.아래 코드는 속성을 컨텍스트에 쓰고 승격시키는 작업 모두의 예를 보여 줍니다. 이 예에서는 고유 필드를 컨텍스트에 씁니다. 이는 오케스트레이션 디자이너가 고유 필드를 파악할 수 있도록 메시지 스키마가 해당 필드를 식별하는 오케스트레이션의 경우에만 유용합니다. 수신 또는 송신하는 쪽에서 다른 파이프라인 구성 요소가 사용할 수 있도록 컨텍스트에 속성을 쓰면 유용할 수 있습니다.
//create an instance of the property to be promoted
SOAP.MethodName methodName = new SOAP.MethodName();
//call the promote method on the context using the property class for name
//and namespace
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,
"theSOAPMethodName");
//write a distinguished field to the context
pInMsg.Context.Write("theDistinguishedProperty",
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",
"theDistinguishedValue");
값을 컨텍스트에 쓰거나 승격시킬 때는 다음 사항에 유의하십시오.
이전에 속성을 승격시키는 데 사용한 것과 동일한 이름 및 네임스페이스를 사용하여 컨텍스트에 값을 쓰면 해당 속성이 더 이상 승격되지 않습니다. 즉, 쓰기 작업이 승격을 덮어씁니다.
컨텍스트에 Null 값을 쓰면 Null 값 속성이 허용되지 않으므로 해당 값이 삭제됩니다.
승격 속성의 길이는 256자로 제한되지만 직접 쓴 속성에는 길이 제한이 없습니다.
승격 속성은 메시지 라우팅에 사용되며 비교 및 스토리지 작업의 효율성을 위해 크기가 제한됩니다. 직접 쓴 속성에는 고정된 크기 제한이 없지만 컨텍스트에 너무 큰 값을 사용하는 경우 해당 값도 처리되고 메시지와 함께 전달되어야 하므로 성능에 영향을 미치게 됩니다.
메시지를 BizTalk Server에서 보낼 준비가 되면 송신 포트에서 해당 메시지에 보완 프로세스를 수행합니다. 송신 파이프라인이 실행되기 전에 맵이 메시지에 적용되므로 파이프라인에 의해 처리되고 어댑터를 통해 전송되기 전에 메시지를 고객 또는 애플리케이션별 형식으로 변환할 수 있습니다. 송신 파이프라인에서는 속성이 메시지 컨텍스트로 승격되는 대신 컨텍스트에서 메시지로 강등(demotion)됩니다.
