1.31.2011

Transformaciones en los Puertos: Biztalk

Normalmente cuando creamos orquestaciones recibimos un mensaje de un cliente y dentro de la orquestación lo transformamos hacia un tipo de mensaje el cual vamos a enviar a otro puerto o vamos a procesar en la orquestación. Este tipo de mapeos es normal para los que desarrollamos en Biztalk, sin embargo; estamos desaprovechando una de las características más importantes del Biztalk: Transformar fuera de la orquestación, es decir en el puerto físico.

¿Y que ventajas tiene este tipo de solución?

Pues muy simple, si el mensaje del cliente cambia ( como suele suceder ) y yo tengo el proyecto dividido correctamente ( una librería para los esquemas, otra librería para los mapas, otra para las orquestaciones y otra para los pipelines ) entonces no tenemos que recompilar nuestra orquestación para hacer el cambio, solamente debemos cambiar el mensaje y modificar el mapeo.

El Ejemplo

Para comprender mejor el concepto vamos a trabajar con un ejemplo. En primera instancia vamos a crear un mensaje que es el que nos llega desde el cliente. Este mensaje tiene un campo tipo consulta de tipo entero que nos indica que consulta desea hacer:

image

Si el TipoConsulta es 0 se requiere una consulta de una persona física, y si es 1 se requiere una consulta de persona jurídica. Pero ahora vamos a suponer que dentro de la orquestación se utiliza otro mensaje, ya que el tipo de consulta es de tipo string, es decir “Fisica” o “Juridica”. El mensaje a utilizar dentro de la orquestación es el siguiente:

image

En situaciones normales recibiríamos el mensaje del cliente y haríamos la transformación dentro  de la orquestación, sin embargo; en este caso no vamos a hacerlo de esa forma. Esta vez, vamos a esperar en la orquestación el mensaje ya transformado y luego de forma muy simple vamos a escribir en el log el tipo de consulta solicitada. La orquestación es la siguiente:

image

Las comparaciones se hacen contra un string y no contra un entero.

image

Las formas de Scripting simplemente tienen una línea de código en C# en donde se indica hacer log del tipo de consulta solicitada:

image

Ahora creamos el mapa para la transformación.

image

En el functoid de script esta la comparación para hacer la transformación.

image

Una vez completado este trabajo, vamos a configurar la orquestación en la consola de administración, nótese que no hemos asociado el mapa a la orquestación en ninguna parte. Para esto, configuramos la orquestación en la consola y le creamos un puerto de recibo y una locación de recibo; la locación de recibo será vía archivo.

image

Ahora si, procedemos a asociar el mapa con el puerto de recibo.

image

Como podemos ver en la imagen, en la opción “Inbound Maps” del puerto, establecemos el mapa que transformará el mensaje del cliente antes de llegar a la orquestación – de hecho si no se transforma la orquestación no se activaría porque no esta esperando un tipo de mensaje del cliente si no el mensaje ya transformado.

Luego ponemos el mensaje en el folder establecido en el receive location, y procedemos a verificar el log con el resultado del procesamiento.

image

Como podemos ver, la transfomación se hizo en el puerto físico y la orquestación se activo porque al messageBox llego el mensaje ya transformado.

Technorati Tags:

1.27.2011

SQL Adapter Wizard Desaparece Generando Orquestación: Biztalk Server 2010

Me encontré con un errro atípico en Visual Studio 2010 a la hora de generar una orquestación a partir de un procedimiento almacenado. Resulta que cuando estaba generando la orquestación el Wizard se cerraba y no se generaba nada ni aparecía ningún mensaje de error error. Luego de “Googlear” en “Bing” el error logre dar con el problema.

Resulta que el wizard se estaba cerrando porque tenía una instalación corrupta del SQLXML 4.0 SP 1 el cual es necesario para generar los tipos desde SQL Server y así poder generar los esquemas con los que Biztalk Interactúa con la base de datos. Al final la solución es reinstalar el SQLXML que esta disponible en el archivo CAB de los redistribuibles para instalar Biztalk Server 2010, los cuales pueden obtenerse desde acá – muy buena referencia por cierto.

El archivo a instalar es el siguiente:

image

Espero les ayude Smile

Technorati Tags: ,

1.24.2011

Maestro Detalle con el Entity Framework 4.0

Quizás la tarea más común a la hora de desarrollar un software de negocios es el uso de maestros detalles en nuestra aplicación, es decir una entidad padre con varios hijos que la complementan. Esto conlleva a que se de una pregunta entre los desarrolladores con mucha frecuencia: ¿cómo funciona un maestro detalle con el Entity Framework? En este post vamos a solucionar este problema.

Foreign Keys en el Entity Framework 4.0

En el EF 4 se creo una nueva forma de manipular asociaciones a través de las llaves foráneas de las tablas asociadas. Esta forma de relación se le llama “Asociación de FK”. Esto permite incluir las columnas de la llave foránea como propiedades en las entidades con lo cual el manejo de las relaciones es mucho más sencillo a la hora de llevar a cabo operaciones del CRUD – Create – Retrieve – Update – Delete. Por ejemplo, a la hora de crear un producto podemos hacer la asociación entre las clases de la forma que se presenta a continuación.

using (var context = new Context()) 
{
Product p = new Product
{
ID = 1,
Name = "Papas Fritas Congeladas",
Category = context.Categories
.Single(c => c.Name == "Comida")
};
context.SaveChanges();
}

Ejemplo


Como de costumbre, vamos a ilustrar el concepto a través de un ejemplo desarrollado en .NET. En este caso vamos a tener una base de datos con el siguiente esquema.


image


Cabe resaltar que los campos Id de cada una de las tablas son AutoIdentity y que la relación del esquema se hace entre el campo OrdenId de la tabla detalle y el campo Id de la tabla Orden. Luego procedemos a crear un proyecto de Tipo Librería de Windows – dll y generamos el esquema se genera automáticamente para el EntityFramework.


image


Como podemos ver en la figura anterior aunque se genera la relación para navegar entre ambas clases, la propiedad IdOrden que relaciona la Orden con el detalle se genera para que podamos utilizarla vía código. Luego procedemos a crear la capa de lógica de negocios, en la cual solo vamos a crear una clase para el manejo de las órdenes y el método que me permite agregar una orden y sus respectivos detalles.

using DAL;

namespace BL
{
public class Orden_BL
{
public int AgregarOrden( Orden pOrden, List<Detalle> pDetalle )
{
foreach (Detalle d in pDetalle)
{
pOrden.Detalle.Add(d);
}

Common.ObtenerContexto().Ordenes.AddObject( pOrden );

return Common.ObtenerContexto().SaveChanges();

}
}
}

En este caso procedemos a recibir dos parámetros a la hora de ingresar la orden a la base de datos: La orden y la lista de detalles que le vamos a asociar a la orden. Seguidamente recorremos la lista de detalles y los vamos agregando uno a uno. Por último agregamos la nueva orden al contexto del esquema del entity framework y procedemos a salvarlo en la base de datos. El código del método ObtenerContexto es el siguiente:

using DAL;

namespace BL
{
public class Common
{
private static Ejemplos_BlogEntities _contexto;
public static Ejemplos_BlogEntities ObtenerContexto( )
{
if (_contexto == null)
_contexto = new Ejemplos_BlogEntities();
return _contexto;
}
}
}

Por último creamos el UI. Esta parte es un poco más simple ya que solamente tenemos que interactuar con la lista de detalles y la orden que vamos a crear. En primera instancia vamos a crear una variable del tipo Lista de detalle para almacenar todos los detalles que vamos creando:

private List<Detalle> _detalles = new List<Detalle>();

public List<Detalle> Detalles
{
get { return _detalles; }
set { _detalles = value; }
}

Seguidamente creamos un botón para agregar detalles a la orden que queremos crear y en este evento procedemos a agregar el nuevo detalle a la colección de detalles y a refrescar el Grid de detalles.

private void btnAgregar_Click( object sender, EventArgs e )
{
Detalle _detalle = new Detalle();
_detalle.Producto = txtProducto.Text;
_detalle.Cantidad = Convert.ToDecimal( txtCantidad.Text );

Detalles.Add( _detalle );

dgvProductos.DataSource = null;
dgvProductos.DataSource = Detalles;
}

Nótese que hasta el momento no existe ningún tipo de interacción con la clase Orden. Esta se lleva a cabo cuando el usuario del sistema decide guardar la orden; es en este momento en donde se procede a crear una instancia de la orden y a invocar el método de la lógica de negocios que hace la inserción de la orden con sus respectivos detalles.

private void btnTerminar_Click( object sender, EventArgs e )
{
Orden _orden = new Orden();
_orden.Cliente = txtCliente.Text;
_orden.Fecha = DateTime.Now;
_orden.Numero = txtNumeroDeOrden.Text;

Orden_BL _ordenBL = new Orden_BL();
_ordenBL.AgregarOrden( _orden, Detalles );
}


