HAL 9K

Continuando con los artículos sobre jBPM 6.x , en esta oportunidad les traigo un tema relacionado con el envió de emails y notificaciones por email. Estas actividades son muy frecuentes en los procesos de negocios, donde nos podemos encontrar con la necesidad de enviar un email como parte de un proceso, en una tarea específica. En este caso hacemos uso de la tarea de servicio email.

jBPM en su serie 6.x viene configurado para usar su propio esquema de Roles (Grupos) y Usuarios, pero un requerimiento muy frecuente es permitir que el jBPM busque u obtenga los Grupos y Usuarios desde nuestros medios personalizados, usualmente una Base de Datos. Escribo este artículo debido a que recientemente me encontraba trabajando en un par de proyectos de BPM con jBPM 6.3, y era requisito obtener los Usuarios y Grupos desde una fuente relacional, razón por la cual me toco apoyar al arquitecto de turno en cómo realizar esa tarea. Ya en un artículo anterior aprendimos a configurar el jBPM para que haga uso de nuestra propia Base de Datos favorita, Postgresql , para la persistencia de sus datos. Hoy vamos a seguir con ese ejemplo como base para aprovechar el ambiente que se definió en esa oportunidad. Así que sin mas preámbulos manos a las sobras…

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos...

Esta es una copia de la traducción del maravilloso artículo escrito en diciembre de 2004 por Ryan Tomayko en el que, en forma de una conversación con su esposa, explica qué es REST Desafortunadamente, hace poco tiempo el propio Ryan Tomayko decidió borrar el artículo porque no se sentía cómodo con una posible interpretación discriminatoria en los roles representados por los dos actores. No puedo estar de acuerdo con esto. Ese artículo expresa algo natural y nos muestra a un ser muy inteligente, una mujer, que hace preguntas que muestran entendimiento, razonamiento y curiosidad. Darle un giro machista es simplemente otra estupidez de estos openmind forzados, hipócritas  e igualadores de oficio. Me niego a aceptar que esta obra muera. La dejo aquí en honor a un trabajo bien hecho.

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

No necesitamos arquitectos. Claro que NO. Somos un equipo de desarrolladores competentes, todos muy capaces, genios comprobados y mal apreciados, somos la crema y nata de la tecnología, los ases de la codificación, los reyes de los lenguajes y las tecnologías. NO. Nosotros no necesitamos ningún dinosaurio con pretensiones de Anciano de la Matrix que venga a decirnos lo que Nosotros, amos y señores, ya sabemos. Los arquitectos son para equipos de retardado y cuasi idiotas. Y…. este, mis queridos lectores, es el modo de pensar de muchos equipos de desarrollo en la actualidad. Como dijo un querido amigo, llenos de concreciones y nada de abstracciones. Pero, adentrándonos en el tema, primero necesitamos resolver algo, ¿cual es el rol del arquitecto de software en un equipo de desarrollo? Muchos piensan que el arquitecto es el responsable de definir los componentes estructurales y comunicacionales de un proyecto de software. Y eso es verdad. Pero es baladí por ser ...