Reunión de la Comunidad .NET de la Ciudad de México del mes de noviembre

by Misael Monterroca 26. November 2009 17:28

El día de hoy será la reunión de comunidad de la cd de México, las platicas estaran muy interesantes y tambien se transmitiran por live meeting para quienes no puedan asistir fisicamente. Mas información de las platicas ->  http://www.superneurona.com/

 Para conectarse por livemeeting sigan las siguientes instrucciones:

 

Misael Monterroca has invited you to attend an online meeting using Live Meeting.
Join the meeting.
Audio Information
Computer Audio
To use computer audio, you need speakers and microphone, or a headset.
First Time Users:
To save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeting.
Troubleshooting
Unable to join the meeting? Follow these steps:  1.      Copy this address and paste it into your web browser:
https://www.livemeeting.com/cc/mvp_no_voip/join 2.      Copy and paste the required information:
Meeting ID: GN249Q
Entry Code: FJZ5!Dx[F
Location: https://www.livemeeting.com/cc/mvp_no_voip

 

Tags:

Comunidades

Mas recursos

by Misael Monterroca 13. February 2008 16:05

Como muy bien Rocky lo comento en su post de "como ser mejor desarrollador" una buena manera de lograrlo es viendo webcast,  MSDN Media Center es un recurso de medios en español en donde existe bastante contenido, WebCast, ScreenCast y PodCast

Y para muestra, falta un botón  mi buen amigo Haaron Gonzalez estará dando dos webcast sobre VSTO y Flujos de trabajo sobre Sharepoint, altamente mente recomendables

 

Salu2

Tags: ,

Comunidades | Learning

Invitaciones a clínica en línea

by Misael Monterroca 13. February 2008 04:20

Hemos tenido una excelente respuesta para la clínica que impartiremos en línea, al momento hemos recibido más de 150 solicitudes de invitación (muchas gracias por su interés),  dicha invitación será enviada el próximo lunes 18 de febrero ya que  estamos realizando los últimos ajustes a nuestro portal. Aún cuando el curso es en línea será necesario establecer un limite, crearemos varios grupos con la finalidad de poder brindarles una mejor atención.

 

La invitación enviada los llevara a una forma de registro que les pedirá la siguiente información básica:

    • Nombre Completo
    • País (hemos recibido invitaciones de varios países)
    • Edad
    • Comunidad (en el caso de que pertenezcas a alguna)
    • Url personal (blog)
    • Nivel de conocimientos en .Net
      • 100 - Básico
      • 200 - Medio
      • 300  - Avanzado
      • 400  - Experto

 

Está información es necesaria para poder crear grupos con perfiles afines.

 

Nuevamente, gracias por su interés.

Tags: , ,

Comunidades | DevWorx Learning Center | Learning

DevWorx Learning Center

by Misael Monterroca 12. February 2008 13:42

Como bien ya lo mencionó Rocky estamos estrenando nuestro DevWorx Learning Center en el cual estaremos generando contenido gratuito sobre la plataforma Microsoft.

 

Estamos comenzando a generar contenido para:

Los cursos se dividirán en varias secciones (el esqueleto ya está generado en cada uno de los sitios) pronto habilitaremos una sección de notificación de contenido vía RSS o e-mail para que puedan estar enterados cada vez que haya nuevo material. Esperamos que esta iniciativa sea de mucha utilidad para ustedes.

 

Si quieren que abordemos un tema en particular no duden en mandarnos un correo.

 

Saludos!

Tags: , , ,

Comunidades | .Net | DevWorx Learning Center | Learning

ScreenCast : WCF Exponiendo un servicio

by Misael Monterroca 6. February 2008 08:12

Este screencast es la continuación de WCF Introducción

 

En este screencast veremos como exponer un WCF Service Library, los temas que son tratados son:

  • EndPoint
  • Bindings
  • Host
  • Medatada

Url WMV para descarga (mejor definición)
Url Flash para ver Online

Tags: , , ,

Comunidades | .Net | ScreenCast | WCF

Windows Server 2008 RTM

by Misael Monterroca 4. February 2008 22:13

Una imagen dice mas que mil palabras...

 

WinServer 2008 RTM

Tags: ,

Comunidades | Windows Server 2008

ScreenCast : Intro AJAX ControlToolkit en VS2008

by Misael Monterroca 31. January 2008 08:21
Les dejo este screencast nivel 100 en donde veremos cómo Instalar, Configurar  y utilizar AJAX ControlToolkit dentro de Visual Studio .NET 2008
 
 
 
 
Nota: Tuve un problema ligero problema con el audio y en ocasiones se escuchan unos picos de ruido, por eso es mejor reproducirlo a un nivel de audio moderado.

Tags: , ,

Comunidades | ScreenCast | Asp.Net

Eventos del Runtime en Workflow Foundation

by Misael Monterroca 29. January 2008 22:25

 

En este articulo profundizaremos un poco más acerca del Runtime Engine, los diferentes eventos del Runtime, su sintaxis y su uso en Workflow Foundation.

Runtime Engine

La arquitectura de Windows Workflow Foundation consta de seis partes principales, el Runtime Engine es una de ellas. El Runtime Engine es una librería que ejecuta flujos de trabajo. El Runtime Engine también provee otros servicios, como mecanismos para comunicarse con software fuera del flujo de trabajo. Todos los flujos de trabajos dependen del Windows Workflow Foundation Runtime Engine. Este motor ejecuta cada flujo de trabajo y maneja su estado a lo largo de su tiempo de vida. El Windows Workflow Foundation Runtime es una librería; por lo tanto, debe ser ejecutado en algún proceso host. En vez de proveer un host requerido, Windows Workflow Foundation le permite al Runtime (y a cualquier flujo de trabajo que ejecute) ser alojado en cualquier proceso Windows, desde una simple aplicación de consola de Windows o una aplicación de formulario, hasta un servidor complejo diseñado teniendo en cuenta el ambiente de flujo de trabajo.

Windows Workflow Foundation cuenta con un conjunto de servicios que le permiten al Runtime ejecutarse dentro de ASP.NET, aunque los vendedores independientes de software y los usuarios finales son libres de crear sus propias aplicaciones contenedoras de flujo de trabajos para aplicaciones existentes.

Al ser Windows Workflow Foundation un Framework para flujos de trabajo en vez de un producto independiente, y al soportar este tipo de diversidades, se convierte en una meta explícita para sus creadores. A pesar de que cada host usa el mismo Runtime Engine, cada uno debe proveer un conjunto de servicios Runtime. Estos servicios brindan soporte para persistir el estado de un flujo de trabajo, rastrear su ejecución, usar transacciones, etc.

Un flujo de trabajo puede ser de larga duración, ya que podría ejecutarse durante horas, días o semanas, y el Runtime de Windows Workflow Foundation podría apagarse durante un flujo de trabajo, y persistentemente almacenaría su estado si hubiera estado inactivo por un período de tiempo.

La decisión de descargar el flujo de trabajo se puede lanzar porque éste se encuentra bloqueado esperando un evento externo; esta decisión es tomada típicamente por el Runtime. Para escribir estados del flujo de trabajo en el disco, el Runtime depende del servicio de persistencia proporcionado por su proceso host.

Los eventos del flujo de trabajo son procesados por el Runtime a través de los delegados de manejo de eventos.

WWF_Eventos_1

¿Por qué son importantes los Runtime Events?

Porque proporcionan un mecanismo para hacer un seguimiento del ciclo de vida del flujo de trabajo, por ejemplo cuando se crea un flujo de trabajo, cuando finaliza el mismo flujo, etc. Otro beneficio de manejar eventos del Runtime es que proporcionan un mecanismo para dar seguimiento a todas las instancias del flujo de trabajo. De esta forma podemos determinar cuántos fueron los flujos de trabajo fueron creados, abortados, terminados, etc. Entre los eventos que se ejecutan del lado del workflowRuntime a los que se puede suscribir son:

Del tipo:

  • EventHandler<WorkflowRuntimeEventArgs>
  • EventHandler<WorkflowEventArgs>

Del motor:

  • Started
  • Stopped

De las instancias:

  • WorkflowCreated/Started/Stopped
  • WorkflowAborted/Terminated/Completed
  • WorkflowIdled/Loaded/Persisted/Unloaded

Eventos de Flujo de Trabajo

Los eventos del flujo de trabajo son procesados por el Runtime a través de los delegados de manejo de eventos. Estos eventos son generados/levantados por el Runtime del flujo de trabajo y no por la instancia del flujo de trabajo. Asimismo, tampoco son modelados como parte de la definición de flujo de trabajo. Los eventos enviados por el Runtime del flujo de trabajo contiene el identificador de la instancia del flujo de trabajo que generó el evento. La Tabla 1 nos muestra los diferentes eventos de flujo de trabajo existentes:

Eventos de flujo de trabajo

Descripción

ServicesExceptionNotHandled

Generado cuando la instancia del flujo de trabajo no puede manejar la excepción interna

Started

Generado cuando se inicia el runtime

Stopped

Generado cuando se detiene el runtime

WorkflowAborted

Generado cuando se aborta la instancia del flujo de trabajo

WorkflowCompleted

Generado cuando se completa la instancia del flujo de trabajo

WorkflowCreated

Generado cuando se crea la instancia del flujo de trabajo

WorkflowIdled

Generado cuando la instancia del flujo de trabajo está inactiva(por ejemplo: Delay o EventSink)

WorkflowLoaded

Generado cuando la instancia del flujo de trabajo se carga en memoria (por ejemplo: re-hydrated)

WorkflowPersisted

Generado cuando la instancia del flujo de trabajo tiene persistencia

WorkflowResumed

Generado cuando la instancia del flujo de trabajo se reanuda después de ser suspendida

WorkflowStarted

Generado cuando se inicia la instancia del flujo de trabajo

WorkflowSuspended

Generado cuando el runtime suspende la instancia del flujo de trabajo

WorkflowTerminated

Generado cuando el runtime o internamente se termina la instancia del flujo de trabajo

WorkflowUnloaded

Generado cuando la instancia del flujo de trabajo se descarga de memoria (por ejemplo: Hydrated)

Tabla 1. Eventos de Flujo de Trabajo

 

En el siguiente ejemplo podemos ver la implementación del evento WorkflowCompleted del WorkFlowRuntime:

private void ApplicationInitMethod() 
 
{ 
 
WorkflowRuntime workflowRuntime = new WorkflowRuntime(); 
 
workflowRuntime.WorkflowCompleted += new EventHandler<WorkflowCompletedEventArgs>( 
 
workflowRuntime_WorkflowCompleted); 
 
} 
 
 
 
void workflowRuntime_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e) 
 
{ 
 
MessageBox.Show("Se completó el flujo de trabajo"); 
 
} 

 

En el siguiente ejemplo podemos ver la implementación del evento WorkflowCreated del WorkFlowRuntime:

private void ApplicationInitMethod() 
 
{ 
 
WorkflowRuntime workflowRuntime = new WorkflowRuntime(); 
 
workflowRuntime.WorkflowCreated += new EventHandler<WorkflowCompletedEventArgs>( 
 
workflowRuntime_WorkflowCreated); 
 
} 
 
 
 
void workflowRuntime_WorkflowCreated(object sender, WorkflowCompletedEventArgs e) 
 
{ 
 
MessageBox.Show("Se creó el flujo de trabajo"); 
 
} 

Tags: , ,

Comunidades | Articulos | WWF

Distintos tipos de Actividades Predefinidas

by Misael Monterroca 29. January 2008 00:47

Distintos tipos de Actividades Predefinidas

Workflow Foundation incluye una gran variedad de actividades predefinidas que podemos utilizar al crear nuestros propios flujos de trabajo. En este articulo veremos algunas de las actividades más destacables incluidas en esta plataforma.

Code

Clase: System.Workflow.Activities.CodeActivity

La actividad Code es una de las actividades más usadas en Workflow Foundation, ya que nos permite ejecutar cualquier tipo de código escrito dentro de un método. Su propiedad más importante es ExecuteCode la cual establece el nombre del método que queremos que se ejecute. En algunos capítulos hemos visto incluso el uso de esta actividad y su importancia que tiene al desarrollar flujos de trabajo. La siguiente figura muestra el resultado de un flujo de trabajo que utiliza esta actividad la cual ejecutará el método MetodoAEjecutar(), siendo el código de ese método el siguiente:

private void MetodoAEjecutar(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Hola Workflow Foundation"); 
 
} 
 

Sequence

Clase: System.Workflow.Activities.SecuenceActivity

La actividad Sequence nos permite ejecutar otras actividades en un orden específico, ya que asimismo esta actividad es un contenedor de otras actividades. Un buen ejemplo de una actividad Sequence son los flujos de trabajo de tipo Sequential Workflow, en donde podemos definir diversas actividades para que se ejecuten de manera ordenada o secuencial.

Los flujos de trabajo de tipo Sequential Workflow son instancias de la clase System.Workflow.Activities.SequentialWorkflowActivity, la cual a su vez hereda de la clase System.Workflow.Activities.SequenceActivity.

La siguiente figura muestra el diseñador de Workflow Foundation con una actividad Sequence con tres actividades de tipo Code. El código de esas actividades es el siguiente:

private void Metodo1(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Code 1"); 
 
} 
 
 
 
private void Metodo2(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Code 2"); 
 
} 
 
 
 
private void Metodo3(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Code 3"); 
 
} 
 

 

Por otro lado, al ejecutar el flujo de trabajo de la figura anterior obtenemos el resultado de la siguiente figura. Nótese como efectivamente el código es ejecutado en el orden establecido.

WWF_Actividades_b