La pantalla que estamos utilizando – advirtiendo que yo por lo general hago pantalla muy desagradables – es la siguiente:


image


Si revisamos la tabla de órdenes vemos que la consulta nos retorna el siguiente resultado:


image


Vale la pena recalcar el hecho de que el Id autogenerado de la orden es 1. Ahora veamos la consulta a la tabla de detalles:


image


Nótese el hecho de que la relación de llave foránea con la orden se hizo de forma automática ya que en ninguna parte del código procedimos a asignar directamente el Id de la llave foránea, simplemente asignamos cada uno de los detalles a la lista de detalles de la orden en la capa de negocios.


Es importante de hacer notar a los que nos leen que no se utiliza ningun esquema de transaccionabilidad en este modelo, ya que no es necesario hacer rollback o commit de la operación en algún momento dado porque el esquema lo estamos asociando en memoria y antes de enviarlo a la base de datos, por lo que al final es una sola operación la que se ejecuta contra la base de datos.


Technorati Tags: ,

1.13.2011

SOA Myth 1: Estandarizar el Formato del Mensaje

Muchos de los proyectos en lo que tengo la suerte de trabajar estan relacionado con Arquitectura Orientada a Servicios. En estos proyectos es normal escuchar opiniones de las personas involucradas en estos proyectos respecto a lo que es SOA, lo que no es SOA, el mejor SOA, el peor SOA, etc. Además, acompañando estas opiniones vienen muchos mitos que por alguna razón surgen y luego persisten en la organización respecto a este tema. Por esta razón he decidido iniciar una serie de post acerca de estos mitos acerca de SOA. En la misma voy a tratar de ir mencionando todos los mitos que he escuchado e ir aclarándolos. Si alguno por ahi tiene algún tema que considera erróneo respecto a SOA, lo puede postear y con gusto lo voy a tratar.

SOA Myth 1: Estandarizar el Formato del Mensaje

Este quizás uno de los aspecto que más se menciona a la hora de construir un proyecto en este tipo de arquitecturas. Inicialmente, las empresas que quieren construir un core de mensajes – un ESB – primero miden el nivel de persuación que pueden tener en contra de sus “partners” y dicen cosas como:

  • Nosotro definimos el mensaje y el que quiere integrarse tiene que cumplir con el esquema del mismo.
  • Use lo que quieran en el core – cualquier tecnología – es problema de los partners si pueden integrarse bien o no.

Este pensamiento se da porque estamos acosumbrados a desarrollar aplicaciones locales que o comparten datos a través de su base de datos, o en el mejor de los casos se integran a través de servicios Web – arquitectura punto a punto. {he aquí otro mito: SOA y Servicios Web que atacaremos en otro post}

En realidad la idea del ESB es poder interconectar sistemas permitiendo no solamente a las empresas tener la posiblidad de conectarse sin conocer exactamente donde esta la aplicación ni que tipo de aplicación es, si no también brindándo la posibilidad de integrarse con el bus con los datos que actualmente tiene  – o maneja - la empresa, caso contrario como haría la empresa para meter datos a un BUS que no tiene? Es por esta razón que los ESB tienen módulos para hacer mapping y functoids dentro de los mapas para mejorar la calidad del mensaje – al final los mapas son documentos XSLT que hacen transformaciones de los datos.

Otro punto a destacar es que no siempre el ESB solo sirve para exponer servicios, si no también para consumir. En este caso debemos acoplar el mensaje que viene con lo que estamos necesitando dentro del ESB y esto depende explícitamente de lo que vayamos a hacer dentro de nuestro workflow de negocios. En la siguiente figura se ven los dos esquemas de exposición de los EndPoints.

image

En el esquema con el Partner 1  el partner me expone el servicio que ya tiene desarrollado y yo procedo a consumirlo, en este caso tengo que mapear el mensaje que ingresa con el mensaje que se espera dentro del bus y transformarlo para que tenga la estructura que yo deseo. En el esquema con el partner 2 yo expongo el servicio con el formato de mensaje que yo establezco; en este caso, yo defino como me deben de llegar los mensajes. Al final lo que debe privar es la posiblidad de enviar y recibir mensajes sin importar quién define la estructura del mensaje y ninguna entidad debe forzar a otra entidad a cambiar sus esquemas de datos para satisfacer su flujo de trabajo.

Technorati Tags: ,

1.03.2011

Calculando el Costo de una Aplicación en Windows Azure

