jBPM empezando con las propuestas?

Por un lado voy a empezar a proponer un simple proceso que podria llevarnos a establecer ese acercamiento y un poco las ideas que he plasmado en post anteriores (Post mas filosóficos: Post 1 , Post 2), por otro lado voy a empezar a compartir por este medio ejemplos de modelado típicos como para ir viendo como se comporta el motor y como podemos modelar algunas cosas que surgen en implementaciones reales. (Ver posts mas practicos: Post 1, Post 2)

Luego de esta un poco confusa introducción del post voy a ir directamente al grano con este proceso que he denominado MPI (Mejora de Procesos Interactiva) con el fin de acercar jBPM y todo el Stack SOA que propone JBoss a los clientes finales (en siguientes post futuros tratare de aboradar una forma sistematizada de llegar a la comunidad de desarrolladores locales, tema que creo fundamental para la aceptación del producto)

A continuación vemos a gran escala como se veria el proceso que propongo ya modelado con GPD de jBPM.

MPI:

Como podemos ver en el modelo la primer tarea que progongo es el acercamiento a la gerencia de nuestro cliente (o al contacto que tengamos dentro de la empresa) con el fin de ofrecer educación (lease charlas descriptivas sobre los productos del Stack SOA y todas las ventajas que ofrecen a nivel empresarial estas herramientas y frameworks de programación).

Acto seguido deberiamos buscar un proceso representativo en el cual podamos enfocarnos con el fin de demostrar las ventajas que presentaria formalizar dicho proceso y luego mejorarlo. Una vez que nos hemos desidido por un proceso en particular la idea seria obtener la mayor cantidad de información sobre el posible con el fin de poder organizar reuniones de trabajo InSite con las personas que realmente llevan el proceso acabo en la realidad. (LOB = Line of Business). Estas reuniones tiene como fin que las mismas personas vean su proceso en el estado actual y mediante brainstorming y con el conocimiento de los consultores sobre la herramienta mejoren el proceso elegido, optimizando tiempos e incrementando costos.

Una vez realizada estas mejoras sobre el proceso elegido es fundamental comunicarle a la gerencia los resultados de estas reuniones, ya que ellos podran ver como se encuentra el proceso actual y veran como optimizarian costos con las mejoras futuras que sus propios expertos (mas la ayuda de los consultores jBPM) han aconsejado.

Espero que se haya entendido el punto de proponer un proceso con el fin de acercar y realizar implementaciones con jBPM. Espero sus comentarios y en los siguientes post vamos a ver en detalle que sub tareas lleva cada tarea de este proceso planteado. Espero feedback a ver si el proceso se puede ir refinando con el fin de que en la practica pueda ser utilizado.

jBPM noticias y realizaciones (Personales)

jBPM Org

Un orgullo para mi ser parte de las noticias de jBPM a nivel mundial. Hoy termino la capacitación de jBPM en las oficinas de Red Hat en Puerto Madero (Buenos Aires / Argentina)  y por suerte el curso fue todo un éxito.

También esta bueno saber que los entrenamientos/cursos que se dictan en la Argentina están al mismo nivel que los países del primer mundo y que hay gente interesada en tomar estos cursos.

Espero poder empezar a postear mas sobre estas experiencias, ya que dar la capacitación de jBPM me ensenio bastantes cosas y me gustaría compartirlas. Espero tener novedades y feedback pronto para poder mejorar la calidad del curso en general (por lo menos la parte que me toca a mi).

Saludos!

Estrategias de implementaciones de jBPM? (Algunas ideas)

Si logramos idear algunas mejoras sobre jBPM (muy orientadas al objetivo de acercar el producto a los clientes) facilmente podriamos crear un proceso que ayude a la preventa de implementaciones de BPM con el fin de demostrar los beneficios concretos de las mismas (Optimizacion extrema de procesos e Incremento de las ganancias).

Estas mejoras/extensiones/optimizaciones/herramientas no necesariamente tienen que estar pensadas para usuarios finales (como analistas de negocios, o clientes en general) ya que esto ocacionaria gastos altos en desarrollo, tiempo de madurez y demasiado QA. Mi idea principal es que inicialmente sean herramientas y extesiones sean pensadas y dirigidas para consultores que conozcan jBPM y esten involucrados en el proceso de preventa de implementaciones de BPM y SOA.

