Gustavo Bonansea: Biztalk

Cómo recibir más de un IDOC a través de un ReceiveLocation del tipo SAP

Thu, 09 Oct 2008 14:44:42 GMT

Aquí hay un artículo interesante (cortito y al pié) que muestra cómo realizar un Custom Pipeline para recibir más de un IDOC desde SAP a través del mismo puerto.

http://msdn.microsoft.com/en-us/library/aa559118.aspx

En el siguiente link hay otra solución con mejor rendimiento en la que se desarrolla un componente de pipeline específico:

http://msdn.microsoft.com/en-us/library/aa577629.aspx

Error instalando Microsoft Biztalk Adapter v2.0 for mySAP Busines Suite Service Pack 1

Thu, 02 Oct 2008 21:58:47 GMT

Cuando estaba instalando el Microsoft Biztalk Adapter v2.0 for mySAP Busines Suite Service Pack 1 se produjo el siguiente error:

An error occurred when adding the adapter to BizTalk configuration. Either the BizTalk configuration database was not found, or an Adapter for SAP was already added to the configuration. Click Cancel if you wish to roll back this installation or click OK to successfully complete the installation, and then manually add this adapter. For information on manually adding the adapter, see the BizTalk documentation after installation is complete.

Intentamos ejecutar el instalador con todos los usuarios, incluidos el Administrador del Dominio sin éxito, hasta que instalando el paquete del adaptador de SAP directamente obtuve el siguiente error:

---------------------------
BizTalk Adapter v2.0 for mySAP Business Suite
---------------------------
BizTalkSAPConfig encountered the following errors while configuring the Adapter

Failed to create the SapTid database due to :BizTalk Server cannot access SQL server. This could be due to one of the following reasons:

1. Access permissions have been denied to the current user. Either log on as a user that has been granted permissions to SQL and try again, or grant the current user permission to access SQL Server.

2. The SQL Server does not exist or an invalid database name has been specified. Check the name entered for the SQL Server and database to make sure they are correct as provided during SQL Server installation.

3. The SQL Server exists, but is not currently running. Use the Windows Service Control Manager or SQL Enterprise Manager to start SQL Server, and try again.

4. A SQL database file with the same name as the specified database already exists in the Microsoft SQL Server data folder.

Internal error from OLEDB provider: "Error de inicio de sesión del usuario 'NT AUTHORITY\ANONYMOUS LOGON'."

Failed to Add the Adapter to the BizTalk Administration due to : BizTalk Server cannot access SQL server. This could be due to one of the following reasons:

3. The SQL Server exists, but is not currently running. Use the Windows Service Control Manager or SQL Enterprise Manager to start SQL Server, and try again.

4. A SQL database file with the same name as the specified database already exists in the Microsoft SQL Server data folder.

Internal error from OLEDB provider: "Error de inicio de sesión del usuario 'NT AUTHORITY\ANONYMOUS LOGON'."

If you are running this program from Setup, you could click Cancel if you wish to roll back this installation or click OK to successfully complete this installation, and then manually add this adapter. For information on manually adding the adapter, see the BizTalk documentation after installation is complete

Entonces agregué el usuario "NT AUTHORITY\ANONYMOUS LOGON" como sysadmin y serveradmin del servidor de SQL Server 2005 y la instalación se concretó con éxito.

Si esto no funciona igual pueden instalar el adaptador de forma manual desde la consola de administración de Biztalk.

Microsoft SQL Server 2005 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine

Thu, 02 Oct 2008 19:28:21 GMT

Instalando Biztalk 2006 R2 en un entorno multiservidor (debajo les dejo unos documentos de microsoft sobre cómo hacerlo) me encontré con el siguiente error:

Microsoft SQL Server 2005 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine. Please install Microsoft SQL Server 2005 Integration Services. (Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper)

Additional information:

Could not load file or assembly 'Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dc8080cc91' or one of its dependencies. The system cannot find the file specified. (Microsoft.BizTalk.Bam.CfgExtHelper)

Se soluciona instalando las herramientas cliente de SQL Server 2005 (verifiquen que han chequeado todos los componentes por si acaso) en el servidor de Biztalk que les está dando el error.

Documentos de instalación de Biztalk 2006 R2 single-server y multi-server: http://www.microsoft.com/downloads/details.aspx?FamilyID=df2e8a88-fb23-49a4-9ac7-d17f72517d12&DisplayLang=en

Biztalk Naming Conventions

Tue, 06 May 2008 18:40:03 GMT

Me ha pasado en varias ocasiones el tener conflictos internos (o sea discutir conmigo mismo) sobre el nombre que se le debería poner a cierto assembly, clase, objeto, etc. Para solucionar ese tema nada mejor que atenerse a una convención de nombres estándar como base. Les paso una para artefactos de Biztalk:

http://www.traceofthought.net/misc/BizTalk%20Naming%20Conventions.htm

Depurar orquestaciones y demás assemblies de BizTalk con Visual Studio

Fri, 16 Feb 2007 13:14:02 GMT

