08.29.08
Posted in Definiciones at 8:20 am by Miguel
Siguiendo los capítulos de la saga de definiciones de términos que utilizamos comunmente en el gremio, hoy toca ver qué dice el Diccionario de la Lengua Española sobre la palabra “Abstracción”, esa palabra que tenemos todo el día en la boca, que muchas veces exigimos, y que en ocasiones, tantas veces es dificil aplicar.
abstracción.
(Del lat. abstractĭo, -ōnis).
1. f. Acción y efecto de abstraer o abstraerse.
abstraer.
(Del lat. abstrahĕre).
1. tr. Separar por medio de una operación intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o noción.
2. intr. Prescindir, hacer caso omiso. Abstraer DE examinar la naturaleza de las cosas. U. t. c. prnl.
3. prnl. Enajenarse de los objetos sensibles, no atender a ellos por entregarse a la consideración de lo que se tiene en el pensamiento.
Permalink
08.28.08
Posted in Buenas Prácticas at 11:33 am by Miguel
Tras la vuelta de vacaciones el volumen de trabajo no me deja dedicarle mucho tiempo al blog, pero a pesar de eso voy a intentar incorporar aunque sea pequeños artículos que le sigan dando la vida suficiente.
Para hoy un pequeño truco que actúa como buena práctica en proyectos de tipo web ASP.NET (y otras tecnologías web).
Es muy común que a la hora de viajar entre páginas de un mismo proyecto, se utilice la instrucción correspondiente de redirección poniendo directamente la URL de la página. Algo así como (código C#):
response.redirect(“~/mantenimiento/coche.aspx”);
Esto en principio no tiene mayor problema, pero, podemos añadirle una cierta y sutil mejora:
response.redirect(ConstantesURL.MANTENIMIENTO_COCHE);
Siendo “ConstantesURL” una clase que contiene las constantes que almacenan las URL de las diferentes páginas que componen la aplicación.
Esto puede parecer una tontería, pero nos protege de forma muy sencilla de los posibles cambios de rutas de páginas que pueden sucederse a lo largo de la vida del proyecto. Es muy común que ante una mala definición inicial, o de un crecimiento inesperado del volumen de páginas, se tenga que restructurar la organización de carpetas. Mediante este método, el coste es muy similar al de hacer un refactoring de un paquete, evitando así los típicos problemas de ir revisando uno a uno todos los enlaces y corrigiendo el viejo enlace por la nueva ubicación.
Saludos.
Miguel.
Permalink
08.22.08
Posted in Eventos at 7:11 pm by Miguel
Evento Microsoft en Barcelona, del 10 al 14 de Noviembre.
Más información,
http://www.microsoft.com/emea/teched2008/developer/default.aspx
Saludos.
Miguel.
Permalink
08.20.08
Posted in AgilePoint, BPM at 10:04 am by Miguel
Siguiendo con las actividades de AgilePoint, hoy vamos a ver la actividad WebService.
La finalidad, es clara, llamar en un momento dado a un servicio web para realizar una actualización en un sistema remoto, o para incorporar información que retorne el servicio web a nuestro proceso.
Tanto la actividad WebService, como la actividad E-Mail (de la que hablamos ayer) son actividades automáticas, que no necesitan actividad humana relacionada. Una vez se llega a ese punto del flujo se ejecutan y una vez ejecutadas el flujo continúa al siguiente paso de manera automática. Este es el mismo comportamiento que siguen los AgileParts, los cuales veremos en próximas entregas.
A continuación la paleta de propiedades de la Actividad WebService:
AgilePoint, Actividad WebService
Destacamos la obvia posibilidad de indicar tanto las credenciales, proxy, timeout… valores típicos para la llamada a un servicio web. Disponemos también de la posibilidad de realizar un envío de email automático al entrar en la actividad y al salir (para indicar algún tipo de aviso o saber si ha ocurrido algún error)…
Una nueva categoría que aparece en las propiedades y que es común a muchas de las actividades automáticas, es la categoría “Status and Error Message”. En las propiedades de dicha categoría, en el caso de que se produzca un error se va a indicar en ellas. Como supondréis, si luego tratáis en el flujo las propiedades $ErrorMessage y $Success, podréis manejar las condiciones y el resultado final del flujo.
Pero una de las piezas fundamentales que nos queda aquí para definir es cuál es la URL donde se encuentra alojado el servicio y cuál es en concreto el método que vamos a llamar. Para ello debemos hacer click en la propiedad “Configure”, y a continuación nos aparecerá la siguiente pantalla emergente:
AgilePoint, Actividad WebService, Definiendo la Conexión
En la zona superior disponemos de la capacidad de señalar una URL para poder cargar el listado de métodos y seleccionar uno en concreto. En la zona inferior tenemos una casilla donde indicamos la URL a la que llamará el proceso en el momento de ejecutar la llamada. En un principio parece no tener mucho sentido esto último ya que aparentemente estamos duplicando el trabajo, pero, la razón de hacerlo así, es que en la zona inferior vamos a poder definir una variable del tipo $URLServicioWeb, para que así podamos definir “desde fuera” en un momento dado cuál es la URL que aloja el servicio web en un entorno de trabajo en concreto. Este es un punto donde las “Propiedades Globales” entran en juego, las propiedades globales se definen desde el Enterprise Manager y aplican en cualquier plantilla disponible en el servidor (las veremos más adelante).
Por último me gustaría que os fijarais en la última captura de pantalla que he incorporado, donde se ve que hemos llamado a uno de los servicios web que provee el propio AgilePoint para poder manejar los procesos y plantillas. La pestaña de valores que retorna el servicio web es la que está marcada, y como véis todos los valores que retorna tienen el símbolo del dolar delante. Esto quiere decir, que a partir de la ejecución de la actividad, todos estos valores van a estar disponibles en el flujo, y que en cualquier momento los váis a poder utilizar para tomar decisiones o para almacenar información. Lo mismo ocurre en los parámetros de entrada del flujo (aunque no se vean en la pantalla) si los tenéis “definidos” y escritos antes, automáticamente se llamará al servicio web pasándole vuestros valores. Muy, muy interesante este uso.
Saludos.
Miguel.
Permalink
08.19.08
Posted in AgilePoint, BPM at 8:33 am by Miguel
El mundo de las propiedades en AgilePoint es parte de la potencia que ofrece el producto. Para dejar un ejemplo claro de su uso, sin sin irme demasiado por las ramas, voy a apoyarme en la Actividad E-Mail, disponible en el Stencil Generic BPM de Envision.
Como supondréis, el fin de la actividad e-mail es el de, en un momento dado, enviar un correo electrónico a una dirección de e-mail determinada. Propiedades como Audit Level y Wait All Incoming las hemos visto ya en anteriores artículos (aunque a Wait All Incoming vamos a dedicarle una entrada por separado para avanzar un poco más su funcionamiento). En cuanto a la propiedad “Deferred Time” va a permitirnos enviar un e-mail en “diferido”, es decir, el envío puede no realizarse justo al ejecutarse la actividad, si no en un momento dado que definamos, más adelante en el tiempo.
Actividad E-Mail
Otras de las propiedades de la Actividad E-Mail son, dentro de la categoría “Notification” la propiedad “Email”, al desplegarla y seleccionando la opción “Add Template”, nos aparece el formulario inferior.
Actividad E-Mail, definición de la plantilla del e-mail
Rellenando los valores del formulario podréis observar que hay algunos que están dispuestos con el símbolo del dolar como prefijo, los valores con el dólar delante son las llamadas propiedades de plantilla. Estos valores, son variables que pueden ir cambiado a medida que el flujo de trabajo va avanzando. La gran ventaja que dispone Envision, es que en cualquier punto vamos a poder añadir una variable de plantilla, como véis en el ejemplo, en las cláusulas from y to, así como en el cuerpo del mensaje la estamos utilizando. También podemos utilizar dichas variables en las propiedades de la Actividad Manual con TimeOut (que ya hemos visto), asignándole a la propiedad Participants el valor “$usuario”. Lo único que quedaría en este último caso, es en algún punto establecer el valor de la propiedad $usuario.
No vamos a necesitar ni definir ni inicializar los valores en ningún punto. No contamos con un listado de propiedades de la plantilla, a la hora de compilar la plantilla no va a hacer ninguna comprobación al respecto. Si a la hora de aplicar el valor de la propiedad, esta no tiene, retornará un valor nulo, y punto. Por ejemplo, si asignamos a una actividad de condición simple (las veremos más adelante) una variable y dicha variable no tiene valor, retornará siempre falso.
El establecimiento de los valores de una propiedad puede llevarse a cabo de diferentes maneras, por ejemplo, tras un cálculo realizado por una actividad automática (como la llamada a un servicio web por ejemplo, lo veremos más adelante), al realizarse la instancia de una plantilla (creando un proceso), o llamada a un proceso en concreto a través de un servicio web de AgilePoint y estableciendo los valores.
Saludos.
Miguel.
Permalink
08.17.08
Posted in AgilePoint, BPM, InfoPath at 8:32 pm by Miguel
Siguiendo con AgilePoint, hoy empezamos con un flujo sencillo definido a través de la herramienta Envision (visio + plugin de ascentn), en donde podemos empezar a ver las primeras actividades (shapes) existentes en la paletas (stencils) de Envision.
AgilePoint + Envision
En primer lugar, un resumen a alto nivel de la herramienta. Para los que estéis acostumbrados a trabajar con Visio os va a sonar prácticamente todo, menos algunos iconos de la barra de herramientas que ubicados en la fila inferior derecha, que son propios de AgilePoint (los veremos en su momento). Otro de los temas que os pueden llamar la atención, es la ventana de propiedades de la zona derecha, más que de Visio, parece sacada de un entorno de desarrollo como Visual Studio. A la izquierda, las paletas de Visio (Stencils), que contienen figuras (las actividades de AgilePoint), que tampoco os sonarán, pero que iremos viendo poco a poco. En el centro, el flujo de trabajo que se ha diseñado (Plantillas/Templates en AgilePoint).
Empezando por la plantilla (vamos a empezar ya a utilizar vocabulario AgilePoint), un flujo sencillo donde participan diferentes actividades de diversa índole.
- Actividad Start: Marca el inicio del flujo a seguir. Sólo puede haber uno por plantilla.
- Actividad Stop: Marca el fin del flujo a seguir. Sólo puede haber uno por plantilla.
- Actividad Subrutina: Corresponde al texto “Notificación”. Una actividad de subrutina representa la llamada a otra plantilla. Una curiosidad al respecto de AgilePoint es que una de las propiedades de la actividad de subrutina define que puede llamarse de forma síncrona o asíncrona, es decir, que cuando se entre en la subrutina se va a esperar en el flujo padre a que termine su hijo, o que se va a lanzar la subrutina hija y el flujo padre va a continuar también al mismo tiempo, respectivamente. Veremos esta actividad más afondo en próximos artículos.
- Actividad Servicio Web: Realiza una llamada a un servicio web determinado, veremos esta actividad más afondo en próximos artículos.
- Actividad Envío de E-Mail: Envía un email a un conjunto de recipientes determinados. Veremos esta actividad más afondo en próximos artículos.
- Actividad Condición Única: Evalúa condiciones de un estado, tipo verdadero y falso. Veremos las condiciones también en próximos artículos.
Actividad Manual y Actividad Manual con TimeOut
La actividad manual es una de las actividades básicas que a priori se van a utilizar más en un desarrollo. Representa una actividad que va a necesitar una intervención humana para ser llevada a cabo. ¿Qué tipo de intervención? Pues ninguna en concreto, representa cualquier tipo de intervención que se quiera realizar. Cuando empecemos a describir las propiedades una a una, veremos donde marcamos cuál es en concreto el trabajo a realizar.
La Actividad Manual con TimeOut funciona como una Actividad Manual, pero incorpora una nueva salida relacionada con un temporizador. En el caso de que la tarea se procese dentro del tiempo estimado, saldremos por un lado, si el tiempo se cumple saldremos por el otro (la salida de la línea roja en la plantilla del ejemplo). La ventaja de esta actividad es que podemos relacionar un comportamiento u otro dependiendo de este temporizador.
A continuación, tenéis la paleta de propiedades asociada a la Actividad Manual con TimeOut. Vamos a ir exáminando alguna de ellas.
Empezando por arriba, tenemos las propiedades englobas en “Time Span”. Aquí es donde podemos definir cuál es el espacio emporal asociado al temporizador que activa la salida roja. Definimos la unidad de tiempo y el valor de dicha unidad. Algo a resaltar también es la propiedad “Business Time”. Si la dejamos en “false” se atenderá a días naturales, si la dejamos a “true” seguirá el calendario laboral que se haya definido en el panel de administración base de AgilePoint (lo veremos en próximas entregas).
La propiedad “Work To Perform” es la propiedad principal de este tipo de actividad, ya que es la que define realmente qué trabajo se debe realizar. “Work To Perform” es el enlace entre el motor de flujo y la capa de presentación, a través del valor que indiquemos aquí se podrá establecer con la aplicación de presentación de turno que utilicemos, el aspecto visual a mostar. Por poner un ejemplo, si hubiéramos creado la plantilla de Agilepoint indicando que usará soporte Infopath (veremos como en otros posts), en el “Work To Perform” nos hubiera dejado elegir entre una de las vistas disponibles en el archivo de InfoPath asociado. En el caso de no trabajar con InfoPath para la capa de presentación si no con una aplicación ASP.NET, el “Work To Perform” podría asociarse al nombre de la página “aspx” donde se pediría al usuario la información asociada a la actividad. Un ejemplo de esto último, si tenemos una actividad manual que tiene un “Work To Perform” llamado “Firmar”, en nuestra capa de presentación web necesitaríamos un archivo en la raíz de la aplicación llamado “Firmar.aspx, Firmar.jsp, Firmar.html…”. En dicha página se encontrarían representadas las reglas de negocio asociadas a la actividad definida en la plantilla.
En la categoría “Notificación”, se representan los diferentes estados en los cuales podríamos enviar un e-mail de forma automática: al crearse la tarea asociada a la activida, al cerrarse, al reasignarse…
Categoría “Participantes”, muy interesante también. La propiedad “Participants” define a qué usuarios se van a asignar las tareas surgidas de la actividad. Se puede definir de varias maneras, mediante una variable (el uso de variables más adelante lo veremos también), o seleccionando directamente un usuario, grupo o rol definidos en el propio AgilePoint (otro tema más a ver en capítulos posteriores). Junto a la propiedad “Participants” tenemos “Max. Participants”, que define cuántos usuarios como mucho tendrán acceso a la actividad. Por defecto es uno, por lo que al alcanzarse esta actividad en el flujo se generaría una tarea para el usuario en concreto marcado como participante, o como máximo a un usuario del grupo o rol asignado como participante. En el caso de asignar como participante a un grupo de 5 usuarios y poner la variable “Max. Participants” a 3, se generarían 3 tareas como máximo asociadas a la actividad, con el mismo “Work To Perform” accesible a los tres.
En la categoría “Avanzadas”, se agrupan las siguientes propiedades:
- Audit Level: Indica el nivel de auditoría, dependiendo de si seleccionamos “High” o “Low” almacenarán más o menos información en las tablas internas de históricos de uso con información asociada al proceso (instancia de la plantilla)
- Auto Complete: Si es “true” la actividad se completará de forma automática una vez lleguemos a ella (se suele utilizar en tareas que se encuentran en el primer lugar de ejecución en la plantilla)
- Reuse Participant: En el caso de que tengamos un bucle, y volvamos a pasar por la misma actividad más de una vez, en el caso de que la actividad tenga asociado un grupo, la tarea creada se asignará al mismo usuario del grupo al que se le asignó inicialmente.
- Wait All Incoming: En el caso de que tengamos más de una entrada sobre la misma actividad, indica si se debe esperar a que lleguen todas para continuar o no. Esta propiedad la veremos más a fondo próximamente.
- Wait Work Performed: Define si la tarea necesita implícitamente validar cierta información de negocio o de condiciones del flujo. Por ejemplo, el cálculo de una factura puede necesitar validar información de negocio, en cambio, indicar que se ha recibido una documentación no. Veremos más adelante un ejemplo bastante claro de esto, cuando hablemos de “Bandejas de Tareas”.
Próximamente más artículos relacionados con AgilePoint.
Saludos.
Miguel.
Permalink
08.16.08
Posted in Gestión de Recursos, Noticias Actualidad at 7:43 pm by Miguel
Queda mal decirlo, pero estos días estoy de vacaciones en mi tierra, Mallorca. Acabo de volver de la playa y al llegar he consultado la página de un diario de deportes on-line para enterarme de las últimas noticias de las olimpiadas.
En portada, Usain Bolt, tras lograr el oro en los 100 metros lisos y record del mundo de velocidad en dicha categoría. La verdad, es que nunca había oido hablar de esta persona (no es el atletismo algo que siga), así que he puesto su nombre en google para empaparme un poco, y, el primer link que ha aparecido ha sido el de la wikipedia. Al entrar, me ha sorprendido algo muchísimo, alguien ya había actualizado su descripción y había añadido ya el nuevo récord. Es muy gracioso, porque aunque se haya producido en el mismo día de hoy, ya aparece escrito en pasado.
Usain Bolt y Wikipedia
“Bolt corrió los 100 metros en 9.69 (viento 0) en los Juegos Olímpicos de Pekín el 16 de agosto de 2008, batiendo un nuevo récord del mundo. Cabe señalar que Bolt comenzó a detenerse metros antes de llegar a la meta, en una muestra de clara superioridad, por lo que es de suponer que podría haber realizado un tiempo aun inferior.”
La verdad es que esta velocidad, la técnica, te hace replantear muchísimas cosas en términos de tiempos y eficiencias en el trabajo colaborativo y desinteresado, como es wikipedia.
Saludos.
Miguel.
Permalink
08.12.08
Posted in Gestión de Recursos at 11:19 am by Miguel
Os dejo un diagrama de ubicación de un equipo de desarrollo que aparentemente está trabajando utilizando Extreme Programming.
Como podréis apreciar, a extremos de la mesa trabajan cuatro personas, utilizando programación a pares. En una de las esquinas, está ubicada la persona que conoce el negocio asociado a la aplicación que se está desarrollando. Muy cerquita sentado del conocedor del negocio, el lider del equipo de desarrollo. Dos pizarras, una a cada lado.
Saludos.
Miguel.
Permalink
08.07.08
Posted in AgilePoint, BPM at 10:53 pm by Miguel
A la hora de trabajar con motores de flujo la forma natural de trabajar suele seguir los siguientes pasos:
1) Los flujos se definen, modelando el area de negocio a controlar, y se publican en el motor flujo.
2) Una vez publicados los flujos, se instancian, lo que eran definiciones iniciales pasan a tener ya vida propia, y las primeras tareas caen en las bandejas de los usuarios.
3) Las mejoras en los procesos de negocio llevan a que se produzcan mejoras en los flujos ya modelados y que se generen nuevas versiones.
4) La nueva versión del proceso de negocio se sube al servidor y pasa a ser también instanciada. Las instancias anteriores siguen en marcha siguiendo el patrón anterior, las nuevas se harán a través de la nueva definición.
¿Pero qué pasa si queremos modificar la versión de un flujo que ya está intanciado y actualizarlo a la última versión? AgilePoint, provee una opción desde el Enterprise Manager para que se puedan migrar los Procesos (en AgilePoint definición de flujo = Plantilla, instancia de plantilla = Proceso) a una versión determinada (tanto anterior como posterior).
Eso sí, cuidadín con los usos. No es lo mismo cambiar de versión un flujo instanciado para modificar el usuario que era responsable de una actividad determinada, o para añadir una opción nueva a una condición, que para modificar el 50% de la forma del flujo. Como siempre, todas las herramientas que son para hacer Merges, hay que tratarlas con sumo cuidado.
De todas maneras, la funcionalidad queda aquí. Versiones de plantillas que se pasan a producción y que en un momento dado pasan a estar instanciadas, podría llegar a conseguirse solucionar problemas de definición cambiando la versión de dichas instancias.
Saludos.
Miguel.
Permalink
08.05.08
Posted in Team Foundation Server at 8:49 pm by Miguel
Recientemente he tenido la primera oportunidad de empezar a trabajar con Team Foundation Server, provisto por la versión 2008 de Visual Studio. Había oido hablar en su momento, incluso había acudido a una presentación de Microsoft de la versión 2005 de Visual Studio donde ya incluían mucha de la funcionalidad de la que se puede disfrutar en la versión 2008.
Hay muchos temas de los que empezar a hablar, y por eso he abierto un tag únicamente con este pretexto. En principio voy a intentar definir funcionalidad que provee Team Foundation Server, intentando comparar sobre todo con Visual SourceSafe 2005, para ayudar así a la gente que haya tenido experiencia con este otro gestor de código.
La primera comparación, se lleva la palma, la gestión del código fuente es sólo una de las funcionalidades que provee Team Foundation Server, mientras que para Visual Sourcesafe era su único cometido. Team Foundation Server intenta integrar toda la gestión de las tareas relacionadas a un proyecto, y no únicamente la gestión de su código fuente.
Teniendo como premisa esto último, me temo que nos vamos a limitar a describir nuevas funcionalidades que en Sourcesafe 2005 no estaban presentes y que aparecen en Team Foundation Server.
Para abrir boca, y al hilo del título del post, un pequeño detalle que diferencia ambas aplicaciones en lo que tiene que ver con la gestión del código fuente. Así como en SourceSafe 2005 al indicar el borrado de un fichero, tras la confirmación pertinente, el borrado provocaba un borrado directamente en el gestor de código, en Team Foundation Server el borrado es un tipo determinado de Check-Out, por lo que al borrar desaparecerá el fichero del proyecto, pero no se borrará del repositorio de código fuente hasta que hagamos check-in del cambio.
El cambio es sutil, pero creo que es un cambio de filosofía que deja ver la evolución que nos espera.
En proximos posts, vamos descubriendo más mejoras.
Saludos.
Miguel.
Permalink
« Previous entries Next Page » Next Page »
