Microsoft BizTalk Accelerator for RosettaNet(BTARN)의 알려진 문제
이 섹션에는 Microsoft® BizTalk Accelerator for RosettaNet(BTARN)의 오류를 방지하는 데 도움이 될 수 있는 유용한 정보가 포함되어 있습니다. 알려진 문제는 다음 영역으로 그룹화됩니다.
0A1 오류 알림
Business Activity Monitoring(BAM: 비즈니스 활동 모니터링)
설치 및 구성
기타
0A1 오류 알림
BTARN은 CIDX 프로세스 구성 속성 및 0A1 규약 속성에 대한 교차 필드 유효성 검사를 수행하지 않습니다.
BTARN은 CIDX가 0A1 계약을 지원하지 않더라도 해당 프로필을 사용하는 계약의 "0A1 계약" 속성을 "0A1 계약" 속성으로 설정한 후 프로세스 구성 프로필의 "표준" 속성을 "CIDX"로 설정하는 것을 방지하지 않습니다.
비즈니스 활동 모니터링
비즈니스 활동 모니터링 보고서에 중복 열 데이터가 표시됩니다.
BAM 활동 웹 보고서의 ActivityID 및 PIPInstanceID 열에는 동일한 콘텐츠가 포함됩니다. 이 데이터는 PIP(파트너 인터페이스 프로세스) instance 식별자를 정확하게 반영합니다. ActivityID는 내부 상관 관계에 이 값을 사용합니다. 이 문자열은 무시해도 됩니다.
비즈니스 활동 모니터링 웹 보고서의 빈 데이터 열
BAM(비즈니스 활동 모니터링) 웹 보고서에는 0A1 메시지 프로세스에 대한 데이터가 포함되어 있지 않습니다. 웹 보고서의 0A1 메시지 열은 "시작 0A1"으로 하드 코딩됩니다.
설치 및 구성
BizTalk 애플리케이션 사용자 그룹과 BizTalk Server Administrators 그룹의 그룹 및 사용자는 동일한 도메인에 있어야 합니다.
BTARN은 BizTalk 애플리케이션 사용자 그룹 또는 BizTalk Server Administrators 그룹에 그룹 추가를 지원합니다. 그러나 BizTalk 애플리케이션 사용자 그룹 또는 BizTalk Server Administrators 그룹에 속하는 개별 사용자 계정 및 그룹은 동일한 도메인의 일부여야 합니다.
BizTalk Server 먼저 제거되면 BTARN 제거가 실패합니다.
BTARN을 제거하기 전에 BizTalk Server 제거하면 BTARN 제거 프로세스가 오류 없이 실패합니다. 이 문제를 resolve 위해 BizTalk Server 다시 설치 및 재구성한 다음 BTARN을 제거합니다.
분산 배포에는 도메인 컨트롤러가 필요합니다.
다중 서버 환경에서 BTARN을 배포하려면 도메인 컨트롤러가 필요합니다. 예를 들어 한 서버에 BTARN을 설치한 경우와 다른 서버에서 구성에 사용되는 SQL Server 데이터베이스가 필요합니다.
사용자 지정 PIP 구성은 지원되지 않습니다.
BTARN의 현재 릴리스는 사용자 지정 요소 또는 기타 비 RosettaNet 표준 정보를 사용하여 PI를 구성하는 것을 지원하지 않습니다.
BTARN이 Single Sign-On 서비스를 자동으로 시작합니다.
BTARN은 BTARN이 필요하고 SSO 서비스가 실행되지 않는 경우 이벤트에서 SSO(Single Sign-On)를 자동으로 시작합니다.
WebApps가 기본 웹 사이트에 대해 구성되지 않은 경우 구성 프로그램은 제외된 경로 목록에서 BTARN 가상 디렉터리를 제거하지 않습니다.
웹 애플리케이션 가상 폴더가 기본 웹 사이트가 아닌 SharePoint Server로 구성된 BTARN 설치를 구성 해제한 경우 구성을 해제한 후 SharePoint 중앙 관리 사이트의 제외된 경로 목록에서 btarnapp 및 btarnhttpreceive 가상 디렉터리를 수동으로 제거해야 합니다. 이는 웹 애플리케이션 가상 폴더를 SharePoint Server로 구성할 때 btarnapp 및 btarnhttpreceive를 제외된 경로 목록에 수동으로 추가해야 하기 때문에 발생합니다. 구성 프로그램에서 제외된 경로 목록에서 자동으로 제거할 수 없습니다.
기타
BTARN은 암호화 알고리즘으로 암호화된 메시지를 받습니다.
BTARN 수신 파이프라인은 메시지를 암호화하는 데 사용되는 프로토콜과 이 필드의 인코딩 설정이 일치하지 않는 경우에도 메시지를 수신하고 암호를 해독합니다. 따라서 BTARN은 RC2-40 또는 3DES에서 암호화된 메시지를 받습니다.
BTARN에는 단일 작업 동기 시나리오에서 신호가 필요합니다.
단일 작업 동기 시나리오에서 BTARN은 항상 신호를 기대하고 생성합니다. 이 동작은 단일 작업 동기 시나리오에서 신호가 필요하거나 필요하지 않을 수 있는 RosettaNet 사양과 다릅니다. BTARN이 응답자인 경우 항상 초기자의 메시지에 대한 응답으로 신호를 생성합니다. BTARN이 개시자인 경우 항상 응답자로부터 신호를 다시 받아야 합니다. BTARN이 신호를 수신하지 않으면 프로세스 구성 설정의 속성에 Time To Perform 지정된 간격 이후에 시간이 초과되고 0A1 메시지가 생성됩니다.
BTARN은 수신된 메시지에서 UTF-16을 지원합니다.
BTARN은 문자 집합이 UTF-16인 메시지를 수신하고 처리합니다. BTARN은 UTF-8 문자 집합으로 메시지를 보냅니다.
네임스페이스는 요청 메시지에서 매핑된 응답 메시지에서 제거해야 합니다.
이중 작업 시나리오의 프라이빗 프로세스에서 BizTalk 매퍼를 사용하는 경우 BizTalk Mapper는 요청 메시지에서 매핑된 응답 메시지 인스턴스의 일부 요소 태그에 네임스페이스를 추가합니다. 이러한 네임스페이스는 송신 파이프라인에서 실패를 일으킵니다. 이러한 네임스페이스를 제거해야 합니다. HeaderHelper 샘플을 사용하여 이 작업을 수행합니다. 자세한 내용은 이중 작업 PIPAutomation 오케스트레이션 [RN3] 및 4단계: HeaderHelper 프로젝트 만들기 [RN3]를 참조하세요.
URI 설정을 변경하려면 IISRESET이 필요합니다.
설치 프로그램을 실행하는 동안 수신 및 보내기 .aspx 페이지에서 사용하는 URI 설정과 수신 및 송신 어댑터의 URI 설정을 설정합니다. .aspx 페이지 또는 어댑터가 설치된 컴퓨터의 이름을 변경하는 경우 이러한 설정을 변경해야 합니다. 구성 프로세스를 다시 실행하여 이러한 설정을 변경할 수 있지만 모든 구성 설정을 다시 설정해야 합니다. 연결된 레지스트리 키(AsyncReceivePortURI, RNIFSenderURI및 SyncReceivePortURI)를 변경하여 URI 설정을 변경할 수 있습니다. 이러한 레지스트리 설정 중 하나를 변경한 후 변경 내용을 적용하려면 IISRESET을 실행해야 합니다. 이는 BTARN이 해당 용도로 설정을 캐시하기 때문입니다. IISRESET을 실행한 후 BizTalk 서비스도 다시 시작해야 합니다.
BTARN은 RNIF v1.1 열거형에 대한 제한을 적용하지 않습니다.
RNIF(RosettaNet 구현 프레임워크) 사양 v1.1은 일부 RNIF 스키마 열거에 대한 제한을 지정합니다. BTARN은 이러한 제한을 적용하지 않으며 이러한 제한 사항에 대해 유효성을 검사하지 않습니다. 제한 사항은 RNIF v2.01에는 적용되지 않습니다.
이는 다음 서비스 헤더 요소에 해당합니다.
GlobalBusinessActionCodeGlobalPartnerClassificationCodeGlobalBusinessServiceCodeGlobalProcessCodeGlobalProcessIndicatorCodeVersionIdentifier
PerformanceControlRequest 매개 변수는 기본 프로세스 구성 설정을 재정의하지 않습니다.
들어오는 메시지에는 서비스 헤더에 매개 변수가 포함될 PerformanceControlRequest 수 있습니다. 이러한 매개 변수에는 BTARN 관리 콘솔에서 만든 프로세스 구성 설정에 설정된 대로 승인할 시간(영수증) 및 수행 시간 지연 매개 변수에 대한 값이 포함됩니다. BTARN은 들어오는 메시지의 매개 변수에 따라 시간 지연을 PerformanceControlRequest 동적으로 설정하지 않습니다. BTARN은 프로세스 구성 설정에 설정된 기본 PIP 값에서 항상 시간 지연을 받습니다. 이는 RNIF(RosettaNet 구현 프레임워크) 사양 v1.1을 따릅니다.
이중 작업 메시지의 PIP 이름 및 PIP 버전은 대/소문자를 구분합니다.
응답 메시지의 PIP 이름 및 PIP 버전이 원래 이중 작업 요청 메시지의 해당 값과 다른 경우 초기자 BTARN은 응답 메시지를 유효하지 않은 것으로 거부하고 응답자에게 예외를 반환합니다.
BTARN은 활성 프로세스가 있는 동안 계약 설정 변경을 지원하지 않습니다.
규약 속성에 대한 변경 내용은 적용 또는 확인을 클릭하여 수락하는 즉시 적용됩니다. 규약을 변경하면 이미 실행 중인 프로세스의 새 활동 또는 해당 계약과 관련된 새 프로세스에서 변경된 규약 속성을 사용합니다. 규약을 변경할 때 실행 중인 프로세스가 있는 경우 메시지에 이전 규약 속성을 이미 사용했을 수 있습니다. 해당 프로세스의 새 메시지는 예측할 수 없는 결과를 생성할 수 있는 새 계약 설정을 사용합니다. 실행 중인 프로세스가 없는 경우 규약 설정을 변경하는 것이 좋습니다.
BTARN은 프로세스 구성 프로필을 변경한 후 필드 간 유효성 검사를 수행하지 않습니다.
프로세스 구성 프로필을 만든 다음 규약을 만들 때 BTARN은 필드 간 유효성 검사를 수행하여 규약 및 프로필의 속성이 호환되는지 확인합니다. 예를 들어 Standard 속성이 "CIDX"로 설정된 프로필의 경우 규약의 0A1 규약 속성이 "No 0A1"로 설정되어 있는지 확인합니다. 그러나 규약을 만든 후 프로세스 구성 프로필을 변경하는 경우 BTARN은 필드 간 유효성 검사를 수행하지 않습니다. Standard 속성을 "RosettaNet"에서 "CIDX"로 변경하는 경우 BTARN은 계약의 0A1 규약 속성이 "No 0A1"로 설정되어 있는지 확인하지 않습니다.
모든 오케스트레이션이 시작되지 않은 경우 오류가 발생합니다.
BTARN 설치 프로그램은 9개의 오케스트레이션을 설치합니다. BTARN이 메시지를 성공적으로 처리하려면 처리를 시작하기 전에 이러한 오케스트레이션 9개를 모두 바인딩, 인리스트먼트 및 시작해야 합니다. 자세한 내용은 BizTalk Server 도움말의 "BizTalk Explorer 오케스트레이션 관리" 또는 "오케스트레이션 관리" topics 참조하세요.
RNIFReceive.aspx는 메시지에서 MIME 아래쪽 경계를 제거하지 않습니다.
RNIFReceive.aspx 페이지가 파트너의 RNIFSend.aspx 페이지에서 메시지를 받으면 메시지에는 MIME 헤더와 MIME 위쪽 및 아래쪽 경계, 기본 64 번호가 포함됩니다. RNIFSend.aspx는 RNIF 전송을 위해 메시지에 헤더와 경계를 추가합니다. RNIFReceive.aspx는 메시지를 공개 프로세스에 제출하기 전에 메시지에서 MIME 헤더 및 경계를 제거해야 합니다. RNIFReceive.aspx는 MIME 헤더와 위쪽 경계를 제거하지만 아래쪽 경계는 제거하지 않습니다. 아래쪽 경계의 존재는 공개 프로세스에서 메시지 처리에 영향을 주지 않습니다.
BTARN은 SQL Server 데이터베이스의 대/소문자 구분 구성을 지원하지 않습니다.
BTARNSQL 서버 데이터베이스 및 데이터베이스 개체의 대/소문자를 구분하는 경우 BTARN 관리 콘솔에서 데이터베이스 리소스를 찾을 수 없고 예외가 throw됩니다. BTARNSQL 서버 데이터베이스 및 데이터베이스 개체는 대/소문자를 구분하지 않아야 합니다.
데이터베이스 유지 관리 스크립트의 모든 쿼리는 UTC 시간 동안 작성해야 합니다.
BTARN SQL Server 데이터베이스는 UTC(유니버설 시간 좌표) 시간을 사용하므로 이러한 데이터베이스 중 하나를 유지하기 위해 만드는 모든 쿼리는 UTC 시간 동안 작성해야 합니다. 예를 들어 유지 관리 스크립트가 명령을 사용하는 GetDate() 경우 를 로 GetUTCDate()변경해야 합니다.
PublicResponder 오케스트레이션은 중복 요청 작업 메시지를 거부합니다.
PublicResponder 오케스트레이션(PublicResponderV11.odx)이 중복 요청 작업 메시지를 받으면 이벤트 로그에 경고를 기록한 다음 메시지를 거부합니다. 응답기 오케스트레이션이 완료된 후 중복 메시지가 수신되면 BizTalk Server 구독이 없으므로 메시지를 중지합니다.
공용 프로세스가 중지된 경우 전송 오류는 BAM에 표시되지 않습니다.
퍼블릭 프로세스 오케스트레이션이 최종 메시지를 처리할 때 전송 오류가 발생하면 이벤트 로그와 HAT에 오류가 표시되지만 BAM은 그렇지 않습니다. 오케스트레이션이 중지되었으므로 BAM에서 메시지를 표시할 수 없습니다.
pipeline.exe 도구를 사용하여 BTARN 수신 파이프라인을 디버그할 수 없습니다.
수신 파이프라인을 디버그하려면 파이프라인을 호스트하는 포트를 만들어야 합니다. BizTalk Server 제공하는 pipeline.exe 도구를 사용하여 디버그할 수 없습니다.
오케스트레이션이 완료된 후 성공적으로 처리되는 재시도된 메시지에 대한 오류가 생성될 수 있습니다.
BTARN은 오케스트레이션을 사용하여 프로세스 흐름을 나타냅니다. 재시도된 여러 메시지가 다시 시도되는 경우 재시도된 메시지가 BizTalk MessageBox에 도착하기 전에 오케스트레이션이 성공적으로 완료될 수 있습니다. 이 동작이 발생하면 BizTalk Server 해당 "완료되었지만 삭제됨" 오류 메시지를 생성합니다. LOB(기간 업무) 애플리케이션을 확인하여 프로세스가 완료되었는지 여부를 확인해야 합니다. LOB 애플리케이션이 성공적인 완료를 나타내는 경우 "완료되었지만 삭제됨" 메시지를 무시할 수 있습니다.
tracking.xls 내보낸 XML 파일에 잘못된 필드가 있을 수 있습니다.
추적 XLS 파일에서 새 추적 뷰를 정의하고 추적 XLS 파일에서 XML 파일을 내보내면 일부 필드 이름이 약간 수정됩니다. 이 문제를 해결하려면 BTARN 설치 프로그램에서 설치한 표준 tracking.xml 필드에 대해 사용자 지정된 추적 XML 파일의 필드를 확인합니다.
신호 및 응답에 대한 RNIF 1.1 서비스 헤더 스키마를 수정해야 할 수 있습니다.
BTARN은 모든 RosettaNet 헤더 스키마를 기본으로 제공합니다. 일부 구현에서는 아래 설명된 대로 신호 제어 및 작업 제어 노드를 다른 구현과 다르게 사용합니다.
BTARN은 아래와 같이 신호 제어 요소를 제공합니다. Action Control 요소도 마찬가지일 수 있습니다.
<!ELEMENT SignalControl (
InstanceIdentifier,
PartnerRoute,
SignalIdentity,
inResponseTo)>
솔루션에 이 시퀀스가 필요한 경우 아무 작업도 수행할 필요가 없습니다.
반면에 다른 구현에서는 다음 코드를 사용합니다.
<!ELEMENT SignalControl (
inResponseTo,
InstanceIdentifier,
PartnerRoute,
SignalIdentity)>
솔루션에 이 시퀀스가 필요한 경우 KB 889523 참조하세요. 이 소프트웨어 업데이트는 해당 XML 스키마를 변경합니다. 이 업데이트는 RNIF 1.1 프로세스에만 영향을 줍니다.
PipAutomationGetAction SQL 저장 프로시저를 업데이트해야 합니다.
단일 레코드를 잠그려면 PipAutomationGetAction SQL 저장 프로시저를 업데이트해야 합니다. 다음 줄을 삭제합니다.
IF @@ERROR <> 0
UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID
올바른 PipAutomationGetAction 저장 프로시저는 다음과 같습니다.
CREATE PROCEDURE PipAutomationGetAction
AS
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRANSACTION
DECLARE @tempGUID nvarchar(36)
SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB WITH (READPAST,UPDLOCK,ROWLOCK)
WHERE Delivered = 0 AND MessageCategory = 10
ORDER BY TimeCreated
SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion, ServiceContent FROM MessagesToLOB
WHERE MessageID = @tempGUID
For xml auto
UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID
COMMIT TRANSACTION
GO
aspx 코드를 사용자 지정하여 오류 설명을 반환할 수 있습니다.
오류 설명을 기록하거나 보내야 하는 경우 응답에 실제 텍스트가 반환되도록 aspx 코드를 사용자 지정할 수 있습니다. 이렇게 하려면 HttpResponse.Status(기본 asp 요청의 응답 개체) 또는 HttpWebResponse.StatusDescription(HttpWebRequest 개체의 GetResponse 메서드에 대한 .NET 호출에 의해 반환됨)을 사용합니다. 적용 가능한 응답 개체 중 하나에서 반환 값을 반환하려면 BTARN과 함께 제공되는 aspx 코드에서 Response.StatusCode가 설정된 방식과 유사한 Response.Status 값을 설정합니다.
인코딩 메서드가 Base64로 설정된 경우 RNIF 1.1 메시지를 부인하지 않는 테이블에서 일반 텍스트로 읽을 수 없습니다.
이는 인코딩 메서드가 Base64로 설정된 경우에만 발생합니다. 인코딩 메서드가 따옴표로 묶인 인쇄 가능 또는 8비트로 설정된 경우 거부하지 않는 테이블에서 메시지를 지우는 텍스트로 읽을 수 있습니다. *.eml 확장명으로 메시지 파일을 저장한 다음 Outlook Express를 사용하여 열어 메시지를 읽어야 하며 Outlook Express에서 메시지를 디코딩합니다. 아래 코드를 사용하여 부인하지 않는 테이블에서 Base64로 인코딩된 메시지를 읽을 수도 있습니다.
byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);
string plainText = Encoding.UTF8.GetString(textBytes);
txtOutput.Text = plainText;