Existe una creencia general de que no se puede realizar debugging con Visual Studio sobre assemblies que se encuentren deployados en BizTalk. La verdad es que sí se puede, al fin y al cabo cada uno de los artefactos de BizTalk (orquestaciones, pipelines, pipeline components, etc) no son más que assemblies .Net como todos los que conocemos, es decir que en el fondo no difieren de un "Hola mundo" en una aplicación de consola, y Microsoft BizTalk Server 2006, no es más que un servicio de windows que se ejecuta dentro de un proceso del sistema operativo y al cual una aplicación como Visual Studio 2005 puede realizar un "attach to process" perfectamente.

Vamos con algunos tips:

Desde Visual Studio verificar que se está compilando en modo Debug, (o development en caso de assemblies de BizTalk) es decir que se está generando la información necesaria para debuggear.

Si los assemblies se registran en la GAC, puede ponerse un post-build event para que se registren los assemblies automáticamente luego de cada compilación. Digo esto porque el intento de debuggear generalmente falla porque VS no puede reconocer la relación entre el assembly que ha sido cargado por el proceso de BizTalk con la línea de código fuente en la que hemos puesto un breakpoint, con lo cual es mejor que cada vez que se compile se actualice todo automáticamente.

Realizar un Attach to process (Debug/Attach to process... desde el menú de VS) al proceso que cargará el assembly que queremos debuggear, en general será el proceso de BizTalk: BTSNTSvc.exe, pero si estamos depurando un pipeline component que se encuentra en una receive location del tipo HTTP por ej., entonces el proceso que tendremos que atachar será el w3wp.exe, el proceso de IIS, dado que el assembly es cargado por una dll llamada btshttpreceive.dll que será hosteada por el Internet Information Server.

Poner puntos de interrupción donde corresponda. Si al lado del punto de interrupción aparece una indicación de warning, la primera vez puede ser porque si recién se inicia el proceso y no se a cargado el assembly todavía no se cargaron los símbolos para el mismo, luego de ejecutar una instancia deberá cargarlos. Si luego de la ejecución sigue indicando que no encuentra la información necesaria es porque la dll (o el pdb, que es el archivo que contiene la información de debug para ese assembly) no se corresponde (o al menos VS no encuentra la correspondencia) con el fuente. En este caso, intenten recompilar y actualizar las dlls y actualizar la GAC si corresponde.

Si VS no puede reconocer la relación entre el fuente y el assembly cargado (es decir que los puntos de interrupción aparecen con warnings y no funcionan) a veces es necesario copiar los archivo pdb en el directorio correspondiente en la GAC. Por ejemplo, si se está debuggeando un assembly llamado Message.dll, debería copiarse el pdb generado en el directorio bin junto con la dll en el directorio: C:\WINDOWS\assembly\GAC_MSIL\Message\1.0.0.12__8f16cd8a13e0857c\ , nótese que el directorio tiene relacionado la versión y PublicKeyToken de la dll. No puede accederse a ese directorio fácilmente con el Explorer de Windows, utilicen otro programa (Total Commander) o directamente línea de comandos (cmd.exe).

Una opción interesante es habilitar que VS se detenga ante el lanzamiento de cualquier excepción, en vez de poner puntos de interrupción. Para hacer esto escriban Debug.Exceptions en la ventanta de comandos y aparecerá un diálogo donde deberá habilitarse la opción Thrown para Common Language Runtime Exceptions, lo que hará que VS se detenga ante la ocurrencia de cualquier excepción, aunque se encuentre manejada por un bloque try.

Inclusive puede realizarse un debugging del propio código de la orquestación. Al final una orquestación no es más que código en c#. Supongamos que tenemos una orquestación llamada "Proceso", el archivo Proceso.odx es un Xml que es tomado por el compilador de orquestaciones de BizTalk y con él genera un archivo en c# llamado Proceso.odx.cs, que luego es tomado por el compilador estándar de C# y se convierte en un assembly .Net. Si habrimos el archivo Proceso.odx.cs podremos ponerle puntos de interrupción para depurarlo (tal vez escriba algún post en el futuro sobre este tema específico).

Debugging remoto. Esto que describí en los puntos anteriores puede hacerse sobre la máquina de desarrollo o de forma remota sobre otro servidor. Para que funcione de forma remota es necesario tener correctamente instalado y configurado los Remote Components de Visual Studio en el server, no voy a explicar esto aquí, para hacerlo les paso dos links con la información necesaria: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vctskInstallingRemoteDebugMonitor.asp y http://support.microsoft.com/kb/910448, que explican esta tarea. Configurar esto sobre entornos muy securizados puede ser bastante complicado, pero sobre un servidor de pruebas no debería representar una misión imposible.

Troubleshooting de BizTalk

Fri, 02 Feb 2007 09:54:16 GMT

Hoy en estado configurando algunos servidores de Biztalk 2006 y me he encontrado con algunos problemas, y por si algún otro le pasa comentaré algo sobre lo que he hecho para que le sirva de guía o al menos le brinde algunas pistas.

Error loading data. Please click on the icon to view details

