Así que guarden la url http://geekswithblogs.net/BiztalkSouthCone

En este lugar vamos a estar posteando varios, entonces es algo más que un "blog personal" por eso el cambio.

Igualmente seguiré posteando por un tiempo los links aquí.

El primer mini artículo está aquí: http://geekswithblogs.net/BiztalkSouthCone/articles/biztalk-queries-in-mmc-snap-in-tool.aspx

Es un snap-in que muestra queries hacia bases sqlserver. Está pensado para trabajar con soluciones biztalk pero en realidad sirve para cualquier escenario donde sea necesario mostrar resultados de queries.

Despues de varios días de errores de conectividad "transientes" donde tenemos errores de conectividad y hosts instances en estado "Stop Pending", encontramos un lindo key en la registry que ayuda.

Por supuesto que si miran al SqlServer no van a encontrar ningun error.

La entrada en la registry SynAttackProtect por defecto en Windows 2003 es 1, en producción y si los Biztalks y Sql no están conectados directo a Internet (un escenario muy recomendable por otra parte :) ) entonces lo mejor es ponerlo en 0.

Aquí el link: http://technet2.microsoft.com/windowsserver/en/library/8d3a9f4d-13d1-4280-ac57-30242504d8ba1033.mspx?mfr=true

Esta es más bien una entrada para mí para acordarme de todos los pasos.

Si leen esto: No hagan esto en producción

1) Parar todos los servicios biztalk

2) Para borrar la messagebox:

- Correr el stored proc bts_CleanupMsgBox

- Correr el stored procedur bts_PurgeSubscriptions

3) Para borrar la base de Tracking

- Ejecutar el stored procedure dtasp_CleanHMData en la BiztalkDTADb

4) Reiniciar los sevicios

Nota: El stored proc bts_CleanupMsgBox que viene por defecto en la base está vacía. Hay que correr el script que está en el folder de instalación\Schema para que haga algo.

Un par de números, con variados temas y algunos bastante interesantes, reseño los que me gustaron más.

Edición Q3 2007

- Monster Biztalk Databases and how to avoid them

- Implementing FIFO processing with Biztalk Server 2006

- Debatch or not to debatch BIG files

Edición Q4 2007

- WCF vs Biztalk

- Property fields vs Distinguished fields

- Applying throttles within Biztalk

- Biztalk requirements beyond the norm (y una lista de utilitarios para troubleshooting del DTC)

Y en ambas un conjunto de links útiles.

www.biztalkhotrod.com

El mecanismo de throttling controla la carga de una "host instance" para que esta carga no exceda la capacidad de la instancia de host. También lo protege de que exista contención en un recurso que pueda impactar en la performance del proceso.

El outbound host throttling (también conocido como "message processing throttling") se aplica a las instancias que tienen orquestaciones o send ports que procesan mensajes que han sido enviados a la MessageBox.

Las condiciones para que se aplique son:

• Que se exceda alguno de los parámetros definidos en los Throttling thresholds de la instancia
• Que el Message Delivery Incoming Rate exceda al Message Delivery Outgoing Rate * Rate overdrive factor (percent) definido para la instancia
• La cantidad de mensajes procesados concurrentemente por la instancia de host exceda los definidos por CPU.

El que me interesa hoy es el segundo de los casos, dado que el factor de overdrive por defecto es de 125%, que en algunos casos es muy simple de sobrepasar.

Vamos al caso de una orquestación que realiza un proceso intensivo y recibe una ráfaga de mensajes. Rápidamente esta orquestación entrará en throttling.

Cuando esto sucede, Biztalk comienza a tomar las siguientes acciones:

• Realiza un delay progresivo del envío de los mensajes a la orquestación. Este delay se incremente con el "escalamiento" de la condición de throttling
• Limita la cantidad de mensajes que se pueden mantener en la "in-memory" queue. Por defecto esta queue es de 100 y cuando está llena, no se desencolan más mensajes hasta que la cola se vacía.
• El tamaño del Message Agent thread pool se limita, reduciendo efectivamente la cantidad de mensajes que se envían al XLANG.

Debajo el patrón de envío de acuerdo al SDK para que se vean los puntos descritos encima.

Ahora el caso: qué sucede si en realidad nuestro caso tiene un momento de alta carga, pero sabemos que puede soportarlo y no queremos que se reduzca la carga sobre el server; en ese caso, el mecanismo de throttling entorpece en lugar de ayudar.

Podemos cambiar los parámetros de manera acorde o, agregando un valor REG_DWORD ThrottlingPublishOverride con el valor 2 en la ubicación HKLM\System\CurrentControlSet\Services\BTSSvc$<HostName> se deshabilita el outbound host throttling completamente para esa instancia de host.

http://www.microsoft.com/latam/prensa/2007/octubre/soa.aspx

http://www.microsoft.com/soa/products/oslo.aspx

Creo que me equivoqué. Biztalk no desaparece, se hace más omnipresente.

Ahora que todos estamos de acuerdo en que vamos hacia servicios, en la plataforma, el mejor lugar es Biztalk.

El framework me da todo pero para hacerlo a mano.

Todos lo precisamos.

Hasta me animaría a pensar en una versión de Biztalk "Express".