Parallel

Clase: System.Workflow.Activities.ParallelActivity

La actividad Parallel como su nombre lo indica permite a un flujo de trabajo ejecutar paralelamente dos o más actividades. Parallel hace uso de la actividad Sequence para definir la serie de actividades que requieren ejecutarse en cada ramificación que definamos. La siguiente figura muestra un flujo de trabajo que implementa esta actividad con cuatro ramificaciones que incluyen cuatro actividades de tipo Code (codeActivity1, codeActivity2, codeActivity3, codeActivity4). El código de los métodos relacionados con esas actividades es el siguiente:

WWF_Actividades_2

 

 

El resultado de la ejecución de este flujo de trabajo será el siguiente:

WWF_Actividades_3 

Es importante aclarar que si bien la actividad Parallel define actividades que se ejecutarán de manera paralela no significa que se ejecutarán al mismo tiempo. Esto obedece a que Workflow Foundation asigna un solo hilo de ejecución para cada instancia de un flujo de trabajo. Esto es por diseño.

 

Delay

Clase: System.Workflow.Activities.DelayActivity

Esta actividad permite definir un retraso de tiempo. Su propiedad más importante es TimeoutDuration la cual especifica la duración en tiempo de ese retraso. La siguiente figura muestra el resultado de agregar esta actividad a la segunda rama del ejemplo de la actividad Parallel, con un retraso de 10 segundos. Podemos observar como efectivamente el retraso de tiempo provoca que el mensaje de codeActivity2 sea desplegado hasta el último lugar.

WWF_Actividades_4

 

While

Clase: System.Workflow.Activities.WhileActivity

La actividad While nos permite ejecutar una serie de actividades de manera cíclica, usando un método que funcione como expresión condicional. Su propiedad más importante es Condition con la cual precisamente definimos el tipo de condición a utilizar (Code Condition o Declarative Rule Condition). En el caso de seleccionar Code Condition necesitamos definir el nombre del método relacionado que fungirá como condicionante para que la actividad While continúe ejecutando iterativamente. El método relacionado con esta actividad debe tener la siguiente signatura:

void NombreDelMetodo(object, ConditionalEventArgs) 

ConditionalEventArgs tiene la propiedad Result de tipo bool. Esta propiedad le indica al runtime de Workflow Foundation si la condición es verdadera o falsa. En este caso para la actividad While si Result es true significa que debe continuar su ejecución de manera cíclica. Si Result es false el ciclo de While es finalizado y continúa la ejecución de la siguiente actividad definida después de While. Veamos un ejemplo de esta actividad.

