FIX: Il adapter EDI BizTalk Server solo supporta un insieme limitato di tipi di documento in BizTalk Server 2004

Il adapter EDI Microsoft BizTalk Server solo supporta un insieme limitato di tipi di documento. L'adapter EDI non funzionerà a alcun tipo di documento per cui diverso dai di tipi, esso fornisce gli schemi. Si visualizza il seguente messaggio di errore quando si tenta di utilizzare gli schemi proprio per i tipi di documento per cui non fornisce gli schemi BizTalk Server:

Informazioni Service Pack

Per risolvere questo problema, ottenere il service pack più recente per Microsoft BizTalk Server 2004. Per ulteriori informazioni, fare clic sul seguente numero di articolo per visualizzare l'articolo del Microsoft Knowledge Base:

Informazioni di correzione

Prerequisiti

Nessun prerequisiti non è necessario.

Riavviare il requisito

Non si deve riavviare il computer dopo aver applicato questa correzione rapida.

Informazioni di sostituzione di aggiornamento rapido

Questa correzione non sostituisce l'eventuali un'altra correzione rapida.

Informazioni sul file

La versione inglese di questa correzione ha gli attributi di file (o gli attributi successivi di file) quelli sono elencati nella seguente tabella. Le date e le volte per questi file sono visualizzate in Coordinated Universal Time (UTC) nell'elenco. Quando si visualizzano le informazioni sul file, viene convertito nella base all'ora locale. Per cercare la differenza fra UTC e fra l'ora locale, utilizzare la scheda disponibile Fuso orario nello strumento Data e ora in Pannello di controllo. Nota: A causa delle dipendenze fra i file, anche la correzione più recente che contiene questi file può contenere i file aggiuntivi.

Installare le note

1. Decomprimere o copiare tutti i file nella directory principale della directory di installazione BizTalk 2004. Per l'impostazione predefinita, la directory di installazione è BizTalk Server 2004 Programmi\Microsoft C:\Program.
2. Eseguire lo script updateEDI.sql che si trova nella cartella EDI\Adapter\Bin\Config contro il database EDI di base BizTalk (BizTalkEDIDb) o facoltativamente dall'utilizzo del file batch updateEDI.bat (Modifica che innanzitutto assegnano un nome il nome di server e il database).

Microsoft ha confermato che ciò è un problema nei prodotti Microsoft elencati nella sezione da "Applicare a". Questo problema veniva corretto in BizTalk Server 2004 Service Pack 1.

Quando si installa questa correzione, BizTalk Server 2004 può utilizzare qualsiasi tipo di documento EDI anche per quei tipi di documento per cui non fornisce schema XSD BizTalk Server.

Preconfezionare recapitati preconfezionare gli schemi

BizTalk Server 2004 i seguenti schemi include:Importante: Al momento di rilascio, solo questi schemi si verificano con BizTalk Server 2004. Esse sono gli unici schemi che è noto che funzionino con BizTalk Server 2004.

Le versioni supportate formate

Le seguenti versioni formate (versioni Segmenti Controllo) sono supportate dal adapter EDI Basare per gli standard X 12 ed EDIFACT dopo aver applicato questa correzione rapida.

X 12

Il adapter EDI Basare supporta le seguenti versioni formate X 12 : 2040, 3010, 3020, 3030, 3040, 3050, 3060, 3070, 4000, 4010, 4020, 4030, 4040 e 4050.

Quando un interscambio si riceve che dispone di una versione successiva alla versione 4050 (per l'esempio quando la versione che si indica nel segmento ISA è maggiore di "00405") dei segmenti di controllo, il sistema tenterà di analizzarlo con la versione massima (per l'esempio 4050).

Questa versione formata non è correlata alla versione di transazione. La versione di transazione si specifica nel segmento GS. Finché l'utente dispone di uno schema che rappresenta il tipo di transazione e la versione di transazione desiderati dall'utente, il sistema accetta quella versione sopra l'ingresso e lo genererà nell'esterno.

EDIFACT

Le Versioni di supporti il seguente formato (o Sintassi EDIFACT) : UNOA adapter EDI Basare e UNOB versioni 1 tra 3.

Nota: Nel seguente articolo di Microsoft Knowledge Base ( KB ) si descrive una correzione design-change che migliora il supporto di busta nel adapter EDI Basare:Gli interscambi EDIFACT devono contenere l'indicazione corretta della sintassi nel segmento UNB. Gli interscambi che si ricevono che dispongono di un'indicazione di una sintassi determinata nel segmento UNB (ad esempio UNOA) devono seguire il set di caratteri che appartiene a quella sintassi. L'identificatore di sintassi nel segmento UNB è obbligatorio.

Sottoinsiemi degli standard principali

Solo gli standard principali essere noti con il adapter EDI Basare supportato. Ad esempio, i seguenti sottoinsiemi esistono dentro il X 12 standard:

• VIC
• VINCE
• UCS
• TCIF

I seguenti sottoinsiemi esistono dentro lo standard EDIFACT:

• EANCOM
• ODETTE
• Inovert

Nessun sottoinsieme non viene supportato dal adapter EDI Basare che accompagna BizTalk Server 2004. Per supportare queste variazioni di sottoinsieme, è necessario utilizzare Acceleratore EDI CovastÆs.

Autorizzare gli schemi che non hanno avuto preconfezionare spedito

Per tutti gli schemi che hanno preconfezionare spedito, è possibile configurare.

Per gli schemi che non hanno preconfezionare spedito, è possibile specificare soltanto che (tutta di esse) è consentito (sopra la finestra di dialogo Indirizzo di ricezione) e la la versione formata predefinita utilizzata per il X 12 e per EDIFACT istanza (sopra la finestra di dialogo di porta di trasmissione) sopra l'esterno.

È possibile che queste impostazioni si trovino nella categoria "Supportare Tipi di documenti" sopra l' Indirizzo di ricezione e le impostazioni di trasporto di porta di trasmissione adapter EDI Basare Finestra di dialogo le caselle. Per l'autorizzazione nell'ingresso, impostare Accept all unlisted documents su Sì nella configurazione Indirizzo di ricezione. Per l'autorizzazione in uscita, impostare Accept all unlisted documents su Sì nella configurazione di porta di trasmissione.

Impostare anche Default X12 format version per X 12, per Default EDIFACT format version per EDIFACT o per entrambi alla versione di formato corretto (busta).

Requisiti di schema di base di adapter EDI

Quando si creano gli schemi personalizzati EDI che utilizza con il adapter EDI Basare, quegli schemi devono seguire numerose regole. BizTalk Server 2004 è molto più rigido alle versioni precedenti di BizTalk Server. In questa sezione si descrivono le regole e i requisiti per utilizzare gli schemi personalizzati o migrati con il adapter EDI Basare.

Dichiarazioni EDI di elemento e segmento

In questa sezione si descrivono i requisiti noti che uno schema XSD deve soddisfare per accettare e utilizzare correttamente dal adapter EDI Basare. A partire con l'oggetto di livello più basso, è i requisiti di dichiarazione di elemento per uno schema EDI:

Elementi

Tutto l'elemento EDI si definisce in XSD come xs:attribute. Se l'elemento è un figlio di un elemento composito, è necessario che l'elemento utilizzi la seguente convenzione di denominazione:Ad esempio, se il segmento di padre si chiama C040, gli elementi di figlio si devono denominare C04001, C04002, C04003 così via. L'elemento composito è definito in seguito in questa sezione.

Gli attributi più importanti all'interno di un elemento EDI sono nel nodo b:fieldInfo e sono la seguenti:

• edi datatype i valori u N9, N, N0 TM R ID AN DT, questo attributo, corrispondono a uno dei seguenti valori. Non è consentito. altro valore in questo attributo
• formato: Questo attributo è obbligatorio quando DT o TM è l'attributo edi datatype.
  • I valori MMDDYY AAMMGG YYYYMMDD DDMMYY DDMMYYYY MMDDYYYY, il formato, quando DT è l'attributo edi datatype corrispondono a uno dei seguenti valori.
  • I valori formato quando TM è l'attributo edi datatype corrispondono a uno dei seguenti valori : HHMMSS o HHMM.
• codelist: Questo attributo è facoltativo e si associa a un insieme di valori dentro EDICodelist.mdb. Per l'impostazione predefinita, questo database di Microsoft Access si trova nella cartella 2004\EDI\Adapter\CodeLists %Programmi%\Microsoft di BizTalk Server. Un insieme di valori da questo elenco di codici solo si utilizza quando ID è l'attributo edi datatype. Un'alternativa all'utilizzo di un elenco di codici consiste in utilizzare un'Enumerazione nel nodo simpleType.
  
  Nota: Per estendere il database codelist, vedere la sezione "Aggiunte e le modifiche di codice elenco".
• sequence number: Questo attributo si utilizza per definire la sequenza nel nodo di padre. Esso è facoltativo. L'ordine predefinito di elementi è l'ordine in cui sono visualizzati da esse nel file.

Elementi compositi

Gli elementi compositi contengono un insieme di elementi correlati a altri. L'utilizzo di compositi implica che i separatori speciali sono utilizzati nei file nativi EDI. Invece che il separatore di elemento normale+ il .The, ad esempio, in EDIFACT, i componenti di un composito sono by per l'impostazione predefinita separato un : l'attributo name è obbligatorio. Esso deve soddisfare una regola. Quando esso è la prima occorrenza, esso dovrebbe corrispondere al valore dell'attributo tag_name del child recordInfo di questo segmento. Quando esso non è la prima occorrenza di questo segmento, un _ dovrebbe essere aggiunto con un numero di sequenza univoca come il seguente esempio lo illustra: Il X 12 o EDIFACT standard prescrive il valore dell'attributo tag_name e non si dovrebbe selezionare casualmente.

Gli attributi più importanti all'interno di un elemento composito EDI sono nel nodo b:recordInfo e sono la seguenti:

• tag name: Questo attributo deve corrispondere al nome composito senza il numero di sequenza. Ad esempio, se C040 o C040_1 è l'elemento composito, l'attributo tag name deve avere il valore C040.

Segmenti

• Segmenti con l'elemento composito

  <xs:element name="name of segment">
   <xs:annotation>
    <xs:appinfo>
     <b:recordInfo 
  	tag_name="value defined according to X12 or EDIFACT standard"
  	structure="delimited" 
  	delimiter_type="inherit_record" 
  	field_order="postfix" 
  	escape_type="inherit_escape" 
  	count_ignore="yes" 
  	trigger_field="" 
  	trigger_value="" 
  	xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
          Insert definition of zero or more conditions 	
     </b:recordInfo>
    </xs:appinfo>
   </xs:annotation>
   <xs:complexType>
    <xs:sequence>	
     Refers to definition of composite. 
     <xs:element ref="name of composite">	
        <xs:annotation>
       <xs:appinfo>
        <b:recordInfo 
  	structure="delimited" 
  	delimiter_type="inherit_record" 
  	field_order="postfix" 
  	escape_type="inherit_escape" 
  	count_ignore="yes" 
  	xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
        </b:recordInfo>
       </xs:appinfo>
      </xs:annotation>
   </xs:element>
    </xs:sequence> 
     Insert definiton of zero or more elements.
   </xs:complexType>
  </xs:element>
  

• Segmenti senza un elemento composito

  <xs:element name="name of segment">
   <xs:annotation>
    <xs:appinfo>
     <b:recordInfo 
  	tag_name="value defined according to X12 or EDIFACT standard"
  	structure="delimited" 
  	delimiter_type="inherit_record" 
  	field_order="postfix" 
  	escape_type="inherit_escape" 
  	count_ignore="yes" 
  	trigger_field=" "
  	trigger_value=" "
  	xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
          Here, definitions of conditions can be inserted. 	
     </b:recordInfo>
    </xs:appinfo>
   </xs:annotation> 
   <xs:complexType>	
  	Insert definition of one or more elements.
  </xs:complexType>
  </xs:element>
  

L'attributo name è obbligatorio. Esso deve soddisfare una regola. Quando esso è la prima occorrenza, esso dovrebbe corrispondere al valore dell'attributo tag_name del child recordInfo di questo segmento. Quando esso non è la prima occorrenza di questo segmento, un _ dovrebbe essere aggiunto con un numero di sequenza univoca come il seguente esempio lo illustra: Il X 12 o EDIFACT standard prescrive il valore dell'attributo tag_name e non si dovrebbe selezionare casualmente.

In questo scenario, sequence number solo è utilizzato quando si è ripetuto il segmento. Ad esempio, se BGM esiste, ha BGM_1 il nome dell'occorrenza successiva di BGM.

Gli attributi più importanti all'interno di un segmento EDI sono nel nodo b:recordInfo e sono la seguenti:

• tag name: Questo attributo deve corrispondere al nome di segmento senza il numero di sequenza. Ad esempio, se il segmento si denomina BGM o BGM_1, l'attributo tag name deve avere il valore BGM.

Loop-segments

Loop-segments possono contenere un qualsiasi o quanto segue ulteriore:

• Altri loop-segments
• Segmenti con gli elementi compositi
• Segmenti senza gli elementi compositi

Loop-segments non possono contenere gli elementi. Loop-segments devono utilizzare la seguente convenzione di denominazione: Gli attributi più importanti dentro un loop-segment EDI sono nel nodo b:recordInfo e sono la seguenti:

• Non deve essere un attributo tag name.

rootNode

Questa parte del XSD è obbligatoria.Il rootNode solo può contenere uno o più seguenti elementi:

• Loop-segments
• Segmenti con gli elementi compositi
• Segmenti senza gli elementi compositi

Il rootNode deve utilizzare la seguente convenzione di denominazione:

• X12_ _ [ value of document type] [ value of standards version]
• _ [ value of document type] EFACT_ [ value of standards version]

Nota: Il formato utilizzato dipende dall'EDI standard effettivo, dalla versione EDI e dal tipo di documento.

<xs:schema>

Questa parte di XSD è obbligatoria.Il nodo b:schemainfo si visualizza xs:schema. Gli attributi più importanti dentro xs:schema sono nel nodo b:schemaInfo e sono la seguenti:

• root reference: Questo attributo dovrebbe corrispondere al nome del nodo principale.
• document type: Questo attributo deve essere il tipo di documento effettivo. Ad esempio, questo attributo deve essere l'u 850 per il tipo di documento X 12 o per INVOIC per il tipo di documento Edifact.
• standard: Questo attributo deve avere un valore di X 12 o di EDIFACT.
• standards version: Questo attributo deve essere la versione per lo standard particolare. Ad esempio questo attributo deve essere una delle seguenti operazioni u 4010 per X 12 o d93a per Edifact.
  
  Nota: Lo standards version deve corrispondere esattamente alla parte standards version del nome rootNode di includere che è il case-sensitive.

Struttura di schema EDI di elemento e segmento

Dentro XSD, esistono molti modi per ottenere l'output desiderato. Con il adapter EDI Basare di BizTalk Server 2004, è la struttura accettabile sola per uno schema EDI. Ogni segmento deve contenere una dichiarazione nella directory principale dello schema. Quindi il segmento deve utilizzare un nodo di riferimento per indicarsi dove esso rientra nel documento. Nei seguenti due esempi si illustra una struttura non correttamente formattata per il adapter EDI Basare e una struttura correttamente formattata per il adapter EDI Basare.

Esempio 1: Il modulo non corretto per il adapter EDI BasareEsempio 2: Il modulo corretto e accettabile per il adapter EDI Basare

Aggiunte e le modifiche agli elenchi di codici

È necessario che gli elenchi di codici per le versioni formate che non sono preconfezionare fornito si aggiungano manualmente nel database di riepilogo di codice. Il nome del database di codice è Edicodelist.mdb (database di Microsoft Access).

Il file Edicodelist.mdb si trova nella cartella 2004\EDI\adapter\Codelists BizTalk Server Programmi\Microsoft Programma. Il database include una tabella è possibile copiare una tabella simile e quindi per tutta la versione formata, quando si aggiunge una nuova versione formata, lo è possibile rinominare.

Il nome di tabella deve avere il seguente formato _ StandardsVersion Standard. ""EDIFACT_D93B o "X12_4050" ad esempio.

Altri valori impostati di codice si devono aggiungere o essere rimossi manualmente dal database Edicodelist.mdb. È possibile che le voci si aggiungano alle tabelle esistenti a estendere il numero degli insiemi di codici.

Queste informazioni solo sono utilizzate in fase della progettazione. Alle tabelle si accede quando l'utente esegue la funzione ValidateSchema per un Schema EDI nel Esplora soluzioni BizTalk. Le seguenti funzionalità XSD non sono supportate:

• Ereditarietà
• I gruppi di sostituzione
• Non è consentito. ordine di gruppo eccetto la "sequenza" La "scelta" e "tutto" non sono supportati specificamente.
• anyElement
• anyAttribute
• Importazione
• Includere
• Ridefinire

Varie limitazioni di schema EDI

• Nessun supporto mobile di segmento. Questa limitazione corrisponde Microsoft BizTalk Server 2002.
• Supporto di segmento binario molto limitato. Questa limitazione corrisponde BizTalk Server 2002.
• Il dato Busta EDI non viene fornito sopra l'ingresso. Quindi il dato non è disponibile per l'utilizzo nel BizTalk Mapper o nelle orchestrazioni. Questa limitazione corrisponde BizTalk Server 2002.
• I layout Busta EDI non si possono personalizzare o non possono essere modificati. Questa limitazione corrisponde BizTalk Server 2002.
• Elencati Identificatore Funzionale X 12 supportati viene risolto a detta della 4050 versione. Questo mezzo che non è possibile utilizzare i set di transazione che si introdurre dopo la versione 4050 perché quanto identificatore gruppo funzionale il sistema non sape appartiene a esso (perché quello non appartiene allo schema).
• L'Annotazione EDI < > count_ignore b:RecordInfo = "esegue" sì viene ignorato dal adapter EDI Basare. Il adapter EDI Basare utilizza la tecnologia hardcoded per contare i segmenti nelle transazioni EDI.
• Il BizTalk Server 2004 Base EDI Adapter utilizza le convalide impostate di carattere EDI più rigide di BizTalk Server 2002. Ad esempio, quando si riceve un interscambio EDIFACT UNOA, esso convaliderà i caratteri dell'interscambio a detta del set di caratteri definiti che appartiene alla sintassi UNOA (che è un sottoinsieme di ISO-646).

Per ulteriori informazioni, fare clic sul seguente numero di articolo per visualizzare l'articolo del Microsoft Knowledge Base: