.Net, Biztalk, y lo que venga...

Introduccion a conectores de BizTalk R2 para WCF

2008-12-25T17:30:00.000-08:00

Hace algún tiempo vengo trabajando con las nuevos adaptadores de WCF que vienen incluidos en la versión R2 de BizTalk 2006, y la idea de este post es solo dar una pequeña introducción a lo que me toca utilizar de todo este conjunto de nuevas herramientas y en algunos post posteriores iré publicando como consumir desde BiztTalk servicios publicados con WCF y las distintas opciones para esto.
Como la mayoría de los que puedan leer este post sabrán, WCF ofrece un rango bastante amplio de posibilidades a cerca de las opciones de cómo consumir un servicio WCF publicado, estas opciones o “bindings” varían tanto en el tipo de transporte y configuraciones de seguridad, pero en general las opciones serian las de la siguiente tabla:

Comenzar con un Send-Port Basico

Comenzaremos creando un Send Port que utiliza el adaptador WSHttpBinding. En este primer paso nuestro objetivo seria integrarse endpoint que se se construye por defecto al crear un servicio WCF en Visual Studio 2008.

Lo primero que deberíamos hacer es asegurarnos que el servicio este levantado y la configuración de su binding se corresponda con el Send Port que estamos creando, esto seria simplemente poner la URL en un IExplorer, verificar que el WSDL del servicio se muestra correctamente y además el binding del servicio expuesto como se muestra en la imagen

Realizados esto pasos tendremos que seleccionar el adaptador y luego podemos hacer click "Configure" para configurar como el adaptador WSHttpBinding como debería ser usado.

Donde los datos que deberemos completar este tipo de Send-Port son realmente muy pocos, por un lado la URL del servicio, por el otro la Soap-Action del methodo que queremos consumir en este Send-Port y cuyo "wsdl:operation name" coincide también con la operación de del servicio que queremos instanciar. (esto es básicamente copiar del WSDL al TextBox: Action como se muestra a continuación).

Muestra del WSDL del servicio:

Configuración del puerto para consumir la operación del WSDL marcado arriba:

Eso seria todo por ahora, en próximos post prometo mostrar como consumir servicios con Custom Binding, que por cierto son bastante mas complejos de consumir y configurar.

Espero que pueda servirles.

Ariel Serlin

Cargar hoja de Excel (.xls) en GridView de Asp.Net

2008-12-23T10:58:00.000-08:00

Algo que a menudo sucede, es que nuestros usuarios pueden tener "bases de datos" enteras en sus computadores en formato Excel y por alguna cuestión que desconozco repentinamente quieren comenzar a utilizarlas dentro de un determinado sistema como una fuente de datos para no tener que cargar todo de nuevo.

Una posible aproximación a solucionar este problema es la que trato de mostrar acá, que básicamente seria importar una hoja de MS Excel a un GridView de Asp.Net, una vez cargada en nuestra grilla, poder darles la posibilidad a nuestros usuarios de corregir algún dato. Finalmente quedaría recorrer la grilla y guardar estos datos en nuestra DB o procesarlos de alguna otra manera (si alguien tiene problema con esta ultima cuestión por favor no dude en escribir). También es válido aclarar que en el ejemplo asumo de antemano que conocemos la estructura del Excel que pretende bindearse al nuestro GridView.

Yendo directamente el punto, la idea en es poder utilizar al motor de consultas JET 4.0, de la misma manera en la que lo utilizaríamos para consultar cualquier otra fuente de datos (una base de datos de MS Acces por ejemplo).

Les copio el código, que me parece que habla por sí solo y más abajo un link con una solución de prueba en la que dejo también incluido un archivo de Excel con el que se podrá probar la solución, solo deberán seleccionar el archivo y luego darle un click al botón importar.

 protected void btnImportarNomina_Click(object sender, EventArgs e)
    {
        if (nominaExcel.PostedFile != null)
        {
            List<Lista> listaCollection = new List<Lista>();
         
             StringBuilder sbConnection = new StringBuilder();
                sbConnection.Append("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=");
                if (nominaExcel.PostedFile.FileName.Contains(".xls"))
                {
                    sbConnection.Append(nominaExcel.PostedFile.FileName);
                    sbConnection.Append(";Extended Properties=Excel 8.0;Persist Security Info=False");
                    System.Data.OleDb.OleDbConnection SQLCon = new System.Data.OleDb.OleDbConnection(sbConnection.ToString());
                    System.Data.OleDb.OleDbCommand SQLCom = new System.Data.OleDb.OleDbCommand("select * from [Hoja1$]", SQLCon);
                    System.Data.OleDb.OleDbDataAdapter SQLDa = new System.Data.OleDb.OleDbDataAdapter(SQLCom);
                 
                    SQLCon.Open();
                    IDataReader Odbreader = SQLCom.ExecuteReader();
                    listaCollection.Clear();
                    while (Odbreader.Read())
                    {
                        Lista lista = new Lista();
                        if (!String.IsNullOrEmpty(Odbreader[0].ToString()))
                        {
                            lista.NumeroDocumento = Convert.ToInt32(Odbreader[0]);
                            lista.Nombre = Odbreader[1].ToString();
                            lista.FechaNac = Convert.ToDateTime(Odbreader[2]);
                            listaCollection.Add(lista);
                        }
                    }
                    SQLCon.Close();
                    GridView1.DataSource = listaCollection;
                    GridView1.DataBind();
                }
        }
    }

Ariel Serlin

Para bajar el codigo hace click aqui

Consultar usuarios de Active Directory desde C#

2008-12-21T16:27:00.000-08:00

Algo que puede resultar muy útil en algunos casos es tener que consultar información de los usuarios de la red dados de alta en Active Directory desde nuestra aplicacion, en este caso con C#.

Para comenzar deberemos tener en cuenta que es necesario poder contar con un usuario dado de alta en Active Directory, aunque con mínimos permisos. Este usuario con el que deberemos contar sera el usuario que se conecte a nuestro Active Directory(en el caso del código este ejemplo debería agregarse su información en nuestro web.config). Y servirá para el caso en el que querramos obtener por ejemplo el correo electrónico, nombre, apellido, o algún otro dato de cualquier usuario, solo teniendo su loguin por ejemplo.

Yendo puntualmente a la solución de nuestro problema, lo primero que deberemos hacer en nuestro proyecto es referenciar al assembly System.DirectoryServices, posteriormente deberemos hacer un using de la misma

Así de simple podremos consultar la información de nuestros usuario de la siguiente manera

Si bien el código que sigue no tiene grandes complicaciones, básicamente consta de dos clases (en el mismo archivo ), que para el caso de la primero solo modela un usuario con sus propiedades y la segunda contiene un método con el comportamiento necesario para conectarse a nuestro AD, a través del usuario configurado en algún archivo de configuracion.

using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
using System.DirectoryServices;
namespace FindUSers
{
    public class Usuarios
    {
        private int id_User;
        public int Id_User
        {
            get { return id_User; }
            set { id_User = value; }
        }
        private string login;
        public string Login
        {
            get { return login; }
            set { login = value; }
        }
        private string password;
        public string Password
        {
            get { return password; }
            set { password = value; }
        }
        private string email;
        public string Email
        {
            get { return email; }
            set { email = value; }
        }
        private string lastName;
        public string LastName
        {
            get { return lastName; }
            set { lastName = value; }
        }
        private string names;
        public string Names
        {
            get { return names; }
            set { names = value; }
        }
  
    }
    public class GetUsersInfo
    {
        public List<Usuarios> FindName(Usuarios usuario)
        {
            //This info can become from web.config
         
                string userAD = ConfigurationSettings.AppSettings["UserAD"];
                string passAD = ConfigurationSettings.AppSettings["PassAD"];
                string ldap = "LDAP://" + ConfigurationSettings.AppSettings["LDAP"];
                string strSearchAD = "";
                if (usuario.Email != "")
                {
                    strSearchAD = "(mail=" + usuario.Email.ToLower() + ")";
                }
                if (usuario.LastName != "")
                {
                    strSearchAD += "(sn=" + usuario.LastName + ")";
                }
                if (usuario.Login != "")
                {
                    strSearchAD += "(sAMAccountName=" + usuario.Login + ")";
                }
                List<Usuarios> listUsuarios = new List<Usuarios>();
                //DirectoryEntry adEntry = new DirectoryEntry("LDAP://Domaincontroler", "user", "pass", AuthenticationTypes.Secure);
                DirectoryEntry adEntry = new DirectoryEntry(ldap, userAD, passAD, AuthenticationTypes.Secure);
                System.DirectoryServices.DirectorySearcher adSearch = new System.DirectoryServices.DirectorySearcher(adEntry);
            
                adSearch.Filter = "(&(objectClass=user)" + strSearchAD + ")";
                SearchResultCollection objResultados;
                //adResult = adSearch.FindOne(); // if only i need the first returned user 
                objResultados = adSearch.FindAll();
                foreach (SearchResult MiObjeto in objResultados)
                {
                    Usuarios usarioToAdd = new Usuarios();
                    usarioToAdd.Email = MiObjeto.Properties["mail"][0].ToString();
                    usarioToAdd.Login = MiObjeto.Properties["sAMAccountName"][0].ToString();
                    usarioToAdd.Names = MiObjeto.Properties["givenName"][0].ToString();
                    usarioToAdd.LastName = MiObjeto.Properties["sn"][0].ToString();
                    listUsuarios.Add(usarioToAdd);
                }
                return listUsuarios;
       
        }
    }
}

Adjunto el código correspondiente al proyecto en el que se encuentra el archio .cs con las dos clases del ejemplo (recuerden agregar un archivo .config con las entradas necesarias ), espero que sirva.

Ariel Serlin

Para bajar el codigo hace click aqui

Suscribirse a multiples IDOCs en una misma ReceiveLocation ( Biztalk )

2008-12-04T06:47:00.000-08:00

Tuve un asunto hace poco en mi trabajo en la que necesitaba suscribirme a mas de un IDOC de SAP y por una cuestión de orden y buenas practicas en la arquitectura del proyecto de EAI en el que estoy trabajando los IDOCs debían ser recepcionados por la misma receive location.
La solucion vino de la mano de un Groso y en este post trato de pasar en claro la forma en la que puede hacer andar esto y por supuesto configurarlo.
La idea es básicamente crear una Pipeline la cual se encargue de desensamblar los IDOCs que lleguen a una determinada receive location y posteriormente configurar la pipeline construida en la receive location que necesitamos realice el trabajo.

El primer paso seria como venimos hablando generar una nueva Pipeline.
Debido a que los esquemas que Biztalk genera cuando importamos la estructura del IDOC sera local en cada proyecto en el que se hizo la importación, pero publico para cualquier proyecto que referenecie voy a hacer de cuenta que los esquemas son importados en los proyectos en los que se encuentran las orquestaciones con lógica y la pipeline se desarrollara en un assembly aparte.

En definitiva los proyectos de Biztalk o assemblys que contendría los esquemas de los IDOCs se verían así en el caso del primero:

Y así para el caso del segundo (pueden ser la cantidad que uno quiera o necesite):

En la siguiente instancia toca construir la Pipeline que nos va a solucionar el problema, la misma podría estar en un assembly aparte, esto es porque sera necesario referenciar las proyectos anteriormente construidos. Resumiendo en tres pasos el proceso de construcción de este proyecto serian básicamente, construirlo, referenciar los assemblys que contienen los esquemas correspondientes a cada IDOC y agregar una Pipeline de recepción que "desensamble" el IDOC correspondiente. Para esto en la Pipeline deberemos agregar tanto shapes de Flat File Disassemble como esquemas de IDCOs tengamos referenciados y configurar en cada sahpe arrastrado un el esquema correspondiente.

