지금까지 설명한 모든 구성 요소는 BizTalk Server를 통해 전달되는 메시지 처리에 중요한 역할을 합니다. 이 섹션에서는 메시지 수신부터 이러한 구성 요소가 기능적으로 상호 작용하는 방법에 대해 자세히 설명합니다. 다음 그림에서는 수신 포트의 구성 및 수신 프로세스를 통해 메시지의 흐름을 보여줍니다.
수신 포트는 하나 이상의 수신 위치와 0개 이상의 맵으로 구성됩니다. 맵은 XML 메시지를 한 구조 또는 형식에서 다른 구조로 변환하는 데 사용되는 XSLT(Extensible Stylesheet Language Transformations) 스타일시트이며 수신 프로세스에서 메시지를 내부 형식으로 정규화하는 데 자주 사용됩니다. 수신 위치는 메시지를 받는 엔드포인트를 제어합니다. 수신 위치는 수신 어댑터에 대한 엔드포인트 구성과 수신 파이프라인으로 구성됩니다.
어댑터의 역할
수신 어댑터는 데이터 스트림을 읽고 메시지를 만들어 메시지를 받는 프로세스를 시작합니다. 예를 들어 파일 어댑터는 파일이 구성된 위치에 배치된 것을 확인하고 스트림에서 해당 파일을 읽습니다. 어댑터는 메시지(Microsoft.BizTalk.Message.Interop.IBaseMessage 인터페이스의 구현)를 만들고, 파트(Microsoft.BizTalk.Message.Interop.IBasePart 인터페이스의 구현)를 추가하고, 데이터 스트림을 파트 콘텐츠로 제공합니다.
또한 어댑터는 위치, 어댑터 유형 및 어댑터와 관련된 기타 속성을 메시지 컨텍스트에 기록하고 홍보합니다. 메시지와 해당 컨텍스트를 만든 후 어댑터는 메시지를 Endpoint Manager에 전달합니다. 그러면 메시지가 수신 위치에 대해 구성된 수신 파이프라인을 통해 처리됩니다. 파이프라인에서 메시지를 처리한 후에는 Endpoint Manager가 메시지 에이전트를 사용하여 메시지를 게시하기 전에 맵을 사용하여 메시지를 원하는 형식으로 변환할 수 있습니다.
파이프라인의 역할
초기 메시지를 만드는 어댑터이지만 수신된 메시지에서 발생하는 대부분의 처리는 수신 파이프라인에서 발생합니다. 파이프라인 처리는 메시지 콘텐츠와 메시지 컨텍스트를 처리합니다. 메시지 콘텐츠는 일반적으로 디코딩, 디스어셈블 및 유효성 검사 단계에서 처리되지만 메시지 컨텍스트는 모든 단계에서 처리될 수 있습니다. 그러나 파이프라인이 반드시 콘텐츠 또는 컨텍스트에서 작동하는 것은 아닙니다. 예를 들어 기본 통과 파이프라인에는 구성 요소가 구성되지 않으며 메시지 콘텐츠 또는 컨텍스트에 대한 처리를 수행하지 않습니다. 간단히 하기 위해 이 문서에서는 일반적으로 메시지 라우팅에 가장 큰 영향을 주므로 디스어셈블 구성 요소에 중점을 둡니다.
디스어셈블러의 작업은 어댑터에서 들어오는 메시지를 처리하고 여러 메시지로 디스어셈블하고 메시지 데이터를 구문 분석하는 것입니다. 들어오는 메시지에 더 많은 작은 메시지가 있는 경우 이를 교환이라고 합니다. 플랫 파일 디스어셈블러와 XML 디스어셈블러는 모두 개발자가 래핑 콘텐츠(즉, 플랫 파일 디스어셈블러의 헤더 및 후행 스키마 및 XML 디스어셈블러에 대한 봉투 스키마) 및 (잠재적으로 반복되는) 본문 콘텐츠에 대한 정보를 구성할 수 있도록 하여 교환을 처리합니다. 또한 이러한 두 디스어셈블러는 원본 메시지를 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 및 플랫 파일 디스어셈블러는 메시지를 처리할 때 메시지 유형을 승격하고, 사용자 지정 디스어셈블러도 적절한 라우팅을 보장하기 위해 이 속성을 승격해야 합니다.
메시지에 형식이 필요하지 않다는 점에 유의해야 합니다. 앞에서 설명한 것처럼 메시지 부분은 모든 이진 데이터일 수 있으며 해당 구조를 정의하는 스키마가 필요하지 않습니다. 이러한 유형의 메시지 파트는 일반적으로 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에서 메시지를 보낼 준비가 되면 송신 포트에서 보완 프로세스를 거칩니다. 맵은 송신 파이프라인이 실행되기 전에 메시지에 적용되므로 파이프라인에서 처리되고 어댑터를 통해 전송되기 전에 메시지를 고객 또는 애플리케이션별 형식으로 변환할 수 있습니다. 송신 파이프라인에서 속성을 메시지 컨텍스트로 승격하는 대신 속성이 컨텍스트에서 메시지로 강등됩니다.
