Que CORRIGE: El Adaptador de EDI de BizTalk Server sólo admite un conjunto limitado de tipos de documento de BizTalk Server 2004

El Adaptador de EDI de Microsoft BizTalk Server sólo admite un conjunto limitado de tipos de documento. El adaptador de EDI no funcionará con ningún tipo de documento de que de los de unos tipos, proporciona esquemas. Es posible recibir el mensaje de error siguiente cuando intenta utilizar sus propio esquemas para los tipos de documento para los que no proporciona esquemas servidor BizTalk Server:

Información de Service Pack

Para resolver este problema, consiga la última versión de Service Pack para Microsoft BizTalk Server 2004. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base

Información de revisión

Requisitos previo

Ningún requisito previo es necesario.

Reinicie requisito

No es necesario que reinicie el equipo una vez aplicado este hotfix

Información de reemplazo de revisión

Este hotfix no sustituye a otros hotfix

Información de archivo

La versión en inglés de este hotfix tiene los atributos de archivo (o atributos de último archivo) mostrados en la siguiente tabla Las fechas y los tiempos para estos archivos aparecen en hora universal coordinada (en UTC). La información de los archivos se convertirá a la hora local cuando la vea Para ver la diferencia entre hora UTC y hora local, utilice la ficha Zona horaria en la herramienta Fecha y hora en Panel de control. Nota Debido a dependencias de archivos, también el hotfix más reciente que contiene estos archivos puede contener archivos adicionales.

Instale notas

1. Descomprima o copie todos los archivos en la raíz de su directorio de instalación BizTalk 2004. De forma predeterminada, el directorio de instalación es C:\Program Programa\Microsoft BizTalk Server 2004.
2. Ejecute la secuencia de comandos updateEDI.sql que se encuentra en la carpeta EDI\Adapter\Bin\Config contra la base de datos (BizTalkEDIDb) EDI de Base de BizTalk o por utilizar opcionalmente el archivo updateEDI.bat (Modificar que el nombre de servidor y la base de datos primero asignan un nombre (Modificar)) por lotes.

Microsoft ha confirmado que se trata de un problema de los productos de Microsoft enumerados en la sección "La información de este artículo se refiere a:". Este problema se corrigió en BizTalk Server 2004 Service Pack 1.

Cuando instala esta revisión, BizTalk Server 2004 puede trabajar con cualquier tipo de documento EDI incluso para aquellos tipos de documento para los que no proporciona esquema XSD servidor BizTalk Server.

Out-of-the-box entregados por esquemas

Los esquemas siguientes se incluyen en BizTalk Server 2004:Importante En el momento de lanzamiento, sólo estos esquemas se prueban con BizTalk Server 2004. Ellos son los esquemas únicos que se sabe que funcionen con BizTalk Server 2004.

Versiones compatibles de formato

Las versiones siguientes de formato (versiones Segmentos de Control) son compatibles con el Adaptador de EDI de Base de los estándares de X 12 y de EDIFACT después de que aplica este hotfix.

X 12

El Adaptador de EDI de Base admite las versiones siguientes de formato X 12 : 2040, 3010, 3020, 3030, 3040, 3050, 3060, 3070, 4000, 4010, 4020, 4030, 4040 y 4050.

Cuando se recibe que un intercambio tiene una versión posterior que la versión 4050 (para ejemplo cuando la versión que se indica en el segmento ISA es posterior que "00405") de los segmentos de control, el sistema intentará analizarlo con la versión más alta (para ejemplo 4050).

Esta versión de formato no se relaciona con la versión de transacción. Se especifica la versión de transacción en el segmento GS. Siempre que el usuario tiene un esquema que representa el tipo de transacción y la versión de transacción que desea el usuario, el sistema puede aceptar aquella versión en lo entrante y lo generará en lo saliente.

EDIFACT

Las Versiones : UNOA Adaptador de EDI de Base de soporte técnico el formato (o Sintaxis siguientes de EDIFACT) y UNOB versiones 1 a 3.