La siguiente figura muestra el diseñador de Workflow Foundation con una actividad While, la cual contiene una actividad Code. El código relacionado con la actividad Code es el siguiente:

int contador = 1; 
 
 
 
private void Metodo1(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine(contador); 
 
contador++; 
 
} 
 

WWF_Actividades_5

Es necesario hacer notar que hemos definido una variable a nivel de clase llamada int contador. Esta variable nos servirá para desplegar su valor en la consola por cada ejecución iterativa de la actividad Code dentro de While. Para la actividad While hemos establecido que Condition es de tipo Code Condition, y hemos definido el método ChecaCondicion() el cual se encargará de evaluar si la condición ha sido alcanzada. El código de ChecaCondicion() es el siguiente:

private void ChecaCondicion(object sender, ConditionalEventArgs e) 
 
{ 
 
e.Result = contador<=20?true:false; 
 
} 

Si analizamos el código del método ChecaCondicion() podemos observar que estamos evaluando que la actividad While seguirá iterando siempre y cuando la variable llamada contador sea igual o menor que 20. Ya que la variable contador se inicializa con el valor de 1, tal y como esperamos, la consola desplegará los números del 1 al 20 ya que al llegar al 20 la condición evalúa a falsa y While alcanza su fin. Esto lo podemos corroborar en la siguiente figura:

WWF_Actividades_6

Throw

Clase: System.Workflow.ComponentModel.ThrowActivity

La actividad Throw nos permite lanzar excepciones dentro de un flujo de trabajo en Workflow Foundation. Esta actividad nos será de mucha utilidad cuando detectemos que el comportamiento o valores dentro de nuestro flujo de trabajo han alcanzado un estado inconsistente y por ello necesitemos parar la ejecución del flujo. Su propiedad más importante es FaultType, la cual indica qué tipo de excepción es la que arrojará esa actividad.

Para poder demostrar el uso de la actividad Throw, usaremos el mismo flujo de trabajo usado para la actividad While, sin embargo después (abajo) de la actividad While arrastraremos la actividad Throw de la caja de herramientas y la colocaremos en el diseñador. La siguiente figura muestra la caja de diálogo "Browse and Select a .NET Type", en donde podemos buscar y definir el tipo de excepción que la actividad Throw arrojará. Para este ejemplo usaremos la excepción de tipo System.ApplicationException la cual está implementada en mscorlib.

WWF_Actividades_7

La segunda propiedad importante para esta actividad es Fault, la cual nos permite definir una propiedad o campo para ligar la excepción. La siguiente figura muestra la caja de diálogo "Bind 'Fault' to an activity's property". En esta caja de diálogo podemos seleccionar un miembro existente o crear un nuevo miembro. En nuestro caso en este ejemplo crearemos un nuevo miembro ya que no hemos escrito código hasta el momento. Podemos seleccionar que la excepción se ligue a una variable o a una propiedad, en nuestro caso usaremos un campo llamado workflow_exception.

WWF_Actividades_8

Una vez definida y configurada la actividad Throw, veamos en la siguiente figura cuál es el resultado de la ejecución de este flujo de trabajo.

WWF_Actividades_9

Como podemos observar, después de desplegar los valores del contador la consola nuestra el mensaje de error relacionado con esa excepción. Ahora bien, podemos darnos cuenta que la ejecución del flujo de trabajo es suspendida gracias a que se está arrojando una excepción de tipo ApplicationException. En la siguiente parte veremos la actividad FaultHandler la cual nos permite capturar cualquier tipo de excepción y manejarla apropiadamente.

FaultHandler

Clase: System.Workflow.ComponentModel.FaultHandlerActivity

La actividad FaultHandler nos permite manejar apropiadamente las excepciones que sean arrojadas por las actividades Throw dentro de nuestros flujos de trabajo en Workflow Foundation. Para demostrar su uso continuaremos usando el proyecto de flujo de trabajo usado en la demostración de la actividad Throw. En un flujo de trabajo podemos definir uno o más actividades de tipo FaultHandler para definir las actividades que deben ser ejecutadas al estar capturando la excepción. Para realizar esto necesitamos cambiar la vista de nuestro diseñador para desplegar la lista de FaultHandlers. Esto lo logramos haciendo clic en la lista desplegable que se muestra al acercar el cursor a la fecha verde de inicio de nuestro flujo de trabajo, tal y como lo muestra la siguiente figura:

