오케스트레이션 성능 최적화

아티클
07/21/2023

이 항목에서는 BizTalk Server 솔루션에서 오케스트레이션을 사용하는 모범 사례에 대해 설명합니다. 여기에는 다음에 대한 권장 사항이 포함됩니다.

오케스트레이션을 사용하는 BizTalk Server 솔루션의 대기 시간 감소
- 메시징 전용 패턴에 대한 오케스트레이션 제거
- 오케스트레이션에서 인라인 보내기 사용
- 오케스트레이션 지속성 지점 최소화
오케스트레이션 중첩
오케스트레이션 디자인 패턴
오케스트레이션 예외 처리 블록

짧은 대기 시간 시나리오에 대한 오케스트레이션 최적화를 위한 권장 사항

다음 기술을 사용하여 오케스트레이션을 사용하는 BizTalk Server 솔루션의 대기 시간을 줄일 수 있습니다.

메시징 전용 패턴에 대한 오케스트레이션 제거

가능한 경우 오케스트레이션 사용을 최소화하여 전체 처리량을 늘리고 비즈니스 프로세스의 대기 시간을 줄입니다. 장기 실행 트랜잭션을 실행할 필요가 없고 각 요청에 대해 여러 시스템을 호출할 필요가 없는 경우 오케스트레이션을 제거하고 비즈니스 논리를 수신 및 송신 포트로 이동하여 BizTalkMsgBoxDb에 대한 총 왕복 수를 줄이고 데이터베이스 액세스로 인한 대기 시간을 줄이는 것이 좋습니다. 이 경우 사용자 지정 파이프라인을 구현하고 이전에 오케스트레이션에서 호출된 도우미 클래스를 다시 사용합니다. 디자인 패턴을 분산형 및 수집 또는 호송으로 구현해야 하는 경우에만 오케스트레이션을 사용합니다. 오케스트레이션 디자인 패턴에 대한 자세한 내용은 BizTalk Server 설명서의 오케스트레이션에서 디자인 패턴 구현(https://go.microsoft.com/fwlink/?LinkId=140042) 항목을 참조하세요.

짧은 대기 시간 시나리오를 수용하기 위해 오케스트레이션에서 인라인 보내기 사용

가능하면 오케스트레이션 사용을 최소화하고 메시징 전용 패턴을 선호하여 전체 처리량을 늘리고 비즈니스 프로세스의 대기 시간을 줄입니다. 장기 실행 트랜잭션이 필요하지 않고 비즈니스 논리가 여러 시스템을 호출할 필요가 없는 경우 비즈니스 논리를 이동하여 포트를 수신 및 보내고 오케스트레이션 사용을 제거하는 것이 좋습니다. 이 방법은 사용자 지정 파이프라인을 사용하여 구현할 수 있으며 이전에 오케스트레이션에서 호출된 도우미 클래스를 다시 사용할 수 있습니다. 짧은 대기 시간 시나리오에서 더 나은 성능을 얻으려면 다음 방법 중 하나를 채택합니다.

불필요한 오케스트레이션을 제거하고 메시징 전용 패턴을 채택하여 BizTalk MessageBox 데이터베이스에 대한 총 왕복 수를 줄입니다. 인라인 전송이 BizTalk 메시징 엔진 및 연결된 오버헤드를 우회하므로 이 방법은 짧은 대기 시간을 수용합니다. 오케스트레이션 인라인 보내기 기능은 BizTalk Server 2006 이상에서 제공됩니다.
오케스트레이션 내에서 물리적 포트에 바인딩된 논리 포트를 제거하고 해당 위치에서 인라인 보내기를 사용합니다. 예를 들어 인라인 보내기를 사용하여 다운스트림 웹 서비스 또는 ADO.NET 구성 요소를 호출하여 SQL Server 데이터베이스에 액세스하는 WCF 프록시 클래스의 instance 만들 수 있습니다. 다음 다이어그램에서는 오케스트레이션이 비즈니스 구성 요소를 인스턴스화할 때 인라인 보내기가 수행되며, 내부적으로 WCF 프록시 개체를 사용하여 다운스트림 웹 서비스를 직접 호출합니다.

묘사

참고

오케스트레이션에서 인라인 보내기를 사용하면 대기 시간이 크게 줄어들지만 이 접근 방식에는 제한이 있습니다. 인라인은 BizTalk 메시징 엔진을 바이패스하므로 메시징 엔진과 함께 제공되는 다음 기능을 사용할 수 없습니다.

트랜잭션 파이프라인
- 복구 가능한 파이프라인
- BAM 인터셉터 API를 호출하는 파이프라인
- BizTalk Server 어댑터 지원
- 일괄 처리
- 다시 시도
- 상관 관계 집합 초기화
- 선언적 구성
- 보조 전송
- 추적
- BAM의 선언적 사용

오케스트레이션 내에서 실행할 수 없는 파이프라인 유형에 대한 자세한 내용은 BizTalk Server 2010 설명서에서 식을 사용하여 파이프라인을 실행하는 방법(https://go.microsoft.com/fwlink/?LinkId=158008)의 "제한 사항" 섹션을 참조하세요.

가능한 경우 지속성 지점 수를 줄여 오케스트레이션 대기 시간을 최적화합니다.

오케스트레이션 scope 보정 또는 scope 시간 제한을 사용하려는 경우에만 "장기 실행 트랜잭션"으로 표시되어야 합니다. 장기 실행 트랜잭션 scope scope 끝에 추가 지속성 지점을 발생하므로 보정을 사용하거나 시간 제한을 scope 필요가 없을 때는 방지해야 합니다. 원자성 scope scope 끝에 지속성 지점을 발생시킬 뿐만 아니라 원자성 scope 내에서 지속성 지점이 발생하지 않도록 보장합니다. scope 내의 지속성이 없는 이 부작용은 경우에 따라 일괄 처리 지속성 지점(예: 여러 송신을 수행할 때)에 유리하게 사용될 수 있습니다. 하지만 일반적으로 가능하면 원자성 범위를 피하는 것이 좋습니다. 오케스트레이션 엔진은 실행 중인 오케스트레이션의 전체 상태를 여러 지점에서 instance 영구 스토리지에 저장하므로 나중에 메모리에서 instance 복원되고 완료될 수 있습니다. 오케스트레이션의 지속성 지점 수는 오케스트레이션을 통해 흐르는 메시지의 대기 시간에 영향을 주는 주요 요소 중 하나입니다. 엔진이 지속성 지점에 도달할 때마다 실행 중인 오케스트레이션의 내부 상태가 직렬화되어 MessageBox에 저장되고 이 작업에는 대기 시간 비용이 발생합니다. 내부 상태의 serialization에는 인스턴스화되어 오케스트레이션에서 아직 릴리스되지 않은 모든 메시지와 변수가 포함됩니다. 메시지와 변수가 클수록 오케스트레이션의 내부 상태를 유지하는 데 시간이 오래 걸립니다. 지속성 지점 수가 너무 많을 경우 성능이 크게 저하할 수 있습니다. 따라서 트랜잭션 범위 수와 셰이프 보내기를 줄여 오케스트레이션에서 불필요한 지속성 지점을 제거하는 것이 좋습니다. 이 방법을 사용하면 오케스트레이션 탈수 및 리하이드레이션으로 인해 MessageBox에서 경합을 줄이고, 전반적인 확장성을 높이고, 오케스트레이션 대기 시간을 줄일 수 있습니다. 또 다른 권장 사항은 항상 오케스트레이션의 내부 상태를 가능한 한 작게 유지하는 것입니다. 이 기술은 지속성 지점의 경우 XLANG 엔진이 오케스트레이션의 내부 상태를 직렬화, 유지 및 복원하는 데 소요되는 시간을 크게 줄일 수 있습니다. 이를 달성하는 한 가지 방법은 가능한 한 늦게 변수와 메시지를 만들고 가능한 한 빨리 해제하는 것입니다. 예를 들어 오케스트레이션 내에 비 트랜잭션 범위를 도입하고 최상위 수준에서 선언하는 대신 이러한 내부 범위 내에서 변수 및 메시지를 선언합니다. 오케스트레이션 지속성 지점을 최소화하는 방법에 대한 자세한 내용은 BizTalk Server 2010 설명서의 다음 topics 참조하세요.

승격된 속성을 사용하여 오케스트레이션에서 메시지 태그 또는 특성에 액세스하기 위한 지침

속성을 승격해야 하는 경우 메시지 라우팅, 필터 및 메시지 상관 관계에 사용되는 속성만 승격합니다. 각 속성을 승격하려면 문서 형식을 인식하고 문서 형식을 정의하는 XSD에 포함된 상대 주석에서 XPath 식을 사용하여 메시지에서 데이터를 검색하려면 디스어셈블러 구성 요소(XML, Flat, custom)가 필요합니다. 또한 각 속성 승격은 메시지 에이전트가 MessageBox 데이터베이스에 메시지를 게시할 때 bts_InsertProperty 저장 프로시저를 별도로 호출합니다. 오케스트레이션이 XML 문서에 포함된 특정 요소 또는 특성에 액세스해야 하는 경우 다음 기술 중 하나를 사용합니다.

작성 및 승격된 속성의 수를 줄이고 반드시 필요하지 않은 속성을 제거합니다.
불필요한 고유 필드를 제거합니다. 고유 필드는 기록된 컨텍스트 속성이며 이름이 데이터를 검색하는 데 사용되는 XPath 식과 같기 때문에 상당한 공간을 쉽게 차지할 수 있습니다. 고유 속성은 문서 형식을 정의하는 XSD에서 주석으로 정의됩니다. 디스어셈블러 구성 요소는 승격된 속성에 대해 채택된 것과 동일한 접근 방식을 사용하며, 들어오는 문서에서 고유 필드를 정의하는 XPath 식을 사용하여 해당 필드를 찾습니다. 그런 다음, 디스어셈블러 구성 요소는 컨텍스트에서 다음과 같은 속성을 씁니다.
- 이름: 주석에 정의된 XPath 식입니다.
- 값: 들어오는 문서 내에서 XPath 식으로 식별되는 요소의 값입니다.
  
  XPath 식은 특히 문제의 요소가 문서 스키마에 매우 깊을 때 매우 길 수 있습니다. 따라서 고유 필드가 많을수록 컨텍스트 크기가 커지게 됩니다. 이로 인해 전반적인 성능에 부정적인 영향을 줍니다.
오케스트레이션 런타임에서 제공하는 XPath 기본 제공 함수를 사용합니다.
메시지가 매우 작고 XML 형식인 경우 메시지를 .NET 클래스 instance 직렬화 해제하고 공용 필드 및 속성으로 작업할 수 있습니다. 메시지에 복잡한 경과(사용자 지정 코드, 비즈니스 규칙 엔진 정책 등)가 필요한 경우 .NET 클래스의 instance 의해 노출되는 속성을 사용하여 데이터에 액세스하는 것이 XPath 식을 사용하는 것이 훨씬 빠릅니다. 오케스트레이션에 의해 호출된 비즈니스 논리가 완료되면 엔터티 개체를 BizTalk 메시지로 다시 직렬화할 수 있습니다. XSD 도구(.NET Framework 2.0) 또는 SVCUTIL(.NET Framework 3.0) 도구 중 하나를 사용하여 XML 스키마에서 .NET 클래스를 만들 수 있습니다.
오케스트레이션에서 도우미 구성 요소를 사용하도록 설정합니다. 이 기술은 고유 필드를 사용하는 데 비해 이점이 있습니다. 실제로 오케스트레이션은 구성 저장소(구성 파일, SSO 구성 저장소, 사용자 지정 Db 등)에서 XPath 식을 읽을 수 있으므로 XPath 식을 변경해야 하는 경우 승격된 속성 및 고유 필드에 대해 수행해야 하는 것처럼 스키마를 변경하고 다시 배포할 필요가 없습니다. 다음 코드 샘플에서는 도우미 구성 요소의 예를 제공합니다. 구성 요소는 BizTalk 런타임에서 제공하는 XPathReader 클래스를 사용합니다. 이렇게 하면 XPath 식이 발견될 때까지 코드가 문서 스트림을 읽을 수 있습니다.

#region Copyright
//===
//Microsoft Windows Server AppFabric Customer Advisory Team (CAT)
//
// This sample is supplemental to the technical guidance published on the community
// blog.
//
// Author: Paolo Salvatori.
//===
// Copyright © 2010 Microsoft Corporation. All rights reserved.
//
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOU BEAR THE RISK OF USING IT.
//===
#endregion
#region Using Directives
using System;
using System.Collections.Generic;
using System.IO;
using System.Xml;
using System.Linq;
using System.Text;
using System.Globalization;
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.Streaming;
using Microsoft.BizTalk.XPath;
#endregion
namespace Microsoft.AppFabric.CAT.Samples.DuplexMEP.Helpers
{
public class XPathHelper
{
#region Private Constants
private const string MessageCannotBeNull = "[XPathReader] The message cannot be null.";
#endregion
#region Public Static Methods
public static string GetValue(XLANGMessage message, int partIndex, string xpath)
{
try
{
if (message == null)
{
throw new ApplicationException(MessageCannotBeNull);
}
using (Stream stream = message[partIndex].RetrieveAs(typeof(Stream)) as Stream)
{
XmlTextReader xmlTextReader = new XmlTextReader(stream);
XPathCollection xPathCollection = new XPathCollection();
XPathReader xPathReader = new XPathReader(xmlTextReader, xPathCollection);
xPathCollection.Add(xpath);
while (xPathReader.Read())
{
if (xPathReader.HasAttributes)
{
for (int i = 0; i < xPathReader.AttributeCount; i++)
{
xPathReader.MoveToAttribute(i);
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.GetAttribute(i);
}
}
}
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.ReadString();
}
}
}
}
finally
{
message.Dispose();
}
return string.Empty;
}
#endregion
}
}

오케스트레이션 복잡성을 최소화하여 성능 향상

오케스트레이션의 복잡성은 성능에 큰 영향을 줍니다. 오케스트레이션 복잡성이 증가함에 따라 전반적인 성능이 저하됩니다. 오케스트레이션은 거의 무한한 다양한 시나리오에서 사용할 수 있으며 각 시나리오에는 다양한 복잡성의 오케스트레이션이 포함될 수 있습니다. 모듈식 접근 방식을 위해 가능한 경우 복잡한 오케스트레이션을 피합니다. 즉, 비즈니스 논리를 재사용 가능한 여러 오케스트레이션으로 분할합니다.

복잡한 오케스트레이션을 구현해야 하는 경우 가능하면 루트 수준이 아닌 내부 범위로 메시지 및 변수를 정의합니다. 이 기술은 흐름이 변수와 메시지가 정의된 scope 떠날 때 변수와 메시지가 삭제되기 때문에 각 오케스트레이션에 대한 메모리 공간을 더 적게 유지합니다. 이 방법은 지속성 지점에서 오케스트레이션을 MessageBox에 저장할 때 특히 유용합니다.

호출 오케스트레이션 셰이프와 시작 오케스트레이션 셰이프를 사용하여 성능 향상

오케스트레이션 시작 셰이프를 피하고 호출 오케스트레이션 셰이프를 사용하여 중첩된 오케스트레이션을 실행합니다. 실제로 호출 오케스트레이션 셰이프를 사용하여 다른 프로젝트에서 참조되는 오케스트레이션을 동기적으로 호출할 수 있습니다. 이 방법을 사용하면 BizTalk 프로젝트에서 일반적인 오케스트레이션 워크플로 패턴을 다시 사용할 수 있습니다. 호출 오케스트레이션 셰이프를 사용하여 다른 중첩 오케스트레이션을 동기적으로 호출하면 바깥쪽 오케스트레이션은 중첩된 오케스트레이션이 완료될 때까지 기다린 후 계속합니다. 중첩된 오케스트레이션은 호출 오케스트레이션을 실행하는 동일한 스레드에서 실행됩니다.