Nota En el artículo siguiente de Microsoft Knowledge Base (KB) se describe un hotfix design-change que mejora compatibilidad de sobre en el Adaptador de EDI de Base:Los intercambios de EDIFACT deben tener la indicación correcta de la sintaxis en el segmento UNB. Los intercambios que se reciben que tienen una indicación de una sintaxis determinada en el segmento UNB (por ejemplo UNOA) deben seguir el juego de caracteres que pertenece a aquella sintaxis. El identificador de sintaxis en el segmento UNB es obligatorio.

Subconjuntos de los estándares principales

Tenga en cuenta que sólo los estándares principales son compatibles con el Adaptador de EDI de Base. Por ejemplo, existen los subconjuntos siguientes en la X 12 estándar:

• VIC
• GANA
• UCS
• TCIF

Existen los subconjuntos siguientes en el estándar de EDIFACT:

• EANCOM
• ODETTE
• Inovert

Ningún subconjunto es admitido por el Adaptador de EDI de Base incluido en BizTalk Server 2004. Para admitir estas variaciones de subconjunto, debe utilizar Acelerador de EDI de CovastÆs.

Autorizar esquemas que no suministraron out-of-the-box

Para todos los esquemas que suministran out-of-the-box, puede configurar no en los cuadros de diálogo de Puerto de envío y de Ubicación de recepción para el Adaptador de EDI de Base, los los que están transportados.

Para los esquemas que no suministran out-of-the-box, sólo puede especificar que (todos de ellos) se permiten (en el cuadro de diálogo Ubicación de recepción) y la versión predeterminada de formato que se utilizará para la X 12 y EDIFACT instancia en lo saliente (en el cuadro de diálogo de Puerto de envío).

A estas configuraciones se les encuentran cuadros de diálogo en la categoría "Admitir Documento Tipos" en la Ubicación de recepción y configuraciones de transporte Adaptador de EDI de Base de Puerto de envío. Para autorización entrante, establezca Accept all unlisted documents en Sí en la configuración Ubicación de recepción. Para autorización saliente, establezca Accept all unlisted documents en Sí en la configuración de Puerto de envío.

También establezca Default X12 format version para X 12, Default EDIFACT format version para EDIFACT o ambos a la versión de formato correcto (sobre).

Base requisitos de esquema Adaptador de EDI

Al crear esquemas personalizados EDI que utiliza con el Adaptador de EDI de Base, aquellos esquemas deben seguir un número de reglas. BizTalk Server 2004 es mucho más estricto que versiones anteriores de servidor BizTalk Server. En esta sección se describen las reglas y los requisitos de utilizar esquemas personalizados o migrados con el Adaptador de EDI de Base.

Declaraciones EDI de elemento y segmento

En esta sección se describen los requisitos conocidos que debe cumplir un esquema XSD para aceptar y utilizar correctamente por el Adaptador de EDI de Base. Empiezan con el objeto más bajo de nivel, los siguientes son los requisitos de declaración de elemento para un esquema EDI:

Elementos

Cada elemento EDI se define como xs:attribute en XSD. Si el elemento es un elemento secundario de un elemento compuesto, el elemento debe usar la convención siguiente de nomenclatura:Por ejemplo, C04001, C04002, C04003 si el segmento primario se denomina C040, los elementos secundarios se deben denominar sucesivamente. El elemento compuesto se define posteriormente en esta sección.

Los atributos importantes en un elemento EDI se encuentran en el nodo b:fieldInfo y son como sigue:

• edi datatype este atributo debe adoptar uno de los valores siguientes u N9, N, N0, TM R identificador AN DT. No se permite ningún otro valor de este atributo.
• formato Este atributo es obligatorio cuando DT o TM son el atributo edi datatype.
  • El formato debe adoptar uno de los valores siguientes MMDDAA AAMMDD AAAAMMDD DDMMAA DDMMAAAA MMDDAAAA cuando DT es el atributo edi datatype.
  • El formato debe adoptar uno de los valores siguientes cuando TM es el atributo edi datatype : HHMMSS o HHMM.
• codelist Este atributo es opcional y se asigna a un conjunto de valores dentro de EDICodelist.mdb. De manera predeterminada, esta base de datos de Microsoft Access se encuentra en la carpeta de servidor BizTalk Server 2004\EDI\Adapter\CodeLists %ProgramFiles%\Microsoft. Sólo utiliza un conjunto de valores de esta lista de código cuando identificador es el atributo edi datatype. Una alternativa al uso de una lista de código consiste en que utiliza una Enumeración bajo el nodo simpleType.
  
  Nota Para extender la base de datos codelist, consulte la sección "Additions y cambios en código muestran".
• sequence number Este atributo se utiliza para definir la secuencia en el nodo primario. Es opcional. Hay el orden predeterminado de elementos el orden en el que aparecen en el archivo.

Elementos compuestos

Los elementos compuestos contienen un conjunto de elementos que se relacionan entre ellos. El uso de composiciones implica que se utilizan separadores especiales en los archivos nativos EDI. En vez del separador de elementos habituales+ el .El, por ejemplo, en EDIFACT, se separan componentes de una composición de forma predeterminada por unos : el atributo name es obligatorio. Tiene que cumplir una regla. Cuando es la primera aparición, debería corresponder al valor del atributo tag_name del secundario recordInfo de este segmento. Cuando hay no la primera aparición de este segmento, un _ se debería agregar con un número de secuencia única como se lo muestra en el ejemplo siguiente: El valor del atributo tag_name es prescrito por la X 12 o por EDIFACT estándar y no se debería elegir aleatoriamente.

Los atributos importantes en un elemento compuesto EDI se encuentran en el nodo b:recordInfo y son como sigue:

• tag name Este atributo debe coincidir con el nombre compuesto sin el número de secuencia. Por ejemplo, si C040 o C040_1 son el elemento compuesto, el atributo tag name debe tener el valor C040.

Segmentos

• Segmentos con elemento compuesto

  <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>
  

• Segmentos sin un elemento compuesto

  <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>
  

El atributo name es obligatorio. Tiene que cumplir una regla. Cuando es la primera aparición, debería corresponder al valor del atributo tag_name del secundario recordInfo de este segmento. Cuando hay no la primera aparición de este segmento, un _ se debería agregar con un número de secuencia única como se lo muestra en el ejemplo siguiente: El valor del atributo tag_name es prescrito por la X 12 o por EDIFACT estándar y no se debería elegir aleatoriamente.

En este caso, sequence number sólo se utiliza cuando se ha repetido el segmento. Por ejemplo, si existe BGM, la aparición siguiente de BGM se debe denominar BGM_1.

Los atributos importantes dentro de un segmento EDI se encuentran en el nodo b:recordInfo y son como sigue:

• tag name Este atributo debe coincidir con el nombre de segmento sin el número de secuencia. Por ejemplo, si el segmento se llama BGM o BGM_1, el atributo tag name debe tener el valor BGM.

Loop-segments

Loop-segments pueden contener cualquier uno o más de los siguientes:

• Otros loop-segments
• Segmentos con elementos compuestos
• Segmentos sin elementos compuestos

Loop-segments no pueden contener elementos. Loop-segments deben utilizar la convención siguiente de nomenclatura: Los atributos importantes dentro de un loop-segment EDI se encuentran en el nodo b:recordInfo y son como sigue:

• No debe ser un atributo tag name.

NombreDeTabla

Esta parte del XSD es obligatoria.El NombreDeTabla sólo puede contener uno o varios de los elementos siguientes:

• Loop-segments
• Segmentos con elementos compuestos
• Segmentos sin elementos compuestos

El NombreDeTabla debe utilizar la convención siguiente de nomenclatura:

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

Nota El formato que se utiliza depende del EDI estándar real, de la versión EDI y del tipo de documento.

<xs:schema>

Esta parte de XSD es obligatoria.El nodo b:schemainfo aparece en xs:schema. Los atributos importantes dentro de xs:schema se encuentran en el nodo b:schemaInfo y son como sigue:

• root reference Este atributo debería coincidir con el nombre del nodo de raíz.
• document type Este atributo debe ser el tipo de documento real. Por ejemplo, este atributo debe ser u 850 para el tipo de documento X 12 o INVOIC para el tipo de documento Edifact.
• estándar Este atributo debe tener un valor de X 12 o de EDIFACT.
• standards version Este atributo debe ser la versión del estándar determinado. Por ejemplo, debe ser este atributo una de las acciones siguientes u 4010 para X 12 o d93a para Edifact.
  
  Nota Los standards version deben coincidir exactamente con la parte standards version del nombre NombreDeTabla de incluir distinguir mayúscula de minúscula.

Estructura de esquema EDI de elemento y segmento

Dentro de XSD, existen muchas formas de que obtiene el resultado deseado. Con el Adaptador de EDI de Base para BizTalk Server 2004, hay sólo una estructura aceptable para un esquema EDI. Cada segmento debe tener una declaración en la raíz del esquema. El segmento debe utilizar un nodo de referencia para indicar dónde cabe en el documento. Los dos ejemplos siguientes muestran una estructura para el Adaptador de EDI de Base con formato incorrecto y una estructura para el Adaptador de EDI de Base con formato correcto.

Ejemplo 1: Formulario incorrecto para el </B> Adaptador de EDI de BaseEjemplo 2 :: Formato correcto y aceptable para el </B> Adaptador de EDI de Base

Adiciones y cambios en listas de código

Dichas listas de código para versiones de formato que no son out-of-the-box enviado se deben agregar manualmente a la base de datos de lista de código. El nombre de la base de datos de código es Edicodelist.mdb (base de datos de Microsoft Access).

Edicodelist.mdb se encuentra en la carpeta 2004\EDI\adapter\Codelists BizTalk Server de Programa\Microsoft de Programa. La base de datos contiene una tabla para cada versión de formato, cuando agrega una versión nueva de formato, puede copiar una tabla similar y a continuación, cambiar el nombre de ello.

El nombre de tabla debe tener el formato siguiente _ StandardsVersion Estándar. ""EDIFACT_D93B o "X12_4050" por ejemplo.

Otros valores establecidos de código se deben agregar o se quitar manualmente de la base de datos Edicodelist.mdb. Las entradas se pueden agregar a tablas existentes al extender el número de conjuntos de códigos.

Esta información sólo se utiliza en tiempo de diseño. Se tiene el acceso a las tablas cuando el usuario ejecuta la función ValidateSchema para un Esquema de EDI en el Explorador de soluciones de BizTalk. No se admiten las características siguientes XSD:

• Herencia
• Grupos de sustitución
• No se permite ningún pedido de grupo excepto "secuencia". "Opción" y "todos" no se permiten en concreto.
• anyElement
• anyAttribute
• Importación
• Inclui
• Vuelva a definir

Diversas limitaciones de esquema EDI

• Sin compatibilidad flotante de segmento. Esta limitación coincide como en Microsoft BizTalk Server 2002.
• Compatibilidad de segmento binario muy limitado. Esta limitación coincide como en BizTalk Server 2002.
• No se transmiten datos Sobre de EDI en lo entrante. Por tanto, los datos no están disponibles para uso en el Asignador de BizTalk u orquestaciones. Esta limitación coincide como en BizTalk Server 2002.
• Los diseños Sobre de EDI no se pueden personalizar o no se pueden modificar. Esta limitación coincide como en BizTalk Server 2002.
• La lista de Identificadores de Funcional de X 12 compatibles es fija según la 4050 versión. Este medio de que no puede utilizar conjuntos de transacción que se introdujeron después de la versión 4050 porque qué identificador de grupo funcional no conoce el sistema pertenece a ello (porque aquél no es parte del esquema).
• La Anotación de EDI &lt; &gt; count_ignore b:RecordInfo "lo" = el Adaptador de EDI de Base lo omite. La Base EDI Adapter usa tecnología no modificable para contar los segmentos en transacciones EDI.
• El BizTalk Server 2004 Base EDI Adapter utiliza validaciones EDI de juego de caracteres más estrictas que BizTalk Server 2002. Por ejemplo, cuando se recibe un intercambio UNOA de EDIFACT, validará los caracteres del intercambio según el juego de caracteres definidos que pertenece a la sintaxis UNOA (que es un subconjunto de ISO-646).

Para obtener información adicional, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: