수신한 EDI 메시지에 대한 규약 확인, 스키마 복구 및 인증
BizTalk Server EDI 메시지를 받으면 EDI 수신 파이프라인은 거래 업체 계약 조회, 스키마 검색 및 권한 부여 프로세스를 수행하여 메시지를 처리하는 방법을 결정합니다.
규약 확인
EDI 수신 파이프라인은 일련의 단계를 통해 메시지의 헤더 필드와 규약 정의의 속성 간에 일치 항목이 있는지 확인하여 거래 업체 규약을 확인합니다. BizTalk Server 규약을 결정하면 교환에 적용되는 문서 스키마를 결정합니다(아래 참조). 일치하는 규약과 연결된 속성 및 관련 스키마를 사용하여 받은 메시지의 유효성을 검사하고 처리합니다.
규약 해결을 수행하기 위해 BizTalk Server 다음과 같이 진행됩니다.
교환 헤더의 보낸 사람 한정자와 식별자 및 받는 사람 한정자와 식별자를 규약의 속성과 일치시켜 규약을 확인합니다.
1단계가 실패하면 교환 헤더의 보낸 사람 한정자와 식별자만 규약의 속성과 일치시켜 규약을 확인합니다. 또한 첫 번째 단계가 성공하지 못했기 때문에 BizTalk Server 메시지를 수신한다고 가정하는 것이 안전합니다. 따라서 BizTalk Server 수신기 한정자 및 식별자를 다음과 일치시키려고 시도합니다.
값 "BT" 및 "HostX12Recvr"(X12 인코딩된 메시지의 경우) 및
값 "BT" 및 "HostEdifactRecvr"(EDIFACT 인코딩된 메시지의 경우)
중요
- BizTalk Server 2013 R2, 2013 및 2010: ISA5, ISA6, ISA7, ISA8, UNB2.1, UNB2.2, UNB3.1 및 UNB3.2 필드는 규약 설정에서 필수입니다.
- BizTalk Server 2009 및 2006 R2: ISA7, ISA8, UNB3.1 및 UNB3.2 필드는 파티 설정에서 필수가 아닙니다. 필드가 비어 있으면 EDI 엔진이 ISA5, ISA6, UNB2.1 및 UNB2.2의 값에 따라 해결 방법을 제공합니다.
- BizTalk Server 2009 및 2006 R2부터 최신 버전의 BizTalk Server까지 해결 방법을 지원하기 위해 하드 코딩된 ID(HostX12Recvr 및 HostEdifactRecvr)와 한정자(BT)가 사용됩니다.
- EDIFACT 메시지는 메시지 구문 및 규칙에 대한 UNECE 지침을 따라야 합니다.
2단계가 실패하면 대체 규약 속성을 사용합니다.
첫 번째 단계에서 X12의 경우 BizTalk Server 다음 값을 사용하여 일치합니다.
ISA05(보낸 사람 한정자)
ISA06(보낸 사람 식별자)
ISA07(받는 사람 한정자)
ISA08(받는 사람 식별자)
EDIFACT의 경우 BizTalk Server 다음 값을 사용하여 일치합니다.
UNB2.1(보낸 사람 식별자)
UNB2.2(보낸 사람 한정자)
UNB3.1(받는 사람 식별자)
UNB3.2(받는 사람 한정자)
일치에 사용되는 규약 속성은 규약 속성 대화 상자의 방향별 규약 탭의 식별자 페이지에 정의됩니다.
이러한 수신 쪽 및 송신 쪽 속성 4개는 거래 업체 규약을 고유하게 식별합니다. 4개의 속성을 통해 보다 유연하게 수신 쪽 처리를 수행할 수 있습니다. 예를 들어 이 규약 확인 방법을 사용하면 송신 포트를 여러 개 만들지 않고도 여러 파티에 승인을 보낼 수 있습니다.
BizTalk Server 4개의 보낸 사람 및 수신자 한정자와 식별자를 모두 사용하여 규약을 resolve 수 없는 경우 보낸 사람 한정자와 식별자만 사용하여 규약을 resolve 시도합니다. X12의 경우 해당 필드는 ISA05와 ISA06입니다. 보낸 사람 및 수신자 속성의 일치와 마찬가지로 BizTalk Server 교환 헤더의 값을 규약 속성 대화 상자의 방향별 규약 탭의 식별자 페이지에 정의된 규약 속성과 일치합니다. 보낸 사람 한정자와 식별자만 사용하여 규약을 resolve 경우 수신자 한정자와 식별자는 규약 속성 대화 상자의 양방향 규약 탭에서 정의되지 않아야 합니다.
규약이 없으면 포트 설정에 인증이 필요하지 않은 한 BizTalk Server 대체 거래 업체 계약을 사용합니다. 포트 설정에 인증이 필요한 경우(인증이 실패할 경우 메시지 삭제 또는 인증 실패 시 메시지 유지가 수신 포트 속성의 일반 페이지에서 선택된 경우) 수신 포트에서 받은 교환에 대해 규약이 필요합니다. 이 경우 교환 헤더를 규약 속성과 일치시켜 규약이 확인되지 않으면 대체 규약 속성을 사용하여 규약을 확인할 수 없습니다. 규약을 찾을 수 없는 경우 교환은 인증에 실패한 것처럼 처리되며 일시 중단됩니다.
참고
계약이 설정 상태인 단계에서 메시지가 확인될 때까지 EDI 파이프라인의 메시지는 계약 확인의 다음 단계로 이동됩니다. 예를 들어 계약 확인의 첫 번째 단계에서 메시지가 확인되었지만 계약이 해제 상태인 경우에는 확인을 위해 메시지가 다음 단계로 이동됩니다.
스키마 검색
BizTalk Server 메시지로 확인되는 규약을 결정한 후에는 메시지의 유효성을 검사하고 처리하는 데 사용해야 하는 스키마를 결정해야 합니다. 이렇게 하려면 규약 속성 대화 상자의 단방향(송신 쪽) 규약 탭의 로컬 호스트 설정 페이지에서 식별된 속성을 사용합니다.
스키마를 확인하려면 BizTalk Server 먼저 스키마 네임스페이스를 결정해야 합니다. EDI 디스어셈블러는 BizTalk Server 함께 제공되는 표준 스키마에 기본 네임스페이스를 사용하거나 사용자 지정 스키마에 사용할 네임스페이스를 결정합니다.
규약 속성 대화 상자의 단방향 규약 탭에 있는 로컬 호스트 설정 페이지에서 사용자 지정 네임스페이스를 결정하는 값 그리드를 설정할 수 있습니다. 해당 표에 일치하는 항목이 없으면 EDI 디스어셈블러는 기본 행으로 표시된 대상 네임스페이스 필드에서 기본 네임스페이스를 사용합니다.
X12 스키마 검색
X12로 인코딩된 메시지의 경우 BizTalk Server 들어오는 교환의 헤더에서 애플리케이션 보낸 사람 식별자(GS02) 및 ST01(트랜잭션 집합 ID)을 사용하여 사용자 지정 네임스페이스를 결정합니다. 규약 속성 대화 상자의 양방향 규약 탭의 로컬 호스트 설정 페이지(트랜잭션 집합 설정 아래)에 있는 대상 네임스페이스 사용자 지정 표에서 이러한 값과 GS02 및 ST01 속성 값 간의 일치 항목을 찾으려고 합니다. 일치 항목을 찾으면 표의 동일한 행에서 식별된 대상 네임스페이스를 사용하여 메시지 유효성 검사 및 처리에 사용할 스키마를 확인합니다. 대상 네임스페이스가 확인되지 않으면 기본 대상 네임스페이스가 사용됩니다. 기본 행으로 표시된 대상 네임스페이스 필드에 네임스페이스가 식별되지 않으면 BizTalk Server 기본적으로 인코딩된 X12 메시지의 대체 규약 속성에서 식별된 대상 네임스페이http://schemas.microsoft.com/BizTalk/Edi/X12/2006스를 사용합니다.
X12 교환의 경우 대상 네임스페이스를 검색한 후 BizTalk Server 다음 정보를 사용하여 스키마를 결정합니다.
발견한 대상 네임스페이스
ST03의 처음 5자에 포함된 버전/릴리스(GS07 == X - 공인 표준 위원회 X12인 경우). ST03이 없거나 잘못되었거나 스키마를 확인하지 못하는 경우 GS08 또는 ISA12(GS07 != X인 경우)의 처음 5자를 통해 버전이 확인됩니다.
ST01의 DocType
EDI 디스어셈블러는 인코딩 유형, 버전/릴리스 및 DocType을 연결하여 스키마 이름을 확인합니다(예: "X12_00401_864"). 그런 다음, 대상 네임스페이스를 스키마 이름(예
http://schemas.microsoft.com/BizTalk/Edi/X12/2006/X12#X12_00401_864: )과 연결합니다.들어오는 HIPAA 837 교환의 경우 BizTalk Server 세 개의 HIPAA 837 스키마를 지원합니다.
| 837 스키마 | 버전 4010의 GS08 값 | 버전 5010의 GS08/ST03 값 |
|---|---|---|
| Claim-Dental_837D | 004010X097A1 | 005010X224A1 |
| Claim-Institutional_837I | 004010X096A1 | 005010X223A1 |
| Claim-Professional_837P | 004010X098A1 | 005010X222 |
참고
HIPAA 버전에서 트랜잭션 집합 278(의료 보험 서비스 검토)의 경우 요청 및 응답 쌍이 모두 GS08 및 ST01에 대해 동일한 값을 공유합니다. BHT02 필드의 트리거 값에 따라 버전 5010에서 278 요청/응답을 구분할 수도 있습니다.
- BHT02의 값 01, 13 및 36은 의료 보험 서비스 검토 요청을 나타냅니다.
BHT02의 2. 11은 의료 서비스 검토 응답을 나타냅니다.
EDIFACT 스키마 검색
EDIFACT로 인코딩된 메시지의 경우 BizTalk Server 들어오는 교환의 헤더에서 메시지 유형(UNH2.1), 메시지 버전 번호(UNH2.2), 메시지 릴리스 번호(UNH2.3), 할당된 코드(UNH2.5), 기능 그룹 ID(UNG2.1) 및 애플리케이션 송신 코드 한정자(UNG2.2)를 사용하여 사용자 지정 네임스페이스를 결정합니다. 그런 다음, 규약 속성 대화 상자의 양방향 규약 탭의 대상 네임스페이스 사용자 지정 표(트랜잭션 집합 설정 아래)에서 이러한 값과 UNH2.1, UNH2.2, UNH2.3, UNH2.5, UNG2.1 및 UNG2.2 속성의 값과 일치하는 값을 찾으려고 시도합니다. 일치 항목을 찾으면 표의 동일한 행에서 식별된 대상 네임스페이스를 사용하여 메시지 유효성 검사 및 처리에 사용할 스키마를 확인합니다. 대상 네임스페이스가 확인되지 않으면 기본 대상 네임스페이스가 사용됩니다. 기본 행으로 표시된 대상 네임스페이스 필드에 네임스페이스가 식별되지 않으면 BizTalk Server 기본적으로 인코딩된 EDIFACT 인코딩 메시지의 대체 규약 속성에서 식별된 대상 네임스페이http://schemas.microsoft.com/BizTalk/Edi/EDIFACT/2006스를 사용합니다.
EDIFACT 교환의 경우 대상 네임스페이스가 검색되면 BizTalk Server 다음 정보를 사용하여 스키마를 결정합니다.
발견한 대상 네임스페이스
UNH2.2의 메시지 버전 번호
UNH2.3의 메시지 릴리스 번호
UNH2.1의 메시지 유형
UNH2.5의 할당된 코드
EDI 디스어셈블러는 인코딩 유형, 버전, 릴리스 및 메시지 유형을 연결하여 스키마 이름을 확인합니다(예: "EFACT_D94A_CONTEN"). 그런 다음, 대상 네임스페이스를 스키마 이름(예
http://schemas.microsoft.com/BizTalk/Edi/Edifact/2006/EFACT#EFACT_D94A_CONTEN: )과 연결합니다.UNH2.5가 메시지에 있는 경우 EDI 디스어셈블러는 먼저 UNH2.5 값을 스키마 이름의 일부로 사용하여 일치하는 스키마를 찾으려고 합니다(예: "EFACT_D94A_CONTEN_TEST"). 일치하는 스키마를 찾을 수 없으면 EDI 디스어셈블러는 UNH2.5 값 없이 스키마를 찾습니다.
권한 부여
BizTalk Server 메시지의 필드와의 계약에 대해 정의된 권한 부여 및 보안 필드의 값을 확인합니다. 불일치가 있는 경우 BizTalk Server 교환을 일시 중단합니다. EDIFACT 인코딩된 메시지의 경우 해당 필드는 받는 사람 참조 암호(UNB6.1 및 UNB6.2)입니다. X12 인코딩된 메시지의 경우 해당 필드는 인증 한정자 및 정보(ISA1-2)와 보안 한정자 및 정보(ISA3-4)입니다.