오케스트레이션 시작 셰이프는 호출 오케스트레이션 셰이프와 비슷하지만 이 경우 중첩된 오케스트레이션은 비동기 방식으로 호출됩니다. 호출 오케스트레이션의 제어 흐름은 호출된 오케스트레이션이 작업을 완료할 때까지 기다리지 않고 호출을 넘어 진행됩니다. 호출자와 호출된 오케스트레이션 간에 이 분리를 구현하기 위해 시작 오케스트레이션 은 BizTalk Messagebox에 메시지를 게시하여 구현됩니다. 그런 다음 이 메시지는 중첩된 오케스트레이션을 실행하는 in-process BizTalk 호스트 instance 사용됩니다. 가능한 경우 호출 오케스트레이션을 사용합니다. 특히 호출 오케스트레이션이 처리를 계속하기 위해 중첩된 오케스트레이션의 결과를 기다려야 하는 경우를 사용합니다. 호출 오케스트레이션 셰이프를 사용하는 방법에 대한 자세한 내용은 BizTalk Server 2010 설명서의 다음 topics 참조하세요.

XLANGMessage와 함께 XmlReader를 사용하고 XmlDocument에서 XmlReader를 사용하여 오케스트레이션 성능 향상

오케스트레이션에서 호출된 .NET 메서드의 오케스트레이션 성능을 향상시키려면 XmlDocument가 아닌 XLANGMessage와 함께 XmlReader를 사용합니다. 다음 코드 예제에서는 이 기능을 보여 줍니다.