WWF_Actividades_10

Al cambiarnos de vista podemos observar que el diseñador de Workflow Foundation crea una actividad FaultHandlersActivity (nótese el nombre en plural), la cual es un contenedor de actividades de tipo FaultHandlerActivity. En esta actividad podemos arrastrar y colocar una o más actividades de tipo FaultHandler para así definir en cada una la serie de actividades que deseamos que se ejecuten al estar manejando la excepción. La actividad FaultHandler tiene la propiedad FaultType, la cual nos sirve para definir el tipo de excepción que esta actividad puede capturar. La siguiente figura muestra el diseñador con una actividad de tipo FaultHandler a la que se le ha definido la propiedad FaultType como System.ApplicationException (para efectivamente capturar la excepción que arroja Throw) y dentro de esta actividad se ha colocado una actividad de tipo Code con el siguiente código relacionado:

private void ErrorManejado(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Error manejado!"); 
 
} 

WWF_Actividades_11

Como podemos deducir, al ejecutar el flujo de trabajo la actividad FaultHandler captura la excepción arrojada por la actividad Throw y despliega efectivamente el mensaje "Error manejado!" en la consola, en vez de desplegar el mensaje por defecto de la excepción. Vale la pena mencionar que cada actividad FaultHandler podría tener una o más actividades relacionadas. El resultado de la ejecución de este flujo de trabajo es mostrado en la siguiente figura:

WWF_Actividades_12

Articulo Publicado en http://desarrollador.redusers.com/

Tags: , , ,

Comunidades | .Net | Articulos | WWF

Continuando...

by Misael Monterroca 4. December 2007 23:14

Bueno estos últimos meses los he pasado de gira tecnológica y esta semana me toco nuevamente en Queretaro (creo que cada vez me gusta mas este estado) haciendo una consultoría en Arquitectura de Software para un centro de investigación el cual afortunadamente ha resultado muy productivo para las personas que participan en el proyecto, una estrellita más para DevWorx.

 

Este post es continuación  de dos post de  Rocky, el primero es para darle la bienvenida a Armando  él tiene ya varios años de experiencia en el desarrollo de software y ha participado en proyectos muy importantes y es un gusto por supuesto tenerlo ahora como parte del equipo de DevWorx (la familia sigue creciendo)

 

el otro tiene que ver con el excelente post de Rodrigo  "Cómo ser un mejor desarrollador? aquí mi granito de arena:

 

  • Adopta una metologia de software
    • Explicación : Una persona metódica tiene más control en las cosas que realiza, sabe identificar en que paso se encuentra y por ende que paso sigue y esto es básico en el proceso de desarrollo de software Identificar, Medir, Documentar, Asegurar, Controlar, una metodología de desarrollo nos ayudara precisamente a cumplir con los puntos anteriores logrando cumplir ese objetivo.
    • Como lograrlo: Existen muchas metodologías, las más importantes podrían ser
  • Especializarse
    • Explicación: He visto muchos currículos del tipo,  domino Java, Php, Cobol, .Net, Asp, Ruby, Python, CSharp, Vb.Net, 4GL y la pregunta seria ¿En cuantos de ellos eres experto? Si bien es muy importante conocer otras tecnologías es MUCHO MAS importante especializarte en alguna de ellas ¿Motivo?  el conocimiento te lleva al éxito, DevWorx se especializa en tecnologías Microsoft (SharePoint, BizTalk, .Net, Commerce Server etc) y NO hacemos consultoría en alguna otra tecnología sin embargo sabemos como interactuar con ellas (RPC, WebServices, Corba etc) es muy diferente decir Conozco otras tecnologías a decir las domino.

 

Estas son las que se me ocurren de momento (Rodrigo ya escribió la mayoría) , posiblemente Maic escribirá cosas muy interesantes.

 

Saludos!

Tags: ,

Comunidades | General

MVP