Sumado a estas herramientas debemos sumar un proceso que nos dicte los pasos a seguir para demostrarles a nuestros clientes de manera facil y no muy costosa para nuestra empresa como impactaria una implementacion de BPM sobre un proceso que este actualmente siendo usado en la empresa del mismo.

Sin meditar mucho sobre el tema se me vienen a la mente una serie de herramientas y extensiones puntuales para alcanzar los objetivos antes mensionados de una manera relativamente poco costosa:

• Crear una extension del lenguaje que nos permita agregar parametros para poder medir distintos parametros de la ejecucion de nuestros procesos. Dos parametros faciles de agregar y muy utiles son costos y tiempos asociados a las tareas que realizan las personas dentro del proceso. Estas tareas son bastantes sencillas por las caracteriticas que propone jBPM de extensibilidad de lenguaje y motor de ejecución.
• Scripts de simulación de ejecuciones procesos (si bien ya se esta gestando un proyecto en los repositorios de JBoss sobre este tema) podrian gestionarse scripts inicialmente para realizar estas tareas y obtener como resultado de los mismos reportes que nos indiquen los comportamientos de distintas instancias de nuestros procesos. Por ahi estos scripts pueden llevar un poco mas de tiempo en cuanto analisis y disenio de los mismos, pero las ventajas que agregan al producto son grandes.
• Scripts de importación de procesos ya definidos en otros medios. Como podria ser Visio o una simple planilla de excel. Con esto ganariamos tiempo cuando los procesos ya se encuentran formalizado dentro de las empresas.

Son 3 simples ideas que acompaniadas por un proceso bien analizado de preventa podrian llevar a atrapar clientes para futuras implementaciones de BPM y a su vez dar a conocer el producto entre la comunidad de desarrolladores y los clientes.

Sientanse a gusto de opinar y agregar ideas.. Espero sus comentarios y feedback sobre lo propuesto..

Como encaja jBPM en el mercado? (Introducción)

Que tema complicado para escribir, ya que conozco poco de estrategias de marketing y mucho menos sobre la política por parte de JBoss para vender servicios sobre el producto jBPM.

La idea de este post es comentar algunas ideas que se me han venido a la cabeza al darme cuenta de que la competencia directa de JBoss y jBPM , tiene algunas estrategias de entrada al mercado que actualmente no he visto por parte de Red Hat/JBoss.

El planteo general es tratar de encontrar una manera real aca en la Argentina (por nombrar un pais donde  la situación del mercado es bastante especial) de poder acercar jBPM a los clientes finales o por lo menos que las empresas en el mercado empiecen a conocer el producto.

Para todo esto creo que hay dos cosas que hay que tener en claro:

1. Limitaciones del producto
2. Estrategias de venta

Limitaciones del Producto:

jBPM (www.jbpm.org) es un producto que nos permite tecnicamente resolver un gran rango de situaciones que involucren cualquier tipo de proceso que pueda ser representado por un grafo dirigido. Esto es, representar un proceso de negocio empresarial, orquestación de servicios, workflows de documentos, o cualquier caso donde tengamos que representar un proceso a cualquier escala en cualquier rubro de la industria.

A nivel técnico el producto ya tiene una madurez bastante importante y estan bien delimitadas las funcionalidades que se pueden obtener del mismo. Y creo que ahi es donde empiezan algunos de los problemas y los puntos que debemos analizar.

Las funcionalidades y alcances que propone jBPM están perfectas a nivel técnico ya que los problemas que nos permite solucionar presentan grandes ventajas con los métodos normales de programación se utilizan actualmente en el mercado.

El problema principal viene dado a otro nivel, y es un nivel mucho menos técnico y de apreciación mas “marketinera”, a lo que me refiero exactamente es que jBPM al ser un producto Open Source, guiado por la comunidad, no esta pensado para satisfacer la parte mas visible para un usuario final o un cliente que pueda llegar a verse interesado. El planteo de JBoss y la comunidad en general es mas que nada proveer a los desarrolladores una biblioteca de clases que nos permita programar cumpliendo la disciplina de BPM y dándonos un motor de ejecución bastante maduro (se encuentra en la versión 3.2.2 actualmente y la versión 4.0 ya tiene fecha aproximada de salida) que nos permite ejecutar nuestros procesos en entornos de producción.

Y entonces porque lo nombre como problema? porque en realidad esta visión, en gran parte dada por la comunidad, deja al producto afuera de toda apreciación comercial, ya que lo visible para los clientes es bastante técnico y carece de herramientas de facil uso por personas que no se encuentran altamente capacitadas para utilizar herramientas de desarrollo.

Para citar algunos ejemplos de esto, basta con decir que cuando queremos empezar a usar jBPM de la pagina oficial bajamos un jar (archivo de bibliotecas Java) y que el único diseniador gráfico de procesos es un plug in para una herramienta de desarrollo.

Cómo solucionamos esto? es la pregunta que surge a simple vista. Y la respuesta no es para nada alegre, ya que la solución seria dedicar horas de desarrollo (de la comunidad, o de los mismos empleados de JBoss) de estas herramientas que cumplan con la funcionalidad de simplificar la interacción de los usuarios finales (analistas de negocio en gran parte) con la herramienta. Tema que es complicado ya que por lo general en este tipo de proyectos son las partes que mas cuestan, ya que la mayoría de los desarrolladores que están al nivel para desarrollar herramientas complejas no están entrenados para el desarrollo de aplicaciones orientadas a usuarios finales y menos aun se cuenta con gente especializada en estos temas.

Cabe también destacar que jPDL, el lenguaje de descripción de procesos que utiliza por “defecto” el motor de jBPM (me refiero a jPDL – JBoss/Java Process Definition Language), si bien es extensible, carece de extensiones básicas para el momento donde necesitamos representar procesos de negocios donde por lo general necesitamos poder representar tiempos asociados a cada tarea dentro del proceso y costos asociados al mismo(O asociado a los recursos que realizan ciertas tareas) . Estos dos detalles (falta de tiempos y costos) producen que nos veamos obligados a extender el lenguaje y tener que programar una extensión para administrar estos cálculos.

Estrategias de venta:

Parte oscura si las hay…, al parecer no existe una estrategia específicamente dedicada a implementaciones de BPM por parte de JBoss / Red Hat, ya que las estrategias o productos que actualmente ofrece JBoss son distintas plataformas que incluyen a BPM como es la SOA Platform que además de BPM incluye productos como JBoss Rules (Drools), JBoss ESB, y los clásicos (JBoss AS, Hibernate, etc).

Conclusión:

Teniendo en cuenta estos dos puntos, seguiré posteando algunas de las cosas que tiene que ver con jBPM y la apreciación del mercado Argentino sobre este tipo de productos (apreciación personal). También tratare de definir las herramientas que actualmente faltan y algún proceso (serie de tareas) que pueda ayudar a involucrar mas a los clientes con jBPM.

Espero un poco de feedback para poder tener post mas elaborados.. sientanse comodos de aportar..de criticar y de dejar sus ideas..