En lo que respecta a desarrollo esto seria todo. Quedaría finalmente hacer deploy de nuestros assemblys en el servidor y configurar, que es por cierto la parte mas sencilla, simplemente al crear nuestra Receive Location creada para recibir los IDOCs informarle que debera utilizar la Pipeline creada y recientemente desplegada en nuestro server de la siguiente manera:

Eso seria todo, espero que pueda servirle.

Ariel Serlin

Logging "Sencillo" en Biztalk

2008-12-01T05:19:00.001-08:00

En la casi todas las ocasiones en las que uno trabaja con Biztalk Server, es imprescindible poder loguear resultados, mensajes o excepciones en algún archivo de texto plano o en el visor de eventos de nuestro server, ya que al no tener interfaz de usuario la única manera de poder analizar detalladamente la ejecución de nuestro flujo de trabajo (workflow) diseñado es analizando el log escrito por la orquestación. Indudablemente lo más conveniente y aconsejable para esta tarea seria utilizar alguna de las librerías ya diseñadas para esta tarea, podrían ser Enterprise Library o Log4Net las más conocidas y que de hecho funcionan bastante bien.

Pero debido a que el uso de estas librerías implica tener que configurar o modificar archivos de conflagración y confeccionar algunos mas en el caso de EntLib, en muchos casos para poder hacer pruebas rápidas o para el caso en el que el entorno va a ser utilizado solo para probar alguna versión nueva de alguna tecnología (me a tocado tener que trabajar en varias maquinas virtuales ) dejo esta pequeña assembly en la cual existen 2 métodos.
El primero solo loguea el valor de alguna variable y el segundo permite escribir contenido de todo un mensaje en un archivo de log.
El código de la clase conteniendo ambos métodos seria:

[Serializable]







     public class ArielLog







    {















        public static void WriteValue(string value)







        {







            File.AppendAllText("C:\\ArchivosLog.txt", value);







            System.Diagnostics.EventLog.WriteEntry("BizTalkLog", value);







        }








        public static void WriteMessage(XLANGMessage msg)







        {







            XmlDocument doc = (XmlDocument)msg[0].RetrieveAs(typeof(XmlDocument));











            string mensaje = doc.InnerXml;







            File.AppendAllText("C:\\Mensjaes.txt", mensaje);







        }








    }

Y para usar estos dos métodos simplemente restaría referenciar a la assembly en la que se encuentra la clase que los contiene y ya podrían ser llamados desde cualquier shape de expresión de la siguiente manera:

Para loguear un mensaje

O para loguear el valor de una variable:

Eso seria todo, por si alguien quiere recompilar la librería para cambiarle el nombre o lo que fuera, adjunto una solución con el código de la assembly firmado para poder ser subida a la GAC y así poder utilizarla desde Biztalk Server.

Ariel Serlin

Para bajar el código hace click aquí

Manejo de Excepciones en Web Services (SOAP Exceptions) con .Net

2008-11-23T12:44:00.000-08:00

Por segunda vez :-( , me toca renegar un poco con el manejo de excpecion que son lanzadas desde web services estándares (no WCF) y hago este post con el solo fin de recordar cómo era para la próxima vez que me toque y por si a alguien más pudiera servirle.

Como sabrán las excepciones lanzadas desde un servicio web (SOAP Exceptions) tienen la particularidad que la propiedad InnerException llega al cliente que consume el servicio por lo general (siempre en mi caso) vacía. Existe sin embargo, en este tipo particular de excepción, una propiedad llamada ¨Detail¨ la cual es perfectamente serializable como XML y puede ser enviada al cliente para su manejo sin ningún tipo de inconveniente.

Ahora bien, para ser lo más explicativo posible, voy a partir del supuesto de que nuestra solución esta desarrollada en distintas capas y la excepción no se genera siempre en el WebMethod que consume el cliente que deberá manejar esta excepción. Pues bien, vamos a suponer que en el caso de nuestra capa de servicios ocurre una excepción y es lanzada hacia alguna capa superior:

public void lanzarException()

     {

         try

         {

             throw new Exception("Se produjo la exception que podria haber sido SQL o regla de negocio");

         }

         catch (Exception e)

         {

             throw e;



         }




     }

Una vez capturada esta excepción, el paso siguiente seria extraer la información de la misma y darle el formato correcto para poder insertar la información extraída, insertarla en un XML y luego "copiar" el mismo en la propiedad detail de la SoapException queremos informar. Para un fin práctico es puesto el código de esta funcionalidad en un método estático (no necesita crearse una instancia de la clase que lo contiene). Es conveniente también que la clase que contiene este metodo este en el mismo proyecto que los servicios web que estamos publicando (Carpeta App_Code) para así poder ser llamada desde cualquier parte del proyecto web.
La funcionalidad de dicho método debería ser como sigue:

public static SoapException BuildSoapException(string infoInnerNode)

        {

            // Nodo con detalles de excepcion.

            System.Xml.XmlDocument doc = new System.Xml.XmlDocument();

            System.Xml.XmlNode node = doc.CreateNode(XmlNodeType.Element,

                 SoapException.DetailElementName.Name, SoapException.DetailElementName.Namespace);

            //Genero informacion especifica para una soap Exception

            //Agrago el child nodo para el XML

            System.Xml.XmlNode details =

              doc.CreateNode(XmlNodeType.Element, "NodoInformacion",

                             "http://tempuri.org/");

            System.Xml.XmlNode detailsChild =

              doc.CreateNode(XmlNodeType.Element, "childConSpecialInfo",

                             "http://tempuri.org/");

            details.InnerText = infoInnerNode;

            details.AppendChild(detailsChild);



            // Meto el child adentro del nodo que acabo de crear.

            node.AppendChild(details);



            //Lanzo la excepcion     

            //el parametro SoapException.ClientFaultCode indica que la llamada desde el cliente fue incorrecta 

            //en formato o parametros

            SoapException se = new SoapException("Error de parametros,  formato, datos desde el cliente",

              SoapException.ClientFaultCode,

              "SeviciosContosoGetProductos",

              node);

            return se;



        }

Y suponiendo que la clase que contiene a dicho método se llamara SOAPExceptionBuilder podríamos simplificar el catch de nuestros web methods de la siguiente forma:

  catch (Exception e)
        {/* Este es el catch a poner el los WebMethods*/

            SOAPExceptionBuilder.exceptionALanzar = SOAPExceptionBuilder.BuildSoapException(e.Message);
            throw SOAPExceptionBuilder.exceptionALanzar;
        }

Finalizada la parte de servidor de cómo construir una Soap Exception solo restaría ver el trato que deberíamos darle del lado del cliente una vez que esta excepción fue capturada, pues bien, como decíamos al principio la propiedad detail de nuestra excepción no contiene otra cosa que no sea un XML por lo que podríamos recorrerlo y mostrar los detalles del error, crear una nueva excepción con los datos obtenidos o simplemente loguearlos. Una de las formas de recorrerlo sería la siguiente (yo solo los muestro por pantalla pero podría ser cualquier de las opciones anteriores):

 catch (SoapException error)
        {

            System.Xml.XmlNode node = error.Detail;
            string s = "";

            foreach (System.Xml.XmlNode nod in node.ChildNodes)
            {

                 s = nod.InnerText;
          
            }
            // LLeno los controles con los detalles de la exception
      
            TextBox1.Text = "Fault Code Namespace : " + error.Code.Namespace;
            TextBox2.Text = "SOAP Actor que lanzo la exception : " + error.Actor;
            TextBox3.Text = "Detalles : " + s;
            TextBox4.Text = "Mensaje : " + error.Message;


            return;
        }

Eso seria todo, espero que sirva y acordarme donde lo puse la proxima que lo tenga que usar :-)

Adjunto el código correspondiente a una solución en la que se encuentra un proyecto con "lógica" para lanzar una excepción cualquiera, un servicio que instancia esta clase y un proyecto web con una página que consume dicho servicio con todo el código utilizado en el ejemplo.

Ariel Serlin

Para bajar el codigo hace click aqui:

Encriptacion de entradas en el Web.Config

2008-09-29T13:24:00.000-07:00

Algo que me resulto realmente muy útil y muy sencillo de utilizar fue la herramienta que trae el SDK de .Net para poder encriptar distintas entradas o claves alojadas en el archivo Web.Config Con anterioridad a esta utilidad, una de las cosas que tocaban hacer era en el momento de hacer el deploy de una aplicación, era crear alguna utilidad mediante la cual el usuario, por lo general alguna persona del área de operación o infraestructura, pudiera editar claves o valores de configuración, encriptarlas o desencriptarlas para poder cambiar sus valores. Paso comentar alguna de las características de esta herramienta, aspnet_regiis.exe. Para comenzar las posibilidades de encriptacion son: mediante algoritmo RSA (Trafico de claves publicas y privadas) o mediante DPAPI (Data Protection application programming interface ). No es necesario tener el entorno de desarrollo instalado en la maquina en la que se quiere realizar la encriptacion/desencriptacion, si tiene que estar instalado el .Net Framework.

Me resulto bastante más útil el hecho de utilizar RSA por el hecho de que por lo general hay aplicaciones que necesitan ser desplegadas en un conjunto de servidores y con RSA se tiene la posibilidad de exportar la clave para después ser llevada a cada server en el que necesitemos desplegar nuestro sitio. Yendo al punto en cuestión, la herramienta puede ser accedida por línea de comandos como se accede a cualquier otra herramienta del SDK de .Net, desde el menú de Inicio->All Programs->Microsft Visual Studio 2005->Visual Studio Tools->Command Prompt Aquí las dos primeras opciones: El comando para encriptar puede trabajar tanto como rutas relativas o "virtuales” como absolutas o a la hora de indicarla la ubicación de nuestro web.config por lo que si queremos trabajar con rutas absolutas es aconsejable ubicarse en el mismo directorio físico en el que se encuentra el archivo a encriptar.

Un vistazo de mi web.config antes de ser encriptado seria algo asi:

Ahora si:
Si vamos utilizar parametros pasando la ruta virtual la opcion seria:

aspnet_regiis -pe "SeccionAEncriptar" -app "RutaVirtual"

Si vamos utilizar parametros pasando la ruta fisica de la aplicacion la opcion seria:

aspnet_regiis -pef "SeccionAEncriptar" -app "RutaFisica"

Por defecto, es decir si no especificamos un proveedor de encriptacion o metodo se realizara con RSAProtectedConfigurationProvider, podemos sin embargo combiarlo si lo especificamos en el parametro -prov y quedaria de la siguiente manera

aspnet_regiis -pef "SeccionAEncriptar" -app "RutaFisica"–prov "DataProtectionConfigurationProvider"

Para realizar la desencripatcion de los datos los procedimientos son los mismos, con la diferencia de que el parámetro pasado a al ejecutable aspnet_regiis deber ser: -pdf (en lugar de -pef si es que usamos rutas absolutas o fisicas ).

En este punto estamos ya en condiciones de tomar algunos recaudos:
La encriptación/desencriptación deberá realizarse en el mismo entorno en donde se encontrara instalada la solución, es decir una vez encriptados los datos, el archivo web.config no podrá ser desencriptado en otra máquina, esto es debido a que cuando utilizamos este comando las claves privadas se almacenan localmente en: C:\Documents and Settings\All Users\Datos de programa\Microsoft\Crypto\RSA\MachineKeys, demas esta decir que debemos tener permiso de escritura sobre esta carpeta.

Esta ultima aclaración servirá para darnos cuenta que al importarse la clave a nivel local en nuestra maquina, es muy probable que en un entorno distribuido (granja de servidores o server farms) algo pueda estar fallando, efectivamente deberemos asegurarnos de que nuestro web.config cuenta con la sección en la cual podremos indicar cual será nuestro contenedor de claves, la especificación de esta sección (configProtectedData) debería ser algo como:

Restaría entonces crear el contenedor de claves de la siguiente manera:

aspnet_regiis -pc "MiContenedor" –exp

Se crea así un nuevo contenedor para la clave de encriptación RSA, asignando el nombre "MiContenedor" y por ultimo:

aspnet_regiis -pa "MiContenedor" "ASPNET"

Donde "MiContenedor" deberá ser el mismo nombre asignado en –pc del comando anterior y que se corresponde con keyContainerName="MiContenedor"/> de webconfig.

Una ultima acotación sobre este tema que me pareció realmente practico, todo esto es a nivel de configuración de nuestro sitio, es decir que el acceso a las entradas de nuestro web.config desde el código sigue siendo igual que si no hubiéramos tocado nada, si lo que encriptamos fueron nuestras cadenas de conexión el acceso seria:

string strConString = ConfigurationManager.ConnectionStrings["MiConectionString"].ConnectionString;

Eso es todo y así de simple :-)

Ariel Serlin

Workflow State Machine y Persistence Service

2008-09-05T12:25:00.001-07:00

En la primera entrada de este blog voy a tratar de mostrar un ejemplo sencillo de utilización de maquinas de estado creadas con Windows Workflow Foundation. Como un amigo me consulto hace poco como haría para trabajar con State Machine Workflows y además utilizar el Persistence Service (serializar un workflow en una base de datos temporalmente) aprovecho la volada para hacer el post.

La idea básicamente de este tipo de workflow es modelar los distintos estados por los que podría pasar un documento o ítem cualquiera como por ejemplo, una factura, un comprobante o cualquier otra cosa que pudiera necesitar ser creado, aprobado, revisado y pueda volver a cualquier de estos estados anteriores.

El primer paso para comenzar a trabajar es ver que tengamos en nuestra PC todos los requisitos para poder trabajar con Workflow Fondation.

En caso de Visual Studio 2005, deberemos tener instalado la versión 3.0 del .Net Framework, las extensiones para workflow foundation y haber creado las bases de datos de persistencia de y tracking de Workflow Foundation, los scripts de creación están generalmente en el directorio: ( C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN )

Verificados estos requisitos podemos abrir Visual Studio y comenzar a trabajar.

El primer paso será crear un nuevo proyecto del tipo State Machine Workflow Librery

Una vez creado el proyecto, podremos comenzar a trabajar con el diseñador de workflow haciendo doble click sobre la clase creada por defecto "Workflow1.cs", en este ejemplo asumiré que solo se trabaja con dos estados posibles, más un estado final.
El diseño de lo que puede suceder en cada estado que identifiquemos seguramente podrá variar mucho de acuerdo al problema que se esté modelando, pero básicamente la idea que trato de mostrar en este caso sería como pasar de un estado a otro, ejecutar algo de código al pasar a ese estado y luego suspender o serializar el workflow hasta que necesitemos utilizar esa instancia nuevamente.

Para hacer que nuestros estados "escuchen o esperen" realizar alguna acción deberemos prepararlos o hacer que se suscriban a un determinado evento, esto seria básicamente agregando tantos Shapes de EventDriven como eventos queremos que se manejen en un estado.

Una vez realizado esto el paso siguiente seria manejar cada uno de los eventos que queremos capturar en cada estado y por cada EventDriven que hayamos manejado. Es aquí donde viene la parte en la que tenemos que escribir un poco de código...,

Necesitaremos primero una clase que herede de ExternalDataEventArgs y de esta forma poder dar a nuestra clase la capacidad de enviar datos a cuando se lanzan eventos, es muy importante que esta clase está marcada con el atributo [Serializable].

El paso posterior a este, seria modelar una interfaz de comunicación la cual deberá estar marcada con el atributo [ExternalDataExchange] y declarar en esta interfaz todos los eventos que vallamos a lanzar en una clase que implementará la interfaz en cuestión, adelantando un poco de que se trata esto el sentido real de esta interfaz de comunicación es poder decir a nuestros estados cuales son los métodos que deberán estar escuchando una vez instanciado nuestro workflow.

Siguiendo con la misma línea tocaría ahora construir una clase que implemente la interfaz recién modelada. De esta forma estaríamos ya en condiciones con continuar el modelado de nuestro flujo de trabajo y teniendo ya las clases que exponen los métodos declarados en la misma podemos avisarle a nuestro flujo de trabajo en qué momento deberá escuchar algún evento o serializarse y persistirse en una base de datos. Para poder hacer esto deberemos hacer doble click sobre alguno de nuestros EventDriven, como comentaba al principio dentro de cada de EventDriven podemos hacer muchas cosas pero a fines explicativos solo pasare de un estado a otro o simplemente persistir el flujo de datos en la DB de persistencia de WorkflowFoundation, para cualquier de los dos casos haciendo doble click sobre cualquier EventDriven podemos agregar Shapes de HandleExternalEvent, que como su nombre lo indica mediante estos podríamos manejar los eventos que fueron lanzados e identificados por los EventDriven, por supuesto después de la ejecución cada EventDriven podemos hacer invocar un Suspend (mas abajo explico un poco mas ) o un SetState
Con los segundo SetState principalmente logramos que nuestro workflow pase de un estado a otro, sencillamente lo que debemos hacer al usar estos shapes es decirle a que estado deberá moverse el workflow cuando la ejecución paso por el mismo, algo muy bueno que vi en este tipo de workflows es que a medida que vamos crenado las distintas transiciones mediantes nuestros SetState dentro de nuestros posibles estados, workflow se encarga de mostrar en forma grafica las nuevas transiciones

Respecto de los Suspend, es muy importante verificar la configuración de los dos parámetros TimeSpan que pide el servicio de persistencia de Workflow Foundation (Persistence Service) al momento de agregar este servicio a nuestro workflow, en el caso del primer parámetro indica durante cuando tiempo nuestro workflow será "dueño" de esa instancia, y el segundo le indica a WF cada cuánto va a ir a nuestra DB a buscar workflow que hayan expirado, teniendo las precauciones recién mencionadas básicamente dotamos a nuestro workflow de la capacidad de automatizar totalmente la persistencia de nuestras instancias en una DB (es válido aclarar que tiene que ser SQL2005).

Finalmente mi workflow tiene una forma como la siguiente:

Para terminar algunas acotaciones de cosas que me parecieron realmente muy buenas y otras no tanto.
Una de las buenas es la rapidez con la que se puede modelar un diagrama de estados, incluso esta bueno sentarse con el usuario al lado y mostrarle como quedaría la lógica de su proceso, pocas veces he tenido la oportunidad de hacer que el usuario me diga "en tiempo de diseño", no esto debería ser de la siguiente manera....
Otra muy buena es que Workflow Fondation provee un conjunto de clases que mediante Generics nos indican el estado actual y los próximos estados posibles de nuestras instancias y la búsqueda de toda esta info viene gratis con el servicio de persistencia. Pueden ver esto implementado en el método [WorkflowStates verEstados(Guid pguid)] de la clase
La no muy buena es la especificación de las excepciones, me parecen poco claras cuando ocurren, pero seguro que en algún momento la van a mejorar

Adjunto el código correspondiente al proyecto de workflow y una pequeña aplicación de prueba, espero que sirva

Ariel Serlin

Para bajar el codigo hace click aqui