BizTalk Server 메시지
BizTalk Server 핵심은 메시지 처리 엔진입니다. BizTalk Server 세부 정보를 이해하려면 메시지와 메시지가 BizTalk Server 표현, 저장 및 처리되는 방식을 이해하는 것이 중요합니다. 메시지가 무엇인지 이해하고 나면 BizTalk Server에서 메시지가 사용되는 방법에 대한 자세한 내용을 더 쉽게 이해할 수 있습니다.
BizTalk Server의 각 메시지는 다중 파트 메시지로 간주되고 0개 이상의 파트로 구성됩니다. 하나 이상의 파트를 가진 각 메시지는 이러한 파트 중 하나가 본문으로 식별됩니다. 각 파트는 XML 문서, 플랫 파일, serialize된 .NET 클래스 또는 다른 이진 데이터 스트림을 나타낼 수 있는 데이터의 이진 청크로 구성됩니다. 메시지의 본문을 사용하여 라우팅에 사용할 수 있는 메시지의 유형을 식별합니다.
이해해야 할 매우 중요한 개념은 모든 메시지가 BizTalk Server 변경할 수 없다는 것입니다. 이는 메시지가 생성된 후에 변경할 수 없다는 것을 의미합니다. 메시지는 MessageBox 데이터베이스에 메시지를 저장한 다음에 생성된 것으로 간주됩니다. 메시지를 변경하는 경우 변경 이후에 사용할 새 메시지를 만들어야 합니다. 특히, 컴파일 규칙에 따라 메시지를 사용하기 전에 메시지 생성에 대한 엄격한 지침을 따라야 하며 생성 블록 외부에서 메시지 변경이 허용되지 않은 오케스트레이션 디자이너에 이러한 요구 사항이 반드시 적용되어야 합니다. 메시지를 변경해야 할 경우 동일한 유형의 메시지를 만드는 새 생성 블록을 만들고 원본 메시지를 새 메시지에 복사한 다음 생성 블록을 벗어나기 전에 새 메시지를 변경해야 합니다.
메시지 속성
메시지를 구성하는 부분 외에도 시스템의 각 메시지에는 메시지 컨텍스트라고 하는 속성 집합이 있습니다. 이러한 속성은 메시지 자체에서 추출되었거나 메시지 자체와 관련된 값일 수 있습니다. 예를 들어 어댑터는 메시지가 수신된 위치 및 메시지를 수신하는 데 사용되는 어댑터 유형과 같이 메시지 수신과 관련된 속성을 컨텍스트에 포함합니다. 속성을 컨텍스트에 기록하거나 컨텍스트로 승격할 수 있습니다. 이러한 두 옵션의 차이는 승격 속성을 메시지 라우팅에서 조건으로 사용할 수 있는 것과 달리 기록된 속성은 사용할 수 없다는 점입니다.
값을 컨텍스트에 기록하거나 승격하는 이 개념은 BizTalk 편집기에서 속성을 승격하는 것과 관련되지만 동일하지는 않습니다. BizTalk 편집기에서 스키마의 요소나 특성을 승격 속성 또는 고유 필드로 플래그 지정할 수 있습니다. 메시지 스키마에서 PropertyField 주석으로 표시된 항목으로 인해 파이프라인 디스어셈블러가 컨텍스트에 승격 속성을 설정하게 됩니다. 또한 메시지 스키마에서 DistinguishedField 주석으로 표시된 항목으로 인해 파이프라인 디스어셈블러가 컨텍스트에 기록된 속성을 설정하게 됩니다.
승격된 속성에 대한 디자인은 메시지 상관 관계 디자인에서 시작되었습니다. 수신되는 메시지를 이미 실행 중인 오케스트레이션 instance 연결하는 기능입니다. 상관 관계를 위해 오케스트레이션의 메시지 사이에 링크를 제공하는 속성 또는 속성 집합을 정의해야 합니다. 예를 들어 구매 프로세스에서는 PurchaseOrderID를 기준으로 메시지의 상관 관계를 지정해야 합니다. 그러나 대부분의 비즈니스 사례에서 메시지에 있는 특정 필드 또는 특성의 이름이 일치하지 않을 수 있습니다. 구매 주문서 스키마는 POId라는 요소를 가지지만 해당 구매서 스키마는 OrderID라는 요소를 가질 수 있습니다. 이 상황에서 PurchaseOrderID와 같은 명명된 속성에 메시지의 상관 관계를 지정하려면 개발자는 상관 관계를 지정하려는 속성의 이름을 값 소스에서 추출할 수 있어야 합니다. 속성 스키마는 이 추상화를 지원합니다.
속성 스키마를 사용하면 공통 위치에서 승격된 속성을 정의하고 다른 스키마에서 참조하도록 할 수 있습니다. 다른 스키마와 마찬가지로 속성 스키마에 네임스페이스가 있지만 이와는 달리 레코드 또는 특성이 아닌 정의된 요소만 가질 수도 있습니다. 속성 스키마에 정의된 각 요소에는 이름과 유형이 있습니다. 속성 스키마를 둘 이상의 스키마에서 참조해야 할 수 있고 속성 스키마의 정보를 런타임 시 구성 요소에서 사용할 수 있어야 하므로 속성 스키마는 다른 모든 스키마와 마찬가지로 BizTalk Server에 배포되어야 합니다. 일반적인 스키마 배포 단계 외에도 승격된 속성에 대한 정보가 추출되어 관리 데이터베이스의 bt_documentSpec 테이블에 저장됩니다.
속성 스키마가 생성된 후에 동일한 유형(예: 정수)의 요소와 특성을 속성 스키마에서 명명된 속성 중 하나로 승격할 수 있습니다.
위의 예제 사례를 완료하기 위해 개발자는 다음 단계를 수행하여 상관 관계에 필요한 공유 속성을 정의합니다.
속성 스키마를 만들고 PurchaseOrderId라는 xs:int 유형의 요소를 정의합니다.
PurchaseOrder 스키마를 만들고 POId라는 xs:int 유형의 요소 또는 특성을 추가합니다.
개발자는 BizTalk 편집기에서 승격 표시 명령을 사용하여 POId 필드를 승격 속성 목록에 추가하고 목록에서 PurchaseOrderId라는 명명된 속성을 선택하여 속성 스키마에 정의된 PurchaseOrderId 속성으로 승격되어야 한다는 것을 표시합니다.
구매서 스키마를 만들고 OrderId라는 xs:int 유형의 요소 또는 특성을 추가합니다.
개발자는 BizTalk 편집기에서 승격 표시 명령을 사용하여 OrderId 필드를 승격 속성 목록에 추가하고 목록에서 PurchaseOrderId라는 명명된 속성을 선택하여 속성 스키마에 정의된 PurchaseOrderId 속성으로 승격되어야 한다는 것을 표시합니다.
이제 이 정의가 문서 스키마에 존재하므로 파이프라인 구성 요소는 OrderId 및 POId를 명명된 속성 PurchaseOrderID로 올바르게 승격하여 라우팅 및 상관 관계에 사용하도록 할 수 있습니다. 이 승격 프로세스에 대한 자세한 내용은 이 문서의 "메시지 처리" 항목을 참조하십시오.
승격된 속성의 이점 중 하나는 승격되는 요소의 값을 메시지 컨텍스트에서 사용할 수 있다는 점입니다. 이는 메시지를 메모리에 로드하여 메시지에서 XPath 문을 실행할 필요가 없으므로 해당 값을 검색하는 데 비용이 적게 든다는 것을 의미합니다. 대신 간단한 PropertyBag을 키와 함께 사용하여 값을 가져올 수 있습니다. 이 유형의 동작은 메시지 라우팅 이외의 상황에 적절한 동작으로 고유 필드를 만드는 이유가 됩니다. 승격 속성이 메시지 컨텍스트에 승격되지만 고유 필드는 메시지 컨텍스트에 기록됩니다. 그러나 승격 속성과 달리 고유 필드를 위한 속성 스키마가 없습니다. 이는 고유 필드를 라우팅에 사용할 수 없으므로 송신 포트 또는 오케스트레이션 수신 셰이프에서 필터 조건으로 사용할 수 없습니다. 그러나 메시지를 메모리에 로드하고 값을 추출하는 대신 고유 필드를 오케스트레이션에서 사용하여 메시지 컨텍스트에서 값을 읽거나 쓸 수 있습니다.
속성을 메시지 컨텍스트에 승격하거나 기록하는 것 외에도 메시지 조건부를 컨텍스트에 추가할 수 있습니다. 메시지 조건부는 BizTalk Server에서 보안 조치로 사용되며 메시지가 라우팅되는 모든 호스트에 지정된 값과 일치해야 하는 메시지에 대한 컨텍스트 정보를 제공합니다. 이 보안 조치를 사용하면 특정 메시지를 수신 및 처리할 수 있는 호스트로만 특정 호스트를 허용하는 방식으로 BizTalk Server 환경을 구성할 수 있습니다. 예를 들어 BizTalk Server 관리 콘솔에서 메시지 디코딩 및 암호 해독에 사용할 인증서의 손 도장(Thumbprint)과 함께 호스트를 구성할 수 있습니다. 이 속성을 구성하면 MessageBox에서 해당 호스트에 대한 응용 프로그램 속성이 생성됩니다. 그런 다음 이 손 도장을 사용하여 수신 및 암호 해독되는 보안 메시지는 해당 손 도장이 구성된 호스트에만 라우팅됩니다.