다음을 통해 공유

¿Donde guardo mis parámetros de configuración?

  • 아티클

Muchas veces he escuchado preguntar a los desarrolladores de BizTalk Server: ¿Donde puedo guardar mis parámetros de configuración? Bien, desde un punto de vista práctico existen tres lugares donde se pueden almacenar:

  1. El archivo BTSNTSvc.exe.config.
  2. Un archivo Xml de configuración propietario
  3. Una aplicación externa. A continuación se evaluara cada uno de los casos.

BTSNTSvc.exe.config

Este es el archivo de configuración del servicio que ejecuta BizTalk Server (BTSNTSvc.exe) el cual generalmente se localiza en la carpeta de configuración (muchas veces la misma de instalacion) de BTS.

NOTA: si no se conoce donde esta el servicio de BizTalk Server, este puede localizarse en la ruta del Registro de Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\ConfigFramework\Path

El Registro de Windows es de suprema importancia para el buen funcionamiento del sistema operativo, por lo que la utilización de este es de riesgo personal.

Este archivo corresponde a un archivo de configuración del framework de .Net, por lo tanto soporta la sección de <appSettings /> en la cual se pueden guardar las varias de configuración, por ejemplo:

<?xml version="1.0" ?><configuration> <runtime> ……… </runtime> <appSettings> <add key="ConnectionString1" value="SQL Server 1" /> </appSettings> ……… </configuration>

Luego, leer dichos valores resulta sencillo bien sea desde la misma orquestación o desde un assembly .Net no BTS referenciado desde la orquestación, así:

Assembly:BizTalk 2004 ó Assembly:.Net 1.1

System.Configuration.ConfigurationSettings.AppSettings.Get("ConnectionString1");

Assembly:BizTalk 2006 ó Assembly:.Net 2.0

System.Configuration.ConfigurationManager.AppSettings.Get("ConnectionString1");

Las ventajas de esta primera es la que se ofrece con el mismo framework de .Net ya que actúa de igual forma, lo cual significa que todos los datos son cargados a memoria la primera ves que se crea una instancia del servicio BTSNTSvc.exe.

La gran desventaja notable de esta opción, es que si es requerido cambiar un valor de alguna de las variables seria necesario detener el servicio y volverlo a iniciar para que este nuevo valor tomase efecto dentro de nuestra ejecución, dando la opción de interrupción de los servicios y por ende posible perdida de información.

En forma adicional, otra desventaja de esta solución es el proceso de despliegue del aplicativo, ya que se hace necesario modificar el archivo de configuración BTSNTSvc.exe.config en la instalación de los elementos de BizTalk Server y este es una modificación de cuidado ya que cualquier daño que sufra dicho archivo afectara todo el funcionamiento de nuestro servicio de BizTalk Server.

Archivo Xml de configuración propietario

Esta es otra técnica muy conocida y consiste en tener un Xml con una configuración propietaria donde se almacena toda la información, posteriormente con la ayuda de una clase Helper desarrollada o con XmlDocument e instrucciones xpath se obtienen los datos solicitados.

La única y gran incógnita de esta opción es donde almacenar el archivo Xml de configuración, en este caso tendríamos muchas opciones, entre las cuales se describen las 3 mas utilizadas:

  • Almacenarlo en una ruta específica que siempre será la misma, por ejemplo: D:\EAI\Proyecto\Archivo.xml.

    Esta opción seria muy buena, pero… ¿cuál es la realidad? En los servidores de producción no se pueden almacenar archivos de configuración en cualquier ubicación sino en la establecida por la arquitectura de la compañía, por lo tanto esta primera opción no es la muy práctica.

  • Otra opción crear una entrada en la sección <appSettings /> del archivo de configuración y en dicha entrada almacenar la ruta del archivo de configuración. De esta forma, antes de leer la información solicitada se consultaría primero la ruta del archivo desde la entrada de <appSettings /> y posteriormente la información requerida de dicho archivo.

    Esta es una opción práctica, y comúnmente muchas de nuestras aplicaciones .Net funcionan así. Sin embargo, esta alternativa tiene un único defecto que se basa en el proceso de despliegue ya que es necesario editar el archivo BTSNTSvc.exe.config y por consecuente cualquiera edición mal realizada podría traer consecuencias fatales para la ejecución de BizTalk Server.

  • Por ultimo, también se puede almacenar el archivo Xml de configuración en la misma localización donde se almacenan los assemblies de .Net tanto BTS como no-BTS. De esta forma, desde el interior del assembly por medio de la clase System.Reflection.Assembly y la propiedad GetExecutingAssembly().Location podemos obtener la ruta actual de ejecución del assembly y de esta forma conocer fácilmente la localización del archivo.

    Esta opción es buena, sin embargo (si, también tiene su pero… L) muchos se preguntaran… ¿Cuál es la carpeta de ejecución del assembly? Bien, si registramos el assembly en el GAC la carpeta sería %windir%\assembly\GAC\Assembly\version_publictoken\Assembly.dll, luego de saber esto la pregunta obligada es, ¿entonces ya se empieza a complicar el asunto, como grabo el archivo Xml en esa carpeta? La respuesta es SI y NO. No por que en este caso no es se registraría el assembly en el GAC para que BizTalk Server pueda reconocerlo, y SI por que de alguna forma es necesario mostrarle el assembly a BizTalk Server para que lo reconozca.

Entonces, ¿como hacer que BizTalk Server reconozca el assembly? Nuevamente esta solucion involucra la modificacion del archivo BTSNTSvc.exe.config, en esta ocasión se especificaria una nueva carpeta en la cual el servicio buscaria assemblies relacionado con la ejecución de BizTalk Server. Para ello seria necesario modificar la seccion del <probing /> archivo, asi:

<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop;Nuevos Assemblies" /> </assemblyBinding> </runtime>………………</configuration>

En esta ocasión, se ha especificado que también busque los assemblies en la carpeta Nuevos Assemblies la cual deberá crearse como subdirectorio de la carpeta donde se encuentra el servicio BTSNTSvc.exe.config. Por lo tanto, bastaría guardar nuestro assemblie de lectura de información en dicha carpeta junto con el archivo Xml de configuración.

Esta alternativa de resolución de assemblies hace parte de la arquitectura de .Net para la localización de assemblies, para mayor información visitar Assembly Placement y <probing> Element.

Un servicio externo

Una tercera opción, es tener una aplicación externa que almacene todos los parámetros o variables de configuración, llámese Web Service, SQL Server, Oracle, Web Page, entre otros. En esta oportunidad, podríamos tener un proceso de orquestación que se pueda invocar desde otros procesos de orquestación y obtener los datos requeridos.

Esta opción seria la mejor para un compañía con una arquitectura SOA, ya que basados en servicios se podrían obtener los parámetros ya centralizados para las demás aplicaciones. En este caso, el despliegue seria de una manera sencilla ya que se utilizarían los elementos nativos de BizTalk Server (puertos) para la localización del repositorio de parámetros y su mantenimiento seria por medio de las mismas herramientas de BizTalk Server en caso tal que la ubicación del servicio cambiase (consola administrativa u otros).

***

Como se puede leer, existen varios lugares donde se puede almacenar los parámetros de configuración de la aplicación. ¿Cuál aplicar? Todo depende del tipo de arquitectura diseñada en la compañía, y que tipo de arquitectura tendrá la solución de EAI con BizTalk Server para que se la decisión a tomar sea la mas adecuada. En cualquier caso, si la decisión es editar el archivo BTSNTSvc.exe.config siempre se hace necesario tener mucho cuidado ya que este archivo, nuevamente, es vital para el correcto funcionamiento de BizTalk Server.

Esta información aplica tanto para la versión BizTalk Server 2004 y BizTalk Server 2006 Beta 2. Sin embargo, no se garantiza su funcionalidad para la versión final de BizTalk Server 2006.

Autor: Carlos Medina

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho