Me encuentro en el aeropuerto de Seattle esperando mi vuelo rumbo a casita, después de una semana sumamente enriquecedora (debo decir, mucho más de lo que yo esperaba) asistiendo al MVP Summit 2008. Creo que fue un evento impresionante, que me sorprendió la manera en la que habló Steve Ballmer y que es extraordinario estar en medio de los equipos de producto de Microsoft (particularmente estuve con los equipos de VB y C#) y en este post me gustaría platicar un poco respecto a mis impresiones.
Desafortunadamente (o afortunadamente) hay un contrato NDA (Non Disclosure Agreement) firmado entre Microsoft y los MVPs que impide comentar detalles y los ejemplos concretos de lo que hemos visto. Sin embargo quisiera compartir algunas reflexiones en estos tiempos de cambio en los que vivimos.
Mi área de interés en esta parte de mi carrera profesional es la teoría de lenguajes de computación, me enoja un poco tener tanto trabajo y no poder dedicarme más a este apasionante tema, sin embargo en tiempecitos he estado investigando y aprendiendo cosas muy interesantes durante los últimos meses, es un tema que me apasiona, quizás como ningún otro en la informática y en este Summit tuve la oportunidad de asistir a pláticas exactamente de estos tópicos, así que con algo de tristeza renuncié a pláticas de Silverlight, de SQL, de SharePoint y hasta de LINQ, y enfoqué todo mi track de sesiones exclusivamente en el área de los lenguajes “puros”, lo cual fue la mejor decisión que pude haber tomado. Estas sesiones me hicieron reafirmar algunas creencias que tengo y modificar otras y las enumeraré a continuación
1) Cosas que siempre he dicho que reafirmé
a) Seguiremos en el camino de la computación “multiparadigma”:
Es bueno ser teórico para programar, me gusta mucho conocer gente que le guste adherirse a una escuela o patrón de diseño, yo soy el principal defensor de la teoría al programar, sin embargo hay que decir que ni VB ni C# son lenguajes puramente orientados a objetos, y mucho menos con la introducción de Visual Studio 2008, con la cual los lenguajes adquiririeron elementos funcionales. Microsoft seguirá por ese rumbo para efectos de aumentar las opciones y la productividad del programador, de cualquier tipo y de cualquier escuela. Los lenguajes evolucionan, deben hacerse más fáciles, mejores y con muchas opciones. Java alguna vez presumía de que era un lenguaje de programación “fácil” y en sus primeras versiones se jactaba de que en el lenguaje solamente se podían hacer las cosas de 2 o 3 maneras distintas cuando en otros lenguajes como C++ lo mismo se podía hacer de 20 formas diferentes. Pues a Java se le cayó esa premisa y conforme ha ido evolucionando (es impresionante que hasta hace algún tiempo java no tenia foreach :P) ha tenido que cambiar e introducir cosas como genéricos y muchas construcciones que le han dado flexibilidad al lenguaje. Lo mismo ha pasado con .NET, sigue en constante evolución y creo que esto es el camino que tendremos en el corto y mediano plazo.
Me saca de onda un poco que a estas alturas del partido haya MVPs en C# que sigan diciendo que var es malo o que se oponen a la evolución natural de los lenguajes, no debería de ser, los lenguajes entre más opciones nos den, se vuelven más flexibles, es función del arquitecto de software elegir un paradigma, patrón y arquitectura para generar mejor software.
b) Los lenguajes open source seguirán ahí:
Microsoft no tiene interés es “competir” frontalmente o posicionar a C# o a VB como una alternativa a lenguajes como Ruby, al contrario, la idea es integrar cada vez más lenguajes de programación heterogéneos que sean compatibles con el CLR y con el DLR (Dynamic Language Runtime). Microsoft está muy comprometido con la comunidad open source y la integración de nuevos lenguajes más específicos para determinadas tareas como F#, Ruby, Phyton etc. será (es) ya un hecho dentro de Microsoft.
c) Los lenguajes dinámicos (y el late binding) NO son malos, si se usan con precaución:
Lo tengo que aceptar: Soy FANÁTICO de los lenguajes que aceptan late binding (léase Visual Basic), siempre lo he sido y seguramente lo seré. Microsoft está haciendo grandes esfuerzos por encontrar una solución que balancee la seguridad del static typing y la flexibilidad del dinamismo y/o late binding. (Por cierto, la diferencia principal del dinamismo al Late Binding es muy sutil podemos decir que un lenguaje dinámico no es más que uno con latebinding con esteroides, y los esteroides son precisamente la creación de un tipo nuevo en compile time (antes de su ejecución), cosa que no sucede con late binding, donde se conoce el tipo hasta la ejecución del mismo y este se encuentra boxeado en un tipo general (que no es lo mismo que genérico) llamado object)
Seguramente un servidor (yo) y DevWorx estaremos haciendo algo al respecto. Allá afuera pasan muchas cosas y no nos vamos a quedar sin participar. El tema de los lenguajes dinámicos es extremadamente apasionante y lo considero como la orientación a objetos real, más humana, más antropomorfizada, es decir, ¿para qué hacer casts y tener bibliotecas de interfaces? Podemos, sin duda alguna generar una real orientación a objetos mediante un polimorfismo llevado al extremo y la programación dinámica es un pilar fundamental para lograrlo. Les recomiendo mucho leer esto: http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Meijer.pdf
2) Cosas que siempre he dicho y que tendré que rectificar
1) He dicho en varios posts que C# se está convirtiendo en un lenguaje funcional y VB en un lenguaje dinámico: Aunque C# 3.0 es más funcional que VB 9.0, en el futuro inmediato pareciera ser que ambos lenguajes seguirán teniendo un soporte similar a tecnologías dinámicas y funcionales respectivamente lo cual lejos de ser malo, es excelente, ambos lenguajes están adquiriendo las capacidades necesarias para seguir estando en la vanguardia y que se pueda programar en ellos cualquier software por complejo que parezca.
En fin, la semana del Summit se acabó y mis proyectos en me esperan apilados, tengo que programar teléfonos celulares, dar cursos de SharePoint (arg!), no es lo que más me gusta, pero ni modo la chamba es la chamba y hay que verla de la mejor manera posible. Espero pronto postear varios posts que tengo empezados pero no terminados.
Existen muchas razones por las cuales una aplicación podría tener la capacidad de dibujar en pantalla y contenido visual como rectángulos, elipses, triángulos, círculos etc. WPF incluye una gran cantidad de funcionalidad para tener este tipo de gráficos y realmente existe una mejora significativa al dibujar con esta tecnología respecto a tecnologías previas como GDI+.
Shapes
Las Shapes (formas) son primitivas que nos permiten dibujar automáticamente algunas formas básicas y muy usadas en la definición de gráficos. La ventaja de utilizar Shapes es que incluyen todo lo necesario para definir la presentación y aspecto visual en las figuras sin necesidad de componer árboles de objetos complejos.
Las Shapes definidas por WPF se encuentran en el siguiente listado
| Shape (Forma) | |
| Ellipse | Dibuja círculos y elipses de circunferencia fija si se le especifican los atributos Width y Height o variable de acuerdo a su objeto contenedor si no se le especifican dichos atributos. |
| Line | Dibuja una línea dados dos puntos. Es posible especificar la presentación de la línea utilizando los atributos Stroke, StokeThikness entre otros. |
| Rectangle | Dibuja rectángulos y cuadrados y tiene la capacidad de modificar la presentación de las esquinas y el trazado de las líneas del rectángulo |
| Polyline | Dibuja rectas continuas |
| Polygon | Dibuja rectas continuas y añade un segmento de recta adicional para cerrar la figura. |
| Path | Dibuja líneas, curvas y en general cualquier caso siguiendo un conjunto de instrucciones especificadas mediante XAML o una notación especial |
Ellipse:
El siguiente código muestra la manera de dibujar dos elipses. La primera elipse tiene especificados los atributos Width Y Height por lo que al momento de cambiar de tamaño la ventana el dibujo de la elipse permanecerá inamovible mientras que en la elipse llamada MiElipseFija ocurrirá un redimensionamiento toda vez que hereda el tamaño especificado por su objeto contenedor
XAML
<Ellipse Margin="68,47,82,86" Width="50" Height="50" Name="MiElipseMovible" StrokeThickness="5" Stroke="Red" /> <Ellipse Margin="68,47,82,86" Name="MiElipseFija" Stroke="Blue" StrokeThickness="5"></Ellipse>
El resultado es el siguiente:
Para definir que una elipse será rellenada con determinado color es posible utilizar el atributo Fill.
Line:
Las líneas son uno de los elementos visuales más utilizados en las aplicaciones. Para definir una línea es necesario indicar los puntos origen y destino a través de los cuales se dibujará el segmento de recta. Para definir estos puntos hacemos uso de los atributos X1, Y1 para definir el primer punto y X2, Y2 para definir el segundo punto. El ejemplo siguiente muestra cómo definir dos líneas.
XAML
<Line X1="0" Y1="0" X2="300" Y2="280"
Stroke="Blue" StrokeThickness="14" />
<Line X1="0" Y1="260" X2="280" Y2="0"
StrokeThickness="14">
<Line.Stroke>
<ImageBrush ImageSource="C:\Revista USERS\2D\fondo.jpg" />
</Line.Stroke>
</Line>
La primera línea define para el atributo Stroke un color fijo mientras que la segunda línea utilizada un elemento ImageBrush para definir el trazado de dicha línea utilizada como fondo una imagen especificada en un archivo el resultado del código anterior es el siguiente.
Polyline
Este objeto representa una colección de líneas. Las líneas son definidas a través de la propiedad Points donde se definen los puntos por los cuales pasará el conjunto de líneas. De la misma manera que sucede con el objeto Line, podemos establecer el formato del trazado de la línea mediante los atributos Stroke, StrokeThikness entre otros. Además es posible utilizar el atributo Fill para llenar el área por la que pasan las líneas.
El código a continuación genera un triángulo:
XAML
<Polyline Points="100,100 200,40 300,100 104,100" Stroke="Black"
StrokeThickness="10" Margin="0,50" StrokeLineJoin="Round" Fill="Red"/>
Resultado
Polygon
La funcionalidad entre Polyline y Polygon es prácticamente la misma. La única diferencia que existe entre ambos objetos es que Polygon automáticamente añade una línea entre el primero y el último punto y de esta manera se genera una figura cerrada. A continuación mostramos el mismo ejemplo anterior utilizando ahora para ver la diferencia entre uno y otro
XAML
<Polygon Points="100,100 200,40 300,100 170,100" Stroke="Black"
StrokeThickness="10" Fill="Red" Margin="0,50" StrokeLineJoin="Round" />
Path
Con la clase Path es posible dibujar prácticamente cualquier trazo. A diferencia de las figuras vistas anteriormente, con éste objeto es posible dibujar inclusive curvas y rectas figuras abiertas y figuras cerradas, para eso, hace uso de la propiedad Data que tiene una notación que permite definir los movimientos, las curvas y las líneas mediante una notación sintaxis que se detalla a continuación.
| Shape (Forma) | |
| M | Define el punto inicial de una figura |
| L | Define una recta a partir de la posición actual y hasta el punto especificado |
| V, H | Definen una línea vertical u horizontal respectivamente |
| C, Q, S, T | Definen curvas de Bezier (cúbicas, cuadráticas, cúbicas suaves y cuadráticas suaves respectivamente) |
| A | Dibuja un arco elíptico |
| Z | Cierra la figura actual |
El siguiente ejemplo muestra como utilizar el objeto Path
XAML
<Path Stroke="Black" Fill="Blue">
<Path.Data>
<PathGeometry Figures="M 10,100 C 10,300 300,-100 300,100 " />
</Path.Data>
</Path>
El código previo genera la siguiente salida:
Cabe señalar que cuando es necesario dibujar una figura compleja no es muy práctico editar a mano el XAML; es por eso que podemos hacer uso de herramientas especializadas en diseño gráfico como Expression Blend que automáticamente genera el código requerido para representar los trazos y dibujos creados en la herramienta misma.
A continuación un ejemplo de código generado automáticamente con Expression Blend utilizando su herramienta Pencil.
XAML
<Path Stretch="Fill" Stroke="#FF000000" HorizontalAlignment="Left" Margin="154.833,0,0,121.5" VerticalAlignment="Bottom" Width="3" Height="59" Data="M155.33333,264 C155.76028,283.21278 157.33333,302.47815 157.33333,322"/>
<Path Stretch="Fill" Stroke="#FF000000" HorizontalAlignment="Left" Margin="189.5,0,0,122.167" VerticalAlignment="Bottom" Width="1.667" Height="59" Data="M190,263.33333 C190,282.62739 190.66667,301.97267 190.66667,321.33333"/>
<Path Stretch="Fill" Stroke="#FF000000" HorizontalAlignment="Left" Margin="156.833,0,0,152.167" VerticalAlignment="Bottom" Width="36.334" Height="2.503" Data="M157.33333,291.33333 C168.83269,289.12798 180.58536,290 192.66667,290"/>
<Path Stretch="Fill" Stroke="#FF000000" HorizontalAlignment="Left" Margin="198.432,0,0,127.415" VerticalAlignment="Bottom" Width="29.565" Height="27.752" Data="M214.66667,290 C204.25621,291.76448 202.49111,287.14113 200,303.33333 198.87719,310.63157 195.22353,319.6057 213.33333,314.66667 222.48637,312.17038 240.35052,303.42693 212.66667,289.33333"/>
<Path Stretch="Fill" Stroke="#FF000000" HorizontalAlignment="Left" Margin="238.167,0,0,125.5" VerticalAlignment="Bottom" Width="1.666" Height="55.667" Data="M239.33333,263.33333 C239.33333,281.67256 238.66667,299.67663 238.66667,318"/>
<Path Stretch="Fill" Stroke="#FF000000" HorizontalAlignment="Left" Margin="246.122,0,0,127.5" VerticalAlignment="Bottom" Width="33.045" Height="34.448" Data="M276,291.33333 C265.47034,284.113 258.73579,272.80992 249.33333,298.66667 245.70658,308.64023 241.38342,318.87219 268,310 270.13969,303.58094 273.33333,299.49906 273.33333,292 268.11259,304.18173 262.25661,306.1878 278.66667,316"/>
Resultado:
Animaciones
WPF incluye clases que nos permiten generar animaciones de una manera muy sencilla. Dentro de WPF básicamente las animaciones se logran mediante la variación de una o varias propiedades a través del tiempo; éstas propiedades pueden ser el tamaño del objeto, su posición, el color, su opacidad etc. Cuando las propiedades cambian durante el tiempo se percibe el efecto de animación.
Para crear una animación primero debemos de definir el objeto al cual queremos animar. Durante los siguientes pasos definiremos un círculo que variará su tamaño constantemente.
1) Antes que nada definimos un círculo con el siguiente código
XAML
<Ellipse Name="MiBalon" Height="50" Width="50" Stroke="Black" StrokeThickness="5"> </Ellipse>
2) Posteriormente utilizaremos la propiedad Ellipse.Triggers que define el suceso o condición que dará inicio a la animación. Existen varios tipos de Triggers como el DataTrigger que especifica una condición que se debe de cumplir para realizar alguna acción. También tenemos el EventTrigger que será el objeto que utilizaremos en éste ejemplo y que se usa cuando queremos definir un conjunto de acciones en respuesta a un evento. Cuando utilizamos EventTrigger debemos definir el evento que debe de suceder para disparar la animación mediante el atributo RoutedEvent, en este caso, definiremos el evento Ellipse.Loaded es decir: En el momento de que se cargue la Ellipse se iniciará inmediatamente la animación
XAML
<Ellipse Name="MiBalon" Height="50" Width="50" Stroke="Black" StrokeThickness="5"> <Ellipse.Triggers>
<EventTrigger RoutedEvent="Ellipse.Loaded"> </EventTrigger> </Ellipse.Triggers> </Ellipse>
3) Después de definir el evento utilizaremos las clases StoryBoard y BeginStoryBoard que representan una línea de tiempo y su inicio.
<Ellipse Name="MiBalon" Height="50" Width="50" Stroke="Black" StrokeThickness="5">
<Ellipse.Triggers>
<EventTrigger RoutedEvent="Ellipse.Loaded">
<BeginStoryboard>
<Storyboard>
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</Ellipse.Triggers>
</Ellipse>
4) Para finalizar la creación de nuestra animación utilizaremos la clase DoubleAnimation que representa una animación que se aplica a aquellas propiedades que sean del tipo Double. De la misma manera existen diferentes tipos de animaciones como BooleanAnimation que anima propiedades del tipo Boolean, ColorAnimation que anima propiedades del tipo Color y así sucesivamente existen objetos de diferentes tipos para animar las propiedades que tienen el tipo de datos compatible con la animación. En nuestro ejemplo podemos apreciar que utilizaremos el atributo Duration que indica el tiempo en el que tiene que ser completada la animación así como los atributos From y To que representan el valor inicial y el valor final de las propiedades que serán animadas. También utilizamos el atributo RepeatBehavior que indica la cantidad de veces que será repetida la animación. El código del ejemplo completo se presenta a continuación.
XAML
<Ellipse Name="MiBalon" Height="50" Width="50" Stroke="Black" StrokeThickness="5">
<Ellipse.Triggers>
<EventTrigger RoutedEvent="Ellipse.Loaded">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation Duration="0:0:01" From="50" To="250" Storyboard.TargetProperty="Width" RepeatBehavior="Forever"/>
<DoubleAnimation Duration="0:0:01" From="50" To="250" Storyboard.TargetProperty="Height" RepeatBehavior="Forever"/>
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</Ellipse.Triggers>
</Ellipse>
El código anterior produce el siguiente resultado:
Además de que podemos utilizar los colores sólidos como el fondo de cualquier objeto que tenga la propiedad Background, también es posible utilizar gradientes. Estos gradientes se establecen a través de brochas (objetos que heredan del tipo Brush) y pueden ser Lineales (LinearGradientBrush) o Radiales (RadialGradientBrush).
En nuestro ejemplo añadiremos un gradiente al fondo del Grid y posteriormente lo animaremos a través de su propiedad Offset.
A continuación utilizaremos para nuestro ejemplo otro tipo de animación llamado ColorAnimation cuyo objetivo será cambiar de color el fondo (Fill) del círculo. El XAML requerido es el siguiente.
XAML
<Grid>
<Grid.Background>
<LinearGradientBrush>
<GradientStop Color="Blue" Offset=".0"></GradientStop>
<GradientStop Color="Lime" Offset=".99"></GradientStop>
</LinearGradientBrush>
</Grid.Background>
<Grid.Triggers>
<EventTrigger RoutedEvent="Grid.Loaded">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation Duration="0:0:02" From="0.0" To=".99" Storyboard.TargetProperty="(Grid.Background).(LinearGradientBrush.GradientStops)[0].(GradientStop.Offset)" RepeatBehavior="Forever" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</Grid.Triggers>
<Ellipse Name="MiBalon" Height="50" Width="50" StrokeThickness="5">
<Ellipse.Fill>
<SolidColorBrush Color="Transparent"></SolidColorBrush>
</Ellipse.Fill>
<Ellipse.Triggers>
<EventTrigger RoutedEvent="Ellipse.Loaded">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation Duration="0:0:02" From="50" To="200" Storyboard.TargetProperty="Width" RepeatBehavior="Forever"/>
<DoubleAnimation Duration="0:0:02" From="50" To="200" Storyboard.TargetProperty="Height" RepeatBehavior="Forever"/>
<ColorAnimation From="Red" To="Yellow" Duration="0:0:02" Storyboard.TargetProperty="(Ellipse.Fill).(SolidColorBrush.Color)" RepeatBehavior="Forever"></ColorAnimation>
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</Ellipse.Triggers>
</Ellipse>
</Grid>
Como podemos ver para poder animar el gradiente hacemos referencia a la ruta completa de la propiedad a la cual deseamos animar y nos referimos en específico a un GradientStop mediante su índice en la colección. El resultado que obtenemos es el siguiente:
Podemos notar que el color de la circunferencia ha cambiado de color rojo especificado hacia el color amarillo así como también se ha desplazado el gradiente hacia el color azul.
Eso es todo amigos cya next post!
Uno de los principales beneficios que ofrece el motor de ejecución de Windows Workflow Foundation es que posee la capacidad de proveer servicios que tienen como objetivo el simplificar las tareas comunes a los cuales se enfrenta un desarrollador de flujos de trabajo.
El primero de los servicios que cubriremos en nuestro estudio ese servicio denominado "Tracking Services" que puede ser utilizados para una gran cantidad de objetivos.
Podemos definir a Tracking Services como el servicio que proporciona automáticamente el rastreo y/o seguimiento de la ejecución de cualquier instancia de un flujo de trabajo. Esta característica es particularmente importante debido a que en los flujos de trabajo muchas veces nos interesa saber qué actividades fueron ejecutadas y en general el camino que se siguió el motor de ejecución para completar determinado flujo de trabajo.
El panorama en el cual a nosotros podemos hacer uso de esta característica es realmente amplio: Por ejemplo: Cuando utilizamos a WorkFlow Foundation como un proveedor de servicios de orquestación en un panorama de Enterprise Service Bus dentro de una arquitectura orientada servicios es sumamente importante conocer los servicios que fueron invocados desde la orquestación y los usuarios que utilizaron el sistema, en este escenario podemos utilizar los Tracking services para monitorear la actividad que se está generando el momento de ejecutar los flujos de trabajo involucrados en orquestación de los servicios, en otras palabras la utilización de estos servicios será efectivamente en los escenarios de auditoría de monitoreo de flujos de trabajo.
Para poder acceder a los servicios que ofrece Tracking services hacemos uso del espacio de nombres System.Workflow.Runtime.Tracking que contiene las clases que nos permitirán generar ya sea a nuestra propia solución de monitoreo y seguimiento de los flujos de trabajo o bien podemos utilizar soluciones que ya vienen listas para usarse como el SQL tracking service.
Antes de continuar los adentraremos un poco al arquitectura de Tracking Services.
Básicamente existen tres componentes principales dentro del arquitectura de los Tracking services y estos son:
1. Tracking Profiles (perfiles de seguimiento)
Los perfiles de seguimiento representan la manera con la cuál es posible identificar los orígenes y las fuentes de los eventos que deseamos capturar dentro del monitoreo del flujo de trabajo. Estos perfiles son indispensables al momento de generar nuestra propia solución de seguimiento. Existen tres tipos de eventos o sucesos a los cuales nos podemos suscribir para monitorearlos
a) Workflow Events (Eventos del flujo de trabajo):
Estos eventos surgen a nivel de instancia y son equivalentes a los eventos a los cuales nos suscribimos al momento de invocar un flujo de trabajo. Como ejemplo de estos flujos tenemos los eventos: Created, Terminated, Suspended etc.
b) Activity Events (eventos de las actividades)
Estos eventos son generados por las actividades que están siendo ejecutadas dentro de la instancia del flujo de trabajo.
c) User Events (Eventos de usuario):
Existen ocasiones en las cuales es necesario obtener información adicional sobre lo que está sucediendo en un determinado flujo de trabajo y que no necesariamente corresponde a la situación de la instancia del mismo flujo de trabajo o de alguna de sus actividades sino que es necesario generar un suceso personalizado para capturar determinado comportamiento del flujo de trabajo.
Para cada uno de los eventos descritos previamente existe una clase específica que guarda información sobre los mismos. Nos referimos a las clases WorkflowTrackingRecord ActivityTrackingRecord y UserTrackingRecord respectivamente
2. Tracking Runtime (Motor de ejecución de los servicios de seguimiento)
El motor de ejecución de los servicios de seguimiento de los flujos de trabajo se encarga de iniciarlo servicios de monitoreo que han sido declarados antes de la invocación de la instancia del flujo de trabajo que deseamos monitorear para hacer esto utiliza la información encontrada dentro de los perfiles de seguimiento.
3. Channels (Canales)
Los canales de monitoreo se usan para enviar los registros asociados a la instancia del flujo de trabajo cuando se encuentra un tracking point que es la clase genérica que recibe información de lo que está sucediendo dentro del flujo de trabajo.
Crearemos a continuación la implementación básica de un servicio de seguimiento personalizado.
1) Iniciaremos con una forma a la que llamaremos FormaInicio, en la cual colocaremos dos etiquetas, una de las cuales usaremos como el receptor de la información que generan las actividades del flujo de trabajo, y otra como los mensajes que genera el servicio de seguimiento (Tracking Service) que generaremos en este ejemplo.
2) Añadiremos a continuación a la solución un flujo de trabajo secuencial y agregaremos una actividad del tipo codeActivity
3) En el código de codeActivity1 simplemente escribiremos en la etiqueta un mensaje con el siguiente código
C#
1:
2:
3: private void codeActivity1_ExecuteCode(object sender, EventArgs e)
4:
5: { 6:
7: Programa.FormaInicio.lblMensaje.Text += "MENSAJE DESDE LA CODEACTIVITY1\n";
8:
9: }
10:
11: }
4) Posteriormente vamos a invocar la ejecución del flujo de trabajo en el manejador de evento del clic del botón de la forma y generaremos la suscripción al evento WorkFlowCompleted del flujo de trabajo con el código que aparece a continuación
C#
private void button1_Click(object sender, EventArgs e)
{
WorkflowRuntime MotorWF = new WorkflowRuntime();
Type Tipo = typeof(Workflow1);
WorkflowInstance InstanciaWF = MotorWF.CreateWorkflow(Tipo);
InstanciaWF.Start();
MotorWF.WorkflowCompleted +=
new EventHandler<WorkflowCompletedEventArgs>(MotorWF_WorkflowCompleted);
}
void MotorWF_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e)
{
MessageBox.Show("¡El flujo de trabajo fue finalizado!");
}
Al momento de ejecutar el código previamente mostrado en la etiqueta que recibe la información generada desde flujo de trabajo deberá aparecer el mensaje "MENSAJE DESDE LA CODEACTIVITY1"
5) Hemos llegado al momento en el cuál propiamente iniciaremos el desarrollo del servicio de tracking. Añadiremos una nueva clase a nuestro proyecto que denominaremos ServicioSeguimiento. Esta clase deberá heredar de la clase TrackingService que es la clase abstracta base que provee la interfase entre un servicio de seguimiento y el motor de ejecución de los servicios de seguimiento que mencionamos anteriormente en los conceptos de arquitectura de este capítulo.
Para generar exitosamente una clase que pueda ser consumida por el motor de seguimiento es necesario sobreescribir (hacer override) los siguientes miembros de la clase base TrackingService.
- GetProfile(Guid),
- GetProfile(Type, Version)
- TryGetProfile
- GetTrackingChannel
- TryReloadProfile.
El motor de ejecución de los servicios de seguimiento solicita un objeto del tipo TrackingChannel para cada una de las instancias que tienen un TrackingProfile asignado y usa este TrackingChannel para mandar los registros asociados a dar una instancia de flujo de trabajo. Dentro de la definición del TrackingProfile se debe de especificar cuáles serán los eventos que serán monitoreados y cuya información es recibida por un TrackingRecord que como vimos anteriormente, puede tener como clases concretas los tipos: ActivityTrackingRecord, UserTrackingRecord o WorkflowTrackingRecord.
Posteriormente la infraestructura de WF manda a llamar el método TryReloadProfile para verificar si se debe recargar el Profile. Este proceso permite a un cliente o a un servicio cambiar un profile de seguimiento cambiar dinámicamente.
C#
public class ServicioSeguimiento : TrackingService
{
protected override bool TryGetProfile(Type workflowType, out TrackingProfile profile)
{
//El objetivo de este método es que el motor de seguimiento
//dependiendo del tipo de WF el servicio puede utilizar diferentes tracking
//profiles. Aunque es necesario hacer el override en este ejemplo utilizaremos
//para que el ejemplo compile en esta muestra usaremos
//el mismo profile para cualquier WF
profile = ObtenerProfile();
return true;
}
protected override TrackingProfile GetProfile(Guid workflowInstanceId)
{
// No será implementado para este ejemplo
throw new NotImplementedException("No implementado");
}
protected override TrackingProfile GetProfile(Type workflowType, Version profileVersionId)
{
return ObtenerProfile();
}
protected override bool TryReloadProfile(Type workflowType, Guid workflowInstanceId, out TrackingProfile profile)
{
// En este caso siempre regresamos falso indicando que no hay nuevos profiles
profile = null;
return false;
}
protected override TrackingChannel GetTrackingChannel(TrackingParameters parametros)
{
//El motor de WF llama este método para obtener el canal para la instancia de monitoreo
return new CanaldeSeguimiento(parametros);