Sugerencias para diseñar un adaptador

Esta sección contiene sugerencias e ideas que los programadores de adaptadores han aprendido al diseñar adaptadores.

Las propiedades de controlador deben ser cadenas si se usan como configuraciones predeterminadas

Parece atractivo usar las propiedades de la hoja de propiedades del controlador generado por XSD como valores predeterminados para sus propiedades location porque si el valor no está establecido en Location , el tiempo de ejecución usa automáticamente el valor establecido en el controlador. Pero existen varios problemas que reducen la utilidad de esta posibilidad.

El problema aparece cuando no se sabe si el valor presentado en tiempo de ejecución debe sobrescribirse o no. La forma habitual de hacerlo es definir alguna noción de NULL para los valores y, a continuación, ejecutar una prueba con ese valor. El problema de usar hojas de propiedades basadas en XSD en BizTalk Server es que NULL sólo se admite para cadenas. Aunque desee que el adaptador tenga una configuración predeterminada mediante el uso de esta prueba de NULL y esté dispuesto a restringir el adaptador a los tipos de cadena, sigue arriesgándose a obtener una interfaz de usuario de lo más extraño.

Las hojas de propiedades generadas por XSD solo admiten la configuración de una propiedad en NULL haciendo clic con el botón derecho en la propiedad, en cuyo punto aparece un menú contextual nullify? y la propiedad se puede establecer en NULL. No existe ninguna información visual que indique si una propiedad es NULL.

Consideraciones sobre la implementación de asistentes para generación de esquemas

Los programadores prefieren escribir código basado en modelos de objetos de tipo seguro. Al principio, manipular XML en el código puede parecer extraño y proclive a errores. Pero algunos trucos y el uso inteligente de la compatibilidad que ofrece .NET Framework pueden simplificarlo todo de manera drástica.

No cree documentos XML con concatenación de cadenas

Una de las peores equivocaciones que puede cometer con XML es intentar generarlo mediante la concatenación de cadenas e imprimir las instrucciones en la memoria. Esto consume grandes cantidades de tiempo de la CPU y de memoria. Incluso para el fragmento de código XML más trivial, resulta más fácil utilizar una herramienta como XmlWriter o el modelo de objetos de documento (DOM). Si usa XmlWriter, no use la capacidad de escritura sin formato, porque el escritor pierde el estado del documento.

En tiempo de ejecución, XmlWriter es preferible a DOM XML por los problemas de consumo elevado de memoria asociados al DOM. Sin embargo, en tiempo de configuración o diseño lo más probable es que no plantee ningún problema. El uso del DOM facilita el uso de consultas XPATH, que pueden constituir una herramienta adicional de gran utilidad.

Estudie la posibilidad de definir el esqueleto del documento XML como recurso

Si va a generar un documento XML de gran tamaño mediante una herramienta de diseño y ese documento generado siempre sigue la misma estructura básica, puede ser conveniente colocar todo el esqueleto del archivo XML en el proyecto para permitir la realización de cambios cuando sea preciso modificarlo.

Cargue el código en un modelo de objetos de documento (DOM) y agregue los elementos necesarios al esqueleto del documento usando XPATH para seleccionar el nodo al que desee agregarlos. En este caso, se crea un archivo Lenguaje de descripción de servicios Web (WSDL). El asistente almacena el archivo WSDL del esqueleto en un recurso y agrega los elementos secundarios en el Lenguaje de definición de esquema XML (XSD) generados. Utiliza selectNode con XPath para encontrar el elemento principal correspondiente. Se trata de código de interfaz de usuario, con lo que el rendimiento no constituye un problema y la implementación resultante es limpia, robusta y mantenible.

Estudie la posibilidad de colocar pasos de procesamiento en la canalización de BizTalk

En general, los adaptadores generados en Microsoft quitan del adaptador el procesamiento basado en formato de mensajes y lo colocan en la canalización de BizTalk. Un buen ejemplo de ello es un adaptador para un origen de datos estructurado que no es XML.

En este caso, el adaptador se limita a obtener los datos, y se usa la canalización de BizTalk para analizarlos y convertirlos a un equivalente de XML. La ventaja es que el propio componente de canalización se convierte en una pieza reutilizable de la arquitectura.

Permita la configuración del comportamiento del adaptador

Una de las conclusiones extraídas del programa beta del adaptador de MQSeries fue que no todos los clientes estaban satisfechos con el mismo comportamiento. Esto se cumplía especialmente en lo relativo al control de errores y al orden. La solución fue hacer que el comportamiento del adaptador fuera configurable. Puede especificar si el adaptador admitirá la ordenación, si los fracasos se moverán a la cola de suspensión o si harán que el adaptador deje de procesar y se deshabilite. Permitir la configuración de este tipo de comportamientos puede simplificar de manera significativa la vida del cliente, que en caso contrario tendría que escribir orquestaciones o secuencias de comandos externas de gran complejidad a BizTalk Server para lograr el mismo resultado.

Admita la correlación con las colas de mensajes

Numerosas plataformas de mensajería admiten la noción de un Id. de correlación en el encabezado de mensaje para proporcionar compatibilidad con un escenario de solicitud-respuesta de nivel de aplicación. Algunos ejemplos de ello son MQSeries, MSMQ y SQL Service Broker. Podría parecer interesante asignar el patrón de solicitud-respuesta del sistema de mensajería externo a un adaptador de envío-respuesta de BizTalk Server. Sin embargo, esto no tiene sentido por el lugar donde residen las transacciones. En concreto, un envío al sistema de mensajería externa exige una confirmación transaccional antes de que el otro extremo de la cola pueda ver los datos. La recepción también debe ser una transacción independiente.

La solución en BizTalk Server es:

• Usar conjuntos de correlaciones en la orquestación

• Configurar dos puertos independientes: uno para el envío y otro para la recepción

  En un caso sencillo, la orquestación especifica el Id. de correlación asociado al mensaje por el adaptador. Éste se pasa al adaptador como propiedad de contexto en el mensaje. En un caso más complejo, el escenario llama al sistema de mensajería externo para asignar el identificador. En este caso, se puede devolver desde el puerto de envío a la orquestación con un mensaje de respuesta. Este mensaje de respuesta se utiliza exclusivamente para devolver el Id., y no es la verdadera respuesta al mensaje.

Nota

Existe una condición de anticipación en el motor de orquestación que permite que la verdadera respuesta al mensaje llegue antes que la respuesta del Id. correspondiente al envío. Esta condición de anticipación se debe controlar en la propia orquestación.