Al parecer esto ocurre cuando el servidor ha sido configurado anteriormente y por algún motivo no puede recuperar o reproducir dicha configuración. La solución es desconfigurar esa determinada funcionalidad (“Unconfigure features”) y reconfigurarla.

Access is denied. (ConfigHelper)

Este problema de seguridad suele ocurrir cuando se está intentando configurar un servidor de BizTalk utilizando cuentas y grupos del dominio para configurar los servicios. Para esto generalmente es necesario que la herramienta de configuración (Microsoft BizTalk Server 2006 Configuration) sea ejecutada con una cuenta que sea administrador local y que tenga permisos para poder evaluar la pertenencia de un usuario a un grupo del dominio donde se encuentra el servidor. Podríamos utilizar la opción de menú “Run as…” para ejecutar la consola de configuración con una cuenta con los privilegios necesarios. Aquí les paso un excelente post del blog de Michael Coates donde explica los permisos, cuentas y consideraciones de seguridad a tener en cuenta http://blog.opsan.com/archive/2004/08/24/171.aspx

Deshabilitar Expect: 100-Continue en BizTalk 2006 (y .Net 2.0 en general)

Tue, 12 Sep 2006 11:43:56 GMT

He tenido recientemente un error de comunicación de BizTalk 2006 utilizando un puerto HTTP. El problema es que, no sólo BizTalk sino .Net en particular, agrega algunos headers que si bien están en el estándar HTTP 1.1, no son muy populares que digamos y no están implementados por todos los servers. Este es el caso del “Expect: 100-continue” (si algún curioso quiere saber para qué sirve vea el siguiente link). Veamos el ejemplo debajo:

Cabecera del mensaje:

POST / localhost /somepage.htm HTTP/1.1
Content-Length: 1623
Content-Type: text/xml; charset=utf-8
Expect: 100-continue
Host: localhost
User-Agent: Microsoft (R) BizTalk (R) Server 2006 3.0.1.0

Para deshabilitar esto tenemos que modificar el archivo machine.config y agregarle la siguiente sección de código:

</system.web>

<system.net>

</settings>

</system.net>

No está demás verificar también que se encuentra definida la sección dentro de los sectionGroup:

</sectionGroup>

</sectionGroup>

Nota: También puede modificarse desde código utilizando la clase ServicePointManager.

Receive Locations, Send ports & Pipelines

Fri, 25 Aug 2006 13:22:12 GMT

Uno de los problemas recurrentes más molestos con los que me he encontrado en BizTalk 2006 es que algunas receive locations o send ports pierden el binding que tienen con la pipeline que se les ha asignado cuando se redespliega algún componente como una orquestación, esquema, etc. No siempre es así, es decir que ocurre solo algunas veces, y es realmente molesto tener que revisar una por una las receive locations y send ports, cada vez que actualizamos algo, para verificar que BizTalk no se ha “olvidado” alguna pipeline. Debajo detallo dos consultas SQL que pueden ejecutarse contra la base de datos BizTalkMgmtDb del SQL Server 2005 contra el que trabaja BizTalk y nos permitirán identificar rápidamente de un vistazo si las asignaciones están correctas.

Receive Locations:

SELECT adm_ReceiveLocation.Name, bts_pipeline.Name AS ReceivePipeline, bts_pipeline_1.Name AS SendPipeline

FROM adm_ReceiveLocation LEFT OUTER JOIN

bts_pipeline ON adm_ReceiveLocation.ReceivePipelineId = bts_pipeline.Id LEFT OUTER JOIN

bts_pipeline AS bts_pipeline_1 ON adm_ReceiveLocation.SendPipelineId = bts_pipeline_1.Id

Resultado:

ReceiveLocationA	GB.Infraestructure.PipelineA	NULL
ReceiveLocationB	GB.Infraestructure.PipelineB	NULL
ReceiveLocationC	GB.Infraestructure.PipelineC	Microsoft.BizTalk.DefaultPipelines.XMLTransmit

Send Ports:

SELECT bts_sendport.nvcName, bts_pipeline.Name AS SendPipeline, bts_pipeline_1.Name AS ReceivePipeline

FROM bts_sendport LEFT OUTER JOIN

bts_pipeline AS bts_pipeline_1 ON bts_sendport.nReceivePipelineID = bts_pipeline_1.Id LEFT OUTER JOIN

bts_pipeline ON bts_sendport.nSendPipelineID = bts_pipeline.Id

Resultado:

SendPortA	GB.Infraestructure.PipelineD	Microsoft.BizTalk.DefaultPipelines.XMLReceive
SendPortB	Microsoft.BizTalk.DefaultPipelines.XMLTransmit	NULL
SendPortC	GB.Infraestructure.PipelineE	NULL

BizTalk Server 2006 Tutorials

Thu, 06 Apr 2006 13:01:40 GMT

Para seguir con el aprendizaje de Biztalk:

BizTalk Server 2006 Tutorials:

http://www.microsoft.com/downloads/details.aspx?FamilyID=6a5f6ef4-aeb8-4d8d-a521-37333a875ce4&displaylang=en