Cómo funciona el desensamblador EDI
BizTalk Server realiza la mayor parte del procesamiento de los intercambios codificados con EDI recibidos en la canalización de recepción EDI (Microsoft.BizTalk.DefaultPipelines.EDIReceivePipeline). La canalización incluye el componente de canalización del componente de canalización de desensamblador EDI que realiza el siguiente procesamiento:
Divide varios intercambios de un único mensaje en intercambios independientes (si la propiedad de canalización "DetectMID" de la ubicación de recepción está definida como True). El desensamblador EDI lo consigue buscando un encabezado de control de intercambio (ISA, UNA o UNB) incluso después de que se haya encontrado un finalizador de control de intercambio (IEA o UNZ) has been encountered.
Valida el sobre.
Desensambla el intercambio.
Campos de desencadenador de procesos para intercambios HIPAA.
Valida EDI y las propiedades específicas del socio comercial, según corresponda. Esto incluye la validación de esquemas EDI, validación de campos cruzados para mensajes con codificación X12 (si está configurado), validación estructural de EDI y validación de esquemas extendida (si el esquema se ha personalizado con un nodo que no sea de tipo EDI). Para obtener más información, vea Validación de mensajes EDI recibidos.
Comprueba que los números de control de intercambio, grupo y conjunto de transacciones no son duplicados, si las comprobaciones están habilitadas en la página Validación (en Configuración de intercambio) de la pestaña acuerdo bidireccional del cuadro de diálogo Propiedades del contrato . Comprueba el número de control del intercambio con los intercambios recibidos anteriormente. Comprueba el número de control del grupo en relación con otros números de control de grupo en el intercambio. Comprueba el número de control del conjunto de transacciones con otros números de control del conjunto de transacciones de dicho grupo. Si se detecta un duplicado, el informe de estado indicará que existe un registro duplicado.
Genera un documento XML para cada conjunto de transacciones. En cada archivo XML, promociona la propiedad de contexto de BTS.MessageType y la define en el nombre de esquema con espacio de nombres.
Convierte todo el intercambio en XML si la propiedad de opción Procesamiento por lotes de entrada está establecida en uno de los dos valores conservar intercambio . Esta propiedad se puede establecer desde la página Configuración de host local en Configuración de intercambio de la pestaña acuerdo bidireccional del cuadro de diálogo Propiedades del contrato. La canalización de recepción promociona la propiedad ReuseEnvelope para identificar el intercambio como conservado.
Genera una confirmación técnica o funcional (si esta opción está configurada). Ésta puede incluir el procesamiento por lotes de las confirmaciones (si está configurado). Promueve la propiedad de contexto de BTS. MessageType, si lo establece igual al esquema de control en el
http://schemas.microsoft.com/EDI/{X12 or EDIFACT}espacio de nombres (por ejemplo, X12_997_Root para una confirmación 997). También promociona la propiedad de contexto EDI.DestinationPartyName, que garantiza que la confirmación se seleccionará para su envío. Para obtener más información, consulte Envío de una confirmación EDI.Realiza la división de documentos HIPAA 276/277 (solo la versión 5010) 834, 835 (solo la versión 4010) y 837, si se aplica.
Promociona o escribe propiedades en el contexto del mensaje (vea la siguiente sección).
Promocionar o escribir propiedades en el contexto:
Cuando el Desensamblador EDI procesa un mensaje recibido, promociona o escribe las siguientes propiedades en el contexto del mensaje:
Para un mensaje sin codificar X12, promueve las siguientes propiedades del sobre: ISA06, ISA08, ISA15; GS01, GS02, GS03, GS08; ST03 y ST01.
Nota
Para un intercambio HIPAA 837 entrante, BizTalk Server admite tres esquemas HIPAA 837: Claim-Dental_837D, Claim-Institutional_837I y Claim-Professional_837P. El ST01 para cada uno de estos es "837". Estos tres esquemas tienen valores diferentes para GS08 en la versión 5010: "005010X223A1" para 837I, "005010X224A1" para 837D y "005010X222" para 837P. Los esquemas tienen valores diferentes para GS08 en la versión 4010: "004010X096A1" para 837I, "004010X097A1" para 837D y "004010X098A1" para 837P.
Para un mensaje sin codificar EDIFACT, promueve las siguientes propiedades del sobre: UNB2.1, UNB2.3, UNB3.1, UNB3.1, UNB11; UNG1, UNG2.1, UNG3.1; UNH2.1, UNH2.2, UNH2.3.
Si se divide un intercambio procesado por lotes, escribe ISA_Segment y GS_Segment en el contexto de los mensajes con codificación X12, o bien escribe UNA_Segment, UNB_Segment y UNG_Segment en el contexto de los mensajes con codificación EDIFACT.
Nota
Los segmentos anteriores se escriben en el contexto. No se promocionan en el contexto. No obstante, puede anexar estos segmentos a un conjunto de transacciones mediante el ejemplo Message Enrichment. También puede tomar el código que anexa los ejemplos y agregarlo a un componente de canalización personalizado. Para obtener más información, vea Ejemplo de enriquecimiento de mensajes (BizTalk Server ejemplo).
Nota
La propiedad promocionada ISA_Segment contiene información de autorización o seguridad (ISA02, Información de autorización, e ISA04, Información de seguridad) que puede dar lugar a la divulgación de información. Puede usar la propiedad Mask security/authorization/password information en la propiedad de contexto (en la página Configuración de host local para configuración de intercambio para las propiedades del acuerdo bidireccional) para reemplazar cada carácter de los campos ISA02 e ISA04 por un carácter '#'. Se trata de un proceso unidireccional: los caracteres '#' no se pueden convertir en caracteres reales.
Para los mensajes con codificación X12 y EDIFACT, promociona ReuseEnvelope, que indica si un intercambio por lotes se divide o se conserva.
Si un intercambio por lotes se conserva, promociona las siguientes propiedades:
InboundTransportatLocation
InboundTransportType
ISA05
ISA07
ISA06
ISA08
ISA15
LastInterchangeMessage = {True|False}
MessageType
ReceivePortID
ReceivePortName
ReuseEnvelope
Analizar el sobre
La canalización de recepción EDI utiliza el esquema de control de encabezado para analizar el sobre de un mensaje EDI recibido y el esquema de documento EDI para analizar los mensajes o conjuntos de transacciones del intercambio.
Si se recibe un mensaje con codificación EDIINT o AS2 a través del transporte HTTP o HTTPS, el desensamblador EDI inspeccionará la propiedad de contexto BTS.MessageDestination. Si esa propiedad se define como SuspendQueue, lo que indica que se ha producido un error en el procesamiento de AS2 y que el mensaje se va a suspender, el desensamblador EDI actuará como un componente de canalización de paso a través y suspenderá el mensaje en el cuadro de mensajes.
Durante el análisis de intercambios EDIFACT, la canalización de recepción EDI elimina el indicador de versión utilizado para los caracteres de escape. El indicador de versión no está incluido en la validación EDI. La canalización de recepción EDI no incluye el indicador de versión cuando computa restricciones de longitud.
Juego de caracteres
Para los intercambios X12, las propiedades del Componente de canalización determinan el juego de caracteres que el desensamblador EDI utilizará para procesar el intercambio. Puede ser Básico, Ampliado o UTF8/Unicode. El valor predeterminado es UTF8. Para intercambios EDIFACT, el campo UNB1.1 determina el juego de caracteres.
Detección de separadores dinámicos
Cuando BizTalk Server recibe un intercambio EDI, ninguna propiedad de contrato indica cuáles deben ser los separadores del intercambio. En su lugar, el desensamblador EDI detecta cuáles son los delimitadores (para X12 o EDIFACT) en tiempo de ejecución.
Para los mensajes X12, el desensamblador EDI utiliza los siguientes caracteres desde el intercambio:
| Separador | Carácter |
|---|---|
| Separador de elementos de datos | 4.º carácter de ISA |
| Separador de elementos de componente | ISA16 |
| Separador de segmentos | 106.º carácter de ISA |
| Sufijo de terminador de segmento | Carácter entre el segmento ISA y el segmento GS Valores: Ninguno, CR, LF o CRLF Nota: el separador solo puede tomar los valores anteriores. |
| Separador de repeticiones o identificador estándar. (dependiendo de la propiedad de acuerdo "uso de ISA11" en la página Sobres de la pestaña acuerdo bidireccional) |
ISA11 |
Para los intercambios EDIFACT, el desensamblador EDI comprueba el segmento UNA que define los separadores del intercambio. Si el intercambio no dispone de un segmento UNA, que es opcional, el desensamblador utilizará los valores predeterminados definidos en las propiedades del componente de canalización.
| Separador | Carácter de UNA |
|---|---|
| Separador de elementos de componente | 4.º |
| Separador de elementos de datos | 5.º |
| Notación decimal | 6.º |
| Carácter de versión | 7.º |
| Carácter de repetición | 8.º |
| Separador de segmentos | 9.º |
| Sufijo separador de segmentos | Carácter entre los segmentos UNA y UNB Valores: Ninguno, CR, LF o CRLF Nota: el separador solo puede tomar los valores anteriores. |
La cadena UNA es opcional. Si está presente, define todos los delimitadores del archivo. Si no lo está, el desensamblador EDI utilizará la propiedad del componente de canalización EfactDelimiters para determinar los delimitadores. Para obtener más información, consulte Configuración de propiedades de canalización EDI.
Enviar errores
Si el desensamblador EDI detecta un error de procesamiento EDI, BizTalk Server envía los dos errores siguientes del Visor de eventos (si está habilitado ese envío):
Error registrado por el BizTalk Server de origen mientras suspende el mensaje. Se trata de un error necesario relacionado con el procesamiento de BizTalk Server.
Un error que notifica problemas en el conjunto de transacciones, tal y como registra el origen BizTalk Server EDI. Se trata de un error específico de EDI.
Uso de las propiedades de acuerdo
El desensamblador EDI usará las propiedades del contrato si puede identificar el contrato (consulte Resolución de acuerdos , Detección de esquemas y Autorización para mensajes EDI recibidos). Si no se encuentra un contrato coincidente y los valores correspondientes tampoco están disponibles en el contrato de reserva, se usarán las propiedades del desensamblador EDI establecidas en la ventana Propiedades de Visual Studio. Sin embargo, esta reserva no se producirá si la autenticación es necesaria en las propiedades del puerto de recepción (si se produce un error en la autenticación si se produce un error en la autenticación o si se produce un error en la autenticación ). En este caso debe configurarse un acuerdo; si no, el intercambio se suspenderá.
Cuando el desensamblador EDI usa propiedades de acuerdo, necesita que se definan las siguientes propiedades de entidad:
| Propiedad | Página de propiedades de acuerdo |
|---|---|
| Repetition separator (Separador de repeticiones) | Página Sobres (en Configuración de intercambio) en la pestaña acuerdo bidireccional |
| Realizar la validación de tipo de datos EDI | Página validación en Configuración del conjunto de transacciones en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Extended Validation (Validación extendida) | Página validación en Configuración del conjunto de transacciones en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Permitir espacios y ceros iniciales y finales | Página validación en Configuración del conjunto de transacciones en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Crear etiquetas XML vacías si se permiten separadores iniciales | Página Configuración de host local en Configuración del conjunto de transacciones en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Opción de procesamiento por lotes de entrada | Página Configuración de host local (en Configuración de intercambio) en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Separadores de EDIFACT predeterminados | - |
| Enmascarar información de seguridad, de autorización y de contraseña | Página Configuración de host local (en Configuración de intercambio) en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Convert implied decimal format Nn to base 10 numeric value (Convertir formato decimal implícito Nn a valor numérico de base 10) | Página Configuración de host local en Configuración del conjunto de transacciones en la pestaña acuerdo bidireccional (para contratos X12) |
| Redirigir ACK a la canalización de envío en el puerto de recepción de solicitud-respuesta | Página Configuración de host local (sección Configuración del receptor ) en Configuración de intercambio en la pestaña acuerdo bidireccional (para contratos X12 y EDIFACT) |
| Juego de caracteres de X12 | Nota de generación de sobres de intercambio X12 : esta configuración solo se usa para validar los valores especificados para las propiedades del contrato. El juego de caracteres X12 utilizado para el procesamiento en tiempo de ejecución se selecciona en las propiedades de canalización. Para obtener más información, vea Conjuntos de caracteres EDI. |
Uso de campos de desencadenador HIPAA
Los segmentos EDI contienen con frecuencia valores de calificador que modifican el significado del segmento. Por ejemplo, el segmento N1 puede contener un elemento calificador “BT” para indicar “bill-to name” o puede contener un elemento calificador “ST” para indicar “ship-to name”. Normalmente, se deja la lógica de negocios para determinar cómo interpretar estos campos y el desensamblador resuelve todas las instancias del segmento N1 en el mismo nombre de registro XML; sin embargo, los esquemas HIPAA enviados con BizTalk Server contienen anotaciones que permiten al desensamblador EDI crear registros XML únicos en función de la presencia de un valor calificado (vea HIPAA Schema Trigger Field Annotations).
Cuando recibe un conjunto de transacciones HIPAA, si el desensamblador EDI detecta un segmento que contiene un campo desencadenador, usa la información del desencadenador para generar un registro XML específico para la combinación de segmento y desencadenador.
La tabla siguiente muestra cómo un segmento N1 se traducirá en un registro XML basado en el valor de N101:
| Segmento N1 | Datos XML resultantes |
|---|---|
| N1*PR*Contoso*XV*0000000~ | <ns0:TS835W1_1000A_Loop> <N1_PayerIdentification_TS835W1_1000A> <N101__EntityIdentifierCode>PR</N101__EntityIdentifierCode> <N102__PayerName>Contoso</N102__PayerName> <N103__IdentificationCodeQualifier>XV</N103__IdentificationCodeQualifier> <N104__PayerIdentifier>0000000</N104__PayerIdentifier> </N1_PayerIdentification_TS835W1_1000A> |
| N1*PE*Fabrikam*FI*9999999~ | <TS835W1_1000B_Loop> <N1_PayeeIdentification_TS835W1_1000B> <N101__EntityIdentifierCode>PE</N101__EntityIdentifierCode> <N102__PayeeName>Fabrikam</N102__PayeeName> <N103__IdentificationCodeQualifier>FI</N103__IdentificationCodeQualifier> <N104__PayeeIdentificationCode>9999999</N104__PayeeIdentificationCode> </N1_PayeeIdentification_TS835W1_1000B> |
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de