Uno de los temas más complicados de explicar a las empresas a la hora de ingresar al mundo de la computación en la nube es el costo de este nuevo esquema. Normalmente las empresas están acostumbradas al esquema de licenciamiento y por lo tanto cuesta un poco entender como es que funciona el cobro en la nube. En este post voy a tratar de explicar a través de ejemplos lo que podría costar tener una aplicación funcionando en Windows Azure.

Costos

Si nos vamos directamente al sitio de Windows Azure y verificamos el esquema de costos, nos vamos a encontrar con la siguiente tabla.

Compute Instance Size CPU Memory Instance Storage I/O Performance Cost per hour
Extra Small 1.0 GHz 768 MB 20 GB Low $0.05
Small 1.6 GHz 1.75 GB 225 GB Moderate $0.12
Medium 2 x 1.6 GHz 3.5 GB 490 GB High $0.24
Large 4 x 1.6 GHz 7 GB 1,000 GB High $0.48
Extra large 8 x 1.6 GHz 14 GB 2,040 GB High $0.96

 

 

 

 

¿Y esto que significa? Bueno, básicamente que dependiendo del tamaño del programa que vamos a tener y del desempeño que vamos a necesitar, así nos pueden cobrar. Además tenemos que tener en cuenta el costo por transacción y el costo por el storage ya sea utilizando Azure Tables o SQLAzure. Para las transacciones vamos a tener un precio de $0.01 / 10K ( Kilobytes ). En lo que respecta a SQLAzure vamos a tener los siguientes precios:

  • Web Edition:
    • Up to 1 GB relational database = $9.99 / month
    • Up to 5 GB relational database = $49.95 / month
  • Business Edition:
    • Up to 10 GB relational database = $99.99 / month
    • Up to 20 GB relational database = $199.98 / month
    • Up to 30 GB relational database = $299.97 / month
    • Up to 40 GB relational database = $399.96 / month
    • Up to 50 GB relational database = $499.95 / month

Igualmente en la base de datos vamos a tener un precio por transacción el cuál estaría reflejado por este precio:

  • Data transfers = $0.10 in / $0.15 out / GB

El último precio del que debemos estar consciente es el ancho de banda de entrada y salida, el cual es el tráfico que existe entre el browser del usuario y el sitio o los servicios que tengamos en nuestra instancia. Este tiene el siguiente costo:

  • Data transfers = $0.10 in / $0.15 out / GB

Escenario

Para comprender un poco mejor como trabaja el esquema de precios vamos a utilizar un ejemplo Supongamos que queremos una aplicación web pequeña que no tiene un uso elevado y que nos va a servir hacer nuestros reportes diarios de labores. En primera instancia vamos a utilizar una instancia pequeña de la aplicación por lo que el esquema de costo sería:

Small 1.6 GHz 1.75 GB 225 GB Moderate $0.12

 

 

Se quiere además que la instancia este ejecutándose 24x7x365 lo que nos daría un costo mensual de

$0.12 * 24 * 30 = $86.4

Seguidamente definimos utilizar SQLAzure en su versión web de hasta 1 GB, por lo que el costo mensual sería de $9.99

El ancho de entrada y salida a utilizar sería de 4 gigas de entrada y 4 gigas de salida,  esto nos daría el siguiente costo mensual:

Entrada = 4 GB * $0.10 = $0.40

Salida = 4 GB * $0.15 = $0.60

El costo total de nuestra aplicación sería:

Costo de 1 Instancia = $86.4

Costo SQL Azure = $9.99

Ancho de Banda = $0.40 + $0.60 = $1

El costo total mensual de tener nuestra aplicación en Azure sería:

$97.39

Variaciones

Si nuestra aplicación va a tener un esquema simple de datos, podemos eliminar SQLAzure y proceder a utilizar Azure Tables. El costo por GB en Azure Storage es de $0.15. Además el costo por transacción de storage es el siguiente:

Storage transactions = $0.01 / 10K

Si calculamos 3 gigas de datos y unas 50000 transacciones el costo sería el siguiente:

6 GB * $0.15 = $0.9

50000 transacciones * 0.01 / 10K = $0.05

Con esto el storage nos saldría por $1.4 mensuales en lugar de $9,99 – por supuesto teniendo en cuenta la desventaja de perfomance e integridad referencial al no utilizar una base de datos relacional. El costo total sería de $88,8.

Conclusiones

A primera vista parece que es más cómodo tener hosting que cloud computing, pero cuidado, los modelos son muy diferentes y existen una gran cantidad de ventajas cuando se usa cloud computing que en post posteriores vamos a estar analizando.

Technorati Tags: