Problemas conocidos del Acelerador de Microsoft BizTalk para RosettaNet (BTARN)

Esta sección contiene información útil que puede ayudarle a evitar errores con el Acelerador de Microsoft® BizTalk para RosettaNet (BTARN). Los problemas conocidos se agrupan en las siguientes áreas:

• 0A1 Notificación de error

• Supervisión de la actividad económica (SAE)

• Instalación y configuración

• Disposiciones adicionales

0A1 Notificación de error

BTARN no realiza la validación entre campos para la propiedad de configuración de procesos CIDX y la propiedad del contrato 0A1

BTARN no impide establecer la propiedad "Estándar" para un perfil de configuración de proceso en "CIDX", después de haber establecido la propiedad "Contrato 0A1" para un contrato que usa ese perfil en "0A1", aunque un CIDX no admita contratos 0A1.

Supervisión de la actividad económica

Los datos de columna duplicados aparecen en los informes de supervisión de actividad empresarial

Las columnas ActivityID y PIPInstanceID de los informes web de actividades de BAM contienen el mismo contenido. Estos datos reflejan con precisión el identificador de instancia del proceso de interfaz de asociado (PIP). ActivityID usa este valor para la correlación interna. Puede ignorar este mensaje.

Columnas de datos vacías en los informes web de supervisión de actividad empresarial

Los informes web de supervisión de actividad empresarial (BAM) no contienen ningún dato para los procesos de mensajes 0A1. Las columnas de mensaje 0A1 de los informes web están codificadas de forma rígida con "Iniciado 0A1".

Instalación y configuración

Los grupos y usuarios del grupo Usuarios de la aplicación de BizTalk y el grupo administradores de BizTalk Server deben estar en el mismo dominio.

BTARN admite la adición de un grupo al grupo Usuarios de la aplicación de BizTalk o al grupo administradores de BizTalk Server. Sin embargo, las cuentas de usuario individuales y los grupos que pertenecen al grupo Usuarios de la aplicación de BizTalk o al grupo administradores de BizTalk Server deben formar parte del mismo dominio.

Se produce un error en la desinstalación de BTARN si se quita primero BizTalk Server

Si quita BizTalk Server antes de quitar BTARN, se produce un error en el proceso de eliminación de BTARN sin errores. Para resolver este problema, vuelva a instalar y volver a configurar BizTalk Server y, a continuación, quite BTARN.

La implementación distribuida requiere un controlador de dominio

La implementación de BTARN en un entorno de varios servidores requiere un controlador de dominio, por ejemplo, cuando haya instalado BTARN en un servidor y las bases de datos de SQL Server usadas para la configuración en otro servidor.

No se admiten configuraciones de PIP personalizadas

La versión actual de BTARN no admite la configuración de PIP con elementos personalizados u otra información estándar que no sea de RosettaNet.

BTARN inicia automáticamente el servicio single Sign-On

BTARN inicia automáticamente single Sign-On (SSO) en un evento cuando BTARN lo requiere y el servicio SSO no se está ejecutando.

El programa de configuración no quitará directorios virtuales BTARN de la lista de rutas de acceso excluidas cuando WebApps no esté configurado para el sitio web predeterminado.

Si desconfigura una instalación de BTARN en la que se configuró la carpeta virtual de la aplicación web para que sea SharePoint Server, no sitio web predeterminado, después de anular la configuración, tendrá que quitar manualmente los directorios virtuales btarnapp y btarnhttpreceive de la lista Rutas de acceso excluidas en el sitio de Administración central de SharePoint. Esto ocurre porque al configurar la carpeta virtual de la aplicación web para que sea SharePoint Server, tiene que agregar manualmente btarnapp y btarnhttpreceive a la lista Rutas de acceso excluidas. El programa de configuración no podrá quitarlos automáticamente de la lista Rutas de acceso excluidas.

Disposiciones adicionales

BTARN recibirá mensajes cifrados en cualquiera de los algoritmos de cifrado.

La canalización de recepción de BTARN recibe y descifra un mensaje incluso si el protocolo que se usa para cifrar el mensaje y la configuración de codificación de este campo no coinciden. Por lo tanto, BTARN recibe mensajes cifrados en RC2-40 o 3DES.

BTARN requiere una señal en un escenario sincrónico de una sola acción

En un escenario sincrónico de una sola acción, BTARN siempre espera y genera señales. Este comportamiento es diferente de la especificación de RosettaNet que una señal puede o no ser necesaria en un escenario sincrónico de una sola acción. Si BTARN es un respondedor, siempre genera una señal en respuesta a un mensaje del iniciador. Si BTARN es un iniciador, siempre espera una señal del respondedor. Si BTARN no recibe una señal, agota el tiempo de espera después del intervalo especificado en la propiedad en los Time To Perform valores de configuración del proceso y genera un mensaje 0A1.

BTARN admite UTF-16 en mensajes recibidos

BTARN recibe y procesa mensajes que tienen un juego de caracteres de UTF-16. BTARN envía mensajes con un juego de caracteres de UTF-8.

Los espacios de nombres deben quitarse de los mensajes de respuesta asignados de los mensajes de solicitud.

Si usa el asignador de BizTalk en el proceso privado de un escenario de doble acción, el asignador de BizTalk agrega espacios de nombres a algunas etiquetas de elemento en las instancias de mensaje de respuesta asignadas a partir de mensajes de solicitud. Estos espacios de nombres provocan un error en la canalización de envío. Debe quitar estos espacios de nombres. Use el ejemplo HeaderHelper para hacerlo. Para obtener más información, vea Double Action PIPAutomation Orchestration [RN3] and Step 4: Creating the HeaderHelper Project [RN3].

El cambio de la configuración del URI requiere IISRESET

Al ejecutar el programa de instalación, establece la configuración de URI que usan las páginas de recepción y envío de .aspx y la configuración de URI de los adaptadores de recepción y envío. Debe cambiar esta configuración si cambia el nombre del equipo en el que están instaladas las páginas .aspx o los adaptadores. Para cambiar esta configuración, vuelva a ejecutar el proceso de configuración, pero esto requiere restablecer todas las opciones de configuración. Puede cambiar solo la configuración del URI cambiando las claves del Registro asociadas (AsyncReceivePortURI, RNIFSenderURIy SyncReceivePortURI). Después de cambiar cualquiera de estas configuraciones del Registro, debe ejecutar IISRESET para que los cambios surtan efecto. Esto se debe a que BTARN almacena en caché la configuración de su uso. Después de ejecutar IISRESET, también debe reiniciar los servicios de BizTalk.

BTARN no aplica restricciones en las enumeraciones de RNIF v1.1

La especificación V1.1 de RosettaNet Implementation Framework (RNIF) especifica restricciones en algunas enumeraciones de esquema RNIF. BTARN no aplica estas restricciones y no se valida con esas restricciones. Las restricciones no se aplican a RNIF v2.01.

Esto es cierto para los siguientes elementos de encabezado de servicio:

• GlobalBusinessActionCode

• GlobalPartnerClassificationCode

• GlobalBusinessServiceCode

• GlobalProcessCode

• GlobalProcessIndicatorCode

• VersionIdentifier

Los parámetros PerformanceControlRequest no invalidarán las opciones de configuración de proceso predeterminadas

Los mensajes entrantes pueden contener PerformanceControlRequest parámetros en el encabezado de servicio. Estos parámetros incluyen valores para los parámetros de retraso de tiempo de confirmación (recibo) y Hora de realización, tal como se establece en los valores de configuración del proceso realizados en la Consola de administración de BTARN. BTARN no establece dinámicamente los retrasos de tiempo en función de los PerformanceControlRequest parámetros del mensaje entrante. BTARN siempre tarda los retrasos en los valores de PIP predeterminados establecidos en los valores de configuración del proceso. Esto sigue a la especificación V1.1 de RosettaNet Implementation Framework (RNIF).

El nombre de PIP y la versión pip de los mensajes de doble acción distinguen mayúsculas de minúsculas.

Si el nombre de PIP y la versión pip de un mensaje de respuesta tienen un caso diferente al de los valores correspondientes del mensaje de solicitud de doble acción original, el iniciador BTARN rechaza el mensaje de respuesta como no válido y devuelve una excepción al respondedor.

BTARN no admite el cambio de la configuración del contrato mientras hay procesos activos

Los cambios en las propiedades del contrato se aplicarán en cuanto haga clic en Aplicar o Aceptar para aceptarlos. Después de cambiar un contrato, cualquier actividad nueva de un proceso ya en ejecución o cualquier proceso nuevo que implique ese contrato usará las propiedades del contrato modificadas. Si se ejecutó un proceso al cambiar el contrato, es posible que ya haya usado las propiedades de contrato anteriores para un mensaje. Los nuevos mensajes de ese proceso usarán la nueva configuración del contrato, lo que puede generar resultados impredecibles. Se recomienda cambiar la configuración del contrato cuando no hay procesos en ejecución.

BTARN no realizará la validación entre campos después de realizar cambios en un perfil de configuración de proceso

Al crear un perfil de configuración de proceso y, a continuación, crear un contrato, BTARN realiza la validación entre campos para asegurarse de que las propiedades del contrato y el perfil son compatibles. Por ejemplo, comprueba que para un perfil con la propiedad Standard establecida en "CIDX", la propiedad de contrato 0A1 del contrato se establece en "No 0A1". Sin embargo, si cambia un perfil de configuración de proceso después de haber creado un contrato, BTARN no realiza la validación entre campos. Si cambia la propiedad Standard de "RosettaNet" a "CIDX", BTARN no comprueba que la propiedad del contrato 0A1 del contrato esté establecida en "No 0A1".

Los errores se producirán si no se inician todas las orquestaciones.

El programa de instalación de BTARN instala nueve orquestaciones. Para que BTARN procese los mensajes correctamente, debe enlazar, dar de alta e iniciar las nueve orquestaciones antes de iniciar el procesamiento. Para obtener más información, vea los temas "Administración de orquestaciones en el Explorador de BizTalk" o "Administrar orquestaciones" en BizTalk Server Ayuda.

RNIFReceive.aspx no quita el límite inferior de MIME de un mensaje.

Cuando la página RNIFReceive.aspx recibe un mensaje de una página RNIFSend.aspx de un asociado, el mensaje incluye un encabezado MIME y un límite superior e inferior de MIME, un número base 64. RNIFSend.aspx agrega el encabezado y los límites al mensaje para la transmisión de RNIF. RNIFReceive.aspx debe quitar el encabezado MIME y los límites del mensaje antes de enviar el mensaje al proceso público. RNIFReceive.aspx quita el encabezado MIME y el límite superior, pero no quita el límite inferior. La presencia del límite inferior no afecta al procesamiento del mensaje en el proceso público.

BTARN no admite una configuración que distingue mayúsculas de minúsculas de SQL Server bases de datos

Si hace que las bases de datos del servidor BTARNSQL y los objetos de base de datos distinguen mayúsculas de minúsculas, la Consola de administración de BTARN no encuentra recursos de base de datos y produce una excepción. Las bases de datos de servidor BTARNSQL y los objetos de base de datos deben distinguir mayúsculas de minúsculas.

Todas las consultas de los scripts de mantenimiento de la base de datos deben escribirse para la hora UTC.

BTARN SQL Server bases de datos usan la hora UTC (coordenada de hora universal), de modo que cualquier consulta que cree para mantener una de estas bases de datos debe escribirse durante la hora UTC. Por ejemplo, si el script de mantenimiento usara el GetDate() comando , debe cambiarlo a GetUTCDate().

Una orquestación PublicResponder rechazará un mensaje de acción de solicitud duplicado.

Cuando una PublicResponder orquestación (PublicResponderV11.odx) recibe un mensaje de acción de solicitud duplicado, registrará una advertencia en el registro de eventos y, a continuación, rechazará el mensaje. Si se recibe un mensaje duplicado una vez completada la orquestación del respondedor, BizTalk Server detendrá el mensaje porque no hay suscripciones.

Los errores de transmisión no se mostrarán en BAM si el proceso público se ha detenido

Si se produce un error de transmisión cuando una orquestación de procesos públicos procesa su mensaje final, el registro de eventos y HAT muestran el error, pero BAM no lo hace. BAM no puede mostrar el mensaje porque la orquestación se ha detenido.

La herramienta pipeline.exe no se puede usar para depurar una canalización de recepción de BTARN

Si desea depurar una canalización de recepción, debe crear un puerto que hospede la canalización. No se puede depurar con la herramienta pipeline.exe que BizTalk Server proporciona.

Se puede generar un error para un mensaje reintentado que se procesa correctamente una vez finalizada la orquestación.

BTARN usa orquestaciones para representar el flujo de proceso. En algunos casos, en los que se reintentan varios mensajes reintentados, la orquestación puede finalizar correctamente antes de que llegue un mensaje reintentado en el Cuadro de mensajes de BizTalk. Cuando se produce este comportamiento, BizTalk Server genera un mensaje de error "completado pero descartado" correspondiente. Debe examinar la aplicación de línea de negocio (LOB) para determinar si el proceso ha finalizado o no. Si la aplicación loB indica que la finalización se completó correctamente, puede omitir el mensaje "completado pero descartado".

Un archivo XML exportado desde tracking.xls puede tener campos incorrectos

Al definir nuevas vistas de seguimiento en un archivo XLS de seguimiento y exportar un archivo XML desde el archivo XLS de seguimiento, algunos de los nombres de campo se modificarán ligeramente. Para corregirlo, compruebe los campos del archivo XML de seguimiento personalizado en el campo estándar tracking.xml instalado por el programa de instalación de BTARN.

El esquema de encabezado de servicio de RNIF 1.1 para señales y respuestas puede necesitar modificación

BTARN envía todos los esquemas de encabezado de RosettaNet fuera de la caja. Algunas implementaciones usan los nodos Control de señal y Control de acciones de forma diferente a otras, como se describe a continuación.

BTARN fuera de la caja envía el elemento Signal Control como se indica a continuación. Tenga en cuenta que el mismo puede ser true para el elemento Action Control.

<!ELEMENT SignalControl (  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity,  
          inResponseTo)>  

Si la solución requiere esta secuencia, no es necesario hacer nada.

Otras implementaciones, por otro lado, usan el código siguiente:

<!ELEMENT SignalControl (  
          inResponseTo,  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity)>  

Si la solución requiere esta secuencia, consulte KB 889523. Esta actualización de software cambiará el esquema XML correspondiente. Tenga en cuenta que esta actualización solo afecta a los procesos de RNIF 1.1.

El procedimiento almacenado pipAutomationGetAction SQL necesita actualizar

Debe actualizar el procedimiento almacenado PipAutomationGetAction SQL para bloquear registros únicos. Elimine las líneas siguientes:

IF @@ERROR <> 0  
    UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID  

El procedimiento almacenado PipAutomationGetAction correcto es el siguiente:

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  

Puede personalizar el código aspx para devolver la descripción del error.

Si necesita registrar o enviar una descripción de error, puede personalizar el código aspx para que el texto real se devuelva en la respuesta. Para ello, use HttpResponse.Status (que es el objeto de respuesta de la solicitud asp intrínseca) o HttpWebResponse.StatusDescription (que devuelve la llamada de .NET al método GetResponse del objeto HttpWebRequest). Para devolver los valores devueltos de uno de los objetos de respuesta aplicables, establezca el valor Response.Status similar al modo en que Response.StatusCode se establece en el código aspx que se incluye con BTARN.

Los mensajes RNIF 1.1 no se pueden leer en texto sin formato de tablas sin rechazo si el método de codificación está establecido en Base64.

Esto solo sucede si el método de codificación está establecido en Base64. Los mensajes se pueden leer en texto no cifrado de tablas sin rechazo si el método de codificación está establecido en comillas imprimibles o de 8 bits. Debe guardar el archivo de mensaje con la extensión *.eml y, a continuación, abrirlo con Outlook Express para leer el mensaje y Outlook Express descodificará el mensaje automáticamente. También puede usar el código siguiente para leer los mensajes codificados en Base64 de tablas que no son de rechazo.

byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);  
string plainText = Encoding.UTF8.GetString(textBytes);  
txtOutput.Text = plainText;  

Consulte también

Solución de problemas conocidos