OpenESB FEMI Sofis Solutions - PMA

Transcripción

1 OpenESB FEMI Sofis Solutions - PMA Página 1 de 22

2 1 BPMS Introducción Modelado de Procesos Editor Gráfico de Procesos Gestión de Tareas Interacción Humana Ejecución de procesos El motor de ejecución Monitorización de procesos OpenESB Sobre OpenESB Especificaciones Técnicas Sobre JBI Base de Datos Soporte y Servicios Caso FEMI Definición del esquema de datos Definición de las operaciones asociadas al flujo de tareas Definición de los usuarios y grupos asociados a la tarea Definición de la interfaz de usuario Definición de la navegación entre páginas Definición del Proceso Almacenamiento de datos de tareas Página 2 de 22

3 1 BPMS 1.1 Introducción El ciclo de vida de un proceso está compuesto por diversas fases cuya automatización y administración resultan imprescindibles para obtener flexibilidad, adaptación y control sobre los mismos por áreas o secciones no-tecnológicas. Nuestra solución de BPM (Administración de Procesos de Negocio) consiste en un conjunto de herramientas 100% open-source, integrables y con fácil administración, basadas exclusivamente en estándares reconocidos en la industria. La utilización de estos estándares resulta imprescindible para que dicha solución sea abierta, en el sentido de incorporar nuevos componentes en el futuro y para poder interaccionar con otros sistemas. El ciclo de vida incluye, en un esquema general, las siguientes fases: OPTIMIZACIÓN DISEÑO Diseño: Corresponde a la especificación y diseño (desde un punto de vista conceptual) de los procesos. Modelado: Corresponde a la modelización de los procesos, ONITORIZACIÓN MODELADO las actividades, los mecanismos de comunicación, etc., utilizando para ello herramientas de modelado de EJECUCIÓN procesos. El modelado se realiza a través de herramientas con interfaces gráficas que generan los documentos en los estándares que correspondan (BPEL 2.0, por ejemplo). Ejecución: Durante esta etapa se realiza la ejecución de los procesos, generando las entradas y salidas correspondientes, interaccionando con las personas y sistemas que corresponda, ya en un ambiente de ejecución. Esta ejecución es realizada a través de motores de ejecución de procesos. Monitorización: La monitorización de procesos consiste en la generación de datos e información correspondiente al proceso, de forma tal que pueda ser analizada por los usuarios y generar alarmas y alertas en casos específicos. Página 3 de 22

4 Optimización: Para cada proceso se definen indicadores que permitirán medir la eficacia y/o eficiencia del proceso, entre otros ítems. El análisis de estos indicadores a través de tableros de control y su relacionamiento con información generada en detalle, permiten tomar medidas correctivas para mejorarlo. La siguiente figura muestra los componentes de la solución propuesta por Sofis Solutions. Esta solución está basada en tecnologías Java y Java EE, utilizando tecnologías open-source. Sus componentes son: Herramienta para el modelado de los procesos: Motor de ejecución de procesos y servicios Herramienta web para la interacción con personas Página 4 de 22

5 1.2 Modelado de Procesos Editor Gráfico de Procesos El modelado de procesos puede realizarse desde una interfaz gráfica de usuario utilizando BPMN o directamente codificando el documento BPEL. El usuario puede, desde la paleta del editor gráfico, seleccionar los componentes a agregar en el proceso y arrastrarlo hasta el punto del proceso que corresponda. La figura siguiente muestra la interfaz de usuario con el área correspondiente al diseño gráfico, la paleta de componentes y las solapas de las vistas de diseño, fuente, etc. (en la parte superior izquierda). Cada elemento en el proceso puede documentarse, lo que permite elaborar reportes del proceso con documentación. Los componentes del proceso pueden versionarse, lo que permite tener un histórico de la evolución de los procesos, así como recuperar versiones anteriores de los mismos. Figura 1: Interfaz del Modelado de Procesos La siguiente figura muestra la interfaz de reglas de asignación. En la parte superior el usuario selecciona los operadores, funciones lógicas, de cadenas de caracteres, etc. y las arrastra al área de diseño. Los parámetros de las funciones y sus resultados se asocian con los distintos elementos y variables que están incluidos en el flujo de datos del proceso. Página 5 de 22

6 Figura 2: Interfaz correspondiente a la asignación Figura 3: Service Component Architecture (SCA) Gestión de Tareas Durante el proceso, se permite realizar la asignación de tareas (por ejemplo, la revisión de datos, la aprobación de una solicitud, etc.), que es manejado por el Worklist Manager. Entre las características del WorkList Manager: Asignación de tareas a usuarios o roles (grupos). Estos usuarios o grupos pueden estar definidos a nivel de un LDAP y se realiza la autenticación contra él. Escalar una tarea. La escala de tareas se aplica en los casos que un usuario no finaliza su actividad en el tiempo asignado. Esta escala puede realizarse tanto a nivel de tiempo como de deadline. Timeout de la tarea. El timeout de una tarea está basado en una duración o en una fecha límite. Página 6 de 22

7 Notificación de tareas. La notificación de una tarea puede realizarse cuando una tarea cambia de estado o cuando se produce su timeout. Ejemplos de notificaciones son: cuando se asigna una tarea a un usuario, se envía un mail informando a dicho usuario que tiene una nueva tarea, cuando se aprueba una orden de compra, se actualiza el sistema de compras de la empresa. Generación automática de XForm. Basado en el esquema de inputs y outputs de una tarea, se genera el documento XForm correspondiente. Este documento puede ser modificado por el usuario, si así se desea, para personalizar su presentación u otros datos. Figura 4: Descripción de la asignación de una tarea El proceso para la definición de las tareas está definido por: a) Un esquema que define los datos asociados a cada tarea. b) Un servicio web que define las operaciones asociadas Página 7 de 22

8 Este servicio web se integra a la definición de los procesos en el documento BPEL. Los datos correspondientes a las tareas se almacenan en bases de datos (definidas a través de conexiones JDBC). Este componente genera documentos XForms que pueden incorporarse mediante portlets al portal Interacción Humana Una de las características de los procesos, es la posibilidad de interaccionar tanto con otros sistemas informáticos como con usuarios humanos, como por ejemplo, el caso de la aprobación de un paso para continuar o el ingreso de un nuevo dato. El IDE incorpora un editor visual de interfaces. La siguiente figura muestra el formulario básico del proceso resultante de la generación con el editor. La siguiente figura muestra el IDE y la paleta básica de componentes gráficos. Página 8 de 22

9 Adicionalmente, la interacción se puede realizar a través de una interfaz Web desarrollada como portlets, de forma tal que estos puedan ser incorporados en un portal interno y que estos portlets puedan interoperar entre si. Figura 5: Interfaz para interacción humana 1.3 Ejecución de procesos El motor de ejecución Nuestra solución para la ejecución de procesos está basada en Glassfish y OpenESB. Glassfish provee las prestaciones del servidor de aplicaciones y OpenESB las prestaciones de SOA y BPM. Página 9 de 22

10 Figura 6: Esquema General de la Solución En el esquema general de la solución, el diseñador de procesos realiza el diseño de los mismos a través del Editor, mediante el diseño y composición de servicios existentes. Estos procesos son ejecutados por el motor de servicio BPEL e interacciona con los otros motores de servicios y componentes de binding, para su comunicación dentro del mismo ambiente JBI o en otros sistemas externos. Estos procesos pueden ser monitorizados a través de herramientas de monitorización, que permitirán construir el tablero de control correspondiente. Página 10 de 22

11 1.4 Monitorización de procesos Nuestra solución incluye un motor JBI para el procesamiento inteligente de eventos. Este motor implementa las prestaciones de CEP (Complex Event Processing) y ESP (Event Stream Processing). Las principales características de este motor son: Incorpora CQL (Continuos Query Language) Incluye una interfaz gráfica para la creación de procesos de eventos (ver figura) Análisis de mensajes a partir de streams y clouds de eventos. Conectividad con todos los sistemas externos soportados por Open ESB SOA Integration Platform Figura 7: Interfaz Gráfica - Procesos de eventos La salida de estos procesos de eventos permite la graficación en tiempo real de los resultados de los procesos, el cálculo de los indicadores del proceso, la elaboración de reportes, etc. Página 11 de 22

12 1.5 OpenESB Sobre OpenESB OpenESB es una plataforma para la integración de negocios, EAI y SOA. OpenESB es 100% Open Source y está licenciada como CDDL. OpenESB está construida sobre una plataforma extensible a la que se puede agregar componentes. OpenESB está integrada por un conjunto de componentes que permiten la comunicación con los sistemas back-end, otros ESB y plataformas SOA y componentes para la transformación de documentos, procesamiento de transacciones, etc. A diferencia de los ESB propietarios, OpenESB está enteramente basado en estándares abiertos. Dado que OpenESB adhiere a JBI, cualquier componente que adhiera a la especificación JBI puede incorporarse a OpenESB. Estándares tales como SOAP, WS-* y varios estándares XML, ayudan a la interoperabilidad con otras instalaciones OpenESB e instalaciones de otros productos ESB u otras plataformas SOA. Una parte de OpenESB es un IDE, lo que hace muy fácil la creación de soluciones de integración o aplicaciones compuestas. Este conjunto de herramientas está basado en el IDE OpenSource NetBeans. Tanto OpenESB como NetBeans cuentas con cientos de miles de descargas a nivel mundial. Sofis Solutions ha llevado a cabo varios proyectos en plaza (se listan en la página ), que incluyen el uso de estas tecnologías. Sofis Solutions cuenta con personal con certificaciones internacionales en estas tecnologías. Sobre los casos de empresas que utilizan OpenESB: Página 12 de 22

