비동기 비즈니스 이벤트 추적
비동기(사용 BufferedEventStream) - 이 모델은 상당한 성능 향상을 제공합니다. 이 모델은 동기 모델과 비슷한 API를 사용하며 생성자만 다릅니다. 데이터를 기본 가져오기 데이터베이스에 밀어넣기 전에 BufferedEventStream은 메모리의 이벤트 데이터를 이진 형식으로 누적한 다음 단일 테이블 레코드로 임시 데이터베이스(MessageBox)에 삽입합니다. 이벤트 버스 서비스는 BizTalk에서 MessageBox 데이터베이스의 큐에 저장한 데이터를 읽고 기본 가져오기 데이터베이스로 가져옵니다.
BAM의 비동기 작업을 구성하려면 이벤트 버스 서비스 및 호출 응용 프로그램(예: 오케스트레이션 호스트)이 다른 컴퓨터에서 실행되어야 합니다. 그러면 호출 응용 프로그램이 다른 컴퓨터의 CPU를 사용하여 처리할 이벤트 데이터를 즉시 제거할 수 있습니다.
이 BAM 토폴로지는 또한 트랜잭션의 일관성이 유지됩니다. 이벤트 버스 서비스는 MessageBox 데이터베이스에서 커밋된 데이터만 읽기 때문에 호출 응용 프로그램에서 롤백된 트랜잭션에 대한 BAM 데이터는 가져올 수 없습니다. 커밋된 트랜잭션에 대한 BAM 데이터는 약간의 지연 시간 후에 쿼리 및 집계에 표시됩니다.
오류가 발생하면 이벤트 버스 서비스가 몇 번 더 작업을 시도하고 제한 시간을 사용하고 복구 논리 등을 수행합니다. 하지만 데이터의 형식이 유효하지 않으면 특수 테이블에서 종료됩니다. 이벤트 로그에는 이러한 상태를 나타내는 이벤트가 표시됩니다. 이러한 추가적인 장애 지점으로 인해 시스템 관리가 더 어려워집니다.
DirectEventStream을 BufferedEventStream으로 바꾸고 BAM 기본 가져오기의 MessageBox 대신 생성자의 MessageBox에 연결 문자열을 전달하여 코드에서 비동기 접근 방식을 쉽게 사용할 수 있습니다.
비동기 비즈니스 이벤트 추적과 관련한 다음 지침에 따라 코드를 작성하십시오.
활동에서 여러 응용 프로그램이 사용되고 데이터를 BAM에 비동기적으로 보내는 경우에는 ActivityID를 모든 구성 요소에 전파하는 경우에도 Continuation을 항상 사용하십시오. 이 경우 ActivityID 앞에 고유한 문자열(예: 응용 프로그램 이름)을 붙여 각 응용 프로그램에서 서로 다른 ActivityID를 사용합니다. 다른 응용 프로그램의 데이터가 BAM에 무작위로 도착하고 BAM은 올바른 쿼리 및 집계 결과를 보장하기 위해 순서가 없는 이벤트를 관리해야 하기 때문에 이 작업이 필요합니다.
이벤트 모니터링의 일반적인 방법(예: COM+ 이완 결합 이벤트 또는 WMI 이벤트)은 이벤트 데이터가 트랜잭션에 대해 독립적이기 때문에 BAM에 적합하지 않습니다. 예를 들어 총 $10,000인 구매 주문서를 10개 받은 것 같은데 $1000인 들어오는 구매 주문서 하나만 있으면 이를 데이터베이스에 저장할 때 오류가 10번 발생할 수 있습니다.