비즈니스 프로세스 정의
서로 다른 시스템 간의 메시지 교환은 BizTalk Server 문제를 해결하는 데 필요한 부분입니다. 그러나 이 교환의 실제 목표는 응용 프로그램을 기반으로 비즈니스 프로세스를 정의 및 실행하는 것입니다. BizTalk Server 엔진은 오케스트레이션을 사용하여 이러한 비즈니스 프로세스의 논리를 정의합니다. 이 엔진은 비즈니스 규칙 그룹을 작성 및 평가하기 위해 비즈니스 규칙 엔진을 사용합니다. 이 섹션에서는 오케스트레이션과 비즈니스 규칙 엔진에 대해 설명합니다.
오케스트레이션 사용
자동화된 비즈니스 프로세스 논리는 Microsoft Visual Basic, Microsoft Visual C# 등의 언어로 직접 구현할 수 있습니다. 그러나 기존의 프로그래밍 언어로 복잡한 비즈니스 프로세스를 만들고, 유지 및 관리하기란 쉽지가 않습니다. 이전 모델과 달리 BizTalk Server 다른 접근 방식을 취합니다. 즉, 비즈니스 관리자나 개발자가 그래픽으로 비즈니스 프로세스를 정의할 수 있도록 합니다. 이 방식을 사용하면 프로그래밍 언어로 프로세스를 직접 빌드하는 것보다 신속하게 작업을 수행할 수 있을 뿐 아니라 프로세스를 보다 쉽게 이해, 설명 및 변경할 수 있습니다. 또한 이러한 방식으로 빌드한 비즈니스 프로세스는 보다 쉽게 모니터링할 수 있습니다. BAM(비즈니스 활동 모니터링) 기술에서는 이러한 이점을 이용합니다.
개발자의 경우 오케스트레이션을 만들려면 XML 스키마를 만들기 위한 BizTalk 편집기, 해당 스키마 간의 번역을 정의하기 위한 BizTalk 매퍼, 비즈니스 프로세스의 논리를 지정하기 위한 오케스트레이션 Designer 세 가지 기본 도구를 사용합니다. 이러한 모든 도구는 Visual Studio 내에서 호스트되어 개발자에게 일관된 환경을 제공합니다. 이 섹션에서는 이러한 각 도구의 역할과 도구를 함께 사용하는 방법에 대해 설명합니다.
스키마 만들기: BizTalk 편집기
오케스트레이션은 XML 문서에 사용할 수 있으며 각 오케스트레이션은 일부 XML 스키마를 준수합니다. 개발자는 BizTalk 편집기를 사용해 이러한 스키마를 정의할 수 있습니다. 이를 통해 궁극적으로는 XSD(XML 스키마 정의) 언어를 사용하여 문서 정보의 구조와 유형을 정의하게 됩니다.
도구 지원 없이 원시 XSD 스키마를 만드는 작업은 간단하지가 않습니다. BizTalk 편집기는 이 필수 단계를 보다 쉽게 수행할 수 있도록 사용자(개발자)가 그래픽 계층 구조로 요소를 정의하여 스키마를 빌드할 수 있게 합니다. 기존 스키마도 파일이나 액세스 가능한 웹 서비스에서 가져올 수 있습니다. 확보한 방법에 상관없이 스키마는 BizTalk 맵의 기준으로 사용됩니다.
스키마 간 매핑: BizTalk 매퍼
비즈니스 프로세스를 구현하는 오케스트레이션은 일반적으로 일부 문서를 받고 다른 문서를 보냅니다. 이때 받은 문서의 정보 중 일부가 특정 방식으로 변환되어 보낸 문서로 전송되는 경우가 많습니다. 예를 들어 주문 처리 프로세스에서 특정 수의 항목에 대해 주문을 받은 다음 특정 원인으로 인해 주문이 거절되었음을 나타내는 메시지를 다시 보낼 수 있습니다. 이 주문의 정보(예: 요청 식별자 및 주문 수량)는 받은 주문 메시지의 필드에서 거부 메시지의 필드로 복사될 수 있습니다. BizTalk 맵 편집기를 사용하면 맵이라는 문서 간의 변환을 정의할 수 있습니다.
위의 그림에 나와 있듯이 각 맵은 두 XML 스키마에 있는 요소 간의 관계를 정의하는 해당 스키마 간의 그래픽 상관 관계로 표시됩니다. W3C(World Wide Web Consortium)는 XSLT(확장 가능한 스타일시트 언어 변환)를 XML 스키마 간에 이러한 종류의 변환을 표현하는 표준 방법으로 정의했기 때문에 BizTalk Server 맵이 XSLT 변환으로 구현됩니다.
맵에 정의된 변환은 문서 간에 변경되지 않은 값을 복사하는 것처럼 간단할 수 있습니다. 이러한 직접 데이터 복사는 링크로 표시되며, 이 링크는 BizTalk 맵 편집기에서 소스 스키마의 해당 요소와 대상 스키마의 그에 대응하는 요소를 연결하는 선으로 나타납니다. 펑토이드를 사용하면 보다 복잡한 변환도 가능합니다. 펑토이드는 XML 스키마 간의 매우 복잡한 매핑을 정의할 수 있는 실행 코드 청크이며, 위에 나와 있듯이 BizTalk 맵 편집기에서는 변환 중인 요소를 연결하는 선의 상자로 표시됩니다. 이러한 변환 중 일부는 매우 일반적이므로 BizTalk Server 여러 기본 제공 펑토이드를 포함합니다. 이러한 기본 제공 펑토이드는 다음과 같은 범주로 그룹화됩니다.
소스 문서의 필드 값에 대해 더하기/곱하기/나누기 등의 연산을 수행한 다음 결과를 대상 문서의 필드에 저장하는 수치 펑토이드
숫자 값을 해당 ASCII로 또는 ASCII를 해당 숫자 값으로 변환하는 변환 펑토이드
소스 문서에서 지정된 값 간의 논리적 비교를 기반으로 하여 대상 문서에 요소나 특성을 만들지를 결정하는 데 사용할 수 있는 논리적 펑토이드. 이러한 값은 같은지, 보다 크거나 작은지 또는 다른 방식으로 비교할 수 있습니다.
소스 문서의 여러 필드에 있는 값에 대해 평균 또는 합계를 계산하거나 기타 값을 계산한 다음 결과를 대상 문서의 단일 필드에 저장하는 누적 펑토이드
데이터베이스에 저장된 정보에 액세스할 수 있는 데이터베이스 펑토이드
XSLT에서 직접 또는 Visual C# 및 Visual Basic과 같은 .NET 사용 가능 언어를 통해 사용자 지정 펑토이드를 만들 수도 있습니다. 또한 펑토이드를 시퀀스로 결합해 한 펑토이드의 출력을 다른 펑토이드의 입력에 연속적으로 표시할 수 있습니다.
문서의 XML 스키마를 정의하는 방법과 서로 다른 스키마가 포함된 여러 문서 간에 정보를 매핑하는 메커니즘이 있어야 합니다. BizTalk 편집기와 BizTalk 맵 편집기를 사용하면 이러한 두 가지 문제가 해결됩니다. 그러나 프로세스에서는 스키마와 맵을 정의하는 것 외에 다른 작업도 수행해야 합니다. 즉, 스키마를 사용하고 맵을 호출할 비즈니스 논리도 지정해야 합니다.
비즈니스 논리 정의: 오케스트레이션 Designer
비즈니스 프로세스는 함께 수행하는 경우 유용한 비즈니스 요구 사항을 충족하는 작업 집합입니다. BizTalk Server 통해 개발자는 오케스트레이션 Designer 사용하여 이러한 작업을 그래픽으로 정의할 수 있습니다. 즉, 개발자는 프로그래밍 언어로 단계를 표시하는 대신 일련의 셰이프를 논리적 방식으로 함께 연결하여 오케스트레이션을 만들 수 있습니다. 오케스트레이션 디자이너에서는 다음과 같은 셰이프를 사용할 수 있습니다.
오케스트레이션에서 메시지를 받을 수 있도록 하는 수신 셰이프. 수신 셰이프는 받을 메시지 유형을 정의하는 필터를 포함할 수 있으며, 새 메시지가 도착하면 새 오케스트레이션 인스턴스가 시작되도록 구성할 수도 있습니다.
오케스트레이션에서 메시지를 보낼 수 있도록 하는 송신 셰이프
메시지 전송 방법을 정의하는 포트 셰이프. 포트 셰이프의 각 인스턴스는 송신 셰이프 또는 수신 셰이프에 연결됩니다. 또한 각 포트에는 포트에서 받을 수 있는 메시지의 종류, 방향(예: 송신 또는 수신) 및 메시지를 보내거나 받는 방법을 결정하는 바인딩(예: 특정 URL 및 기타 정보 지정) 등의 옵션을 정의하는 유형도 포함될 수 있습니다.
오케스트레이션이 부울 조건을 기준으로 서로 다른 작업을 수행할 수 있도록 하는 if-then-else 문을 나타내는 판단 셰이프. 오케스트레이션 디자이너에 포함된 식 편집기를 통해 이 조건문을 지정할 수 있습니다.
조건이 true일 때 반복적인 작업 수행을 제어하는 반복 셰이프
메시지 작성을 허용하는 메시지 생성 셰이프
문서 간에 정보를 전송하고 BizTalk 맵 편집기를 통해 정의된 맵을 호출하여 정보를 변환할 수 있도록 하는 변환 셰이프
개발자가 여러 작업을 순서대로가 아닌 병렬로 수행하도록 지정할 수 있게 하는 병렬 작업 셰이프. 이 셰이프 뒤에 오는 셰이프는 모든 병렬 작업이 완료될 때까지 실행되지 않습니다.
작업을 트랜잭션으로 그룹화하고 오류 처리를 위한 예외 핸들러를 정의하도록 허용하는 범위 셰이프. 기존의 원자성 트랜잭션과 장기 실행 트랜잭션이 모두 지원됩니다. 그러나 원자성 트랜잭션과 달리 장기 실행 트랜잭션은 롤백이 아닌 보정 논리를 통해 예기치 않은 이벤트를 처리합니다.
값을 오케스트레이션 변수에 할당할 수 있도록 하는 메시지 할당 셰이프. 이러한 변수를 사용하여 작성 중인 메시지나 문자열 등 오케스트레이션에서 사용되는 상태 정보를 저장할 수 있습니다.
아래 그림은 이러한 셰이프 중 몇 가지를 사용하여 오케스트레이션 디자이너에서 만든 오케스트레이션을 보여 줍니다. 이 간단한 예제에서는 메시지를 받아서 그 내용을 기준으로 결정을 내린 후에 해당 결정의 결과로 두 경로 중 하나가 실행됩니다. 실제 문제를 해결하는 오케스트레이션은 이보다 훨씬 더 복잡할 수 있습니다. 이러한 복잡한 다이어그램을 더 쉽게 사용할 수 있도록 오케스트레이션 Designer 확대 및 축소 기능을 포함합니다. 개발자는 현재 관심 있는 오케스트레이션의 해당 부분만 볼 수 있습니다.
개발자가 오케스트레이션을 정의하고 나면 셰이프 그룹과 셰이프 간의 관계가 .NET Framework의 CLR(공용 언어 런타임)에서 사용되는 MSIL(Microsoft Intermediate Language)로 변환됩니다. 즉, BizTalk Server 개발자가 정의하는 셰이프 그룹은 최종적으로는 표준 .NET 사용 가능 어셈블리가 됩니다. 필요한 경우 셰이프 내부에서 COM 또는 .NET 개체를 호출하여 오케스트레이션에 명시적 코드를 추가할 수도 있습니다.
웹 서비스의 역할
웹 서비스는 응용 프로그램이 SOAP를 사용해 XML 문서를 교환할 수 있도록 하며, 통합 플랫폼에 큰 영향을 줍니다. 외부 웹 서비스에 액세스하기 위해 오케스트레이션의 작성자는 Visual Studio에서 웹 참조 추가 옵션을 웹 서비스 어댑터와 함께 사용하여 작업을 직접 호출할 수 있습니다. 마찬가지로 BizTalk Server 하나 이상의 오케스트레이션 작업을 SOAP 호출 가능한 웹 서비스로 노출하는 ASP.NET 웹 서비스 프로젝트를 생성할 수 있는 웹 서비스 게시 마법사를 제공합니다. 개발자는 이 두 옵션을 사용하여 비즈니스 프로세스 내에서 기존 웹 서비스에 액세스할 수 있으며 오케스트레이션의 기능을 다른 비즈니스 프로세스에 대해 웹 서비스로 표시할 수 있습니다.
웹 서비스의 성장은 비즈니스 프로세스 정의 방법에도 영향을 주었습니다. 예를 들어 두 조직이 웹 서비스를 사용하여 상호 작용하는 경우 상호 운용성의 효과성을 높이려면 각 상호 작용 파티가 상대방이 사용 중인 비즈니스 프로세스에 대한 정보를 파악해야 할 수 있습니다. 두 조직 모두 BizTalk Server 사용하는 경우 이는 큰 문제가 아닙니다. 거래 업체 관리 기술과 같은 도구를 사용하여 이 지식을 배포할 수 있습니다. 두 조직에서 서로 다른 제품을 사용하는 경우에는 공급업체와 관련이 없는 방식으로 비즈니스 프로세스 측면을 설명할 수 있는 방법이 있으면 유용합니다.
이를 위해 Microsoft, IBM 등은 BPEL(비즈니스 프로세스 실행 언어)을 만들었습니다. 오케스트레이션 Designer 사용하여 정의된 비즈니스 프로세스를 BPEL로 내보낼 수 있으며 BizTalk Server BPEL에 정의된 프로세스를 가져올 수도 있습니다. 언어는 외부적으로 표시 가능한 비즈니스 프로세스 부분을 설명 및 공유하는 데 유용한 반면, BPEL은 전체 비즈니스 프로세스의 플랫폼 간 실행보다는 이 문제를 해결하는 데 보다 주력합니다. BPEL은 전적으로 웹 서비스를 기반으로 하며, BizTalk Server 및 이 언어를 지원하는 다른 제품은 더 많은 것을 제공한다는 것을 이해하는 것도 중요합니다. 예를 들어 BizTalk Server 서로 다른 XML 스키마, 로컬 개체에서 메서드 호출 및 BPEL에서 사용할 수 없는 기타 기능 간의 매핑을 지원합니다. 이러한 여러 가지 원인으로 인해 BPEL은 비즈니스 프로세스를 정의하는 데 최적의 언어라고는 할 수 없습니다. 또한 BPEL은 아직 OASIS(Organization for the Advancement of Structured Information Standards)에서 표준화 작업을 진행 중이므로 현재 완결된 기술로 보기는 어렵습니다.
오케스트레이션은 BizTalk Server에서 비즈니스 프로세스를 만드는 데 필요한 기본적인 메커니즘입니다. 그러나 오케스트레이션의 일부 측면은 다른 측면보다 자주 바뀌는 경향이 있습니다. 특히 가장 변화가 심한 요소는 비즈니스 프로세스에 포함된 결정(비즈니스 규칙)입니다. 관리자의 지출 한도는 지난 주에 $100,000였지만, 그녀의 프로모션은 이를 최대 $500,000까지 올리거나 느린 지불 고객의 최대 허용 주문이 100대에서 10대로 감소합니다. 비즈니스 규칙 엔진을 사용하여 이러한 규칙을 지정하고 업데이트할 수 있습니다.
비즈니스 규칙 엔진 사용
오케스트레이션 디자이너와 BizTalk 편집기 및 BizTalk 맵 편집기를 함께 사용하면 비즈니스 프로세스 및 해당 프로세스에서 사용하는 규칙을 효과적으로 정의할 수 있습니다. 그러나 비즈니스 규칙을 보다 쉽게 정의 및 변경하는 방법이 있으면 유용합니다. 이를 위해 BizTalk Server에서는 BRE(비즈니스 규칙 엔진)를 제공합니다. 대부분의 개발자는 BRE를 사용하지만 비즈니스를 보다 많이 수행하는 사용자는 비즈니스 규칙 작성기라는 도구를 사용해 비즈니스 규칙 집합을 만들고 수정할 수 있습니다.
BRE가 유용한 상황의 예로는 복잡한 비즈니스 규칙 집합을 평가해야 하는 경우가 있습니다. 예를 들어 대출 승인 여부를 결정할 때는 고객의 신용 기록, 수입 및 기타 요인을 기반으로 하여 대규모 규칙 집합을 파악해야 할 수 있습니다. 마찬가지로 피보험자에게 생명 보험을 판매할지 여부를 결정할 때도 피보험자의 연령, 성별, 건강 상태 등 다양한 요소를 고려해야 합니다. 오케스트레이션의 판단 셰이프 등을 사용하여 이러한 모든 규칙을 조건문으로 표시할 수는 있지만 이를 구현하는 작업은 매우 복잡합니다. 따라서 이렇게 규칙을 많이 사용하는 프로세스의 경우에는 BRE를 사용하면 개발자의 작업이 보다 간단해집니다.
개발자는 BRE를 통해 규칙을 필요한 대로 빠르고 쉽게 변경할 수 있습니다. 오케스트레이션 내에서 구현되는 비즈니스 규칙을 변경하는 데 필요한 작업을 생각해 보면 그 이유를 알 수 있습니다. 개발자는 먼저 Visual Studio에서 오케스트레이션을 열고 적절한 셰이프(그리고 호출하는 .NET 또는 COM 개체)를 수정한 다음 수정된 어셈블리를 빌드하고 배포해야 합니다. 또한 이러한 과정을 진행하려면 해당 오케스트레이션이 포함된 BizTalk 응용 프로그램을 중지했다가 다시 시작해야 합니다. 이러한 상황에서 대신 BRE를 사용해 이 비즈니스 규칙을 구현하면 다시 컴파일 또는 다시 시작하지 않고도 규칙을 수정할 수 있습니다. 즉, 비즈니스 규칙 작성기를 사용하여 원하는 규칙을 변경한 다음 새로운 규칙 집합을 재배포하기만 하면 됩니다. 그러면 변경 내용이 즉시 적용됩니다. 그리고 오케스트레이션은 대개 개발자가 만들고 유지 관리하기 때문에 비즈니스 규칙을 읽기가 쉬우므로 보다 기술 수준이 높은 사용자가 없어도 비즈니스 분석가가 규칙을 수정할 수 있는 경우도 있습니다.
비즈니스 규칙 집합 작성자는 보통 비즈니스 규칙 작성기를 통해 이러한 규칙을 지정하는 데 사용할 어휘를 먼저 정의합니다. 어휘의 각 용어는 일부 정보에 대한 간단한 이름을 제공합니다. 예를 들어 어휘에서 배송 수량, 최대 항목 수량, 승인 제한 등의 용어를 정의할 수 있습니다. 이러한 각 용어는 상수로 설정할 수도 있고 일부 XML 스키마(및 들어오는 메시지)의 특정 요소 또는 특성이나 일부 데이터베이스에 대한 SQL 쿼리 결과에 매핑할 수도 있으며, .NET 개체의 값에도 매핑할 수 있습니다.
어휘를 정의한 후에는 비즈니스 규칙 작성기를 사용하여 해당 어휘를 사용하는 비즈니스 정책을 만들 수 있습니다. 각 정책은 하나 이상의 비즈니스 규칙을 포함할 수 있습니다. 규칙은 일부 어휘에 정의된 용어와 보다 큼, 보다 작음, 같음 등의 논리 연산자를 함께 사용하여 비즈니스 프로세스의 작동 방법을 정의합니다. 비즈니스 규칙은 받은 XML 문서에 포함된 값이 보낸 XML 문서에서 만든 값에 영향을 주는 방식 또는 받은 값이 데이터베이스에 기록되는 값이나 기타 항목에 영향을 주는 방식을 정의할 수 있습니다.
오케스트레이션은 비즈니스 정책을 실행하기 위해 CallRules 셰이프를 사용합니다. 이 셰이프는 BRE 인스턴스를 만들고 실행할 정책을 지정한 다음 받은 XML 문서 등 이 정책에 필요한 정보를 전달합니다. BRE는 를 사용하여 프로그래밍 방식으로 호출할 수도 있습니다. NET 기반 개체 모델을 사용하면 BizTalk Server 사용하지 않는 애플리케이션에서 호출할 수 있습니다. 즉, Windows Forms 응용 프로그램, 웹 서비스를 표시하는 소프트웨어 및 .NET Framework를 기반으로 하는 기타 모든 항목은 현재 발생한 문제를 해결하는 데 필요할 때마다 BRE를 사용할 수 있습니다.
어휘와 비즈니스 규칙은 모두 여기서 설명하는 단순한 예에 비해 훨씬 복잡할 수 있으며 훨씬 많은 기능을 제공할 수 있습니다. 그러나 어휘를 정의한 다음 해당 어휘를 사용하는 규칙 집합을 정의하는 핵심 아이디어는 비즈니스 규칙 엔진의 주요 요소입니다.