Gabriel 的个人资料Biztalk Blandengue (http...照片日志列表更多  |  工具 帮助 |
|
2006/2/24 Como crear un mensaje a mano (manual) en un custom component para un receive pipeline de BiztalkComo crear un mensaje a mano (manual) en un custom component para un receive pipeline de Biztalk
Es posible que por diferentes circunstancias queramos crear un mensaje de manera totalmente controlada en un componente de un pipeline. En particular yo voy a explorar como hacerlo en un pipeline de entrada pero podria usarse una tecnica similar en un pipeline de salida.
Como es dificil entender un ejemplo sin un escenario, me plantee un escenario donde, desde un sistema externo, se envia un objeto del Framework .NET serializado de manera estandar y ese objeto debe ser ingresado a Biztalk dentro de un mensaje, en un esquema especifico. El componente del pipeline sera el encargado de resolver la "diferencia de impedancia" entre el objeto que ingresa desde el adaptador original y el mensaje XML que debe llegar a Biztalk. En particular, tendre una aplicacion Windows Forms, que permite ingresar un string en un campo de texto, esta aplicacion WinForm serializara este string usando un SoapFormatter y enviara el resultado de esta serializacion a un archivo en un directorio designado. Un receive port de Biztalk con una receive location asociada al directorio anterior, tomara este mensaje y lo enviara a un pipeline personalizado que tendra nuestro componente que, en la etapa de Disassemble, deserializara el objeto en un String nuevamente y lo insertara en un mensaje creado totalmente a mano de un tipo conocido por nosotros. La emision de ese mensaje luego se hara por un puerto de salida que puede suscribirse al tipo de mensaje que emita el pipeline (o para probar mas facil inicialmente, a todos los mensajes que entran por el receive port definido al principio).
Me parecio muy bueno publicar este ejemplo porque puede extenderse y ayuda en los siguientes casos:
* Si necesito crear un mensaje de manera completamente manual * Si necesito modificar un mensaje de manera extensiva en un componente * Puede ser extendido para cambiar el objeto String por cualquier objeto serializable de una aplicacion especifica (notar que el Assembly del objeto debe estar catalogado y accesible por el pipeline component en el Biztalk donde se realice la deserializacon). * Muestra de manera simple como controlar el tipo de esquema que se emite para Biztalk, lo cual puede servir para aplicaciones donde el esquema se debe definir en run-time en el pipeline. * Ejemplifica algunas tecnicas que no deben olvidarse nunca cuando se crea un pipeline component El ejemplo esta en BTS 2004 pero funciona sin problemas convirtiendolo a BTS2006. Los fuentes estan acá: http://www.paradigma.com.uy/paradigma/PublicFiles/ManualMsgPc.zip
2006/2/22 Cursos gratis de Biztalk2006/2/14 Feliz Día BiztalkMe gusta como nos hablamos con esquemas claros, y cómo cuando por algo no nos entendemos, siempre tenemos un mapa que nos muestra como llegar de un punto al otro.
Si algo necesita coordinación, siempre tenemos una orquestación que nos guía para que no perdamos el hilo de nuestra relación.
En cualquier caso, la flexibilidad de tus adaptadores y cómo puedo incorporar diferentes componentes en tus pipelines me hacen sentir siempre cerca tuyo.
¿Donde están mis otros Adapters?Si están buscando los adaptadores para Oracle, JDEdwards, PeopleSoft, Siebel o TIBCO, no se instalan con el paquete principal, tienen que tener el .EXE "Microsoft_BizTalk_Adapters_for_Enterprise_Applications-Beta2.exe" y después de descomprimirlo y ejecutarlo, les quedan en c:\Program Files\Microsoft Biztalk Server 2006\LOBAdapters.
2006/2/6 El contexto y el mensajeSupongamos que usted tiene que integrar varios sistemas que llegan por el mismo "canal" de comunicaciones. Específicamente y ya que aquí hablamos de Biztalk, imagine que llegan varios mensajes de distintos sistemas por el mismo adaptador. Entonces es lógico que necesite incorporar al mensaje información del sistema donde viene, y, potencialmente algunos otros datos acerca del mensaje. Es decir, adicionar al mensaje información que, normalmente es información "de contexto". Cuando digo "de contexto" es metainformación, información acerca del mensaje en sí, pero que no atañe al mensaje. Esta información, sin embargo, deberá ser incorporada en alguna instancia (el propio sistema origen, el adaptador, etc.) para que pueda yo luego realizar procesamiento teniendo en cuenta esta información de contexto. Está claro que necesito agregarla, ahora me centraré en por qué tengo que agregarla separándola del mensaje. Pensemos en el mensaje en XML, que hoy por hoy es la única representación de mensajes en la cual nos podemos poner de acuerdo cuatro o cinco que nos juntemos con unos cafés de por medio (con alcohol de por medio nos ponemos de acuerdo de cualquier cosa). Si yo separo la información de contexto en un registro diferente, tengo dos ventajas innegables:
1) Puedo potencialmente generar un tipo "registro de contexto" común a diferentes sistemas, dado que normalmente la información de contexto en el escenario planteado es bastante horizontal.
2) Puedo, una vez determinado el flujo de control por donde debo continuar el procesamiento de un mensaje o el canal al cual lo tengo que enviar, separar el mensaje original sin información adicional de contexto para que llegue al sistema destino.
Ejemplo, un alta de cliente genera un mensaje del tipo
<Cliente>
<Nombre>Juan Perez</Nombre>
<Direccion>Molino de Perez 343</Direccion>
</Cliente>
Si viene del sistema "Payroll" en modo de "Alta Definitiva" esta información de contexto podría ser capturada como sigue:
<MensajeSistema>
<Contexto>
<Sistema>Payroll</Sistemas>
<Operacion>AltaDefinitiva</Operacion>
</Contexto>
<Mensaje>
<Cliente>
<Nombre>Juan Perez</Nombre>
<Direccion>Molino de Perez 343</Direccion>
</Cliente> </Mensaje>
<MensajeSistema>
Sería fácil, en función de este registro, emitir el mensaje solamente para un sistema que esté esperando solamente los datos, dado que el sistema probablemente me defina una orquestación y la operación alguna acción dentro de la misma.
2006/2/4 Trucos por Don BoxEl amigo Wilson me envió este link con Don Box, vale la pena (como siempre) verlo.
Si no tienen tiempo, algunos bocaditos:
* Recordar que el objetivo final de la presentación es "poner algo en la cabeza de la audiencia".
* Less is more.
* No olvidar que siempre estamos tratando de conservar la atención del oyente.
* Modular: no hablar tán rápido. Usar tonos de voz, recordar que hablar bajo crea intimidad y trae a la audiencia más cerca.
* Para los técnicos: usar font Lucida Console 14.
* Descansar: si la noche anterior no sabemos algo, no lo sabremos al día siguiente a las 8 de la mañana.
* Enfocarse en los conceptos, no en los hechos; los hechos los podemos repartir en un documento para que la gente se lleve.
* No dar tanta relevancia al powerpoint. Algunas frases:
"Powerpoint is meaningless. Powerpoint is, at best a meaning to an end. What matter is what the guy or girl in the room is gonna say, how they're gonna control the experience"
Con respecto a la competencia que se genera entre el presentador y los slides:
"You're trying to grab they're attention and people are trying to read the slides. They figure there's something important there"
"You're constantly competing with this visual aid wich is supposed to be an aid"
|
|
|
%3a+2006%e5%b9%b42%e6%9c%88&referrer=){kind=small}
