Diferencia entre revisiones de «Oracle BPM»

Revisión del 21:17 3 nov 2010

BPM, acrónimo de Business Process Management, en español Gestión de Procesos de Negocio, se identifica como uno de los tópicos más escuchados en lo que respecta a tecnologías aplicadas al entorno empresarial. Constituye una filosofía que acompañada de tecnología permite gestionar de forma integral la organización, administrando mejor la carga de trabajo entre las diferentes áreas.

¿ Qué es Oracle BPM ? Es un entorno de ejecución de procesos de negocios de empresas y está compuesto de diferentes aplicaciones y servicios que pueden ser instalados y configurados en diferentes topologías a manejar diferentes escenarios, soportando diferentes usos.

Un entorno BPM es la infraestructura técnica en la cuál se ejecutan procesos de negocio. Definimos entorno BPM como todos los componentes ejecutables (aplicaciones y servicios) que trabajan juntos para permitir la ejecución de procesos de negocio.

Infraestructura técnica

Algunos componentes deben estar siempre presente para el entorno de ejecución, mientras que otros dependen de la activación de características o requisitos externos. Oracle BPM soporta una variada cpombinación de estos componentes, que van desde muy sencillos y pequeños a toda la organización.

Los componentes que tienen que estar presentes:

• por lo menos un motor BPM con su correpondiente esquema de base de datos
• un directorio en el repositorio que contiene el esquema de base de datos
• la aplicación BPM, vista de usuario final
• la aplicación BPM, vista administrador

Los componentes opcionales:

• servidor LDAP
• más motores BPM
• un servicio de monitoreo de procesos
• múltiples áreas de trabajo de BPM
• clientes JAVA

Ejemplos de entornos Oracle BPM

Los siguientes gráficos proveen una vista de alto nivel de diferentes partes. Estos gráficos muestran 3 tipos de artefactos: cajas, puntos, y registros.

• Las cajas representan aplicaciones y servicios en el entorno.
• Los puntos representan los servicios expuestos por las aplicaciones (cajas).
• Las flechas representan una conexion entre una aplicación y un servicio expuesto por otro.

Ejemplo 1: ilustra la arquitectura generada con el wizard de Oracle BPM Enterprise Standalone

Ejemplo 2: ilustra la arquitectura generada con el wizard de Oracle BPM Enterprise for WebLogic

Ejemplo 3: entorno clusterizado a través de Oracle BPM Enterprise for WebLogic

Representea una topología escalable, típicamente usada en instalaciones grandes.

Componentes de un entorno BPM

Esta sección enfoca sobre las cajas presentadas en los gráficos de arriba. Las cajas representan la ejecución de aplicaciones como parte del entorno. Consideramos aplicaciones a procesos Java standalone, servidores web y de aplicaciones, aplicaciones web, aplicaciones JEE (EARs), servidores de base de datos, servidores LDAP.

Desde esta perspectiva, los componentes de un entorno BPM se pueden dividir en 3 grupos: BPM Core, BPM Clients y servicios de soporte. Cada entorno BPM contendrá componenetes en cada uno de estos grupos.

BPM Core

Hay 2 componentes principales: el motor BPM y el servicio de monitoreo de procesos.

Motor BPM

Es un componente que ejecuta procesos de negocio. El motor BPM es el elemento core de cada entorno BPM desde diferentes puntos de vista:

• desde un punto de vista lógico, es el responsable de crear, almacenar y mover alrededor de instancias de procesos desplegados en él
• desde un punto de vista de ejecución. un motor BPM es un servicio que ejecuta tareas de procesos que son definidas por procesos de BPM como actividades de procesos. Las ejecuciones pueden ser disparadas externamente por clientes o internamentes en el 'background'
• desde un punto de vista físico, el motor de BPM toma diferentes formas dependiendo de los productos seleccionados. Es un proceso java standalone en el caso de un enterprise standalone. Es una aplicación JEE en el caso de enterprise para weblogic y websphere

Hay muchos parámetros de configuración con los cuales adaptar el comportamiento de motores BPM, para cosas como hilos, puertos, conexiones a base de datos.

¿ Dónde definimos el motor BPM ?

Los motores BPM son creados en un directorio BPM. Esto es un repositorio metadata con todas las definiciones, incluyendo motores, organización de procesos y recursos. Cuando un motor comienza a ejecutar, este lee los parámetros del directorio BPM, y los procesos desplegados. Una vez que el motor es creado, este representa la definición lógica.

Motor BPM como una aplicación J2EE

El motor BPM J2EE ejecuta como una aplicación ear desplegada en un contenedor J2EE (WebLogic o WebSphere). El ear contiene EJBs, MDBs y Servlets que juntos conforman el motor BPM. Un archivo ear debe ser generado desde el proceso BPM administrador para cada motor BPM definido. Este archivo ear está desplegado en un servidor J2EE o cluster. Desplegando en un cluster, muchos servidores ejecutan motores BPM concurrentemente. Algún cluster puede responder el pedido de un proceso desplegado en el motor BPM.

Motor BPM como un proceso Java

El motor BPM sin dependencias ejectuta como un proceso java que se realiza en segundo plano y no requiere J2EE o contenedor web. Solamente un proceso Java ejecuta el motor, lo que se llama motor activo. Uno o más procesos Java pueden permanecer en modo pausa como soporte. Cuando el motor activo deja de responder uno de los motores pasivos toma el rol de motor activo. El motor BPM sin dependencias tiene sus propios hilos, conexiones, gestión de pedidos, y es altamente configurable.

Servicios expuestos del motor BPM

El motor de BPM expone varios servicios a través de los cuales puede comunicarse con clientes externos. Estas interfaces contienen operaciones a manipular, consultas, y crean instancias de procesos desplegados en el motor BPM. Estos servicios son representados por los puntos en las figuras de arriba.

Motores BPM y procesos de negocio

Los procesos de negocio suelen interactuar entre sí, por ejemplo, para dar inicio a un sub-proceso, o notificar a otro proceso de algún evento.

Desde una perspectiva de diseño, dos procesos que interactúan no es necesario que ejecuten en el mismo motor de BPM. El conocimiento y comunicación entre los motores BPM es manejado automáticamente por el motor. Sin embargo, en algunos casos es necesario configurar la ubicación del motor BPM.

Desde una perspectiva de cliente, diferentes versiones del mismo proceso pueden ser desplegados en diferentes motores. Clientes BPM conectan al directorio BPM, then conocen motores corriendo los procesos que les interesa y conectan a esos motores.

En la mayoria de ambientes BPM el total de procesos de negocio ejecutan en un motor BPM. En algunos casos, es necesario tener muchos motores ejecutando en el mismo ambiente BPM.

¿ Cuántos motores BPM en tu ambiente ?

Motores BPM son desplegados para procesos de negocio. Los procesos pueden ser desplegados en algún motor BPM definido en tu entorno BPM.

Desde el punto de vista de ejecución, un proceso es desplegado en un motor BPM, este no puede ser cambiado a otro, al menos que despliegues una nueva versión del proceso, uno activo y el otro deprecado.

Desde el punto de vista físico, los protocolos de comunicación a ser usado entre los motores BPM dependen de su tipo (independiente o JEE) y si los motores son definidos en el mismo. En el caso de motores JEE, los clientes BPM deben configurarse con las propiedades del motor BPM.

Hay dos posibles casos donde los motores BPM definidos en diferentes directorios BPM interactuan. En el primer caso, tenemos comunicación B2B entre diferentes organizaciones. Y la interacción es limitada a la comunicación interprocesos (IPC).

En el segundo caso, una organización muy grande tiene diferentes directorios BPM para diferentes divisiones o areas funcionales, más claro que centralizar los procesos en un único directorio BPM. En este escenario los usuarios finales deben ver las instancias de procesos ejecutando en motores BPM definidos en diferentes directorios BPM. Esto puede ser archivado por configuración de clientes BPM. El cliente BPM es el que agrega la información desde los motores y presenta una vista unificada al usuario.

Servicio de monitoreo de procesos

El Servicio de Control de Procesos es responsable de la construcción de la información global de las ejecuciones de instancias de procesos y métricas.

Desde el punto de vista lógico, el servicio busca nuevos eventos de instancias de procesos (creaciones, ejecuciones, terminaciones) que han ocurrido desde la última ejecución y transforma los acontecimientos en filas agregadas al tablero.

Desde el punto de vista del tiempo de ejecución, cada entorno tiene su propia instancia del servicio de monitore de procesos. Cada instancia consulta el esquema de base de datos de tiempo de ejecución de cada motor BPM definido en el directorio BPM en busca de nuevos eventos, que luego serán agregados.

Desde un punto de vista físico, el servicio funciona de forma continua como una JVM independiente en segundo plano, y es independiente del tipo de motor de BPM (Independiente, WebLogic, WebSphere) y si los motores se detienen o se inicia. El servicio no tiene interfaz de usuario y sólo lee los esquemas de base de datos del motor BPM, y escribe en los esquemas de base de datos específicos. Ya que se ejecuta independiente, se conecta a bases de datos utilizando drivers JDBC, haciendo conexiones directas, y no puede utilizar datasources de JEE.

El Servicio de Control de Procesos tiene un propósito muy específico y crítico. Sin esto, no recibe información precisa para mostrar en el tablero de control de los procesos. En algunos casos, cuando el servicio no ha estado funcionando durante mucho tiempo, debe leer y agregar muchos eventos, considerando tiempo y recursos considerables.

BPM Clients

Los clientes BPM son aplicaciones que interactuan con los procesos de negocio que ejecutan en los motores BPM.

La mayoría de los clientes de BPM se conectan a los motores de BPM a través de los servicios expuestos por el motor. Pero hay otro tipo de cliente BPM: los que interactúan con los procesos de negocio a través de recursos externos, como una cola JMS, un sistema de archivos, o una tabla de base de datos. En este caso es el proceso de negocio en sí - como parte de su definición - la que establece una interacción empujando y tirando de la información a través de estos recursos, la definición de un contrato con la entidad externa para intercambiar información. Desde el punto de vista de que el servicio de motores BPM utiliza el cliente para conectarse, tenemos dos grandes grupos: los clientes PAPI, que utilizan el servicio de proceso interno, y los clientes de servicios Web.

Cliente PAPI

Es el proceso API y refiere a la API de Java que este cliente usa para interactuar con el motor BPM. PAPI está embebido en muchas aplicaciones web. Realiza funciones críticas desde el punto de vista de usuario final. Está configurado para autenticar y autorizar usuarios finales, encuentra los procesos disponibles en el directorio BPM, conecta a los motores BPM que ejecutan dichos procesos, y retorna información a los usuarios finales. Es la única API de JAVA para la interacción de procesos.

Características de ejecución del cliente PAPI

PAPI está diseñado para soportar un portal de procesos interactivo. Algunas optimizaciones se realizaron para la perfomance de cliente PAPI, incluyendo cache en memoria de información acerca de procesos.

Un cliente PAPI requiere conectividad al directorio y al motor.

Los clientes PAPI no hablan entre si ni acceden a recursos utilizados por los procesos de negocio.

Los clientes PAPI pueden ejecutarse como procesos independientes de JAVA. Cada uno requiere una copia de la memoria caché y exige mucha memoria.

Area de trabajo BPM

El "workspace" o area de trabajo BPM es lo más importante en la aplicación de usuario final. El area de trabajo BPM es a los procesos de negocio lo que el Outlook es al mail: la principal aplicación de interacción. El area de trabajo BPM es un cliente PAPI, y tiene funcionalidad adicional que es importante entender. Desde la perspectiva de la topología, es una práctica saludable tener áreas de trabajo BPM siempre disponible. El area de trabajo BPM provee un montón de funcionalidad sobre PAPI: soporte a flujos de pantallas, tableros, diseños de páginas, etc. La aplicación también permite adaptar la interfaz de usuario a través de hojas de estilos y otras configuraciones. Autenticación y SSO (Single Sign On) tienen importantes consideraciones en el área de trabajo de BPM. El área de trabajo BPM puede confiar en el servidor web (Tomcat, Weblogic, etc) para autenticar y conectar a usuarios remotos.

Clientes Web Service (WS)

Pueden elegirse clientes WS entre dos servicios disponibles: los servicios "Process-WS" expuestos por el motor BPM y la aplicación "PAPI-WS".

El servicio "Process-WS" expone ciertas actividades del proceso de negocio como operaciones de WS. En particular, puede ser usado para crear nuevas instancias de procesos y enviar notificaciones a las instancias de procesos existentes. Las actividades de los procesos de negocio tienen que ser marcadas explícitamente como expuestas para ser agregadas al servicio. Técnicamente, este servicio es provisto por el mismo motor BPM. Cuando levanta el motor, lee todos los procesos definidos y busca cuales actividades están marcadas. La interfaz expuesta por el servicio es definida por el parámetro las actividades expuestas (creación y espera notificación), entonces la interfaz del servicio está directamente relacionada a la definición de los procesos.

El servicio "PAPI-WS" expone la mayoría de las operaciones de PAPI a través de una interfaz SOA. Este servicio está separado de la aplicación web PAPI-WS. Esta aplicación se despliega como cualquier otra aplicación web, y simula un servicio web alrededor de la funcionalidad PAPI. El servicio "PAPI-WS" es un cliente PAPI porque usa la API. La interfaz expuesta por el servicio es similar a la API, y esta es independiente de los procesos desplegados. PAPI-WS puede interactuar con cualquier proceso desplegado en el entorno.

Clientes de administracion

Esta categoría incluye el proceso administrador de BPM, la herramienta principal de administración junto con el área de trabajo de BPM y la vista de archivos. Estas aplicaciones web no son usadas para tareas diarias, y son importantes en la configuración y administración del entorno.

El proceso administrador proporciona configuración y administración para la organización, motores, recursos externos, procesos de negocio, y es usado para desplegar procesos de negocio en los motores BPM. Adicionalmente a la configuración técnica de la conexion del directorio BPM, el proceso administrador de BPM también maneja la configuración del resto del entorno.

Desde un punto de vista técnico, el proceso administrador de BPM requiere conectividad al directorio y a motores BPM en orden al monitoreo y control de los mismos (parar, comenzar). El proceso administrador BPM también puede crear el esquema de base de datos requerido por el motor BPM.

La aplicación administradora del área de trabajo de BPM es la responsable de configurar las vistas del área de trabajo (PAPI) y presentar la disponibilidad a los usuarios del área de trabajo. Utilizado por los dueños del negocio o administradores, quienes quieren proporcionar adaptaciones, vistas basadas en roles y presentaciones a usuarios. Por ejemplo, puede proporcionar una vista de seguimiento para los gestores y una cola de trabajo priorizada para los roles no gerenciales.

El visualizador de archivos BPM es una aplicación web que es usada para ver la información archivada de instancias de procesos. Esta información se saca de los motores BPM y se introduce en los archivos de base de datos.

Clasificación por tipo de aplicación

Hay varios tipos de procesos clientes, incluyendo aplicaciones de usuario final y sistemas backend. Las aplicaciones de usuario final pueden ser parte del producto, por ejemplo, área de trabajo BPM. La mayoría de los entornos tendrá al menos una aplicación de usuario final con la que los usuarios del proceso interctúan con el sitema. La aplicación a ser usada está basada en decisiones de diseño tomadas por el equipo de desrrollo. Estas aplicaciones deben ser comunicadas con el motor BPM en orden a acceder a la información de los procesos e invocar operaciones de los procesos.

¿ Cuántos clientes BPM en tu entorno ?

NO hay restricciones en el número y tipo de clientes BPM trabajando en un entorno BPM. Estas decisiones están basadas en la arquitectura del entorno. La mayoría de los entornos usan áreas de trabajo BPM, mientras que otros pueden optar por construir su propia interfaz de usuario, ya sea a través del PAPI o servicios web. Una tercera opción es escribir los servicios backend que llevan a cabo operaciones específicas en los procesos, como la creación de una instancia cuando llega un mensaje en una cola. Un punto de interés en estos entornos distribuidos es la sincronización de información a través de diferentes componentes. Por ejemplo, si una instancia de proceso está actualizada por una tarea ejecutada en el motor BPM, el estado actualizado de la instancia del proceso debe estar propagado a cualquier cliente PAPI que pueda estar escuchando para actualizaciones. Otro ejemplo es que si un nuevo proceso está desplegado, este debería aparecer inmediatamente en el área de trabajo de BPM y estar disponible para usar. La frecuencia y método de actualización de los diferentes componentes del entorno son consideraciones importantes en los cambios posibles de las propiedades del entorno.

Servicios de soporte

Un número de servicios de soporte son requeridos para el entorno BPM, incluyendo base de datos, LDAPs y servidores web y J2EE. Los requerimientos de servicio específico dependen de la configuración, topología, y el motor BPM.

Base de datos

Toda la configuración e información de ejecución se almacena en base de datos. En sistemas de archivos del servidor, se almacenan los archivos de log, cache. La BPM de Oracle requiere un esquema separado de base de datos por cada función específica:

• Requerido por cada directorio BPM: metadata
• Requerido por cada motor BPM: información de ejecución

Conexión a base de datos

Hay 2 maneras para que una aplicación BPM pueda obtener conexión a la base de datos: directamente, via los drivers de JDBC o usando datasources de J2EE. Las aplicaciones independientes como el administrador de BPM, el servicio de monitoreo de procesos y el motor independiente siempre usan los drivers JDBC.

Servidores de aplicaciones J2EE

Los servidores de aplicaciones pueden ser usados como contenedores para motores BPM y/o clientes BPM (área de trabajo BPM, por ejemplo). Cualquier combinación es soportado, asumiendo la configuración correspondiente. Por ejemplo: un área de trabajo BPM corriendo en Weblogic puede ser conectada a un motor BPM independiente. Un cliente java PAPI independiente puede ser conectado a un motor BPM desplegado en Weblogic o WebSphere, motores BPM siempre ejecutan como una aplicación J2EE instalada en un servidor o un clúster.

Recursos J2EE usados por el motor BPM

Los motores BPM que ejecutan en un servidor de aplicaciones J2EE utilizan datasources para acceder al esquema del directoio y motor. Adicionalmente a estos esquemas requeridos, cada motor BPM requiere dos recursos de mensajeria: una cola y un topic. Estos recursos JMS son necesarios para archivar funcionalidad que el motor BPM independiente puede implementar sin ellos. Los servidores de aplicación no proporcionan un framework para las ejecuciones en segunod plano, entonces las colas JMS son usadas como disparadores de eventos en segundo plano con un MDB. El motor BPM genera un mensaje cuando una tarea tiene que ejecutar. El MDB levanta el mensaje y ejecuta la tarea. El topic JMS se usa para enviar información a los clientes PAPI. Los motores BPM necesitan una forma de propagar los cambios a todos los clientes PAPI, y estos clientes esperan mensajes en estos topicos. El motor BPM coloca un mensaje en el topic cuando hay noticias para publicar, y los clientes leen los mensajes y actualizan la memoria interna. Entonces, el motor BPM es el publicador y los clientes PAPI son los suscriptores.

Portal web: centro de integracion web, portal weblogic

La BPM de Oracle está integrada con portales en diferentes formas. Algunas aplicaciones web de BPM, área de trabajo BPM particulares, pueden ser navegadas a través del centro de integración web (WCI) o del portal weblogic (WLP). Otra alternatiba es construir portles, usando PAPI. Este último caso no es diferente de cualquiere adaptación de una aplicación PAPI.

Desde el punto de vista físico, el área de trabajo de BPM ejecuta separado de JVM, tipicamente se construye en un servidor Tomcat, y se comunica con WCI remotamente. Para la integración del directorio BPM, la información del WCI es accedida de la misma manera que con cualquier proveedor LDAP.

Portal weblogic de integracion (WLP)

La integración con este portal se logra mediante la creación de un portal de aplicaciones que incluye un área de trabajo BPM de portlets, además de todas las librerías del cliente PAPI. Esta aplicación se instala en WLP, y de ese modo se incorpora en el portal.

Desde el punto de vista físico, el área de trabajo de BPM del portal de aplicaciones ejecuta sobre el proceso java WLP, de la misma forma que el área de trabajo BPM de las aplicaciones web que ejecutan en Tomcat o Weblogic.

LDAPs

Son usados como fuente de información de la organización, específicamente usuarios, unidades organizacionales y grupos. Esta integración es muy flexible y configurable.

Integración técnica

Desde un punto de vista técnico, LDAP se convierte en parte de los metadatos del directorio, por lo que cualquier aplicación que requiere acceso al directorio BPM (por ejemplo, los motores BPM, los clientes PAPI, el proceso administrador). Dado que el acceso a LDAP es de sólo lectura, se utiliza el acceso anónimo. No obstante, puede configurarse la conexión segura y la autenticación. Generalmente, las conexiones LDAP se utilizan a través de un pool para mejorar el rendimiento, y la autenticación se utiliza con usuario/contraseña que proporciona LDAP. Luego, el proceso de autorización se maneja con el esquema de directorio BPM.

Integración funcional

BPM define usuarios, grupos y unidades de la organización en una estructura única y bien definida. Esto difiere de cómo muchas organizaciones definen los conceptos. Por ejemplo, Oracle BPM definie que un usuario solo puede pertenecer a una unidad de organización, asigna funciones a los usuarios y grupos, mientras que algunas organizaciones podrían asignar funciones a la unidad organizativa. Es importante entender que en todos los casos la estructura LDAP tiene que estar mapeada con el modelo de organización de la BPM.

Servicios requeridos por el proceso de negocio

Si tus procesos de negocio integran con otros sistemas (web service, colas, etc), estos se convierten en parte de tu entorno BPM y son necesarios para que tus procesos ejecuten. La configuración de estos recursos se realiza sobre todo en el proceso administrador de BPM.

Servicios provistos por componentes BPM

El proveedor de servicios más importante es el motor BPM. Cada operación instancia de proceso se produce en el motor de BPM y la dispara automáticamente el motor, o externamente un cliente BPM. El principal servicio expuesto por el motor BPM es el servicio de procesos interno. Este servicio es usado por PAPI para interactuar con el motor. Cada cliente PAPI usa este servicio para consultar e invocar instancias del proceso.

Servicio de proceso del motor BPM

Desde el punto de vista lógico, el servicio de proceso del motor BPM expone una interfaz a través de diferentes protocolos:

• protocolo Java RMI, si es una implementación standalone
• EJBs, que utilizan el protocolo del servidor de aplicaciones (wl, t3, loop, etc) en las implementaciones en wl y websphere. Los EJBs forman parte de la aplicación ear, que se instala en el servidor de aplicaciones como motor BPM.

Los clientes PAPI ubican automáticamente los motores y seleccionan el protocolo adecuado en función del tipo de motor.

Elección de una topología

Muchos factores pueden influir la selección de una topología:

• Carga de los procesos de negocio: el número de instancias de proceso, las actividades en el proceso, y personas que interactuan con el proceso
• Aprovechamiento de infraestructura existente: servidores wl, etc
• Aprovechamiento de conocimientos existentes: J2EE, Java
• Políticas institucionales, por ejemplo, separar backend del frontend
• Confiabilidad, disponibilidad y requisitos de performance
• Costo

Guia para definir una topología

Algunas pautas según las capacidades del producto:

• Definir al menos un motor de BPM
• Los procesos pueden ser desplegados en ninguno de los motores definidos
• Cada motor de BPM se puede configurar independiente y optimizado para casos de uso específicos
• Puede haber muchos clientes BPM según se necesiten
• El área de trabajo de BPM y los clientes PAPI pueden estar en el mismo servidor que el motor de BPM o en otro diferente
• Los clientes PAPI pueden implementarse en cluster o en granja de servidores
• Cada cliente PAPI pude configurarse de forma independiente
• Los clientes PAPI pueden interactuar con cualquiera de los procesos
• Los motores de BPM, clientes PAPI y todas las aplicaciones de BPM requieren conexión con el directorio BPM
• El área de trabajo BPM y el motor BPM son aplicaciones que consumen muchos recursos. La decisión de ubicar en el mismo servidor de destino o grupo tiene importantes implicaciones en el rendimiento
• La comunicación entre el área de trabajo BPM y el motor BPM requiere de una configuración específica, dependiendo de si están en diferentes grupos o dominios. Es más fácil de configurar desplegados en diferentes dominios en lugar de grupos diferentes

Requisitos

Demo

Problemas y soluciones

Ver también

• Nota original de entorno BPM explicado