13 1.5.2 Especificaciones Técnicas Sistema Operativo Solaris TM SPARC 9*, 10 Solaris x86 9*, 10 Red Hat Linux AS 3.0 Red Hat Linux AS 4.0 JDS Release 3 (x86) JDS Release 3 32-bit (Opteron) Windows 2000 Server Windows 2003 Server Windows XP Memoria 1GB de espacio en disco Se recomienda 2GB de RAM (dependerá de la cantidad de usuarios del sistema y qué otras aplicaciones ejecuten en el mismo servidor) Sobre JBI JBI es un estándar desarrollado por la Comunidad Java que permite la implementación de arquitecturas orientadas a servicios. Define un ambiente para la interacción de components que utilizan un modelo de servicios basado en WSDL 2.0. Estos componentes funcionan como proveedores de servicios, como consumidores de servicios o ambos. Estos componentes se clasifican en Motores de Servicio (service engines) y Componentes de Binding (binding components). Los primeros proveen o consumen servicios dentro del mismo ambiente JBI. Los segundos proveen o consumen servicios externos y lo hacen a través de un conjunto de protocolos. Los componentes JBI, una vez instalados en el ambiente JBI, interaccionan entre ellos usando documentos de intercambio de mensajes publicados por el componente JBI que provee los servicios. Estos documentos describen el intercambio de mensajes usando WSDL. El ambiente JBI provee una infraestructura de mensajería para el intercambio de mensajes entre los componentes JBI. Los componentes interaccionan entre ellos a través de esta infraestructura y nunca directamente. Los componentes provistos en nuestra solución se describen a continuación. Motores de Servicio Componentes de Binding Página 13 de 22

14 Motores de Servicio Aspect SE BPEL SE Camel SE Data Mashup Encoding SE ETL SE IEP SE Scripting SE Screen scraping SE Scheduler SE SQL SE WLM SE XSLT SE Componentes de Binding CICS BC CORBA BC DCOM BC BC File BC FTP BC HL7 BC HTTP BC IMS BC JDBC BC Database BC JMS BC LDAP BC MQ Series BC MSMQ BC RSS BC SAP BC SIP BC SMTP BC SNMP BC SWIFT BC TCPIP BC UDDI BC XMPP BC Al ser una tecnología open-source, es posible desarrollar nuevos motores de servicio o nuevos componentes de binding, si el proyecto así lo requiere, por ejemplo, para conectarse a un sistema legado o proveer un servicio diferente. Página 14 de 22

15 1.6 Base de Datos La aplicación a desarrollar requerirá la persistencia de datos, tanto de los propios datos de la aplicación, como de los correspondientes a la ejecución de los procesos (persistencia de las instancias de los procesos). A estos efectos, se requiere un motor de base de datos al que conectarse a través de JDBC. En el caso de incorporar un nuevo motor de base de datos, Sofis Solutions recomienda el uso de MySQL 5.0. Sofis Solutions es Ready Partner de MySQL y Centro Autorizado de Educación MySQL. Página 15 de 22

16 2 Soporte y Servicios Sofis Solutions es partner de las tecnologías que ofrece. Sun Microsystems o Centro Autorizado de Capacitación de Sun Microsystems o Miembro del programa Sun Partner Advantage NetBeans integrante de la comunidad NetBeans (respaldo de Sun Microsystems) OpenESB (en proceso de partnership) MySQL o Centro Autorizado de Educación MySQL o Ready partner JBoss o JBoss Ready Partner KnowledgeTree - Partner Página 16 de 22

17 3 Caso FEMI 3.1 Definición del esquema de datos La siguiente figura muestra el esquema de los datos a utilizar en el proceso. Página 17 de 22

18 3.2 Definición de las operaciones asociadas al flujo de tareas Página 18 de 22

19 3.3 Definición de los usuarios y grupos asociados a la tarea Estos usuarios y grupos pueden estar asociados con un repositorio LDAP. Página 19 de 22

20 3.4 Definición de la interfaz de usuario Editor gráfico para definición de interfaz de usuario que incluye la separación de lógica y presentación (CSS, JSP y lógica en Java). Disponibilidad de componentes AJAX. 3.5 Definición de la navegación entre páginas A través de la interfaz gráfica se define la navegación entre las páginas con las que interacciona el usuario, según las acciones asociadas a botones u otros elementos. Página 20 de 22

21 3.6 Definición del Proceso El editor gráfico de procesos permite definir el proceso y genera código BPEL. Este editor gráfico define el proceso en forma visual, genera el código fuente en BPEL y permite definir los elementos a loguear (registrar) a través de la opción de logging. El diseñador de reglas, permite definir las asignaciones y otras reglas incluidas en el proceso. Página 21 de 22

22 3.7 Almacenamiento de datos de tareas Los datos de las tareas y sus estados son almacenados en bases de datos. Esta base de datos puede ser gestionada desde el propio IDE. Página 22 de 22