// As a general rule, use XmlReader with XLANGMessage, not XmlDocument.
// This is illustrated in the parameter passed into the following code.
// The XLANG/s compiler doesn't allow a return value of XmlReader
// so documents must be initially constructed as XmlDocument()
public static XmlDocument FromMsg(XLANGMessage old)
{
    //get at the data
    XmlDocument ret = new XmlDocument();

    try{
        XmlReader reader = (XmlReader)old[0].RetrieveAs(typeof(XmlReader));
        //construct new message from old
        //read property
        object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
    }
    finally {
        // Call Dispose on the XLANGMessage object
        // because the message doesn't belong to the
        // .NET runtime - it belongs to the Messagebox database
        old.Dispose();
    }
    return ret;
}

또 다른 방법은 스키마를 기반으로 .NET 클래스를 만드는 것입니다. 이렇게 하면 문서를 XmlDocument 개체에 로드하는 것보다 메모리가 적고 .NET 개발자를 위한 스키마 요소에 쉽게 액세스할 수 있습니다. BizTalk 스키마를 기반으로 클래스를 생성하려면 Visual Studio와 함께 제공되는 xsd.exe 도구를 사용할 수 있습니다. 예를 들어 ItemA, ItemB, ItemC라는 필드가 포함된 간단한 스키마에 대해 xsd.exe <schema.xsd> /class 를 실행하면 다음 클래스가 생성됩니다.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.1433
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System.Xml.Serialization;