SCJP – Capitulo 3: Asignaciones (Parte #4)

• Contruyendo e instanciando arrays anonimos:
  Es un shortcut como el anterior y se usa de la siguiente manera:
  int[] testscores; // se llama anonimo porque aca no lo igualamos a nada
  testsocres= new int[]{2,4,5};

  RECORDAR: new Object[3]{null,new Object(),null} //no compila por el 3!!!

• Asignacion legal de elementos a un array:
  Que podemos poner en un array en particular:
  • Array de primitivas: acepta cualquier tipo de primitivas que se pueda implicitamente convertir al tipo declarado del array:
    EJ:
    int[] x= new int[5];
    byte b=4;
    char c=’c';
    short s=7;
    x[0]=b;
    x[1]=c;
    x[2]=s;
    //TODO OK!
  • Array de referencia a objetos:
    Podemos poner cualquier subclase del tipo declarado del array. Y si declaramos al array de tipo de una interfaz podemos poner cualquier objeto que implemente dicha interfaz (si cumple IS-A puede asignarse)
  • Asignacion de referencias de array (1 dimension):
    Si declaramos un array de tipo int, solo podemos reasgnar a otro array de tipo int (no importa el tamaño)
    En mas dimiensiones ojo con la cantidad de dimensiones.
• Bloques de inicializacion:
  Los bloques de inicializacion corren la primera vez que la clase es cargada en memoria, si es un bloque static, y cuando una nueva instancia es creada si es un bloque de instancia.
  Ej:
  class SmallInit{
  static int x;
  int y;
  static{ x=7;}
  {y=8;}
  }

  Los bloques de instancia corren justo despues de que se llama a super(), en el constructor (es decir, despues de que todos los super constructors hayan corrido). Si tenemos mas de un bloque de inicializacion el orden importa!.
  Los bloques de inicializacion por lo general se usan para no duplicar codigo cuando tenemos muchos constructores similares. Finalmente si cometemos un error en el bloque de inicializacion
  obtenemos una exception ExceptionInicializationError.

Usando clases wapper y boxing:

Las clases wappers en las API de java sirven para 2 propositos primarios:

• Proveen un mecanismo para envolver el valor de las primitivas en objetos y asi incluir a las primitivas en actividades reservadas para objetos (ser agregados a collection o ser devueltos en algun metodo que devuelve un object)
• Porveen funciones de utilidades para los tipos primitivos. La moyoria relacionada con conversiones.

Intro a las clases Wrapper:

Hay clases wrapper para todos los tipos de primitivas:

(TABLA!!!)

Creando Objetos Wrapper:

Los objetos wrapper son inmutables!! Recordar!!

• Consturctores de los objetos wrappers:
  Todas las clases wrapper menos Character proveen 2 constructores:
  Uno que toma la primitiva de la clase y otro que toma la representacion en string del tipo construido.
  Ej:
  Integer i1 = new Integer(11);
  Integer i2 = new Integer(“11″);
  Y Character solo tiene:  Character c1 = new Character(‘a’);
  Y Boolean puede tomar true, false, “true”, “false”
• El metodo valueOf():
  Los metodos static valueOf() nos proveen otra forma de crear objetos Wrapper. Por ejemplo tenemos:
  valueOf(String value, int radix);
  valueOf(String value);
  Integer i2 = Integer.valueOf(“0101010″,2); -> nos convierte de binario a decimal y lo asigna a i2
• Usando las utilidades de conversion de las clases Wrappers:
  • xxxValue(): cuando necesitamos convertir un valor wrapeado a una primitiva usamos uno de los tanto xxxValue(); Todos estos metodos no reciben argumentos:
    Integer i2 = new Integer(42);
    byte b = i2.byteValue();
  • parseXX y valueOf():
    Ambos toman un string como argumento y lanzan un NumberFormatException si el string no esta correctamente formado. La diferencia entre los dos metodos es:
    - parseXXX() devuelve la primitiva en el nombre del metodo (XXX)
    - valueOf() devuelve una instancia nueva del objeto wrapper del tipo que invoco al metodo
    Ej:
    double d = Double.parseDouble(“3.14″);
    Double d2 = Double.valueOf(“3.14″);
  • toString():
    La clase Objet tiene el metodo toString() y por lo tanto todas las demas en Java tambien. La idea del metodo es poder obtener una repsentacion del objeto en forma de String.
    Todas las clases Wrapper tiene este metodo que no recibe argumentos, no es static, y devuelve un String con el valor de la primitiva.
    Todas las clases numericas poseen un metodo static sobrecargado con toString. Ej:
    String d = Double.toString(“3.14″);
    Integer y Long poseen un tercer metodo static que recibe un segundo argumento llamado radix.
  • toXXXString() (Binary, Hex, Octal):
    Las clases Integer y Long los poseen, y nos permite pasar de base 10 a otras bases. Ej:
    String s3 = Integer.toHexString(254); // s3 = fe
    (TABLA DE LA PAG 233)

Jugando con jBPM #1- Ejemplo básico

<post>

Hacia rato que no escribia nada por aca.. pero bueno.. aprovecho ahora para mostrar algunos ejemplos que tengo en mente con jBPM. La idea es mostrar procesos simples y a la vez ir viendo un poco las APIs de jBPM y los Handlers mas comunes..y otras cosas que vayan surgiendo…

En este ejemplo vamos a ver un proceso inventado por mi llamado Mails, que tiene como finalidad representar el proceso que muchos realizamos en el dia a dia de revisar nuestros e-mails.

La siguiente imagen representa el proceso modelado con GPD (Graphic Process Designer):

Ejemplo

Como podemos ver el proceso se explica por si solo, esta es una de las ventajas de utilizar un lenguaje Orientado a Grafos como jPDL.

A continuación vamos a ver algunos snippets de código en jPDL generados por la herramienta GPD. La idea es resaltar y empezar a ver un poco de como esta conformado jPDL y como lo vinculamos con comportamientos (o detalles técnicos) para que el proceso pueda ejecutarse en un entorno de ejecución.

Vamos a empezar con la definición clásica de todo proceso en jPDL:

<process-definition xmlns=”urn:jbpm.org:jpdl-3.2″  name=”Mails”>
<start-state name=”Inicio”>
<transition to=”Login”></transition>
</start-state>
…

Como podemos ver, nada raro.. solo se explicita que versión de jPDL que estamos usando, el nombre del proceso  y luego ya podemos empezar a describir los nodos que compondrán el proceso.

También vemos el nodo llamado Inicio del tipo start-state que nos indica por donde va a comenzar la ejecución del proceso cuando tengamos una ejecución/token/execution path del mismo. Como se puede observar el nodo start-state tiene solo una transición a un nodo llamado Login.

A continuación vemos el nodo llamado Login que es de tipo task-node, estos tipos de nodo tiene la características de contener una lista de nodos task que son los que realmente definen las tareas humanas que se van a crear para el o los usuarios asignados.

<task-node name=”Login”>
<task name=”Ingresar Datos”>
<description>
El usuario Ingresa los datos Nombre de Usuario y Contraseña
</description>
<assignment expression=”group(user)”></assignment>
<controller>
<variable access=”read,write” name=”username” mapped-name=”username”></variable>
<variable access=”read,write” name=”password” mapped-name=”password”></variable>
</controller>
</task>
<transition to=”Autentificacion”></transition>
</task-node>

Como podemos ver dentro de este task-node tenemos sola una tarea definida (tag task) llamada Ingresar Datos. Las cosas a destacar de esta tarea son:

• La asignación de un grupo de usuarios mediante una expresión, lo que quiere decir que todos los usuarios que estén dentro del grupo user podrán realizar esta tarea (en post siguientes entrare en detalle de este tema)
• La descripción es solo a nivel informativa
• Definimos variables que deberán ser llenadas en esta tarea (en este caso, username y password, también me explayare en este tema en post siguientes)

Siguiendo un poco con el proceso vemos un nodo de tipo node, el cual define una acción que delega el comportamiento en el la clase AutentificacionActionHandler.

<node name=”Autentificacion”>
<action name=”Autentificacion” class=”com.sample.action.AutentificacionActionHandler”></action>
<transition to=”Autentificacion ok?”></transition>
</node>

Esta clase AutentificacionActionHandler implementa la interfaz llamada ActionHandler que define y nos obliga a implementar el método execute:

import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;

public class AutentificacionActionHandler implements ActionHandler {

public void execute(ExecutionContext context) throws Exception {
// Llamada al método de autentificacion obteniendo los datos
// que ingreso el usuario en el formulario a partir de las
// variables del contexto
String username=(String)context.getVariable(“username”);
String password=(String)context.getVariable(“password”);
boolean loggedIn=login(username,password);
context.setVariable(“loggedin”,loggedIn);
}

}

Esta podría ser una implementación correcta de esta accion, la cual utiliza un método login para revisar si el usuario se autentifica correctamente con el sistema o no. Y este resultado se guarda en una variable de contexto llamada loggedin. Como vamos a ver ahora esta variable se utiliza en el siguiente nodo para decidir que transición tomar:

<decision name=”Autentificacion ok?” expression=”#{loggedin==true}”>
<transition to=”Cargar Mails Bandeja de Entrada” name=”Si”></transition>
<transition to=”Login” name=”No”></transition>
</decision>

Acá solo tenemos que destacar que este nodo decision que la expresión que decide por que transición seguir se analiza en runtime para cada instancia del proceso. Esto significa que dependiendo del valor de la variable loggedin en la instancia del proceso (sacada del contexto del mismo) es porque transición seguirá la ejecución.

Espero que se haya entendido mas o menos el ejemplo, ya de a poco iré ganando un poco de habilidades de redacción y tratare de mejorar mi ortografia, pero la idea del post era empezar a ver un poco de jPDL, gráficamente y su sintaxis XML, seguido un poco de los actions handlers. En próximos post veremos temas como:

• Ejecución del proceso
• Fork Nodes
• Process State y Super State
• Decision Handlers
• Exceptions

Hasta la próxima.. dejen comentarios o criticas a gusto y placer!

</post>