Jun 05

DWR (Direct Web Remoting)es una librería Javascript que permite el uso de Ajax (Asynchronous JavaScript and XML) de forma mucho más simple (Este artículo asume que se entiende los conceptos de Ajax, y de Java).

DWR es una librería mas orientada a apoyar la integración, que a apoyar la parte gráfica, de hecho si se buscan Widgets (objetos gráficos) esta no es la librería, pero por otro lado lo fuerte de DWR es que permite “publicar” fácilmente funcionalidad de clases Java para accederlas vía Javascript.

Luego si nuestra funcionalidad o lógica de negocio esta en Java, DWR es una de la mejores opciones para aprovecharla, ya que usar una clase Java que tenemos en un servidor de aplicaciones vía Javascript es tan fácil como definir un archivo de configuración en el servidor.

Ahora si se requiere además darle una interfaz más rica (rich interface) a los usuarios, es bueno combinar DWR con otras librerías Ajax como YUI (Yahoo User Interface), JQuery, Prototype, Scriptaculous, Dojo, o Spry.

Con Ajax se terminan las paginas JSP, o ASP (o deberían terminarse), porque Ajax solo necesita Javascript y HTML para la parte de presentación, esto lo explicaremos mejor en otro articulo, pero por ahora créannos. Y con DWR ni siquiera son necesarios los Servlets, esto en el sentido de que no se necesitan desarrollar servlets para implementar la lógica de negocio, porque DWR si internamente esta basado en Servlets, en otras palabras gracias a DWR no necesitamos implementar nuestros servlets sino solo necesitamos clases Java (POJO).

Si se conoce la tecnología Axis, que permite publicar clases Java como Webservices, este es el símil para publicar clases Java como objetos Ajax (objetos Javascripts), de hecho es muy fácil publicar con DWR un servicio realizado para Axis. Incluso las buenas prácticas o blueprints de Axis para publicar clases como Webservices se aplican totalmente para publicar clases para Ajax., ya que hay que tener los mismos cuidados en cuanto a seguridad y manejo de desempeño (performance).

La definición oficial de DWR es:

DWR permite a Javascript (en un Browser) interactuar con las clases Java en un Servidor, y ayuda a manipular las paginas Web con los resultados.

Si, porque otra característica importante de DWR es que ofrece funcionalidades Javascript que permiten fácilmente manipular el HTML de la página: como obtener los datos de un formulario (HTML Form), o de cualquier otro tag HTML, o setear fácilmente los valores de los tags HTML, ademas aporta facilidades para clonar tags, lo que permite por ejemplo crear nuevas filas (rows) en una tabla (HTML Table), muy útil para mostrar una consulta. DWR no nos provee ningun objeto grafico prehecho, pero si nos permite la flexibilidad para hacer cualquier cosa con el HTML.

Bueno basta de conceptos y vamos directo al código.

Hemos llamado a este tutorial “el Mejor”, solo para llamar su atención, pero la verdad es que es bastante bueno, por lo siguiente:

  • Es lo mas simple posible, tiene lo justo y necesario para entender el concepto principal de DWR, y como funciona.
  • Esta actualizado, otros ejemplos están basados en versiones anteriores de DWR.
  • Esta completo, otros ejemplo ponen solo parte del código.
  • Usa clases y colecciones de clases (Collection) como parámetros de entrada y parámetros de salida, que es lo que típicamente se va a usar en un sistema real, otros ejemplos usan datos más básicos. De esta forma también se muestra como se manejan las colecciones y las clases en Javascript.

Tutorial DWR en 10 Simples Pasos

  1. Lo primero es bajar DWR (http://getahead.org/dwr/download), basta bajar solo la librería (dwr.jar).
  2. Luego hay que modificar el archivo “web.xml”, este se encuentra bajo el directorio “WEB-INF”, ejemplo: ”\dwrEasy\WEB-INF”, se debe incluir las definiciones de los servlets que atienden los requerimientos DWR-AJAX.

Web.xml:

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web_app>
  <display_name>dwrEasy</display_name>
  <servlet>
    <servlet_name>dwr-invoker</servlet_name>
    <display_name>DWR Servlet</display_name>
    <description>Direct Web Remoter Servlet</description>
    <servlet_class>org.directwebremoting.servlet.DwrServlet</servlet_class>
    <init_param>
      <param_name>debug</param_name>
      <param_value>true</param_value>
    </init_param>
  </servlet>
  <servlet_mapping>
    <servlet_name>dwr-invoker</servlet_name>
    <url_pattern>/dwr/*</url_pattern>
  </servlet_mapping>
</web_app>

  1. A continuación se debe implementar la clase Java que va a ofrecer los servicios, esta basta que sea un clase Java simple (POJO), con un constructor sin parámetros, y donde cada método de la clase es un “potencial” servicio Ajax.

Esta clase va a estar del lado del servidor de aplicaciones (ejemplo: Tomcat, JBoss, o Websphere) no necesariamente tiene que ser un servidor J2EE.

EasyService.java:

package com.soaagenda.services;

import com.soaagenda.valueobjects.*;

public class EasyService {
    public EasyService() {
    }

    public EasyResponse getProducts(EasyParameter parametersX){
        EasyResponse responseX= new EasyResponse();

        // si parametros vacios devuelve error, error if empty parameters
        if (parametersX==null || parametersX.getClientID()==null || parametersX.getClientID().length()< =0){
            responseX.setErrorCode(10001);
            responseX.setErrorDescription("Debe indicar ID Cliente. Give us Client ID");
            return responseX;
        }

        //crea lista productos del cliente, fill the client product list
        //para ejemplo en duro, for the example fixed data
        Product[] productsListX= new Product[2];

        Product productX= new Product();
        productX.setBarCode("0001");
        productX.setName("Tarjeta Visa, Visa Credit Card");
        productsListX[0]= productX;

        productX= new Product();
        productX.setBarCode("0002");
        productX.setName("Tarjeta American Express, American Express Credit Card");
        productsListX[1]= productX;

        //respuesta exitosa, sucessfull response
        responseX.setErrorCode(0);
        responseX.setErrorDescription("Consulta Banco Exitosa, Succesfull Bank Query");
        responseX.setProducts(productsListX);

        return responseX;
    }
}

Este ejemplo simula una consulta de los productos bancarios de un cliente como Tarjetas de Crédito (VISA, Master Card, Dinners, American Express), Cuentas Corrientes, o Creditos de Consumo, para esto se le pasa como parámetro un objeto que tiene el ID del cliente, y el tipo de producto a consultar, el servicio (o método) devuelve otra clase con el código de error, mensaje de error, y la lista de productos (un arreglo de clases producto).

  1. También hay que definir las clases de datos (Value Objects) que va a utilizar el servicio, esta clases deben ser javabeans (atributo privados, con getters y setters):

EasyParameter.java: define los parámetros de entrada del servicio.

package com.soaagenda.valueobjects;

public class EasyParameter {
    private String clientID;
    private String productType;
    public EasyParameter() {
    }

    public void setClientID(String clientID) {
        this.clientID = clientID;
    }

    public void setProductType(String productType) {
        this.productType = productType;
    }

    public String getClientID() {
        return clientID;
    }

    public String getProductType() {
        return productType;
    }
}

EasyResponse.java: define la estructura para los resultados del servicio.

package com.soaagenda.valueobjects;

public class EasyResponse {
    private int errorCode;
    private String errorDescription;
    private Product[] products;

    public EasyResponse() {
    }

    public void setErrorCode(int errorCode) {
        this.errorCode = errorCode;
    }

    public void setErrorDescription(String errorDescription) {
        this.errorDescription = errorDescription;
    }

    public void setProducts(Product[] products) {
        this.products = products;
    }

    public int getErrorCode() {
        return errorCode;
    }

    public String getErrorDescription() {
        return errorDescription;
    }

    public Product[] getProducts() {
        return products;
    }
}

Product.java: define la estructura de un producto.

package com.soaagenda.valueobjects;

public class Product {
    private String barCode;
    private String name;
    public Product() {
        try {
            jbInit();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    private void jbInit() throws Exception {
    }

    public void setBarCode(String barCode) {
        this.barCode = barCode;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getBarCode() {
        return barCode;
    }

    public String getName() {
        return name;
    }
}

  1. Vamos a indicarle a DWR que clases vamos a publicar para Javascript (Ajax), esto se hace en el archivo “dwr.xml”, y también corresponde a un esquema de seguridad porque podemos llegar a especificar solo que métodos de una clase queremos exponer, y que atributos.

Para nuestro ejemplo vamos a publicar toda la clase servicio (com.soaagenda.services.EasyService), es decir todos sus métodos, y todas las clases de datos (com.soaagenda.valueobjects.*).

dwr.xml

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE dwr PUBLIC "-//GetAhead Limited//DTD Direct Web Remoting 2.0//EN" "http://getahead.org/dwr/dwr20.dtd">
<dwr>
  <allow>
    <!-- define la clase de servicios que se va a publicar mediante DWR -->
    <!-- defines the service class to share across DWR -->
    <create creator="new" javascript="EasyService">
      <param name="class" value="com.soaagenda.services.EasyService"/>
    </create>
    <!-- define las clases de datos que utiliza el servicio -->
    <!-- defines the data classes to share across DWR -->
    <convert converter="bean" match="com.soaagenda.valueobjects.*"/>
    </allow>
</dwr>

  1. Ahora si compilamos las clases, y publicamos nuestro ejemplo Web (deploy), DWR nos presta una utilidad para probar que todo anda bien, esta se accede desde un Browser, en el path “/dwr/”, dentro de nuestro sitio (ejemplo: http://localhost:8028/dwrEasy/dwr/)

DWR Test Page

Seleccionado el servicio, nos aparece primero las librerías javascript necesarias para implementar una pagina Web, luego la lista de servicios (métodos de las clase servicio) a los que tenemos acceso (getProducts).

DWR Test Page EasyService

Como no restringimos los métodos de la clase, incluso nos aparecen los métodos que hereda por ser una clase Java (como hashCode, getClass).

Si presionamos el botón “Execute”, ejecuta el servicio, y para el caso de nuestro ejemplo este retorna un error “Debe indicar ID Cliente”, lo que esta bien porque no le hemos indicado parámetros de entrada, con esto sabemos que todo anda bien, porque esa respuesta la da nuestra clase que esta en el servidor, es decir, ejecutamos desde Javascript (Browser) una clase que esta del lado del servidor, eso es Ajax y DWR!!.

  1. Lo siguiente es crear nuestra pagina HTML que va a consultar los resultados y mostrarlos, esta pagina es sumamente simple, tiene un formulario (Html Form), en realidad solo tiene las variables del form, porque ya no es necesario el tag “<form>” (recuerden que con Ajax la forma de hacer request al Server cambia, ahora es asíncrona), y tiene una tabla (html table) para mostrar el resultado.

Mi Primera Pagina DWR

dwrEasyPage.html

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Editable Table Demo</title>
  <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
  <script type='text/javascript' src='/dwrEasy/dwr/interface/EasyService.js'></script>
  <script type='text/javascript' src='/dwrEasy/dwr/engine.js'></script>
  <script type='text/javascript' src='/dwrEasy/dwr/util.js'> </script>
  <script type="text/javascript" src='dwrEasyJS.js'> </script>
</head>

<body>
<h1>Easy DRW Demo</h1>
    <h3>Buscar / Search</h3>

   <table>
      <tr>
        <td>ID Cliente / Client ID:</td>
        <td><input name="formClientID" type="text" id="formClientID" size="15"/></td>
      </tr>
      <tr>
        <td>Tipo Producto / Product Type</td>
        <td><input name="formProductType" type="text" id="formProductType" size="15"/></td>
      </tr>
      <tr>
        <td colspan="2" align="right">
          <input type="button" value="OK" onclick="javascript:submitProductsRequest()"/>
        </td>
      </tr>
    </table>

    <h3>Productos / Products</h3>
    <p>Respuesta / Response:
      <input name="serviceResponse" type="text" id="serviceResponse" size="50"/>
    </p>

    <table border="1">
      <thead>
        <tr>
          <th>Codigo / BarCode</th>
          <th>Nombre / Name</th>
        </tr>
      </thead>
      <tbody id="myTable">
        <tr id="myPattern" style="display:none">
          <td>
            <span id="codePattern">code example</span></td>
          <td>
            <span id="namePattern">name example</span></td>
        </tr>
      </tbody>
    </table>
</body>
</html>

Si analizamos el código, lo primero es la referencia a las librerías Javascript (“EasyService.js”, “engine.js”, “util.js”), estas fueron generadas por DWR, luego aparece la librería (“dwrEasyJS.js”) que ya es propietaria (custom), y que debemos construir para realizar la lógica de interacción (esta redescribe a continuación).

Luego aparecen las variables del formulario a solicitar (formClientID, formProductType), y el botón que define la acción de consulta, ejecuta la función Javascript “javascript: submitProductsRequest()”, esta funcion es la que se encuentra definida en la librería (“dwrEasyJS.js), la cual vamos a tener que contruir.

Después viene la tabla que mostrará los datos (myTable).

Podemos ver que hay ciertas características especiales en el código Html, estas le van a servir a DWR para encontrar donde obtener, o donde mostrar los datos:

Los “Id” de los tags html le sirven a DWR para manejar los datos:

· Los id “formClientID”, “formProductType” le permiten encontrar loas parámetros de entrada.

· El id “myTable”, le servirá para saber que tabla limpiar.

· El id “myPattern”, le indicará a DWR que filas (rows) debe “clonar” para mostrar cada registro de producto de la lista, como es un “patrón” en principio va oculto (style=”display:none”).

· Los id “codePattern”, “namePattern” servirán para qeu DWR sepa donde colocar los datos de cada producto, en este caso se usan tags “<span>”.

Como vemos esta pagina es solo Html, y Javascript, que “hermosamente simple”, nada de JSP, ni de ASP, una pagina que se puede publicar en cualquier servidor Web.

  1. Lo que sigue es la librería Javascript propia.

dwrEasyJS.js

function submitProductsRequest() {
  var idX=dwr.util.getValue("formClientID");
  var typeX=dwr.util.getValue("formProductType");

  var parametersX={clientID:idX,productType:typeX};

  EasyService.getProducts(parametersX,showProducts);

 }

function showProducts(responseX) {

// borro filas excepto el patron, delete rows except pattern row
        dwr.util.removeAllRows("myTable", { filter:function(tr) { return (tr.id != "myPattern");}});

	if (responseX.errorCode!=0){
  	  alert('Error: '+responseX.errorDescription);
	  return;
	};
	var productsX=responseX.products;
	var lengthX=productsX.length;
	var itemProductX;

 	if (lengthX==0){
  	  alert('No hay productos, Cant find products');
	  return;
	};

	dwr.util.setValue("serviceResponse", responseX.errorDescription);

	var id="00";
	for (var i=0 ; i<lengthx ; i++)
        {
           temProductX= productsX[i];
           id="00"+i;
           dwr.util.cloneNode("myPattern", { idSuffix:id });
           dwr.util.setValue("codePattern" + id, itemProductX.barCode);
           dwr.util.setValue("namePattern" + id, itemProductX.name);
           $("myPattern" + id).style.display = "";
        }
}

  1. Esta librería tiene dos funciones: “submitProductsRequest” la que obtiene los parámetros de entrada y ejecuta el servicio correspondiente (clase Java EasyService.getProducts() vía DWR), y la función que muestra los datos (showProducts).

Finalmente hay que subir las páginas (Deploy) en el sitio Web, quedando el proyecto con la siguiente estructura:

.Proyecto DWR de Ejemplo

Ejecutamos la pagina de prueba “dwrEasyPage” en nuestro Browser (ejemplo “http://localhost:8028/dwrEasy/dwrEasyPage.html”), ponemos un dato en “ID Cliente”, presionamos “OK”, y listo!, nuestra primera aplicación Ajax-DWR.

  1. The End

May 28

Cuando nos da el siguiente error:

[ERROR, org.directwebremoting.impl.DefaultCreatorManager]Creator: ‘NewCreator[XXX]’ for XXX.js is returning null for type queries.

Se debe a que no encuentra el constructor de la clase que se esta exportando en DWR, esto se puede deber a los siguientes motivos:

  • El nombre de la clase o el package de la clase esta mal definido en el archivo “dwr.xml”.
  • La clase no tiene el constructor por defecto vacio.
  • La clase no se encuentra en el classpath, por ejemplo si es un proyecto Web no se encuentra en el directorio “..\WEB-INF\classes\”, o “..\WEB-INF\lib\” (si esta dentro de un jar).
  • Del anterior se desprende que; suele suceder que cuando se compila la clase no se incluye en ningun jar, luego en el fondo esta mal definido el proyecto en cuanto a la compilación, y generación de librerias (jars).
Dic 04

Existen tecnologías dentro del ambiente SOA, y BPM, que tienen mucho en común, y por lo tanto muchas veces no se logra visualizar de forma clara sus diferencias, estamos hablando de los “coordinadores de tareas”, u “orquestadores” en general , herramientas que permiten organizar actividades en un flujo. Bajo este concepto podemos tomar:

  • ETL (Extract Transform and Load)
  • WorkFlow tradicional
  • ESB (Enterprise Service Bus)
  • BPM o BPMS (Business Process Management Suite)

Estas herramientas en general permiten a través de asistentes gráficos crear un proceso a partir de la organización de tareas, o subprocesos.

Extract, Transform and Load (ETL)

Nacida para traspasar información desde un repositorio de datos origen a uno destino, esta tecnología esta orientada a los procesos de datos, procesos basados en repositorios como Base de Datos y archivos.

ETL es una de las tecnología mas antiguas de integración, integración a nivel de datos, y tal como las Bases de Datos relacionales su utilidad se ha consolidado en el tiempo. Incluso en la actualidad dentro de la “Arquitectura Orientada a Servicios” (SOA) tiene su puesto en lo que son los “Servicios de Información”, porque a pesar de que su principal uso es en procesos Batch (procesos de actualización masivos), también se puede usar para el desarrollo de funcionalidades especificas pero que involucran la integración de entidades de información dispares (distintas).

Tal como su nombre lo indica permite Extraer (Extract), Transformar (Transform), y Cargar (Load), información desde, y hacia distintas fuentes de datos.

  • Extraer: permite extraer la información de distintas fuentes de datos, principalmente bases de datos, y de la mayoría de los proveedores conocidos: Oracle, Sybase, DB2, MySQL, esto lo hace directamente desde las tablas, o usando “Stored Procedures” existentes. También permite extraer datos de archivos como XML, Excel, CSV, Texto, entre otros. Y han evolucionado hasta incluso obtener información de colas de mensajes, objetos Java, y Webservices, abarcando de cierta forma el terreno de los ESB.
  • Transformar: a través del manejo de Metadata (datos en un formato estándar desacoplado de la fuente) permite unir la brecha existente debido a la diferencia de los tipos de datos, por ejemplo el proceso de información “Actualizar Datos de un Cliente” que involucra actualizar en distintos lugares, puede requerir que un dato que esta en entero deba pasarse a tipo float (real), o que los apellidos que están separados en una base de datos deban guardarse juntos en un solo campo en otra base de datos, o que un código de comercio que esta en cierto estándar (como EAN) se deba traducir a otro estándar (como ISBN) porque así se maneja en el otro repositorio.
  • Cargar: permite guardar la información procesada en la misma diversidad de entidades que maneja dentro de la extracción: Bases de Datos, y archivos de distinto tipo.

En la actualidad las herramientas de ETL permiten componer estos procesos mediante asistentes gráficos, ambientes de desarrollo (IDE) que realizan una introspección de las fuentes de datos, obteniendo todos los objetos y sus campos de datos, permitiendo a través de “arrastrar y soltar” construir el flujo de proceso de datos. Además pueden incorporar reglas de negocio que permiten potenciar la funcionalidad del procesos.

Ejemplo: Proceso de Información Agrega Nuevo Producto

Proceso ETL

A este proceso ejemplo se le entrega un producto, el cual lo transforma en metadata, para poder por un lado obtener la marca asociada (desde una base Sybase), y por otro lado su código EAN (usando un Stored Procedure), si el código EAN no existe se busca en un archivo XML, luego finalmente toda la información se carga en la tablas de Productos (Base DB2), y además se registra en un archivo de Log (archivo txt). Mas que nada este ejemplo sirve para mostrar la relación que se puede establecer entre los distintos objetos ETL, pero la estructura definitiva de un diseño ETL dependerá de la herramienta que se utilice.

Los principales objetos que maneja un ETL son:

  • Tablas de Bases de Datos
  • Procedimiento Almacenados (Stored Procedures)
  • Archivos XML
  • Archivos de Texto, Archivos Excel.
  • Transformaciones de Datos.

Otra característica que ofrecen actualmente los ETL, y que es muy importante para la Arquitectura SOA, es que los procesos ETL se pueden ejecutar como WebServices, para lo cual el motor de ETL publica el proceso en formato SOAP, pudiendo ser ejecutado desde cualquier plataforma (Java, .Net), y ser integrado en tecnologías como ESB (Enterprise Service BUS).

Luego, en el contexto de SOA podríamos indicar que ETL es la herramienta que permite diseñar y construir procesos de información (servicios de información) basados en actividades (automatizadas) a nivel de datos.

Algunas herramientas ETL del mercado son:

WorkFlow Tradicional

Decimos WorkFlow “Tradicional”, porque la forma actual y bajo SOA de implementar un workflow es BPM, pero existen aun tecnologías WorkFlow tradicionales (no BPM), pero la mayoría se esta transformando en soluciones BPM.

La verdad es que actualmente muchas herramientas WorkFlow se acercan a lo que es BPM, viéndolo solo desde el punto de vista del flujo de los procesos de negocio, por eso aquí vamos a ver el concepto de WorkFlow Tradicional que se refiere al WorkFlow como era antes de evolucionar a BPM.

WorkFlow (Tradicional) es la tecnología que permite coordinar actividades humanas (realizadas por personas, Human Task), aquí se definen roles, actividades, reglas de negocio, en buenas cuentas un flujo de trabajo (WorkFlow), pero que a diferencia de BPM no contempla en forma natural los “servicios de negocio”, es decir no contempla las actividades de sistemas (System Task) bajo el estándar SOA.

Ejemplo: WorkFlow Actualizar Stock de Productos

Proceso WorkFlow

Este WorkFlow ejemplo define un procesos donde un ejecutivo ingresa Stock de productos, el supervisor verifica el stock ingresado, y si es un producto nuevo además verifica la ficha del producto, si por alguna razón no se valida el registro vuelve al ejecutivo, quien debe corregir el ingreso. Este es un ejemplo genérico, la estructura del diseño del proceso dependerá de la herramienta utilizada.

Luego en una solución (WorkFlow tradicional) el participante (usuario) debe indicar el cumpliendo de la tarea (cambio de estado), para de esta forma continúe el flujo de trabajo, y cuando debe interactuar con algún sistema, debe levantar dicho sistema y realizar la actividad en él, por ejemplo ejecutar el sistema de stock para agregar un nuevo producto.

Esa es otra gran diferencia con BPM, en BPM se trata de proveer una sola interfaz para un participante del proceso, ocultando la interacción con los sistemas, mientras en un WorkFlow (tradicional) la persona debe interactuar con distintos ambientes o aplicaciones, dicho de otra forma: la persona debe manejar distintas aplicaciones (sistemas), y además registrar su avance en el WorkFlow.

Con WorkFlow (al igual que BPM) se le da seguimiento y control a los procesos de negocio, es decir, podemos saber el estado actual de cada proceso, en que lugar del flujo se encuentra. Otra similitud con BPM , o dicho de otra forma; otra característica que BPM heredo de los WorkFlow, es que a través del proceso generalmente fluye información (documentos, datos), lo que se llama la metadata, u objeto de negocio (BPM).

Enterprise Service Bus (ESB)

Esta tecnología permite integrar sistemas a nivel de servicios, cuando se habla de tecnología para implementar SOA en una empresa la primera herramienta que se debe incorporar es el “Service Bus”.

Esta herramienta permite componer procesos a partir de servicios SOA, los servicios SOA son componentes funcionales encapsulados fuertemente reutilizables, haciendo el “típico” símil: son piezas de lego que permiten construir un sistema uniendo bloques, y en este caso construir un proceso uniendo servicios SOA.

Proceso ESB Actualiza Producto en Sistemas

Proceso ESB

En este proceso ejemplo se entrega el producto a actualizar se comprueba el tipo de producto (Ecommerce o SAP), usando una clase Java (conecto EJB), luego se actualiza en el sistema Ecommerce usando un WebService, o se actualiza en el sistema SAP usando un conector provisto por el ESB.

Al igual como BPM absorbió las funcionalidades de WorkFlow (a través de BPEL4People), también absorbió las funcionalidades del ESB (a través de BPEL), de hecho las BPMS (BPM Suite) suelen traer como parte de sus componentes el ESB.

La diferencia con BPM es que el ESB no maneja las actividades humanas (Human Task) solo maneja actividades automatizadas (System Task).

La diferencia con ETL (tradicional) es que ETL esta orientado a componentes de datos, y ESB esta orientado a componentes de Servicios.

Los objetos que principalmente maneja ESB son:

  • WebServices
  • Conectores a Colas de Mensajes, y JMS
  • Conectores a Aplicaciones de clase Mundial (PeopleSoft, SAP, JDEdwards)
  • Conectores a J2EE (EJB) y .Net
  • Transformaciones de Datos

Los ESB también manejan Metadata para la transformación de datos, y para lograr que los sistemas se entiendan a pesar de la diferencia en los tipos de datos que manejan.

Una característica importante es que los procesos se pueden ejecutar a través de WebServices, es decir un proceso de negocio ESB se puede publicar en protocolo SOAP, permitiendo que una gran variedad de plataformas puedan acceder a estos procesos.

Algunos ESB tienen conectores para Base de Datos, permitiendo integrar consultas a tablas (SQL Query), y procedimientos almacenados (Stored Procedures), con esto el ESB comienza abarcar terreno de los ETL, pero a decir verdad esta característica pone en riesgo la orientación a servicios (SOA), ya que los servicios deben corresponder a la capa de negocio, y no a la de datos.

Algunos ESB importantes:

Resumiendo ESB desde el punto de vista SOA es la herramienta que permite desarrollar procesos basado en servicios SOA.

BPM Suite.

BPM es la solución que permite construir procesos de negocio basado en coordinar tanto actividades interactivas (human task), como servicios (system task). BPM une lo mejor del mundo del WorkFlow Tradicional con el ESB.

En un mismo flujo se integran tareas realizadas por personas, con tareas automatizadas(sistemas), entregándole al participante de un proceso de negocio una sola interfaz, ocultando la interacción con los sistemas legados.

Ejemplo Proceso de Negocio Actualizar Stock de Productos

Proceso BPM

Basado en los ejemplos anteriores, en este proceso se integran 2 servicios al WorkFlow “Actualizar Stock”: una vez ingresado el stock, si el producto existe, entonces se obtiene los datos del producto usando un “WebService” (Obtiene Ficha Producto), y si el supervisor valida el ingreso al final se actualiza el producto usando otro “WebService” (Actualiza Producto), este ultimo servicio se supone es el proceso ESB “Actualiza Producto en Sistemas” publicado como WebService. Este es un ejemplo simplificado, en la realidad puede ser necesario incluir algunos servicios más.

La otras características de valor agregado de BPM son: que ofrece un grupo de herramientas para atender todo el ciclo de visa de un proceso de negocio, dentro de las cuales se destaca, el modelador (diseño procesos), el IDE (desarrollo de servicios), y el monitor (BAM), este ultimo que permite realizar un seguimiento y control mas acabado de los procesos de negocio.

Orquestadores en la Arquitectura de Referencia SOA

Desde el punto de vista de arquitectura marco SOA, los orquestadotes se organizan de la siguiente forma:

ETL, ESB, BPM, SOA

Nov 27

Technorati Profile

Nov 16

Parte importante de la infraestructura (plataforma) que soporta a SOA y BPM son lo servidores de aplicaciones, y las aplicaciones sobre estas tecnologia demanda alta disponibilidad y un alto desempeño, por lo tanto deben contemplar una configuración adecuada. A continuación analizaremos los principales conceptos de una plataforma de este tipo, y especialmente nos centraremos en como lo maneja la solución de IBM.

El WebSphere Application Server Network Deployment (WAS ND) es una configuración que provee: alta disponibilidad (HA High Availability), tolerancia a fallas (FailOver), mejoras de desempeño (performance), mejoras de Seguridad, y escalabilidad (simplifica crecimiento servidores). Esto a través de:

§ manejo de clúster

§ balanceo de carga (WLM WorkLoad Management)

§ WebServices GateWay (versión 6.0)

§ manejo de cache (antememoria) para los recursos Web y J2ee (java).

§ Backup Clúster

WAS ND puede manejar varios nodos (servidores WAS), en cada nodo puede haber varios servidores de aplicaciones (lógicos), y en cada servidor varias aplicaciones.

WebSphere Application Server Network Deployment

Alta Disponibilidad a nivel de Servidor de Aplicaciones, hay que destacar que WAS-ND es una solución para manejo de clúster de servidores de aplicaciones, no para servidores Web (IBM Http Server) para este último existen otros productos o tecnología como IP Sprayer , o WebSphere Edge Server. Luego WAS-HD esta orientado a distribuir las solicitudes (request) J2EE: Servlet Request , y EJB request.

Clusters conjunto de servidores de aplicaciones (lógicos) que tienen instaladas las mismas aplicaciones, cada clúster es un clon de un servidor de aplicaciones (lógico), un clúster sirve para balanceo de carga (WLM), y alta disponibilidad.

Celda (cell) aquí corresponde al conjunto (dominio) de nodos según una agrupación lógica con el fin de facilitar la administración, por ejemplo sirve para sincronizar los clusters (clones de Serv. app lógicos).

Deployment Manager es el panel de control y de administración del ambiente WAS-ND, el Deployment Manager es un WAS de administración, pero “no” participa directamente en la distribución de los request (Servlet o EJB Request), luego este modulo no participa directamente en balanceo de carga, son otros los componeles de WAS-ND que participan en la distribución de los request: el “HTTP PlugIn”, y el “WLM PlugIn”. El Deployment Manager es el encargado de sincronizar la configuración y el deployment entre los distintos nodos y clusters, luego su participación es en tiempo de deployment.

WAS Network Deployment WorkLoad

HTTP PlugIn modulo que se asocia al “Http Server”, encargado de rutear y balancear los Servlet Request. Este plugin determina que clúster (servidor app lógico clonado) atenderá el request según un esquema de balanceo de carga.

Balanceo Carga del Http Plugin si el request tiene “session” lo rutea directamente al clúster que esta manejando dicha session (para que no se pierda), si no tiene “session” entonces selecciona un clúster según un criterio de balanceo que se basa: en un peso especifico para cada clúster (que el usuario administrador asigna) y la carga de trabajo que tiene en el momento cada clúster, según esquema de round robin (recorrido circular).

Persistencia de Session, y Alta Disponibilidad: la session no se pierde porque siempre se asigna el mismo clúster, pero que sucede si ese clúster se encuentra abajo (el proceso o el nodo no responden), entonces se le debe asignar otro clúster. El WAS-ND maneja distintos esquemas para la persistencia de la session en estos casos: in memory (sin persistencia), in database (sesión en la base de datos), y memory2memory (a través de mensajes JMS). El problema es que la persistencia de datos degrada el performance, y no asegura consistencia 100%, además en el caso de la base datos agrega un punto falla: sin base de datos no hay sesiones, y el sistema no va a funcionar. Sin persistencia de sesión puede haber mejor performance con el manejo de clusters, pero “no” va haber alta disponibilidad al 100%(el usuario va a tener que volver a logearse). La persistencia de sesión se puede configurar a nivel de aplicación, o a nivel servidor de aplicación lógico (se define en un app server, y sesión compartida por clústeres).

WLM PlugIn es el modulo que se encarga de rutear y balancear los “EJB request”. Este plugin determina que clúster atenderá el request de acuerdo a un algoritmo de balanceo. Este modulo se encuentra en todo Nodo del WAS ND, porque en este caso un nodo puede ser cliente o servidor (clúster) de los EJB.

Balanceo Carga WLM PlugIn si el request tiene una transacción, se asigna al mismo clúster que inicio la transacción, si el request corresponde a un objeto existente en un clúster se le sigue asignando es clúster, si el request corresponde a la creación de un objeto entonces se le asigna un clúster según un esquema round robin (mismo de Http PlugIn), pero con la posibilidad de manejo de la siguiente condición previa (preferencias): “in Process” (mismo clúster cliente), “Prefer Local” (mismo nodo cliente).

Persistencia de EJB, y Alta Disponibilidad: existen 3 tipos de EJB los Entity Beans, los Session Bean Stateless, y los Session Bean Stateful, en los 3 casos se mantiene su persistencia debido a que siempre se asigna el mismo clúster en el cual se crearon, pero cuando ese clúster no responde se le asigna otro clúster, ¿Que pasa entonces con la persistencia del EJB?, la respuesta depende del tipo de EJB: si es Entity Bean no se pierde porque esta se mantiene en la base de datos, si es un Session Bean Stateless tampoco hay problema porque no hay nada que perder (no maneja datos en la sesión), pero si es Session Bean Stateful en WAS 6.0 se debe configurar un esquema memory2memory de persistencia, y en WAS 5.0 simplemente se pierde el estado de este session bean (usuario debe volver a logearse).

Escalabilidad Vertical: definir múltiples clones de un servidor de aplicaciones (lógico) en la misma maquina. En ciertos casos un servidor de app. que se implementa con un solo proceso JVM no utiliza todo el poder de la CPU llevando la carga de la cpu al 100%, la escalabilidad vertical permite crear múltiple procesos JVM, utilizando todo el poder de CPU, y obteniendo failover a nivel de procesos.

WAS Network Deployment Vertical Clusters

Escalabilidad Horizontal: definir múltiples clones de un servidor de aplicaciones (lógico) en distintas maquinas, esta solución incrementa el performance.

WAS Network Deployment Horizontal Clusters

Nov 12

Registered at RegisteredCommons.org

Implementar procesos de negocio bajo el enfoque BPM es una tarea compleja que requiere de la Organización bastante disciplina, y un nivel de madurez metodológico y en estándares alto, esto se traduce en:

  • Tener un acabado conocimiento de los Procesos del Negocio.
  • Dominar la orientación a servicios (SOA).
  • Aplicar varias tecnologías nuevas (XML, WebServices, EBUS, BAM, Portlets, J2EE, .NET, BPEL, BPEL4People, etc.)
  • Tener un esquema de control y apoyo adecuado (Governance).

Luego con tanto prerrequisito implementar BPM puede o tomar mucho tiempo, o involucrar una alta inversión inicial. Entonces ¿Como podemos comenzar a implementar BPM ahora, sin tener que hacer una inversión tan riesgosa?.

A continuación se presentará una alternativa utilizando el enfoque “Ágil” (Agile), el mismo en el que se fundamenta “Xtreme Programming” (XP), a este nuevo enfoque le llamaremos XtremeBPM.

Los principios “Ágiles” son:

  • Simplicidad: consiste en desarrollar solo lo que se necesita actualmente, entregar soluciones simples pero escalables. Los proyectos deben ser de corto plazo. Es muy complejo predecir el futuro.
  • Retroalimentación: el proyecto se divide en pequeñas partes que se desarrollan y prueban, obteniendo una retroalimentación del usuario antes y oportuna.
  • Comunicación: propone una comunicación directa y continua entre clientes y desarrolladores, el cliente se integra en el equipo para establecer prioridades y resolver dudas, y de esta forma ve el avance día a día.
  • Decisión (Courage): enfrentar los problemas inmediatamente, mejorar el sistema si la retroalimentación lo sugiere, y enfrentar los cambios de plan apenas se identifican.

Si nos detenemos en estos principios podremos ver que están en total concordancia con los objetivos de BPM:

  • Integración de TI y Negocio: BPM acorta la brecha entre negocio y TI, y refuerza el concepto de que las soluciones estén basadas directamente en los objetivos de negocio, y en los procesos de negocio. Esto esta directamente relacionado con los principios ágiles de comunicación y retroalimentación.
  • Enfoque Evolutivo: BPM descarta totalmente los enfoques BigBang (revolución en los sistemas), propone un enfoque evolutivo, comenzando por la implementación de algunos procesos de negocio, los principales, y al igual que SOA realizando primero los componentes mas reutilizables, y con el tiempo ir sumando soluciones. A lo mismo que apunta el principio de la “simplicidad” (enfoque ágil).
  • Time2Market: otro objetivo de BPM es salir con las soluciones en forma oportuna, y lograr adecuarse lo mas rápido posible a los cambios del mercado, a los cambios de negocio. El principio ágil de la “Decisión” (Courage) para enfrentar los cambios va en la misma dirección.
  • Ciclo de Vida Procesos: BPM se basa en el ciclo de mejoramiento continuo de los procesos de negocio pasando por el modelamiento, simulación, publicación, ejecución, y monitoreo de los procesos, donde el monitoreo retroalimenta al modelo con estadísticas reales del proceso. Los mismos fundamentos que hay detrás de los principios ágiles de simplicidad y retroalimentación; soluciones que van a mejorando en el tiempo.

La idea de XtremeBPM es ir avanzando en forma acorde al desarrollo de las capacidades de la Organización, comenzando por los pasos mas fáciles de BPM, e ir aumentando la complejidad, y mejorando la solución en forma continua.

Antecedentes de BPM.

Un proceso de negocio se puede definir como una secuencia de actividades para lograr un objetivo o meta de negocio, por ejemplo en un Banco el proceso para “Otorgar un Crédito de Consumo”. En esta definición es importante recalcar lo de “objetivo de negocio”, porque permite diferenciarlos de los otros procesos, por ejemplo el proceso de “Impresión Masiva de Contratos” no es un proceso de negocio, porque no logra una meta de negocio sino una meta operativa, es un proceso informático, lo que si; puede ser parte de un proceso de negocio.

Proceso de Negocio Otorgar Credito de ConsumoEl modelo del proceso de negocio es el componente fundamental de BPM, porque este modelo (o flujo) es el que de cierta forma se ejecuta en el motor de BPM (el Process Server).

El proceso de negocio (su modelo BPM), se compone principalmente de:

  • Actividades: son las tareas que debe hacer una persona (tarea interactiva, human task), o debe hacer un sistema (servicio, o system task) dentro del proceso de negocio. Por ejemplo “Revisar Antecedentes Financieros” (actividad interactiva), o “Imprimir Contrato” (servicio de un sistema).
  • Roles y Usuarios: son los responsables de ejecutar las tareas interactivas, por ejemplo un “Ejecutivo” de un Banco.
  • Objeto de Negocio: es la información o documento que fluye a través del proceso de negocio, por ejemplo la “Solicitud de Crédito”, o el “Crédito de Consumo” (en que se transforma la solicitud), o la “Ficha del Cliente”.
  • Flujos (flechas): es la secuencia que se define entre las actividades.
  • Decisiones: criterios para tomar distintas opciones en el procesos, distintas direcciones en el flujo.
  • Subproceso: otro proceso interno.

Componenetes Modelo BPM


Obstáculos que enfrenta BPM.

A continuación presentaremos los principales obstáculos que presenta un proyecto BPM.

Modelar la Realidad una Tarea Compleja

Como se indicó; el modelo del proceso de negocio es el núcleo de la solución BPM, pero plasmar un proceso real en un modelo es una tarea compleja. Lo que sucede es que la realidad tiene excepciones, es variable, y un modelo trata de “fijar” las reglas.

Otro alcance en BPM es que como el modelo del procesos es el motor de la solución, el nivel de detalle requerido es mucho mayor, porque el modelo ya no solo tiene un objetivo “didáctico” o de documentación de los procesos, en BPM tiene que tener el suficiente detalle como para ser ejecutado.

Si nos damos cuenta un modelo “tradicional” de un proceso de negocio se centra en el “camino feliz” (HappyPath), es decir en el caso que todo anda bien, como en el ejemplo del diagrama anterior “Otorgar un Crédito de Consumo” donde el flujo muestra el caso de un Cliente “ideal”, que cumple todos los requisitos para que se le otorgue un crédito: tiene un patrimonio adecuado, no tiene deudas, y no tiene antecedentes penales, este modelo para efectos de “mostrar” el proceso puede ser suficiente, pero el “camino feliz” es solo la punta del iceberg en un proceso real cada excepción determina varios nuevos caminos en el flujo (decisiones), incluso las excepciones en combinación pueden determinar otros caminos:

  • Que sucede si le patrimonio no es suficiente.
  • Que sucede si tiene deudas en el sistema.
  • Que sucede si tiene antecedentes
  • Que sucede si se arrepiente de firmar una vez aprobado el crédito.
  • Que sucede si tiene antecedentes pero en el ultimo tiempo es un Cliente ejemplar, y su patrimonio es importante.

Luego las excepciones hacen bastante mas complejo el modelo, pero son necesarias para su ejecución.

Y hay otro tipos de excepciones que son comunes, y que también “dificultan” la implementación de un proceso, como la “generalización” de los roles, por ejemplo el “Supervisor” (de una sucursal) es quien “Autoriza el Crédito”, pero en la realidad existe una sucursal pequeña donde lo autoriza específicamente “Juan Perez” que es un Ejecutivo Senior, en este caso no podemos asignarle el rol de supervisor a “Juan Perez” porque le entregaríamos otros privilegios, y dependiendo de la solución BPMS la alternativa incluso puede ser crear un rol especial para un solo caso.

También en la realidad se da el caso de que el flujo depende del criterio de un experto el cual decide cual es la próxima tarea, y la próxima tarea puede ser un subconjunto grande de posibilidades, luego difícilmente vamos a modelar todas las flechas de salida hacia todas las actividades posibles.

caso Experto

Incluso puede ser aun mas complejo: un experto no solo determina la próxima actividad sino toda una forma de flujo especial en cada caso.

Luego, el modelo para realmente operar, se comienza a alejar del modelo inicial entregado por el área de negocio, y tratar de lograr obtener una primera versión funcional del proceso se hace realmente difícil de lograr.

Generalmente lo que se hace en estos casos es que se implementa solo el “camino feliz” y las excepciones se manejan como cajas negras, o simplemente se dejan fuera de la implementación inicial del proceso, pero esto deja muchas funcionalidades sin implementar.

Importancia del Manejo de Excepciones.

El “camino feliz” generalmente es la ejecución (flujo) mas común de un proceso de negocio, que puede corresponder el 70% de los casos reales, luego una solución BPM que implemente solo este flujo estaría apoyando el 70% de los procesos que se ejecutan, pero desde el punto de vista de gestión, el 30% que queda fuera, puede ser tanto o mas importante en cuanto a información , seguimiento y control.

Un caso especial o excepción puede transformarse en un”taco” dentro del flujo del proceso, luego es importante conocer las actividades que se realizaron en el manejo de la excepción, y cuanto demoraron. Si las excepciones se manejan como “cajas negra” entonces ¿Como identificaremos los casos especiales, que se hacen tan comunes que ya deberían ser parte del flujo?.

Modelar por Partes.

Otra forma de hacer mas manejable la implementación de un proceso de negocio con BPM, es empezando con una parte del proceso, donde si se manejen la mayoría de sus excepciones, en el ejemplo del proceso de “Otorgar un Crédito de Consumo” podría ser la parte de la evaluación del Cliente que hace el ejecutivo con todas sus excepciones., dejando fuera las actividades del supervisor. Y esta parte del proceso se lleva a producción, luego en etapas siguientes se implementan las otras partes del procesos hasta completarlo.

El problema de este enfoque es que sigue siendo una solución a medias, es como pavimentar una parte del camino solamente, lo que a vista del usuario final no es considerado como una solución.

Catálogo de Servicios en Desarrollo.

Una de las diferencias importantes entre implementar BPM y el enfoque tradicional de los WorkFlows, es que BPM integra en el flujo a los “servicios” (actividad automatizada realizada por un sistema , y bajo el estándar SOA).

Luego si en una empresa los servicios SOA aun están en desarrollo, es decir, se cuenta solo con un conjunto pequeño de servicios implementados bajo SOA, entonces implementar un proceso de negocio funcional implica una fuerte carga de trabajo en el desarrollo de los servicios necesarios, lo que suele demorar la implementación de un proceso bajo BPM.

Este es otro escollo que suele determinar que un proceso de negocio se realice por partes, o que se opte por implementar primero los servicios de un solo sistema legado (uno de todos los sistemas que están involucrados en el proceso de negocio).

Tareas Interactivas Legadas.

BPM supone una interfaz común para las tareas interactivas, es decir se espera que la solución BPM provea las interfaces necesarias para que un participante del proceso de negocio (un usuario) realice sus actividad, por ejemplo una pantalla que le permita al Supervisor “autorizar el Crédito”, donde se le muestren los datos principales del cliente y de la solicitud, quizás se adjunte la solicitud de crédito (el documento), y donde el tenga la opción de aprobar ,o rechazar el crédito.

Pero muchas veces esta interfaz existe en la empresa y esta implementada en un sistema (legado), y migrarla a la plataforma BPM es una tarea compleja.

Evitar Doble Tarea.

En las soluciones WorkFlow tradicionales, generalmente el usuario tenia que por un lado ingresar al sistema legado hacer su tarea interactiva, y después meterse en el ambiente del WorkFlow para registrar el avance, es decir por cada actividad interactiva tenia que hacer 2 tareas. En BPM se propone evitar esto con la integración de los sistemas (a través de los servicios), y mediante la interfaz común. Así en BPM un actividad como “Registrar el Crédito” internamente y automáticamente registra el avance del proceso a la siguiente tarea, y no lo tiene que hacer expresamente el usuario.

Pero si finalmente para efectos de tener una primera implementación del proceso, se implementa por partes, o solo se implementan algunos servicios, entonces lo mas probable es que se den casos en que el usuario deba registrar su avance en BPM porque el servicio se sigue haciendo en el sistema externo.

Practicas y Principios de XtremeBPM

A continuaciones mostraremos las practicas de desarrollo de XtremeBPM, que tratan de minimizar el impacto de los obstáculos antes mencionados.

Este nuevo enfoque muestra una forma de enfrentar el problema, partiendo por los componentes mas simples, pero mejorando la solución en un proceso continuo, logrando finalmente lo mismo que el enfoque tradicional, que es: el proceso de negocio implementado.

La idea de este enfoque es lograr desde un principio los siguientes objetivos (de la administración de un procesos de negocio):

  • Seguimiento y Control del Proceso de Negocio.
  • Entregar Información de Gestión del Proceso (en tiempo real).

Modelo Centrado en las Actividades.

Lo mas complejo de modelar un procesos de negocio no es determinar las actividades que lo componen, sino representar los distintos flujos o secuencias que existen entre las actividades, gráficamente hablando lo mas complejo es colocar las “flechas” en el modelo.

Tomando ejemplos anteriores, el problema en el manejo de excepciones en un proceso de negocio, no es que agregan tantas nuevas actividades, sino que agrega nuevas secuencias a las actividades existentes, mas flechas y en distintas combinaciones, lo cual desordena el modelo, por ejemplo para el “Otorgamiento de un Crédito”, un Cliente que tuvo antecedentes penales, pero que tiene un patrimonio excelente, quizás este caso especial mas que una nueva actividad, determina que el flujo salte directo a la actividad “Autorizar Crédito” (actividad que ya existe).

Esto incluso lo respaldan metodologías como UML, aquí lo primero que se define son los “Casos de Uso”, es decir, se determinan las distintas funcionalidades por tipo de usuario, o en metodologías orientadas a objeto (OO), aquí se indica que lo primero es comenzar a identificar los objetos y los métodos a partir de los requerimientos del usuario. Fácilmente podemos entonces hacer un paralelo, donde lo primordial es determinar las actividades de un BPM (o modelo de procesos de negocio) al igual como los casos de uso UML, o los “métodos” de OO.

XtremeBPM se basa en ese hecho: de que es más fácil e inmediato determinar las actividades de un proceso que identificar sus flujos, luego la primicia es:

Implementar Primero las Actividades sin los Flujos

En vez de simplificar la implementación del proceso tomando solo una parte de él, o dejando fuera las excepciones, XtremeBPM propone tomar todas las actividades del proceso pero dejando fuera (en primera instancia) los flujos (las flechas). Es decir la primera implementación del proceso de negocio será principalmente actividades, sin flechas (o con muy pocas de ellas).

Participante Determina Flujo.

¿Pero entonces quien determina la secuencia de las actividades?

Respuesta: Las determina cada participante del proceso, es decir un usuario determina cual tarea es la próxima, y quien la realiza.

Manejo de los Estados y Restricciones de Entrada

Una parte importante de esta primicia (XtremeBPM), es que se deben determinar los estados principales de los objetos de negocio, y para las actividades se debe definir los estados que son prerrequisito “obligatorios” de entrada, por ejemplo para al actividad “Autorizar Crédito” la solicitud de crédito debe cumplir con los estados “Patrimonio Verificado”, “Deudas Verificadas” y “Antecedentes penales verificados”, es decir un CheckList de estados.

De esta forma no interesa el orden en que se realizaron las actividades previas, lo que si importa es que se cumplan ciertas condiciones, o estados. El ejemplo esta bastante simplificado, porque las condiciones no son solo si se cumple un estado u otro, sino a veces son condiciones un poco mas complejas, como:

§ El Patrimonio supere cierto monto.

§ Las deudas estén por debajo de un monto.

Estas condiciones “obligatorias” o “estado obligatorios” son los que se deben validar como entrada de una actividad.

Validar Estados en la Entrada

Aquí hay otra característica importante de XtremeBPM, que es; que condiciona la simplificación del modelo, porque muchas veces los estados se tratan de evaluar en la salida de una actividad, dependiendo hacia que actividad se va a saltar, lo cual hace que se tenga que manejar repetidas veces las condiciones, por ejemplo supongamos que N actividades desembocan en la actividad “Autorizar Crédito”, pero en vez de validar en la entrada de esta ultima, validamos en las actividades previas como condiciones para saltar a “Autorizar Crédito”, entonces debemos implementar N veces la validación.

Validar Estados en la Salida

Si no se cumple con las Condiciones se Devuelve.

Si un objeto de negocio no cumple con las condiciones o estados de entrada de una actividad se devuelve a la actividad previa, y al usuario previo, de esta forma se evitan las asignaciones erróneas, y el objeto de negocio vuelve a quien trato de asignarlo.

Actividades “EstereoTipo” (StereoType)

Este es otro aspecto fundamental de este enfoque, las actividades “Estereotipo” son una forma de extender el modelo del proceso de negocio, y son una forma manejar las posibles actividades nuevas o que no están aun en el proceso implementado (no están en el modelo).

En el mismo ejemplo del proceso de “Otorgar un Crédito”, supongamos que hay un caso excepcional que implica la actividad especial “Aprobación del Crédito por el Gerente de Área”, ¿Que se hace en este caso, si el modelo no incluye esa tarea?; lo mas probable es que se realice la tarea pero sea “obviada” en el flujo BPM (no se registre que se hizo), luego dicha actividad especial queda fuera del seguimiento, y control del proceso, y la información de control queda inconsistente, por ejemplo pareciera que la tarea previa o posterior demoro mas porque suma el tiempo de esta tarea especial.

En XtremeBPM se propone que cada proceso de negocio tenga una actividad genérica a la cual llamamos “Actividad Estereotipo”, la cual cualquier participante puede asignar en cualquier punto del flujo. Lo mínimo que tiene que tener esta actividad es:

§ Campo Estereotipo: campo que indica el tipo de actividad, en el ejemplo seria “Aprobación del Gerente”.

§ Descripción Actividad: campo que indica a grandes rasgos que se debe hacer para cumplir la actividad. Este lo define quien enviá la tarea.

§ Desarrollo u Observaciones: campo que indica el detalle de lo que se hizo, o las observaciones de su ejecución. Este lo define quien recibe y/o ejecuta la tarea.

Este concepto es parecido a los estereotipos en UML que permiten extender la metodología a componentes nuevos que no existen en los diagramas base.

Una ventaja esta en que como la actividad “estereotipo” esta dentro del proceso, entonces tiene acceso a los objetos de negocio del flujo, luego por ejemplo para la actividad “Aprobación del Gerente”, el Gerente tiene acceso a los datos de la “Solicitud de Crédito”, tal como cualquier otra actividad del flujo.

Además como cualquier otra actividad aparece en el historial, y en las distintas vistas de control, asegurando de esta forma el seguimiento de estas tareas extraordinarias.

Control y Seguimiento desde un Inicio.

La principal ventaja de XtremeBPM es que se cuenta desde un principio con el “Control y Seguimiento” del proceso de negocio, como BPM mantiene el historial del desarrollo de las actividades entonces en todo momento podemos saber por donde paso el flujo: quien hizo que actividad, cuando se demoro, y luego cual fue la siguiente actividad.

Como este enfoque toma todas las actividades del proceso, a diferencia de tomar solo una parte del proceso, no existen espacios vacíos en el seguimiento del proceso.

Los gráficos de monitoreo (BAM) también cumplen su funcionalidad, por ejemplo gráficos (de barra) que indiquen “Cantidad de Procesos por Actividad” o “Actividades que son Cuellos de Botella” son consistentes bajo esta solución “XtremeBPM”.

Flujos van Apareciendo

Lo primero es “aclarar” que este enfoque es un proceso de mejoramiento continuo, es decir, no se pretende que los procesos nunca tengan flujos (flechas), sino que solo como una forma de enfrentar el problema se implemente primero sin flujos, pero a medida que se va ejecutando el proceso se vayan implementando los flujos.

Y aquí hay otra ventaja de este enfoque; es que lo flujos comienzan a aparecer, no es necesario un análisis detallado de requerimientos, basta con ver algunos “historiales” de ejecución de los procesos para determinar los flujos mas comunes del proceso.

Por otro lado no necesariamente las actividades van a necesitar tener definido un flujo, en la realidad hay actividades que no van a necesitar nunca un orden o secuencia predeterminado, en estos casos bajo XtremeBPM no debería implementarse tampoco un flujo (las flechas).

Manejo de Errores de Asignación

El principal problema de que el flujo no este predefinido (no existan flechas) es que “por error o por mala intención” se asigne una tarea incorrectamente, o se salte alguna tarea.

“El Manejo de Estados y Restricciones de Entrada” prevén esta situación en la mayoría de los casos, pero puede haber excepciones donde no haya forma de controlar (todavía) el cumplimiento previo de actividades, o la asignación a la persona adecuada.

Pero esto hay que analizarlo desde el siguiente punto de vista; si actualmente no hay WorkFlow o proceso BPM implementado, tampoco se esta controlando este problema, y es más existe mayor “riesgo” que con XtremeBPM, porque por lo menos:

  • Con XtremeBPM podemos revisar el historial y queda evidenciado cualquier flujo erróneo, y eso los participantes del proceso lo saben.
  • Con XtremeBPM podemos saber si una persona tiene muchos procesos de negocio estancados.
  • En XtremeBPM las posibilidades están mas limitadas que en la realidad (sin WorkFlow); dentro del proceso de negocio solo se puede asignar tareas que corresponden al proceso, y asignar a participantes validos dentro del proceso, es decir, existen ciertas restricciones mínimas. Por ejemplo sin Workflow una persona puede enviar la “Solicitud de Crédito” por email a cualquier otra persona, y de cierta forma perderse este proceso, o lo que es peor aún llegar a la persona inadecuada.

También están los aspectos de seguridad manual como respaldo, por ejemplo, esta bien un ejecutivo se equivoco y asigno a otro ejecutivo para “Autorizar el Crédito”, y no al Supervisor, pero como la solicitud de crédito debe llevar al firma y timbre del supervisor , aquí hay otro resguardo de que el error no va a seguir curso.

En resumen hay que sopesar ventajas versus desventajas, y claramente son mayores las ventajas en tener todas las actividades en el modelo, y darle de forma efectiva seguimiento al proceso, que esperar a tener un flujo totalmente definido, o tener una parte pequeña del proceso implementada.

Seguridad versus Flexibilidad.

Ahora siempre va a haber casos donde la seguridad prime, donde no haya cabida a asignaciones erróneas, y donde este bien definido el rol que ejecuta una actividad. En este caso la actividad se asigna al rol determinado:

Supongamos que la actividad “Autorizar Crédito” solo lo puede hacer un supervisor, no existe otra posibilidad, entonces esta actividad se restringe al rol “Supervisor”, reduciendo así el riesgo de asignación a la persona inadecuada, pero por otro lado se pierde la flexibilidad o se hace mas compleja la solución, por ejemplo que hacemos con el “Ejecutivo Senior” de la pequeña Sucursal que no puede ser Supervisor, pero si “Autoriza Crédito” en su sucursal (hemos perdido flexibilidad en pro de la seguridad).

Modelo XTremeBPM

Según el principio de “Modelo centrado en las Actividades” , la siguiente es la implementación inicial del ejemplo “Proceso para Obtener Crédito de Consumo”:

Proceso de Negocio bajo XtremeBPM

Esta es la implementación sin flujos (con muy pocas flechas), pero donde en cada actividad se permite determinar cual es la próxima tarea, y a la persona que se asigna.

Se agrega una actividad inicial “Recibir Solicitud”, que es la actividad que permite dar el puntapié inicial en el flujo. Cuando llega un Cliente con una “Solicitud de Crédito”, es la actividad que realiza quien lo recibe, y que permite después poder asignar cualquier otra actividad válida del proceso.

Por “Participante Valido del proceso” se entiende que son todos los roles o usuarios validos en el proceso de “Otorgar un Crédito”, por ejemplo pueden ser ejecutivos , supervisor, o gerente de una sucursal.

En este caso la tarea “Autorizar Crédito” se restringe solo al “Supervisor” por prioridades de seguridad del proceso.

Se supone que en este modelo también contempla las principales actividades de los casos de excepción.

En un principio el orden de cómo se ejecutan las actividades “Verificar Patrimonio”, “Verificar Antecedentes”, “Verificar Deudas”, o “Avisar Rechazo” son irrelevantes, con el tiempo, y si es realmente necesario se van a comenzar a definir los distintos flujos (flechas), apoyados en el historial de ejecución.

Levantar la Interfaz Legada.

Si para los procesos interactivos existe una interfaz en los sistemas existentes (legados) XtremeBPM propone usarla directamente, es decir levantar la aplicación legada y saltar a la funcionalidad correspondiente, de forma tal de aprovechar la interfaz de usuario existente.

Esta claro que esto supone la intervención del sistema legado, y existirán casos en que no se puede hacer.

Pero esta solución es bastante manejable en sistemas Web (legados) donde se puede construir un Portlet, sección (IFrame) que acceda directamente a la funcionalidad Web (legada).

Recordar que esta es la solución para implementar de forma mas inmediata un proceso de negocio, pero con el tiempo se debe ir pasando las interfaces legadas a una interfaz propia de BPM (interfaz única), como parte del mejoramiento continuo de un proceso de negocio.

Servicio de Avance BPM.

Para evitar el problema de doble tarea (hacer actividad interactiva y además registrar avance en BPM) en el caso anterior, se propone intervenir el sistema legado para que llame a un “Servicio de Avance BPM” una vez completada la funcionalidad, para que automáticamente el Flujo avance a la siguiente actividad.

Generalmente existen conectores en las soluciones BPMS para realizar esto.

Generadores de Servicios, o Adaptadores de Servicios para Sistemas Legados.

Una forma de tener antes los Servicios SOA necesarios para implementar el proceso de negocio, es utilizar generadores de código, o adaptadores para poder componentizar los sistemas legados.

En algunos BPMS se provee de dichas herramientas, en otras ocasiones puede convenir incluso desarrollarlos.

Por ejemplo si nuestro sistema legado tiene gran parte de su funcionalidad de negocio en “Stored Procedures”, quizás conviene utilizar un generador de código o adaptador que permita darle una cara Java al procedimiento, para que sea más fácil implementar un WebService bajo los estándares SOA. Hay que recalcar que no se recomienda una herramienta que transforme un “Stored Procedure” directamente en un WebService, por que lo mas probable es que ese WebService no cumpla ninguno de los principios SOA de reusabilidad, y de ser un servicio de negocio, porque difícilmente el Stored Procedure cumple dichos principios SOA, luego queda como resultado un servicio orientado a la base de datos, mas que un servicio SOA.

Desafíos Extremos para las Suite BPM (BPMS) Actuales

El futuro de XtremeBPM es que las suites (BPMS)provean las herramientas necesarias para facilitar este enfoque, es decir, que las herramientas BPM en un futuro provean ciertas características que permitan acortar el ciclo para alcanzar el proceso de negocio totalmente implementado.

Generador de Flujos.

Una herramienta bastante útil seria que los BPMS propusieran los flujos, basados en el historial de ejecución de un proceso..

Es decir se implementa con XtremeBPM un proceso basado solamente en las actividades (centrado en actividades), y a medida que se va ejecutando en producción, el BPM determina los flujos (la secuencia de actividades) mas comunes, gráficamente hablando el BPM determina las flechas entre las actividades.

Luego mediante un asistente grafico (Wizard) se fijan los flujos, es decir, se determina cual es el flujo definitivo.

Generador de Roles.

Lo mismo se puede aplicar a los roles, primero se deja la libertad de que cualquier usuario valido del procesos realice la actividad, y después de acuerdo al historial de ejecución se ofrece la lista de personas o roles que ejecutan comúnmente dicha actividad.

Robots para Levantar Sistema Legados.

Las suites BPM (BPMS) podrían incluir robots que permitieran grabar secuencias que permitieran levantar funcionalidades de los sistemas legados, parecidos a los robots para ejecutar test de pruebas. Estos mismos robots deben incluir la capacidad para evaluar el resultado de la funcionalidad (legada), y poder registrar el avance en el flujo BPM.

Manejo de Actividades Estereotipo.

La herramientas BPM deberán contemplar el manejo de las actividades estereotipo, por ejemplo deberían incluirse por defecto en la implementación de cualquier proceso. Y los módulos de seguimiento, control y monitoreo deberían también contemplarlas como actividades tipo, por ejemplo en un grafico de barra (BAM) debería aparecer una barra por cada estereotipo.

Manejo de Asignación de Tareas y Restricciones de Entrada.

Las herramientas BPMS deberán contemplar el manejo por defecto de que en una tarea se pueda asignar la siguiente actividad, y quien la realiza, también se debe manejar las condiciones de entrada, y automáticamente si no se cumplen devolver el flujo al origen (actividad y persona anterior).

Asignación de Roles y Personas Especificas a una Actividad.

Algunas herramientas BPMS de cierta forma lo ofrecen actualmente, que es la posibilidad de asignar roles a una actividad, pero que se puedan ademas incluir y excluir personas especificas, de forma de contemplar los casos excepcionales.

Registered at RegisteredCommons.org

Xtreme BPM
was created by Luis Alberto Espinoza Bustamante
on 2007-11-12.
License: http://creativecommons.org/licenses/by-nc-nd/2.0/cl/ .
Description: Design and Development Principles for BPM and tools definitions

Oct 17

Generalmente cuando se realiza una consulta a una base de datos se traen “todos” los registros, lo cual funciona con conjuntos de tamaño razonable, pero con mas de 3000 registros ya puede traer problemas de performance, o de memoria (Memory Fault).

Lo mejor en estos caso es paginar, y lo bueno es que JDBC proporciona ciertas facilidades, como la función para saltar a un registro determinado “absolute()”. Y siendo JDBC funciona para la mayoria de las bases de datos: Oracle, MySQL, SyBase IQ, DB2.

Aquí hay un ejemplo completo, se le entrega el numero de pagina, y la cantidad de filas, y retorna un arreglo con los registros. Esta implementación mejora considerablemente el desempeño (performance) de la consulta (query), debido que el conjunto resultado (result set) que se recorre, y maneja es mucho menor.

El ejemplo tambien sirve para ver como se debe hacer una consulta a la base de datos en Java, con JDBC, ya que implementa otras recomendaciones comunes, como el uso de “prepared statement”, que tambien optimiza la ejecución de las consultas, precompilando el query en la Base de Datos, y manteniendolo en “cache” para futuras ejecuciones (donde solo cambia los parametros de busqueda).

public ArrayList seleccionaPaginado(Connection conexionX, int nroPaginaX, int cantidadFilasX)throws Exception{

	  String sqlX;
	  ArrayList arreglo = new ArrayList();

	  int filaActual = 0;
	  if (nroPaginaX > 0) {
		  filaActual = (nroPaginaX - 1) * cantidadFilasX;
	  }

	  sqlX = "select * from EJEMPLO";
	  arreglo.clear();
	  String codigoX;
	  String tituloX;

	  try{
		  PreparedStatement pStatemenX = conexionX.prepareStatement(sqlX,
				  ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
		  ResultSet rSetX = pStatemenX.executeQuery();

		  if (filaActual>0){
			  boolean loHizo = rSetX.absolute(filaActual);
		  }   

		  int i=0;
		  while (rSetX.next() && i < cantidadFilasX) {
			  codigoX = rSetX.getString("CODIGO");
			  tituloX = rSetX.getString("TITULO");

			  arreglo.add(codigoX+", "+tituloX);
			  i++;
		  }

		  rSetX.close();
	  }catch (Exception e){
		  System.out.println(e.toString());
		  throw e;
	  }

	  return arreglo;
}
Sep 25

FrameWork es un concepto sumamente genérico, se refiere a “ambiente de trabajo, y ejecución”, por ejemplo “.Net” es considerado un “framework” para desarrollar aplicaciones (Aplicaciones sobre Windows). En general los framework son soluciones completas que contemplan herramientas de apoyo a la construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de ejecución).

Siguiendo con el ejemplo: “.Net” ofrece el “Visual Studio .net” (ambiente construcción o desarrollo) que le permite a lo desarrolladores construir aplicaciones, y su motor es el “.Net framework” que permite ejecutar dichas aplicaciones. El motor de “.net” es una anexo al sistema operativo (un componente que se instala sobre el sistema operativo), y que ahora viene incluido en la mayoría de los sistema operativos de Microsoft.

FrameWork puede ser algo tan grande como “.NET” o Java (también es un framework), pero también el concepto se aplica a ámbitos mas específicos, por ejemplo; dentro de Java en el ámbito especifico de aplicaciones Web tenemos los framework: Struts, “Java Server Faces”, o Spring. Estos frameworks de Java en la practica son conjuntos de librerías (API’s) para desarrollar aplicaciones Web , más librerías para su ejecución (o motor), y más un conjunto de herramientas para facilitar esta tarea (debuggers, ambientes de desarrollo como Eclipse, etc).

Otros ejemplos de frameworks para ámbitos específicos:

  • Ámbito: Webservices => FrameWork: Axis.
  • Ámbito: Interfaz de Usuario Web Dinámica => FrameWork: Ajax – DWR
  • Ambito: Procesos de Negocio => BPMS (WebSphere, AquaLogic, o Oracle)

Por eso antes se debe acotar que ámbito se desea “apoyar” con un FrameWork.

El ámbito más común es el de desarrollo de aplicaciones o sistemas (genérico), bajo el cual algunos buenos ejemplos de Framework sobre Java son:

  • Spring en combinación con Eclipse (eclipse es el equivalente a Visual Studio .NET pero para Java)
  • Struts en combinación con Eclipse.

Las anteriores se recomiendan porque son las mas “estándares”, es decir los más usados, y por lo tanto se encuentra un montón de documentación e información al respecto, además si se buscan proveedores que manejen esas tecnologías, se van a poder encontrar fácilmente, y por ser tecnologías que están en “boga” también existen mas herramientas e implementaciones, que van a facilitar el desarrollo de aplicaciones. Por otro lado son tecnologías abiertas, es decir. funcionan prácticamente sobre cualquiera HW y Sistema Operativo, y en esta caso si hablamos de aplicaciones Web, funcionan sobre cualquier Servidor de Aplicaciones conocido (IBM WebSphere, BEA WebLogic, o JBoss). Y en cuanto a costos prácticamente no hay costos de licencias: Spring, Struts, y Eclipse no tienen costos de licencias.

Y si no se maneja Java, y se viene de la escuela de Visual Basic la solución es

  • Net en combinación con “Visual Studio .net”

Referencias:

Ago 22

Un requqerimiento común en Java, y XML, es realizar un traspaso de un string XML al objeto XML estandar que es DOM.

El siguiente ejemplo muestra como pasar desde un objeto Document (org.w3c.dom.Document) al String XML respectivo, y viceversa.

    public String DOM2String(Document doc)
    {
        TransformerFactory transformerFactory =TransformerFactory.newInstance();
        Transformer transformer = null;
        try{
            transformer = transformerFactory.newTransformer();
        }catch (javax.xml.transform.TransformerConfigurationException error){
            coderror=123;
            msgerror=error.getMessage();
            return null;
        }

        Source source = new DOMSource(doc);

        StringWriter writer = new StringWriter();
        Result result = new StreamResult(writer);
        try{
            transformer.transform(source,result);
        }catch (javax.xml.transform.TransformerException error){
            coderror=123;
            msgerror=error.getMessage();
            return null;
        }

        String s = writer.toString();
        return s;
    }

    public Document string2DOM(String s)
    {
        Document tmpX=null;
        DocumentBuilder builder = null;
        try{
            builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
        }catch(javax.xml.parsers.ParserConfigurationException error){
            coderror=10;
            msgerror="Error crando factory String2DOM "+error.getMessage();
            return null;
        }
        try{
            tmpX=builder.parse(new ByteArrayInputStream(s.getBytes()));
        }catch(org.xml.sax.SAXException error){
            coderror=10;
            msgerror="Error parseo SAX String2DOM "+error.getMessage();
            return null;
        }catch(IOException error){
            coderror=10;
            msgerror="Error generando Bytes String2DOM "+error.getMessage();
            return null;
        }
        return tmpX;
    }
Ago 22

BEA AquaLogic BPMS (ex Fuego) es una suite BPM (BPMS) que permite crear, ejecutar y optimizar procesos de negocio. Esta suite permite la colaboración entre las áreas de negocio, y el área de TI (Tecnologías de la Información), para automatizar y optimizar los procesos del negocio, impulsando eficiencia y agilidad, mientras se reducen los costos, y se mejora la calidad.

Los analistas de negocio pueden diseñar y correr simulaciones de un proceso completo sin necesidad de apoyo de TI, y solo cuando el proceso abarca las especificaciones de negocio, es traspasado a TI para que implemente e integre los componentes necesarios para implementar el proceso.

Las interfaces de usuario para integrar a los participantes en el proceso (WorkFlow) son generadas automáticamente, y además se provee Portlets (componentes de presentación) estándar para el ambiente de ejecución.

Datos en tiempo real, e históricos son recolectados por el servidor, y están disponibles en dashboards (paneles de control), y reportes, que permiten realizar una optimización continua de los procesos de negocio, y hacer seguimiento de las actividades del negocio.

BEA AquaLogic BPMS es un componente critico para las empresas que desean implementar SOA, permite la orquestación de servicios, e integrar a las personas que necesitan interactuar con dichos servicios. Esta solución ofrece beneficios tangibles para SOA en la línea del negocio, a través de la creación, ejecución, y optimización de los procesos de negocio con la participación de los usuarios de negocio.

BEA AquaLogic BPMS también se ajusta a implementaciones que no involucren aun una infraestructura de servicios, por ejemplo se pueden crear solo WorkFlows (solo actividades humanas) que permiten controlar los procesos actuales de una empresa y optimizarlos, esta solución además permite integrarse fácilmente a sistemas existentes a través de un conjunto de asistentes guiados (Wizards), sin necesidad de crear servicios, por ejemplo integración directa con base de datos (querys), o stored procedures.

BEA AquaLogic Designer.

Es el ambiente de diseño para los analistas de negocio, permite la creación de cualquier tipo de proceso haciendo drag&drop (arrastre) de los elementos de procesos en la “áreas de rol” (swimlanes) correspondientes.

BEA AquaLogic BPMS

Este modulo soporta estándares como BPEL, y UML, y permite con un solo clic hacer switch en la forma de visualización del modelo de un estándar a otro. Se puede modelar y simular un procesos sin necesidad de programar, ni del departamento de TI, ni tampoco necesita que el proceso este implementado en producción, ni de estar conectado al servidor de procesos.

BEA AquaLogic BPM Studio.

Es el ambiente de trabajo de los desarrolladores de procesos, incluye todo lo del BPM Designer, sumando las herramientas necesarias para que el desarrollador cree los componentes de negocio, se integre a los sistemas existentes, y ensamble la interfaz de usuario para la interacción de las personas participantes. Esta herramienta soporta interfaces estándares como J2ee, .NET, WebServices, XML, COM, SQL, y más.

BEA AquaLogic BPM Enterprise Server.

Orquesta todos los procesos y sus recursos; personas, organizaciones, sistemas, gestionando la secuencia y reglas de negocio definidas, y auditando cada paso para asegurar la fluidez en la ejecución del proceso. El servidor ejecuta los procesos diseñados en el BPM Studio, así como cualquier procesos escrito en BPEL.

BEA AquaLogic BPM Workspace.

Es parte del BPM Enterprise Server, y es el ambiente de trabajo para los participantes del procesos de negocio. Las actividades de negocio que requieren de interacción de personas son automáticamente publicadas con una interfaz Web, sin necesidad de diseño Web manual, o programación. Los participantes tienen una vista de sus tareas pendientes y se les ofrece un medio para ejecutar dichas tareas. Los componentes de presentación de AquaLogic pueden ser expuestos como Portlets estándar (JSR168) lo que permite integrarlos sin problemas en cualquier solución de Portal como WebSphere , JBoss, y Weblogic Portal.

BEA AquaLogic BPM DashBoard (BAM).

El verdadero valor de SOA, y BPMS, es la visibilidad que se provee de la operaciones de negocio. AquaLogic BPM permite ver información en tiempo real e histórica de las actividades, que sirve para monitorear la performance de los procesos de negocio, y su estado , a través de indicadores de performance y SLA (Service Level Agreements, niveles de servicio a cumplir).