//
// This source code was auto-generated by xsd, Version=2.0.50727.42.
//

/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="http://Schemas.MySchema")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="http://Schemas.MySchema", IsNullable=false)]
public partial class MySchemaRoot {

    private string itemAField;

    private string itemBField;

    private string itemCField;

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemA {
        get {
            return this.itemAField;
        }
        set {
            this.itemAField = value;
        }
    }

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemB {
        get {
            return this.itemBField;
        }
        set {
            this.itemBField = value;
        }
    }

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemC {
        get {
            return this.itemCField;
        }
        set {
            this.itemCField = value;
        }
    }
}

그런 다음, 메시지 요소에 액세스하기 위해 .NET 어셈블리에서 이 클래스를 참조할 수 있으며 반환된 개체를 메시지에 직접 할당할 수 있습니다. 다음은 위에서 생성된 클래스를 사용하는 예제입니다.

public static Root SetValues(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)
{
   try
   {
   MySchemaRoot rootObj=(MySchemaRoot)msg[0].RetrieveAs(typeof(MySchemaRoot);
   rootObj.ItemA="value a";
   rootObj.ItemB="value b";
   rootObj.ItemC="value c";
   }
    finally {
        msg.Dispose();
            }

   return rootObj;
}

이 기술을 사용하면 메시지를 처리할 때 개체 지향 접근 방식을 사용할 수 있습니다. 이 기술은 주로 비교적 작은 메시지와 함께 사용해야 합니다. 이 기술은 XmlDocument 개체에 메시지를 로드할 때보다 훨씬 적은 메모리를 사용하지만 전체 메시지가 여전히 메모리에 로드되기 때문입니다. 더 큰 메시지를 처리할 때 는 XmlReader 클래스를 사용하여 메시지를 읽고 XmlWriter 클래스를 사용하여 메시지를 작성합니다. XmlReader 및 XmlWriter를 사용하는 경우 메시지는 VirtualStream 개체에 포함됩니다. 메시지 크기가 BizTalk 그룹 속성 구성 페이지에 노출되는 큰 메시지 임계값(바이트) 에 지정된 값을 초과하면 메시지가 파일 시스템에 기록됩니다. 이렇게 하면 전반적인 성능이 저하되지만 메모리 부족 예외는 방지됩니다.

물리적 포트에 바인딩된 논리 포트 사용을 최소화하여 성능 향상

다음 어댑터를 사용하는 물리적 포트에 바인딩된 논리 포트의 사용을 최소화하여 성능을 높일 수 있습니다.

SQL Server, Oracle
WSE, HTTP, WCF
MSMQ, MQSeries

2010년 BizTalk Server Microsoft.XLANGs.Pipeline.dll 포함된 XLANGPipelineManager 클래스를 사용하여 오케스트레이션에서 송신 및 수신 파이프라인을 직접 호출할 수 있습니다. 따라서 파이프라인 처리를 포트에서 오케스트레이션으로 이동할 수 있습니다. 오케스트레이션의 논리 포트는 지정된 .NET 클래스의 instance 호출하는 식 셰이프(예: ADO.NET 사용하는 데이터 액세스 구성 요소)로 대체할 수 있습니다. 이 기술을 채택하기 전에 어댑터 및 물리적 포트를 사용하지 않으면 일괄 처리, 재시도, 선언적 구성 및 보조 전송과 같은 기능을 활용하는 기능이 손실된다는 점에 유의해야 합니다.

오케스트레이션 디자인 패턴

오케스트레이션 Designer 개발자는 다양한 엔터프라이즈 통합 패턴을 구현할 수 있습니다. 몇 가지 일반적인 패턴으로는 집계, 예외 처리 및 보정, 메시지 브로커, 분산 및 수집, 순차 및 병렬 호송이 있습니다. 이러한 패턴을 활용하여 BizTalk Server 사용하여 복잡한 EAI(엔터프라이즈 애플리케이션 통합), SOA(Service-Oriented 아키텍처) 및 BPM(비즈니스 프로세스 관리) 솔루션을 개발할 수 있습니다. 오케스트레이션 디자인 패턴에 대한 자세한 내용은 BizTalk Server 설명서 및 엔터프라이즈 통합을 위한 패턴 및 모범 사례(https://go.microsoft.com/fwlink/?LinkId=140042)의 오케스트레이션에서 디자인 패턴 구현(https://go.microsoft.com/fwlink/?LinkId=140043) 항목을 참조하세요.

오케스트레이션에서 .NET 클래스를 적절하게 사용하여 성능을 최대화합니다.

일반적으로 오케스트레이션 내에서 사용되는 .NET 클래스는 두 가지 범주로 나눌 수 있습니다.

도우미 및 서비스 - 이러한 클래스는 추적, 오류 처리, 캐싱 및 serialization/deserialization과 같은 오케스트레이션에 대한 일반적인 서비스를 제공합니다. 이러한 클래스의 대부분은 내부 상태 및 여러 공용 정적 메서드가 없는 정적 클래스로 구현할 수 있습니다. 이 방법은 동시에 실행되는 다른 오케스트레이션에서 동일한 클래스의 여러 개체를 만들지 않도록 하므로 호스트 프로세스의 작업 공간을 줄이고 메모리를 절약하는 데 도움이 됩니다. 상태 비 상태인 클래스는 오케스트레이션이 탈수될 때 BizTalk MessageBox에 직렬화되고 유지되어야 하는 내부 상태의 전체 크기를 줄이는 데 도움이 됩니다.
엔터티 및 비즈니스 개체 - 이러한 클래스를 사용하여 주문, 주문 항목 및 고객과 같은 엔터티를 관리할 수 있습니다. 단일 오케스트레이션은 내부적으로 동일한 형식의 여러 인스턴스를 만들고 관리할 수 있습니다. 이러한 클래스는 일반적으로 상태 저장이며 개체의 내부 상태를 수정하는 메서드와 함께 공용 필드 및/또는 속성을 노출합니다. 이러한 클래스의 인스턴스는 XmlSerializer 또는 DataContractSerializer 클래스를 사용하거나 XLANGPart.RetrieveAs 메서드를 사용하여 XLANGMessage 부분을 .NET 개체로 역직렬화하여 동적으로 만들 수 있습니다. 상태 저장 클래스의 인스턴스가 가능한 한 늦게 만들어지고 더 이상 필요하지 않은 즉시 해제되는 방식으로 비 트랜잭션 범위를 사용하여 오케스트레이션을 구성해야 합니다. 이 방법은 호스트 프로세스의 작업 공간을 줄이고 오케스트레이션이 탈수될 때 MessageBox 데이터베이스에 직렬화되고 유지되는 내부 상태의 전체 크기를 최소화합니다. BizTalk Server 오케스트레이션을 사용하는 방법에 대한 자세한 내용은 BizTalk Server 오케스트레이션(https://go.microsoft.com/fwlink/?LinkID=116886)에 대한 FAQ 문서를 참조하세요.

참고

이 문서는 BizTalk Server 2004 및 BizTalk Server 2006용으로 작성되지만 제시된 개념은 BizTalk Server 2010 오케스트레이션에도 적용됩니다.

오케스트레이션 예외 처리기 블록

오케스트레이션 예외 처리기 블록을 사용하는 경우 하나 또는 여러 범위에 모든 오케스트레이션 셰이프를 포함하고(가능하면 트랜잭션이 아닌 범위) 적어도 다음 예외 처리기 블록을 만듭니다.

제네릭 System.Exception 오류를 처리하기 위한 예외 처리기 블록입니다.
COM 예외와 같은 관리되지 않는 가능한 오류를 catch하고 처리하기 위해 일반적인 예외를 처리하기 위한 예외 처리기 블록입니다.

오케스트레이션 예외 처리 블록을 사용하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.
BizTalk Server 예외 처리 사용(https://msdn.microsoft.com/library/aa561229.aspx).
Charles Young 블로그, BizTalk Server 2006: 보상 모델(https://go.microsoft.com/fwlink/?LinkId=158017).

참고

이 블로그는 BizTalk Server 2006을 염두에 두고 작성되었지만 블로그에 설명된 원칙도 BizTalk Server 적용됩니다.

오케스트레이션에서 맵을 사용할 때 고려 사항

오케스트레이션에서 맵을 사용하는 경우 다음 고려 사항이 적용됩니다.

맵을 사용하여 오케스트레이션에서 비즈니스 논리와 함께 사용되는 속성을 추출하거나 설정하는 경우 고유 필드 또는 승격된 속성을 사용합니다. 맵을 사용하여 값을 추출하거나 설정할 때 문서가 메모리에 로드되지만 고유 필드 또는 승격된 속성을 사용할 때 오케스트레이션 엔진은 메시지 컨텍스트에 액세스하고 문서를 메모리에 로드하지 않기 때문에 이 방법을 따라야 합니다.
맵을 사용하여 여러 필드를 하나의 필드로 집계할 경우 오케스트레이션 변수와 함께 고유 필드 또는 승격 속성을 사용하여 결과 집합을 누적합니다.

참고 항목

성능 최적화

다음을 통해 공유