UNIVERSIDAD TÉCNICA FEDERICO SANTA MARIA DEPARTAMENTO DE INFORMÁTICA SANTIAGO CHILE

Transcripción

1 UNIVERSIDAD TÉCNICA FEDERICO SANTA MARIA DEPARTAMENTO DE INFORMÁTICA SANTIAGO CHILE ANÁLISIS DE PLATAFORMAS DE CÓDIGO ABIERTO PARA ALCANZAR LAS FUNCIONALIDADES DE UN BPMS COMERCIAL JOSÉ GUILLERMO ESPINA DOTE MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO CIVIL INFORMÁTICO PROFESOR GUÍA: BERNARD HITPASS. PROFESOR CORREFERENTE: HERNÁN ASTUDILLO. NOVIEMBRE 2009 i

2 A Mariapaz que me obligó a trabajar ii

3 Contenido Índice de tablas y figuras Pág. Resumen / Abstract iv/v Glosario vi Introducción xi Capitulo 1: Identificación y Definición del Problema 10 Capitulo 2: Estado del Arte 13 Capítulo 3: Propuesta de Solución 64 Capitulo 4: Validación de la propuesta 71 Capitulo 5: Conclusiones y trabajo futuro 94 Anexos 97 Referencias 105 iii

4 Resumen En la actualidad existe una variedad de tecnologías y disciplinas de apoyo a la gestión organizacional. Una de las que últimamente ha causado impacto es el BPM (del inglés Bussiness Process Management) que, a través de los BPMS (del inglés Bussiness Process Management Systems o Suites), permiten orquestar procesos de negocio, mejorando la toma de decisiones y disminuyendo costos, entre otros beneficios. El problema es que estos sistemas son software de elevados precios acotando la cantidad de organizaciones que puedan optar a su adopción. Por esto último, se presenta una solución, la que usando sólo plataformas código abierto, permita tener las funcionalidades que ofrece un BPMS comercial, disminuyendo significativamente los costos de manera que pueda ser costeado por una pyme. Posteriormente, se explicarán los detalles técnicos de la propuesta, se validará su uso con una pyme ficticia, y se indicarán las consecuencias de una posible implementación satisfactoria en una organización. Palabras clave: BPM, BPMS, SOA, Código abierto. iv

5 Abstract At present there are a variety of technologies and disciplines in support of the organizational management. One of the recent that caused impact is the BPM (Business Process Management) that, through the BPMS (Business Process Management Systems or Suites), allow orchestrate business processes, improving the decision-making and decreasing costs, among other benefits. The problem is that these systems are software of high prices restricting the amount of organizations that are eligible for adoption. By the latter, presents a solution, which using only Open Source platforms, allows the features that offers a commercial BPMS, decreasing costs significantly so that it can be financed by an SME. Subsequently, will explain the technical details of the proposal, it was validated their use with an sme fictitious, and indicate the consequences of a possible implementation satisfactory in an organization. Key words: BPM, BPMS, SOA, FLOSS. v

6 Glosario - BPM: Del inglés Business Process Management (BPM), es una disciplina de gestión empresarial cuyo objetivo es mejorar la eficiencia y eficacia a través de la orquestación sistemática de los procesos de negocio. - BPMS: Del inglés BPM Suite o System (BPMS), son complejos software para llevar a cabo la implementación de la disciplina BPM en una organización. - TQM: Del inglés Total Quality Management (TQM), es una estrategia de gestión orientada a crear conciencia de calidad en todos los procesos organizacionales. - TPS: Del inglés Toyota Production System (TPS), es un sistema integral de producción y gestión creada en la empresa japonesa automotriz Toyota. - SOA: Del inglés Service Oriented Architecture (SOA), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. - TI: La Tecnología de Información (TI), es el estudio, diseño, desarrollo, implementación, soporte o dirección de los sistemas de información computarizados, en particular de software de aplicación y hardware de computadoras 1. - ERP: Del inglés Enterprise Resource Planning (ERP), son sistemas de información gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía comprometida en la producción de bienes o servicios. 1 Según lo definido por la asociación de la tecnología de información de América (ITAA). vi

7 - SCM: Del inglés Supply Chain Management (SCM), es el proceso de planificación, puesta en ejecución y control de las operaciones de la red de suministro con el propósito de satisfacer las necesidades del cliente con tanta eficacia como sea posible. - XML: Del inglés Extensible Markup Language (XML), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). - CPU: Del inglés Central Processing Unit (CPU), o simplemente el procesador o microprocesador, es el componente en una computadora digital que interpreta las instrucciones y procesa los datos contenidos en los programas de la computadora. - Pyme: Pequeña y mediana empresa (conocida también por su acrónimo PyME, PYME o pyme), es una empresa con características distintivas, tienen dimensiones con ciertos límites ocupacionales y financieros prefijados por los estados o regiones a las que pertenecen. Son agentes con lógicas, culturas, intereses y espíritu emprendedor específico. Usualmente se ha visto también el término MIPyME (acrónimo de Micro, pequeña y mediana empresa), que es una expansión del término original en donde se incluye a la microempresa. En Chile el Servicio de Impuestos Internos (SII) clasifica a las empresas por nivel de ventas anuales netas con IVA, en Unidades de Fomento (UF), excluyendo al sector informal. De 0 a UF es micro, de a UF es pequeña, de a UF es mediana y para o más UF de ingresos es gran empresa. - SOFOFA: Sociedad de Fomento Fabril (SOFOFA o SFF) es la asociación gremial de las empresas, gremios del sector industrial chileno. - USD: Del inglés United States Dolar, es la moneda de los Estados Unidos. vii

8 - J2EE: Del inglés Java 2 Enterprise Edition (J2EE) hasta la versión 1.4), es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de N niveles distribuida. - DOM: Del inglés Document Object Model (DOM), es esencialmente una interfaz de programación de aplicaciones que proporciona un conjunto estándar de objetos para representar documentos HTML y XML, y una interfaz estándar para acceder a ellos y manipularlos. - IDE: Del inglés Integrated Development Environment (IDE), es un software que provee facilidades para el desarrollo de software. Generalmente está compuesto por un editor de código fuente, herramientas automáticas de compilación y de depuración. viii

9 Introducción El presente trabajo es una propuesta de solución operativa para la aplicación de la disciplina BPM por una pyme chilena. Como éstas organizaciones no cuentan con un presupuesto como para costear la compra e instalación de un BPMS, se consideró el uso exclusivo el uso de software de código abierto. Para llevar a cabo el diseño de la solución, se realizó un estudio de las funcionalidades de un BPMS comercial y las alternativas libres para suplir esos módulos. La estructura de este trabajo es la siguiente. En el capítulo 1 se presentará el problema que motiva a usar BPM y plataformas de código abierto. En el capitulo 2 se describirán funcionalidades de un BPMS comercial, realizando una pequeña revisión de software comercial como ActiveVos, SmartBPM y Oracle BPM, y se presentará la gama de alternativas código abierto que podrían servir para hacer uso de BPM de manera gratuita. Luego, en el capítulo 3, se propone una solución usando las alternativas revisadas en el anterior. Finalmente, en el capitulo 4 y 5 se realiza la descripción de la solución y su validación respectivamente, seguido de las conclusiones que finiquitan el trabajo. La diferencia entre los conceptos código abierto y software libre se explican en el anexo 1. ix

10 Capitulo 1: Identificación y Definición del Problema La experiencia ha demostrado que un gran porcentaje de los fracasos de proyectos de creación de negocios, tuvieron como causa problemas de gestión. Un ejemplo de este hecho se refleja en el sitio del boletín electrónico comercial chileno Kumentun 2, el que en su edición del mes de marzo, publica un reportaje llamado El difícil mundo de las Pymes. En él se explica que, a nivel mundial, entre un 75% y 80% de las empresas pymes fracasa en los primeros 5 años de gestión, y otro 5% a 10% no alcanza a cumplir los 10 años de funcionamiento, mientras que sólo un 3% a un 5% llegan a madurar y a convertirse en empresas consolidadas. Luego, se detalla las causas importantes del alto nivel, las cuales son problemas de planificación, producción, control, comercialización y gestión. Se sabe también, que la adopción de BPM en empresas trae múltiples beneficios en la gestión [1], como la reducción de costos, debido a que disminuyen riesgos y se evitan gastos producidos por procesos de negocios mal configurados. Otra mejora es el aumento de la calidad del producto o y/o servicio final, porque disminuyen los tiempos en los ciclos de producción y una mejora con el trato al cliente. Otro aspecto, es un aumento en la agilidad de la organización, que permite tomar decisiones más rápidamente. 1.1 Problema Existe un número significativo de empresas pequeñas y medianas que necesitan de herramientas de gestión, como un BPMS, y no poseen ingresos suficientes como para pagar una licencia de un sistema de ése tipo

11 1.2 Oportunidad y motivación Un estudio de la Universidad de Chile, en conjunto con la SOFOFA 3 [2], concluyó que el uso de TI de software libre, en el ámbito de las soluciones de negocios, favorecen con una mayor probabilidad de éxito a las empresas que la media a nivel internacional. Entonces, se puede ver una oportunidad de solucionar el problema haciendo uso de software de código abierto. 1.3 Objetivo general Determinar de qué forma, y en qué medida, se pueden usar plataformas de código abierto para realizar las funcionalidades que ofrece una suite de BPM comercial, minimizando los costos de manera que puedan ser pagados por empresa pequeña o mediana. 1.4 Objetivos específicos - Analizar características entre alternativas de código abierto para poder implementar la disciplina BPM en una organización - Presentar una solución factible que permita una posible implementación de BPM usando las alternativas código abierto del punto anterior. 1.5 Metodología de trabajo Para abarcar el problema identificado y cumplir con los objetivos propuestos, se analizarán las características que ofrecen los BPMS comerciales. A continuación se desarrollará el estado del arte, el cual cubre aspectos técnicos de los BPMS, las funcionalidades de las alternativas comerciales y de las plataformas 3 SOFOFA: Sociedad de Fomento Fabril. Es la asociación gremial de las empresas, gremios del sector industrial chileno. Fue fundada en

12 código abierto. Luego, se propondrá una solución que se analizará de manera crítica, de manera de lograr conclusiones que aporten a los gestores de negocios. 12

13 Capítulo 2: Estado del Arte 2.1 Contexto La disciplina BPM se lleva a cabo en la práctica gracias a un sistema o suite BPM (lo que llamaremos desde ahora en adelante, BPMS). En una organización que se vale de TI para su proceso productivo un BPMS abarca una gran parte de la totalidad de los sistemas. Se presenta a continuación, en la figura 2.1, un ejemplo de un BPMS conectado a un conjunto de tecnologías, que podrían estar implementadas en una plataforma distinta y/o en un lugar físico distinto. Esto es posible a la arquitectura SOA. Figura 2.1: Esquema ejemplo [3] de un BPMS funcionando con otras tecnologías empresariales, tales como servidores Web, bases de datos, portales, servidores de correo, etc. No es necesario que éstas estén implementadas en la misma tecnología o desplegadas en las mismas plataformas Para mayor información, ver el concepto SOA. 13

14 2.1.1 Que es un BPMS y que debería hacer? El concepto clave de BPM [4] es la convergencia de tecnologías con teorías de gestión de procesos. Esto produce nuevos procesos de diseño e implementación que darán paso a lo que se llamarán BPMS. Un BPMS es una nueva clase de software que permite a las organizaciones crear procesos integrados usando soluciones de TI. Por proceso integrado se entiende que los BPMS deben ser capaces de integrar a personas, sistemas e información. Las organizaciones que usan un BPMS deben tener las siguientes capacidades: - Un involucramiento por parte de la organización al diseñar procesos de negocio. - La habilidad de integrar personas y sistemas que participen en los procesos de negocio. - La habilidad de simular procesos de negocio al momento de diseñar el óptimo para la implementación. - La habilidad de monitorear, controlar y mejorar procesos de negocio en tiempo real - La habilidad de hacer cambios en procesos de negocio existentes en tiempo real, sin tener la necesidad de elaborar un proceso esforzado de conversión. Según un artículo [5], donde implementan un framework de evaluación de sistemas BPM, los autores determinaron que las categorías clave que conforman un BPMS son: 14

15 - Modelado de procesos: Los modelos de procesos se usan para facilitar el entendimiento de procesos de negocio tanto de gestores de negocios como de gestores de TI. La visualización de procesos permite encontrar imperfecciones en los procesos y mejorarlos. Los modelos permiten colaboración horizontal en toda la organización, incluyendo a los que no los desarrollan, permitiendo concentrarse en diferentes partes del proceso. - Ambiente de orquestación: Orquestación, dentro del contexto actual, se refiere a la posibilidad de que un proceso de negocio ejecutable interactúe con servicios internos y externos. Estas interacciones ocurren en el nivel de mensajería, que será explicado más adelante en detalle, e incluye lógica de negocio. Entonces, el ambiente de orquestación se refiere a cómo las herramientas definen el proceso de negocio ejecutable. - Espacio de trabajo: El espacio de trabajo incluye el soporte por tener diferentes interfaces de usuario con diferentes roles, debido a que idealmente éste debiera verse diferente tanto para el gestor de negocios como para el desarrollador de software. - Administración de procesos: La mayoría de los procesos no solamente trabajan en su propio ambiente, sino que lo hacen en muchas partes, por ejemplo, servicios horizontales a la organización. La administración de procesos es generalmente fácil en estructuras de procesos jerárquicos donde existe un solo punto de entrada y el usuario tiene acceso a todos los detalles del proceso. En muchos casos los procesos son una mezcla de procesos jerárquicos e interacciones entre personas. Entonces, ésta categoría se refiere a qué tipo de información el administrador o usuario puede obtener de los procesos que ya se están ejecutando. - Gestión de las reglas del negocio (en inglés, Business Rules Management): La gestión de reglas del negocio es uno de los elementos clave de un proceso son las reglas usadas en y entre la secuencia de los 15

16 pasos del proceso. Una regla puede ser por ejemplo que un cliente de un banco necesite un ingreso mensual de cierta cantidad de dinero como mínimo para poder solicitar un crédito. Las reglas deberían poder cambiarse continuamente y ser versionadas. - Monitoreo de actividad de negocio (en inglés, Business Activity Monitoring): El monitoreo de actividades de negocio se refiere a como se puede proveer acceso en tiempo real a los indicadores críticos de desempeño del negocio para mejorar la velocidad y efectividad de las operaciones del negocio. - Motor de procesos: El motor de procesos, también denominado motor de orquestación, coordina la secuencia de actividades de acuerdo a los flujos y reglas del modelo de los procesos. En un ambiente de servicios, el motor contiene todo los flujo de procesos, llamando a los servicios apropiados y determinando que pasos realizar. - Repositorio de procesos: El repositorio de procesos contiene definiciones de procesos, componentes de procesos, modelo de procesos, reglas del negocio, entre otros. Los repositorios permiten a las organizaciones reutilizar partes de procesos a través de múltiples procesos y permitir hacer el desarrollo de nuevo procesos de manera más fácil. - Gestión de recursos: La gestión de recursos consiste en como el sistema contiene diferentes recursos, tales como usuarios, roles, etc. - Conectividad: La conectividad se refiere a como el sistema se dispone a conectarse con diferentes estándares, como por ejemplo servicios Web, adaptadores, etc. 16

17 2.1.2 Estándares y arquitectura de un BPMS Existen varios estándares para la definición de procesos de negocios y para la integración de procesos de negocios [4]. Los primeros, especifican como el proceso de negocio debería ser diseñado con semánticas para distintos tipos de actividades, transiciones, subprocesos, etc. Los estándares de interacción de procesos especifican el cómo los procesos de negocio pueden ser invocados y definen los participantes que pueden colaborar con su ejecución mediante el uso de servicios Web. Éstos últimos pueden traspasan los límites físicos de una empresa, permitiendo comunicar a un cliente remoto con el BPMS de la organización. Un cliente podría ser una persona u otro BPMS, un partner de negocio externo o una aplicación interna que pueda invocar una nueva instancia de un proceso, actualizar o realizar consultas, entre otras funciones que ofrezca el servicio. Los estándares más representativos pertenecen a las organizaciones WfMC 4, el de BPMI 5 y el de la OASIS 6. Se resumen en la tabla 2.2 a continuación: 4 WfMC: del inglés, Workflow Management Coalition, es una organización de desarrolladores, consultores, analistas e investigadores que trabajen en flujo de trabajo y BPM. 5 BPMI: del inglés, Business Process Management Initiative, es una organización internacional sin fines de lucro que propone estándares de procesos de negocio. 6 OASIS: del inglés, Organizaton for the Advancement of Structured Information Standard, es un consorcio sin fines de lucro orientado en el desarrollo, convergencia y adopción de estándares abierto para información global. 17

18 Definición de procesos de negocios Interacción de procesos de negocio WfMC XPDL (XML Process Wf-XML 2.0 Definition Language) OASIS BPEL4 (Business Process Execution Language) BPEL (Business Process Execution Language) BPMI/W3C BPML (Business Process Modeling Language) WSCI (Web Service Choreography Interface) Tabla 2.2: Resumen de estándares BPM más representativos, tanto para definición como para interacción en cada organización, según la organización responsable. Todos los estándares nombrados se basan en esquemas XML, lo que permite persistencia y un posible intercambio de definiciones entre sistemas heterogéneos y herramientas de modelado. Se debe mencionar también, en esta sección de estándares, a la notación gráfica BPMN, mantenida por la organización OMG 7 (del inglés, Object Management Group), utilizada para diseñar diagramas para definir procesos de negocio. Lo que ofrecen los diseñadores de workflow de los BPMS es la capacidad de realizar diseños de procesos de negocio en BPMN, los cuales son intuitivos y pueden ser entendidos por cualquier miembro de la organización, para luego pasarlo a algún estándar de definición de procesos que permita ejecutarlo. Se presenta un ejemplo, de parte de un proceso definido en BPEL, en el anexo Estándares de definición de procesos de negocios A continuación se presentará una breve descripción y un metamodelo de cada uno de los lenguajes que definen procesos de negocios. 7 OMG: del inglés Object Management Group, es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA. 18

19 a) XML Process Definition Language (XPDL) En la figura 2.3, que se encuentra a continuación, se presenta el metamodelo el nivel más alto de abstracción [6]. Se explicarán las entidades de manera breve. Un ejemplo de definición de XPDL se encuentra en el anexo 6. 19

20 Figura girada 2.3: Metamodelo de alto nivel de XPDL. Para cada una de las entidades nombradas en la figura existe un conjunto de propiedades asociadas 20

21 b) Business Process Modeling Language (BPML) Business Process Modeling Language (BPML) es un lenguaje creado por la compañía Intalio, donde la versión 1.0 de la especificación es publicada en noviembre del La especificación provee [7] un modelo de abstracción para expresar procesos de negocio y dar soporte entidades. BPML define un modelo formal para expresar procesos abstractos y ejecutables que apuntan todos los aspectos de los procesos de negocio empresariales, incluyendo actividades de distintas complejidades, transacciones y sus compensaciones, administración de datos, concurrencias, receptores de excepciones y semánticas operacionales. A continuación se revisará de manera general las entidades más importantes del nivel más alto de abstracción del metamodelo, el cual se presenta en la figura 2.4 a continuación. 21

22 Figura 2.4: Metamodelo de alto nivel de BPML Estándares de interacción entre procesos de negocios a) Business Process Execution Language (BPEL) El Business Process Execution Language for Web Services [8] (BPEL4WS, usualmente acortado a BPEL) es un lenguaje para la definición y ejecución de procesos de negocios. No es solo un estándar de lenguaje de procesos, es por eso que no está en la sección anterior de estándares de definición de procesos de negocios (1.5.1). La definición de procesos BPEL consiste de dos tipos de archivos: 22

23 - Los archivos WDSL (del inglés Web Service Definition Language) que especifican del servicio web su interfaz, los tipos de enlaces con otros procesos, propiedades, tipos de puertos y operaciones, servicios implementados y llamados por el proceso. - Los archivos BPEL los cuales definen un proceso incluyendo actividades principales, enlaces compañeros (del inglés, partner links), conjuntos de correlación, variables, receptores de compensación, faltas y eventos. Las entidades que definen un proceso se presentan en la figura 2.5, la cual corresponde al metamodelo de la especificación BPEL. Figura 2.5: Metamodelo de alto nivel de BPEL. 23

24 b) Web Services Choreography Interface (WSCI) La versión 1.0 de WSCI [9] fue escrita por BEA, Intalio, Sun y SAP en el año Es un lenguaje de descripción de interfaz que define el flujo de mensajes intercambiados por un servicio Web participante en interacciones coreografiadas con otros servicios. WSCI describe la interfaz dinámica de un servicio Web participante en un intercambio de mensajes dado, esto significa una reutilización de las operaciones definidas para un interfaz estática. WSCI trabaja en conjunto WDSL (del inglés Web Service Description Language), la base para el W3C Web Services Description Working Group. Además puede trabajar con otros lenguajes de definición servicios que muestre las mismas características como WSDL. WSCI describe el comportamiento observable de un servicio Web. Este es expresado en términos de dependencias temporales y lógicas a través de intercambio de mensajes, con reglas de secuencia, correlación, recepción de excepciones y transacciones. WSCI también describe el intercambio colectivo de mensajes interactuando a través de servicios Web, así provee una perspectiva de las interacciones global y orientada a mensajes. WSCI no apunta la definición y la implementación de procesos internos que eventualmente orienten el intercambio de mensajes. WSCI no contiene la definición y la implementación de un proceso interno, sin embargo describe el comportamiento observarle de un servicio Web a través de una interfaz orientada al flujo de mensajes. Esta descripción permite a desarrolladores, arquitectos y herramientas para describir y componer una vista global de la dinámica del intercambio de mensajes a través del entendimiento de interacciones con el servicio Web. c) Workflow Extensible Markup Language (Wf-XML) 2.0 WfXML está construido sobre la especificación AWSP (del inglés Asynchronous Web Services Protocol) del grupo OASIS (el mismo que mantiene 24

25 a BPEL) que ofrece un mecanismo de control remoto y monitoreo de workflow. Se presenta a continuación, en la figura 2.6, el metamodelo de WfXML. Figura 2.6: Metamodelo de alto nivel de BPEL. En este modelo existen dos servicios Web, el que implementa la interfaz Observer y el AWS (del inglés Async Web Service) que implementa las interfaces ServiceRegistry, Factory, Instance y Activity. El AWS es el servicio web que puede ser controlado y monitoreado remotamente, el servicio Web observador es el servicio que realiza el control y el monitoreo. En el modelo de referencia WfMC, un servicio promulgado (del inglés enactment, se refiere a que un servicio puede ser ejecutado como un interprete para proveer una guía a los realizadores del proceso en tiempo real). Que implemente ambos servicios, puede controlar o ser controlado por otro servicio promulgado Arquitectura de un BPMS La arquitectura de un BPMS se basa en lo que es SOA. A continuación, en la figura 2.7, se presenta una figura explicativa donde se pueden ver los elementos nombrados anteriormente. Las interfaces están definidas según el método de comunicación que se definieron recién. 25

26 Figura 2.7: Esquema básico de arquitectura de software de un BPMS comercial Costo de licencias de un BPMS A continuación se presenta la tabla 2.8, la que resume algunos precios de algunas BPMS para un caso hipotético de una empresa con un servidor de 2 CPU, 50 usuarios al día, 25 usuarios ocasionales, 1 proceso y 1000 pasos por día. Esta información fue sacada de un artículo en línea de la revista de computación Network Computing [10]. 26

27 Suite Costo básico (en USD) Costo para la empresa ficticia (en USD) Bluespring Software BPM Suite por CPU Computer Associates CleverPath Alon Parte con Business Process Manager 10 Fuego FuegoBPM Suite 5.5 Basado en el proceso y el analizador se paga en separado Lombardi Software TeamWorks 5.02 Basado en CPU Oracle BPEL Porcess Manager Basado en CPU (40000 c/u), y por agregar el servidor de aplicaciones de Oracle (10000) Pegasystems PegaRules Process Según el usuario y su Commander 4.2 frecuencia de acceso Tibco Staffware Process Suite Precio de todos los productos por separado Savvlon Business Manager 6.0 Por modelo empresarial También ofrece basándose en modelo a menor costo. Ultimus BPM Suite 7.0 Por pasos por día de clientes activos Tabla 2.8: Resumen de costos de implementar un BPMS comercial para el caso analizado en el artículo de la revista Network Computing. Considerando por ejemplo la solución de Oracle, la empresa ficticia debe pagar USD sólo por el uso del software en dos servidores, sin contar los costos de implantación y capacitación de personal. Si se toma el precio del dólar a 500 pesos chilenos, da como resultado 40 millones de pesos por el uso del BPMS. Por otro lado, una mediana empresa obtiene UF de ganancia al año como mínimo, lo que, suponiendo la UF a pesos chilenos, da como resultado pesos chilenos aproximadamente de ganancia al mes. Entonces, la empresa debería pagar prácticamente un ingreso mensual completo para sólo poder pagar la licencia del software, lo cual en la realidad no sirve, porque en una implementación real se deben considerar gastos de instalación y aprendizaje. 27

28 2.1.7 Opciones comerciales de BPMS A continuación se verán las funcionalidades, características y arquitecturas de diferentes alternativas de BPMS comerciales, para luego buscar soluciones de código abierto que permitan conformar un sistema para aplicar BPM. a) ActiveVos ActiveVos 8 es un BPMS comercial corriente, no muy conocido en el mercado, y pertenece a la empresa estadounidense Active Endpoints. El software hace uso de una serie de estándares para definir procesos, modelar, protocolos de comunicación, seguridad, monitoreo, etc. Sin embargo su núcleo son 4. BPMN 1.0, WS-BPEL 2.0, WS-HumanTask 1.0, BPEL4People A continuación, en la figura 2.9, se presenta un esquema con las tecnologías que permiten la integración del sistema [11]. Figura 2.9: Tecnologías que comunican los módulos de ActiveVos con otras instancias En junio de 2007, Active Endpoints, Adobe, BEA, IBM, Oracle y SAP publicaron las especificaciones BPEL4People y WS-HumanTask, los cuales describen como la interacción humana en procesos BPEL pueden ser implementados 28

29 El ciclo de trabajo que compone a ActiveVos está compuesto por 5 pasos, modelar, simular, implementar, desplegar y ejecutar, monitorear y optimizar. Al igual que varias tecnologías tanto de código abierto como comerciales, ActiveVos hace uso del IDE Eclipse (el cual será explicado más adelante) para interactuar con el usuario como se ve en la figura 2.10 presentada a continuación. Figura 2.10: Diseñador ActiveVos. Utiliza el IDE Eclipse. El precio de tener este software es de USD por socket de CPU la primera vez de compra, y USD las subsiguientes licencias por cada socket de CPU. b) Oracle BPM del mercado. La solución de Oracle para implementar BPM es una de las más populares 29

30 Figura 2.11: Esquema arquitectónico de alto nivel de la propuesta de Oracle Como se muestra en la figura 2.11 cada instancia del servidor de administración de procesos de BPE corre en un servidor de aplicaciones, que puede ser Oracle, Jboss, WebLogic o WebSphere. Como es de su propia compañía, el funcionamiento con el servidor de Oracle está optimizado, permitiendo aprovechar un servidor de aplicaciones J2EE para la ejecución transaccional de pasos de procesos, u para el conjunto de hilos y conexiones de la base de datos que son usadas para asegurar la entrega garantizada de mensajes. Para llenar estos requerimientos de manera consistente, cada servidor operacional ejecuta pasos de procesos usando un acercamiento completo sin estado, utilizando un formato DOM binario de alto rendimiento para procesar el almacenado, recepción y ejecución. Usando esta metodología, cada instancia de proceso es solo guardada en la base de datos por un cuadro de tiempo de la interacción del proceso. Como resultado, Oracle BPM permite la optimización de desempeño a un nivel el cual, haciendo uso de un hardware actualizado, se pueden ejecutar más de 100 pasos de procesos por CPU. 30

31 c) Pegasystems SmartBPM SmartBPM es uno de los más conocidos BPMS de clase mundial (del inglés World Class 10 ) del mercado. En el cuadrante mágico de las BPMS, reporte realizado por Gartner 11, éste software está clasificado como el más amplio y visionario del mercado de elite de los sistemas BPM. 2.2 Trabajo previo y situación actual En el punto anterior, se revisaron las funcionalidades de BPMS comerciales. Si bien eran de distintas características, todos intersectaban en una serie de funcionalidades necesarias para conformarse como una herramienta que permita llevar a la práctica la disciplina BPM. Se han realizado intentos de construir un BPMS código abierto. Los más comunes de encontrar en la literatura son Intalio, JBoss jbpm, Enhydra Shark, Nova Bonita y OpenWFE. Se detallarán a continuación jbpm a) Descripción JBPM [6] es una plataforma para lenguajes de procesos ejecutables, desde un flujo de trabajo BPM hasta una orquestación de servicios. jbpm soporta 3 diferentes lenguajes de definición de procesos. Cada uno tiene una función específica y un ambiente. Estos son jpdl, BPEL y Pageflow. 10 Se les llama a los BPMS World Class a aquellos que tienen una madurez y consolidación en el mercado. Se caracterizan por se considerados en reportes de grandes consultoras como Gartner. 11 Gartner, S.A.. es un proyecto de investigación de tecnología de la información y de firma consultiva con sede en Stamford, Connecticut, EEUU. Se conocían como el Grupo Gartner hasta

32 A continuación se puede ver en la figura 2.12 y 2.13 al diseño de un proceso en jbpm y su código jpdl, variante propia de XPDL, correspondiente respectivamente. Figura 2.12: Un proceso definido en JBoss jbpm Figura 2.13: El mismo proceso de la figura 5 en lenguaje jpdl 32

33 BPM compila estos lenguajes de proceso nativamente sobre una sola tecnología, la maquina virtual de procesos (PVM), la cual asegura estabilidad ante cualquier avance en la tecnología. jbpm Está compuesto por: 1. Un motor de workflow llamado JBoss jbpm core component el que se encarga de ejecutar una instancia de proceso. 2. Una herramienta de definición de procesos llamada JBoss jbpm Graphical Process Designer (GPD). Es un plugin del IDE Eclipse el cual provee soporte en la definición de procesos en formato jpdl (propio de jbpm), el cual es el lenguaje utilizado por el sistema (como es común, basado en esquema XML). 3. El JBoss jbpm console Web application, el cual tiene 2 funciones, es un cliente de workflow basado en Web, el cual en modo Home los usuarios pueden iniciar y ejecutar un proceso. También tiene una herramienta de administración y monitoreo en el modo Monitoring donde los usuarios pueden observar e intervenir en la ejecución de las instancias de procesos. 4. El JBoss jbpm identity component el cual se encarga de la definición de la información organizacional, tales como usuarios, grupos y roles en las cuales las distintas tareas son asignadas. Actualmente esta definición se hace a través de inserciones SQL estándares en la base de datos del workflow. b) Funcionalidades En jbpm, una definición de proceso se empaca como un archivo de proceso. Éste archivo se pasa al jpdl process engine para su ejecución. El jpdl 33

34 process engine traza una gráfica, ejecuta las acciones definidas, mantiene un estado del proceso y archiva todos los eventos del proceso. JBoss jbpm está encapsulado con los siguientes componentes: Process engine, Éste componente define las acciones del proceso, mantiene el estado del proceso y registra todos los eventos vía los siguientes componentes delegados: Gestores de eventos, como request handler, state manager y log manager Gestores de carga y ejecución, como definition loader, execution service. Process lenguaje: El process definition lenguajes (jpdl) está basado en GOP y en el esquema XML. Interaction services: Estos servicios muestran a las aplicaciones legacy como funciones o datos usados en las ejecuciones de procesos. Las relaciones están bien explicadas en la figura 7 que está a continuación, Figura 2.14: Esquema de componentes de jbpm. Como se muestra en la figura 7, las definiciones de procesos contienen action handlers que son cargados y ejecutados por el jbpm process engine. Cuando el process engine encuentra un nodo en la definición de los procesos que tiene una acción asociada con él, todas los action handlers relacionados se invocan. Los action handlers son instancias de código Java que interactúan con sistemas externos cuando son ejecutados. 34

35 El diseñador gráfico puede ser usado para crear las definiciones de procesos, adjuntarles action handlers a eventos, editar la definición por código fuente, crear archivos de procesos, testear las definiciones de procesos, etc. c) Arquitectura A continuación, en la figura 8, se presenta un esquema general de cómo trabaja la arquitectura de la plataforma. Figura 2.15: Esquema de la arquitectura y flujo de la información Intalio (versión Community Edition) a) Descripción Intalio provee una alternativa interesante para el modelado de proceso de negocios. La ventaja de ésta solución es que soporta una amplia gama de estándares, tiene una interfaz de usuario clara y bien establecida y es gratis [6]. 35

36 Intalio está compuesto por un ambiente para diseñar procesos, el cual funciona con la plataforma Eclipse, y un servidor para ejecutar, monitorear y controlar procesos, basado en el servidor Apache ODE. El ambiente de diseño de procesos se llama Intalio Designer [7] (ver figura 1). Es una herramienta simple tanto como para analistas del negocio, ingenieros de software y administradores de sistemas para ayudar el modelado de procesos de negocio, su relación con sistemas externos e interfaces de usuario, y su despliegue en el servidor, llamado Intalio Server. Como resultado, todos los stakeholder se benefician teniendo un ambiente de trabajo común que fomenta la comunicación entre disciplinas y preserva la integridad del proceso de negocio en todo su ciclo de vida, desde el diseño al despliegue, y optimización. A continuación, en la figura 2.16 se presenta una imagen del software funcionando. Figura 2.16: El diseñador de Intalio Está construido para funcionar en la plataforma Eclipse, por lo que funciona en cualquier plataforma. No se necesita escribir alguna línea de código, debido a que es capaz de transformar cualquier diagrama BPMN en un proceso ejecutable BPEL 2.0. Estos procesos pueden ser desplegados a Intalio Server 36

37 Intalio Server es un servidor nativo de procesos BPEL 2.0 en una arquitectura J2EE certificado para una amplia gama de plataformas. Fue diseñado para ser desplegado en un grid de servidores en el departamento de energía (DOE) de Estados Unidos. Intalio Server está basado en el proyecto código abierto Apache ODE. El servidor, como se dijo anteriormente, es nativo en la implementación BPEL 2.0 estándar, sin embargo también es compatible con versiones anteriores, como BPEL 1.0 y 1.1. Soporta además migraciones de procesos BPEL a otros motores como los de Oracle y Sun. La ejecución de los modelos no requiere una implementación de clases Java para la generación y despliegue de procesos. Para la ejecución de procesos Intalio Server utiliza el framework JACOB. El uso de este último permite tener persistencia en estado de ejecución y concurrencia. b) Arquitectura A continuación se presenta la figura 2.17 con la arquitectura de Intalio. Notar que solo las secciones con la distinción CE (del inglés comunity edition) corresponden a la versión gratuita. 37

38 Figura 2.17: Arquitectura de Intalio. Notar que sólo el área con el efecto semitransparente de la izquierda es libre y código abierto. La solución completa (que incluye BAM, BRE, etc.), más el soporte, es comercial. El lector debe notar que esta solución es cómoda para el usuario final, sin embargo la versión gratuita deja fuera importantes características, como el BAM, BRE, ESB, Portal, CMS y LDAP Enhydra Shark a) Descripción El proyecto Enhydra Shark [11] provee un servidor de flujo de trabajo con un motor Java código abierto incluyendo una implementación estándar completamente basada en las especificaciones de la WfMC usando XPDL como formato de definición de procesos nativo y la API ToolAgents del WfMC para la ejecución de actividades del sistema por parte del servidor. Cada componente (capa de persistencia, administrador de tareas, etc.) puede ser usado con su implementación estándar o modificada / reemplazada por los módulos específicos del proyecto. De este modo Enhydra Shark puede ser usado como una librería Java, usar otras aplicaciones o correrlo en un contenedor 38

39 J2EE soportando APIs de beans, Corba ORB o siendo accedido como un servicio Web. El proceso de almacenamiento y de instanciación se hace a través de una API de persistencia configurable. El núcleo del motor de flujo de trabajo soporta un caché LRU configurable de los objetos del flujo de trabajo. El caché puede apagarse para instalaciones en clústeres. Posee además una aplicación administradora para controlar formulario y archivos XSLT. El servidor de Enhydra Shark es una aplicación Java de código abierto y un servidor de servicios Web incluyendo Apache Tomcat (o alternativamente Jetty) y Apache Axis. Mientras la API del servlet se usa para dar soporte a la lógica de presentación, la plataforma contiene niveles empresariales para construir un alto volumen de sitios Web en una arquitectura de n-capas Nova Bonita a) Descripción Nova Bonita [9] es el nombre de la nueva versión de Bonita v4 y se caracteriza por tener una máquina virtual, la cual es un motor de procesos genérico que soporta múltiples lenguajes, entre ellos BPEL y XPDL. En la figura 2.18 se está el diseñador de Bonita que, al igual que Intalio, usa Eclipse como plataforma. En la figura 2.19 está el mismo modelo que en la figura 3 pero en lenguaje XPDL. 39

40 Figura 2.18: Ejemplo de proceso usando Bonita. Figura 2.19: El proceso de la imagen anterior en lenguaje XPDL. b) Funcionalidades Los servicios en Nova Bonita buscan ser universales en temas de conectividad. Las versiones, tanto la estándar (basada en Java StandAlone) como la empresarial (basada en el servidor JEE) pueden ser fácilmente configurables gracias a los contenedores de servicios. Para que funcione, cada servicio relacionado con el flujo de trabajo ha sido pensado en términos de una interfaz con diferentes posibles implementaciones, 40

41 persistencia, identidad, seguridad, tiempos, ejecución asíncrona, administración de tareas o logs de historial, son ejemplos de servicios configurables. Las APIs de Nova Bonita se dividen en 5 áreas: - DefinitionAPI: Usada para crear y modificar elementos mayores de un proceso en el motor. Por ejemplo, paquetes, procesos, actividades, roles y variables llamadas a través de métodos de Java en vez de la importación de archivos XPDL. También permitirá modificar elementos en tiempo de ejecución como tareas e instancias. - QueryDefinitionAPI: Usada para obtener la definición del flujo de trabajo para paquetes, procesos, actividades, roles, etc. - RuntimeAPI: Usada para administrar procesos, instancias y realizar tareas del ciclo de vida, así como asignar y actualizar variables. - QueryRuntimeAPI: Usada para obtener información almacenada y en tiempo de ejecución de paquetes, procesos, instancias, actividades y tareas. Permite también obtener listas tareas (actividades manuales) parametrizadas por el estado de autenticación del usuario así como también obtener y listar variables de un conjunto de instancias particulares de flujos de trabajo. - ManagmentAPI: Usada para desplegar procesos del flujo de trabajo en el motor. Archivos XPDL y entidades como mapeadores o realizadores de tareas pueden ser desplegadas individualmente o de una vez. - CommandAPI: Es una API genérica que permita ejecutar comandos específicos que pueda necesitar la aplicación basada en el flujo de trabajo. Permite a los desarrolladores escribir y ejecutar sus propios comandos empaquetados dentro de la aplicación. 41

42 El servicio de Nova Bonita funciona sobre el servidor JOnAS. JOnAS [10] es un servidor de aplicaciones J2EE de código abierto implementado en Java. Forma parte de la iniciativa de código abierto de ObjectWeb, la cual fue lanzada en colaboración con varios socios, entre los que se encuentran Bull, France Télécom e INRIA OpenWFE a) Descripción Su nombre proviene de la sigla Open Source Ruby Workflow Engine. El motor de workflow Route está escrito en Ruby. Un proceso es iniciado cuando se le entrega al motor una definición de proceso al motor. Un proceso es expresado en Route en su propio lenguaje, los que pueden ser XML y Ruby DSL. Una definición de proceso describirá el flujo de trabajo entre varios participantes. b) Arquitectura El motor de Route puede tener simultáneamente múltiples instancias de procesos, creadas desde uno o más procesos diferentes. Además, Route permite modificar los procesos mientras corren. A pesar de que es reconocido como un motor bastante usado, no se profundizará en Open WFE por funcionar en una plataforma que no se usa ampliamente como Java o.net. 42

43 2.3 Análisis De las soluciones presentadas, Intalio es la solución que destaca frente a las otras gracias a que satisface de mayor y mejor manera los requerimientos para implementar BPM. Ésta plataforma tienen un completo ambiente de desarrollo de procesos, utilizando el IDE Eclipse, el cual permite trabajar con toda la gama de elementos de la notación BPMN v1.2 y desplegar fácilmente los procesos al lenguaje ejecutable BPEL 2.0 o inferior. El problema de este último es que no tiene un soporte nativo de interacciones humanas 12. Por otro lado OpenWFE, Enhydra Shark y Nova Bonita poseen una poderosa interfaz Web, destacándose la ultima con una implementación en Web 2.0, permitiendo desligarse de una aplicación de escritorio, como un IDE, para definir procesos de negocio. Se comunican en XPDL, que permite representar todos los elementos de BPMN y soporta interacciones humanas. Por último, jbpm es el más difícil de usar, debido a que no es una plataforma pensada para el usuario final, sino un framework para ser reutilizado por desarrolladores en otras aplicaciones. En esta solución se definen los procesos en JPDL, el que es una versión limitada del lenguaje XPDL. Todas las soluciones presentadas, a excepción de jbpm, son buenas iniciativas de BPMS código abierto para ser usados, luego de una capacitación, por un usuarios finales, tales como el personal de una pyme. Sin embargo, si bien se tiene la capacidad de definir y ejecutar procesos con estas herramientas, al comparar con un BPMS comercial se dejan fuera importantes funcionalidades como la gestión de reglas de negocio o gestión de contenidos, y se presenta una seria falta de colaboración del sistema con la organización, debido a que obliga a los usuarios a manejar una cuenta exclusiva para el BPMS, lo cual atenta contra la filosofía de integración de la disciplina. 12 Para reparar esta falencia, se creó un estándar complemento llamado BPEL4PEOPLE. 43

44 2.4 Plataformas código abierto A continuación se describirán diversas plataformas código abierto que podrían servir para implementar las funcionalidades de un BPMS comercial y suprimir el problema de integración planteado en el punto anterior. Están clasificadas por módulos operativos Comunicación e integración a) LDAP No es una plataforma, como el resto de las soluciones que están a continuación, sino que es un protocolo. Su nombre proviene del inglés Lightweight Directory Access Protocol. Es de tipo cliente servidor y permite control de acceso un servicio de directorio. La importancia de incluir a LDAP en este trabajo es que podría permitir utilizar las mismas cuentas de usuario que estén en un servidor, que implemente este protocolo, de la organización. Así se evitará tener diferentes autenticaciones para las mismas personas de una organización. b) Open ESB Un ESB es [12] una aplicación Middleware cuyo rol es proveer interoperabilidad entre diferentes protocolos de comunicación. Por ejemplo, no es poco común para una compañía recibir órdenes en ASCII a través de protocolos antiguos como FTP. Un ESB puede estimular que la orden del FTP se transforme a XML, y así poder ingresarla internamente a un servicio web para se consumido y procesado. A pesar de que esto pude hacerse a manualmente, el ESB ofrece adaptador fuera de caja para tales procesos, y más comúnmente, herramientas de modelos de flujo de eventos visuales para generar cadenas de 44

45 microflow. El costo ahorrado sobre las técnicas convencionales de codificación es generalmente substancial. Los servicios Web son los protocolos que se comunicará en ESB, entre los cuales están los nombrados en el capítulo anterior (Wf-XML 2.0, BPEL y WSCI). OpenESB es iniciativa iniciada por Sun Microsystems y es mantenida por el proyecto Java. Todos los participantes del proyecto Open ESB son empleados de Sun. Open ESB es una implementación de la especificación JBI. JBI (del inglés, Java Business Integration) es un estándar [13] que define una arquitectura que permite integración de productos a ser construidos basándose en componentes que pueden ser conectados en el ambiente JBI, tal como se ve en la figura 2.20 a continuación Figura 2.20: Esquema del sistema de construcción mediante conexiones Los componentes conectados pueden entonces proveer servicios adicionales, consumir servicios o ambos. Por ejemplo, el componente A podría proveer una funcionalidad de transformación XSLT, mientras que el componente B podría consumir mensajes JMS (del inglés Java Message Service). A continuación, en la figura 2.21 se presenta un esquema arquitectónico de JBI. 45

46 Figuras 2.21: Esquema arquitectónico de alto nivel de JBI Uno de los subproyectos que componen a Open ESB es una implementación del ambiente de runtime que fue iniciado para proveer una implementación de JBI al servidor de aplicaciones Glashfish de Sun. Otro ejemplo de subproyecto es el componente de enlace de JMS y un motor de servicio BPEL. En la figura 2.22 que se encuentra a continuación, se presenta un esquema de arquitectura básico del ESB [14]. Figura 2.22: Arquitectura de Open ESB 46

47 c) JBoss ESB Jboss ESB [15] es ampliamente conocido y popular por ser el servidor de aplicaciones de la serie de framework como Hibernate, un maleador objetorelacional; Seam, un framework para la construcción de aplicaciones Web 2.0 y jbpm, un motor de procesos. En el área de la integración empresarial, Jboss provee un JMS llamado JBossMQ (predecesor de JBoss Messaging) y un motor de reglas llamado JBoss Rules. En el 2006, JBoss adquirió un ESB llamado Rosetta, el cual fue usado para construir JBoss ESB que cumple con todas las funcionalidades con las que debe cumplir un ESB [15]. Para la lógica personalizada y soporte de servicios Web, se tiene a EJB 3 (del inglés Enterprise JavaBeans) y a POJO (del inglés Plain Old Java Object) los que pueden ser desarrollados y desplegados en el servidor de aplicaciones de JBoss. A continuación se presenta las figuras 2.23, 2.24 y 2.25, las cuales explican de manera top-down [16]. Figura 2.23: Arquitectura de Jboss ESB desde un nivel de abstracción que pueden verse las relaciones con otros sistemas. 47

48 Figura 2.24: Arquitectura de Jboss ESB desde un nivel de abstracción que pueden verse las entidades con las que interactúe Jboss ESB. Figura 2.25: Arquitectura de Jboss ESB desde un nivel de abstracción donde se pueden ver los componentes del ESB y su relación con otros componentes. Las otras tecnologías descritas son sólo de ejemplo, podrían no estar, o, haber más. 48

49 d) Fuse ESB Fuse ESB es parte de una integración de aplicaciones y componentes de mensajería basadas en proyectos Apache, que incluyen Fuse Message Broker, Fuse Services Framework y Fuse Meditation Router. Fuse ESB utiliza JBI al igual que Open ESB, el cual fue detallado antes. Fuse ESB tiene una arquitectura conectiva que permite conectar cualquier estándar basado en el motor de servicios JBI, o un componente de enlazado o un paquete adaptable OSGi, incluyendo BPEL, XSLT o motores JMX, además de AJAX, REST, HTTP, SSL, UDP y protocolos de transporte de multi invocación; estándares de servicios Web, SOAP, WSDL, JAX-WS, JAX-RS, WS-Security y WS-ReliableMessaging; especificaciones dependientes tales como JTA y JNDI; correo electrónico y FTP (del inglés File Transfer Protocol); APIs basadas en JBI con las cuales Fuse ESB soporta WS-BPEL 2.0 para orquestación, XSLT, XQuery, framework Smooks y soluciones compatibles con JMX para gestión de sistemas. Fuse ESB. A continuación, en la figura 2.26 se presenta un esquema arquitectónico de 49

50 Figura 2.26: Arquitectura de Fuse ESB e) WSO2 ESB WSO2 es un ESB que usa como base a Apache Synapse y se distribuye como código abierto bajo la Apache License para el detalle de las licencias de software). El framework viene integrado con soporte XML, Namespace, Xpath, XSLT, XQuery y XOP; servicios Web, como SOAP 1.1 / SOAP 1.2, WSDL 1.1 / WSDL 2.0, WS-Addressing, WS-Security, WS-ReliableMessaging, WS-Policy, MTOM/SwA y XML/HTTP(POX) y formatos REST; protocolos, como HTTP/S, JMS 1.x, archivos Apache VFS, Mail (POP3, IMAP, SMTP), FIX (del inglés Financial Information exchange), AMQP y mensajes binarios hesianos, entre otras características. A continuación, en la figura 2.27, se presenta un esquema arquitectónico de su funcionamiento. 13 Sitio sobre licencias Apache, 50

51 Figura 2.27 Arquitectura de WSO2 ESB f) Apache ServiceMix La base de Apache SerivceMix [15] es la especificación JBI, explicada anteriormente en la sección de Open ESB el cual también hace uso de ella, entregada por JCP (del inglés Java Community Process) bajo la JSR (del inglés Java Specification Request) 208 en el Apache ServiceMix puede ser integrado con otros proyectos Apache como Apache ActiveMQ, es un servicio de mensajería que provee seguridad y hace posible un ambiente distribuido y clustering. ServiceMix puede ser integrado también con Apache CXF, Apache ODE, Apache Camel, Apache Jerónimo, Jboss y con cualquier contenedor. Está implementado en muchas empresas en el mundo. A continuación, en la figura 2.28 se presenta un esquema arquitectónico de alto nivel de Apache ServiceMix. 51

52 Figura 2.28: Esquema arquitectónico básico de Apache ServiceMix g) PEtALS PEtALS, al igual que Apache ServiceMix y OpenESB, también se basa en JBI y está certificado oficial por Sun Microsystems en marzo del Nació debido a que expertos en EAI (del inglés Enterprise Application Integration) de EBM Websourcing se sentían insatisfechos con las soluciones de integración existentes y decidieron lanzar un proyecto código abierto llamado PEtALS. Posteriormente, PEtALS fue soportando nuevas tecnologías como JMS, SMTP, SOAP, FTP, entre otros. Su arquitectura está centrada en proveer un ambiente distribuido donde diferentes instancias de PEtALS son continuadamente integradas al ambiente ESB. Esto significa que los servidos mantenidos en diferentes instancias están disponibles a para acceder a otra unidad sin una configuración adicional. A continuación, en la figura 2.29, se presenta un esquema del flujo de mensajes de PEtALS. 52

53 Figura 2.29 Esquema básico del funcionamiento de mensajería de PEtALS. h) Mule ESB Mule [17] es un ESB liviano orientado a eventos y una plataforma de integración flexible, a pesar de no reutilizar la arquitectura JBI como otros ESB. Mule ofrece conectividad a más de 20 protocolos de transporte e integra con un largo número de proyectos de integración incluyendo Spring, ActiveMQ, Joram (del inglés Java Open Reliable Asynchronous Messaging), Apache CFX, Apache Axis y JBoss Drools. A continuación, en la figura 2.30, se presenta un ejemplo de la mensajería de Mule, y en la figura 2.31, un esquema arquitectónico básico. 53

54 Figura 2.30: Esquema del flujo básico de información de Mule ESB. Figura 2.31: Esquema arquitectónico básico de alto nivel 54

55 2.4.2 Interfaz de usuario a) IDE Eclipse Eclipse 14 es un ambiente de desarrollo de software extensible a través de plug-in. Está escrito en Java y es usado para desarrollar aplicaciones Java. Sin embargo, con el uso de plug-in, se puede usar para otros lenguajes como C, C++, COBOL, Python, Perl, PHP, entre otros. La gran mayoría de los BPMS comerciales y de código abierto usan Eclipse como plataforma para interactuar con el usuario. b) Jboss Portal Un portal Web permitirá a todos los usuarios interactuar con las herramientas que ofrece un BPMS de manera personalizada. Según Wikipedia, un portal se define de la siguiente manera: Un portal de Internet es un sitio web cuyo objetivo es ofrecer al usuario, de forma fácil e integrada, el acceso a una serie de recursos y de servicios, entre los que suelen encontrarse buscadores, foros, documentos, aplicaciones, compra electrónica, etc. Principalmente están dirigidos a resolver necesidades específicas de un grupo de personas o de acceso a la información y servicios de una institución pública o privada. Es una definición completa y da a entender que un portal es un elemento que integra información de manera cómoda para diversos usuarios agrupados A continuación se tiene otra definición de Sun Microsystems, la cual se encuentra en la especificación del estándar JSR 286. Se presenta en inglés ya que no existe una traducción oficial

56 A portal is a web-based application that commonly provides personalization, authentication, [and] content aggregation from different sources and hosts the presentation layer of information systems. Esta última definición complementa a la de Wikipedia en que explica que el contenido se provee de diferentes fuentes y corresponde a la capa de presentación de sistemas de información. Basándose en ambas definiciones, se concluye que un portal debe ser un punto de integración de sistemas proveedores de información y servicios, los que se desplegarán a diversos usuarios según sus perfiles de manera personalizada y privada, gracias mediante métodos de autenticación y canales seguros de comunicación respectivamente. El portal de JBoss es un framework que entrega una composición de aplicaciones Web. Los estándares soportados son JSR-168 (Especificación de Portlets y API 1.0), JSR-170 (Repositorio de contenido para tecnología Java), JSR-252 (Java Server Faces 1.2), JMX 1.2 (del inglés Java Management Extension), WSRP (del inglés Web Services for Remote Portlets) 1.0 Base Level y es conforme a J2EE cuando es desplegado sobre el servidor de aplicaciones de JBoss. Sobre la arquitectura, JBoss Portal puede ser usado para lograr un mayor rendimiento a través de servicios middleware con el servidor de aplicaciones de JBoss, JBoss Cache, JGroups e Hibernate. Gracias a éste último, se podrá comunicar con cualquier motor de bases de datos relacional que lo soporte. Otras tecnologías importantes es la capacidad de funcionar con SSO/LDAP, autenticación JAAS, Cacheing, Custering y un instalador SAR basado en navegador que permite hacer la instalación de manera rápida. A continuación se presenta la figura 2.32, donde muestra la jerarquía de los objetos que participan en el portal [18]. 56

57 Figura 2.32: Jerarquía de los objetos de Jboss Portal. c) Liferay Portal Liferay es un portal código abierto muy popular y que cumple con todas las funcionalidades de un portal empresarial. Posee las siguientes funcionalidades principales [19]: 1. Uso de estándares JSR-168/JSR Funciona como CMS y WCM 3. Permite la colaboración y es un software social gracias a que posee de manera integrada blogs, calendarios, correo, paneles de mensajería, encuestas, RSS feed, Wiki, alertas, anuncios, noticias. A continuación, en la figura 2.33, se presenta un esquema arquitectónico de alto nivel de Liferay Portal. 57

58 Figura 2.33: Esquema arquitectónico de Liferay Portal Gestión de contenido Existen varios sistemas de gestión de contenido, tales como los CMS (del inglés Content Management System), WMS (del inglés Web-based Content Management) y ECM (del inglés Enterprise Content Management), cada uno con diferentes alcances. Un ECM [20] es un término ambiguo ya que no hay una definición oficial. Un proveedor de ECM frecuentemente lo describen como una colección de tecnologías de contenido céntrico que incluye un gestor de documentos (del inglés Document Management), el cual captura, organiza y comparte archivos binarios. Un WCM, el cual administra los archivos y contenido específicamente para ser desplegados por Web. La clave de WCM es reducir cuellos de botella al diseñador Web y la capacidad de los propietarios de los contenidos publicar de manera fácil. Un DAM (del inglés Digital Asset Management), el cual administra gráficos, video y audio, un RM (del inglés Records Management), que administra contenido como registros legales como políticas, planos y documentos de auditoria. Finalmente un contenedor de imágenes de captura, etiquetado e imágenes provenientes de documentos de escáner. Algunos ofrecen también colaboración, búsqueda y ocasionalmente, portales. Como alternativas de código 58

59 abierto se tiene a los portales antes nombrados (Jboss Portal y Liferay Portal), que tienen sus propios sistemas de administración de contenido, y a Alfresco a) Alfresco Alfresco es un ECM que contiene todas las características nombradas anteriormente, aunque también se destaca algunas [20] como integración con herramientas de auditoria (como Microsoft Office), seguridad, servicio de versiones, meta data, workflow, escalabilidad/confiabilidad e interfaz de usuario personalizable. A continuación se presenta la figura 2.34 que muestra detalles [21] de funcionalidades y arquitectura del software. Figura 2.34 Esquema arquitectónico y funcional de Alfresco CMS Monitoreo de actividades de negocio (BAM) El concepto de Monitoreo de actividades de negocio o BAM (del inglés Business Activity Monitoring) se refiere a la capacidad de obtener visibilidad de los procesos que están siendo ejecutados por la organización en tiempo real. La 59

60 implementación se realiza a través de diferentes plataformas que ofrecen paneles de información (del concepto en inglés dashboard que parece ser más preciso) que reflejan el curso del progreso y recursos utilizados por los procesos de negocio que están ejecutándose. Para poder realizar un monitoreo de actividades, se puede lograr de diferentes maneras en función de la información que una organización requiera para poder tomar decisiones de nivel empresarial. En la presente memoria se presentarán dos framework que permiten generar reportes de inteligencia de negocios que podrían suplir la información necesaria para hacer un seguimiento correcto de los procesos de negocio, y, para poder realizar decisiones. Estas implementaciones son SeeWhy y Pentaho. a) SeeWhy SeeWhy es un framework que sirve de herramienta generadora de reportes. Ésta plataforma interactúa con el usuario de 2 maneras, a través de un módulo de administración llamado Desktop y otro donde se pueden ver el resultado de los reportes, llamado Navigator ambos basados en Web. Para su funcionamiento [22] SeeWhy está diseñado para aceptar eventos de datos desde otros sistemas y transformarlos en información, la cual se puede transformar en notificaciones y reportes en paneles de información o dashboard. A continuación, en la figura 2.35 se presenta un ejemplo del funcionamiento de ésta solución. 60

61 Figura 2.35 Esquema de ejemplo del funcionamiento de SeeWhy. La plataforma trabaja con la información que va almacenando, en este caso, el motor de BPM jbpm. b) Pentaho Pentaho es una suite liviana, de código abierto y fácil de usar para proyectos de Java con el único propósito de generar reportes. Los usos más comunes son reportes operacionales, financieros, producción e inteligencia de negocios. La arquitectura de ésta solución provee a desarrolladores modificar y contribuir al desarrollo del motor de reportes, dando flexibilidad al acceso del código fuente. A continuación, en la figura 2.36 se presenta un esquema de la arquitectura de las clases, y sus dependencias, que componen al motor de reportes de Pentaho. 61

62 Figura 2.36: Esquema arquitectónico de Pentaho Gestión de reglas de negocio La gestión de reglas de negocio se lleva a cabo a través de un motor de reglas de negocio, en el cual se declaran reglas tal cual lo hace un analista de negocio en un requerimiento (un grupo de sentencias if-then-else). Un motor toma estas reglas y la ejecuta con la información de la organización de la manera más eficiente. Como ejemplo, se tiene el típico caso de un banco que evalúa si puede dar crédito a cierto cliente, o el del algún supermercado que decida que artículos debería poner en ciertos estantes de cierto pasillo. Como alternativa de implementación de motor de reglas de negocio de código abierto se tiene a JBoss Rules, más conocido como Drools. a) Drools Drools [23] es un BLiP (del inglés Business Logic integration Platform), está escrito en Java y es un proyecto código abierto. La plataforma consiste en 4 62

63 módulos principales, Drools Expert, el cual es el motor mismo, Drools Fusión, el cual es el módulo CEP (del inglés Complex Event Processing), Drools Flow, el cual combina reglas y procesos, Drools Guvnor, el cual es un sistema de reglas de negocio avanzado y Drools Solver, un módulo opcional que contiene un algoritmo de búsqueda para resolver problemas planteados, como por ejemplo líneas de tiempo. A continuación, en la figura 2.37, se presenta del funcionamiento de Drools Figura 2.37: Esquema arquitectónico que ejemplifica el funcionamiento de Drools 63

64 Capítulo 3: Propuesta de Solución En los capítulos anteriores se ha revisado lo que busca la disciplina BPM, las funcionalidades de un BPMS comercial. Con la información recopilada en esas secciones se puede resumir que se necesita un sistema que: - Permita definir, almacenar y ejecutar procesos de negocios orquestados a través de workflow optimizando la cadena de valor de la organización. - Permita integrar a los miembros de la organización, de manera de que los procesos ejecutados que involucren a varios usuarios sean colaborativos. - Permita tener un espacio de trabajo que facilite la información de eventos que sucedan en la organización, así como la comulación entre personas y equipos de trabajo. También es necesario tener la capacidad de llevar un registro de documentos personales o compartidos de manera de facilitar el trabajo colaborativo. - Permita definir reglas de negocio y tener la capacidad de actualizarlas fácilmente si alterar implementaciones que hagan uso de ellas, tales como procesos de negocio. - Permita monitorear actividades de negocio de manera de tener indicadores para tomar decisiones estratégicas de la organización. - Permita conectarse a otros sistemas y/o que otros se conecten a él. Gracias a este resumen y la revisión de funcionalidades de las plataformas código abierto del capítulo anterior, se puede comenzar a planear una solución factible que permita satisfacer el problema planteado. A continuación se presenta el diseño de la propuesta de este trabajo. 64

65 3.1 Diseño de la solución La solución propuesta tiene una arquitectura como la que se puede ver en la figura 3.1 que está a continuación. Figura 3.1: Esquema arquitectónico de la solución propuesta Las funcionalidades se cubren usando las siguientes plataformas: - Gestor de procesos: JBoss jbpm. - Comunicación e integración: Mule ESB. - Gestión de contenido: Alfresco. - Monitoreo de actividades de negocio: Pentaho. - Gestión de reglas de negocio: JBoss Drools. - Protocolo de autenticación: LDAP. Otras plataformas que son requisito para el funcionamiento básico de los framework nombrados anteriormente. - Servidor Web y de aplicación: Apache Tomcat 6.0 y Tomcat

66 - Ambiente para desarrollo: Eclipse Galileo más plugin de jbpm. - Persistencia: MySQL Detalle de la solución A excepción del BRMS Drools, las aplicaciones constan de un portlet, se comunican a través del ESB o de alguna clase Java (puede ser un framework MVC como Spring, un EJB o un servlet), y, almacenan datos en la base de datos Interfaz de usuario Los portlet permiten interactuar con el usuario a través de aplicaciones específicas desplegadas en ellos. Un portlet es un componente modular personalizable, similar a una ventana de un sistema de escritorio de un sistema operativo, donde un usuario puede usar una aplicación en función del rol, comunidad que pertenece, o, si es que está registrado en el sitio. Liferay soporta la especificación Java Portlet 2.0 (llamada JSR-286). El contenido de un portlet, el que es generado por él, se le llama fragmento. Un fragmento es una pieza de código estructurado (por ejemplo HTML, XHTML, WML, etc.) adherido a ciertas reglas y puede ser agregado a otros fragmentos para formar el documento completo. Otro aspecto de la interfaz de usuario es el uso del IDE Eclipse para definir procesos. Al igual que muchos BPMS comerciales (como por ejemplo ActiveVos y Oracle BPM) y de código abierto (como por ejemplo Intalio y Enhydra Shark) se recurrió al uso de este ambiente de desarrollo debido a que no se logró encontrar una herramienta Web de código abierto que permitiera definir procesos de negocio y desplegarlos de manera fácil al motor BPM escogido. Esto último es una pequeña falencia de la solución propuesta, debido a que se necesitará que el 66

67 usuario, una vez que defina, exporte su proceso en formato XML y lo despliegue manualmente en el portlet de jbpm del portal Liferay para su ejecución Flujo de la información Una de las soluciones para permitir el flujo de datos de distintas plataformas entre dos puntos comunes del sistema es el uso de un ESB. Mule, permite comunicar las diferentes aplicaciones usadas desde la interfaz, a través de los portlets, hasta la persistencia, materializada gracias al motor de bases de datos relacional MySQL. Específicamente, Mule permitió conectar los portlet al servicio de procesos de negocio de jbpm de manera fácil, permitiendo abstraer el uso de la API del motor de BPM escogido. También, el uso de Mule, podría permitir la conectividad con futuras plataformas y/o otros sistemas, los que podrían ser antiguas implementaciones. Esta conexión se puede lograr gracias a wrappers que se encargan de hacer una interfaz de servicio Web para poder comunicarse con soluciones creadas en plataformas deprecadas (como COBOL o PRO-C), pero que aún se usan bastante, sobre todo en organizaciones que llevan años en el mercado y no desean modernizar sus aplicaciones debido a que se hace más económico mantenerlas funcionando que construirlas de nuevo sobre una tecnología más avanzada Motores de aplicaciones Son aquellos cuadros de la figura anterior etiquetados como engine. Corresponden a la lógica de las aplicaciones, procesan las solicitudes de portlets y almacenan información en la base de datos relacional. Podrían ser servlet o servicios Web y, además, podrían estar implementados en diferentes servidores. 67

68 3.2.5 Persistencia El almacenamiento de datos, tanto usuarios, roles, datos estadísticos, entre otros se lleva a cabo a través de MySQL. El almacenamiento de objetos de un mantenedor de contenidos se haría en el mismo servidor Web. 3.3 Obtención de la solución Con el diseño de la solución y los requerimientos funcionales determinados gracias al análisis operativo de los BPMS comerciales y las prácticas de la disciplina BPM, se puede implementar la propuesta y probar su funcionamiento, que es el objetivo del capítulo 4. Sin embargo no se logró la construcción ideal de todos los módulos operativos en un único prototipo, debido a problemas de arquitectura de software. Específicamente, por problemas de versiones entre los componentes, así como la del compilador de la plataforma Java, con el que fue diseñado la construcción y despliegue de cada framework. La solución a esto fue realizar varios prototipos, los que en suma dan como resultado el sistema deseado. Para llegar a ésta solución, se comenzó un completo estudio de la documentación de conectividad entre soluciones. La primera opción fue partir por la combinación de soluciones basándose en JBoss, sin embargo el portal de Liferay ofrecía más funcionalidades, interfaces de usuario atractivas y cómodas, y, soporte nativo para la integración de las plataformas jbpm y Mule ESB. Con Liferay, jbpm y Mule ESB escogidos, se determinó a Alfresco como CMS gracias a recomendaciones de la comunidad y libros de referencia para realizar las integraciones con Liferay. 68

69 SeeWhy y Pentaho tenían sus beneficios. Por un lado, SeeWhy tiene una integración nativa con jbpm a través del servidor de aplicaciones de JBoss, mientras que Pentaho, su comunidad ha hecho uso de él con Liferay. Para el prototipo de ésta memoria se usó Pentaho debido a su rápida implementación. Por último, no se encontraron muchas opciones respecto a un motor de reglas de negocio. La opción de Drools fue prácticamente la única donde se encontraron referencias y una comunidad que permitieran disminuir el riesgo de la incapacidad técnica y la posible falta de conocimiento para poder lograr la integración con ésta plataforma. 3.4 Prototipos Para lograr la demostración, se hicieron 4 prototipos. A pesar de que hubiese sido óptimo haber integrado todas las tecnologías en un solo prototipo, no se pudo debido a conflictos de compatibilidad y falta de conocimiento específico de cada plataforma. Con el primer prototipo se logró integrar y usar Liferay, Mule ESB, JBoss jbpm. Por problemas de versiones, se tuvo que desarrollar un segundo prototipo para integrar Liferay con Alfresco, debido a que no se logró hacerlo funcionar con el primero. Un tercer prototipo se usó para integrar Liferay con Pentaho, y un cuarto para demostrar el uso de Drools, como BRMS, con jbpm. Para todos, se usó el IDE Eclipse más el plugin del diseñador de procesos de jbpm para crear nuevas definiciones de procesos de negocio. En resumen, se diseñaron 4 prototipos: - Prototipo A: Liferay, Mule ESB y jbpm. - Prototipo B: Liferay, Alfresco y LDAP. 69

70 - Prototipo C: Liferay y Pentaho - Prototipo D: Drools y jbpm A continuación, en la figura 3.2, se presenta una imagen del primer prototipo (Liferay integrado con Mule ESB y JBoss JBPM) Figura 3.2: Imagen del primer prototipo. Se pueden ver entre los portlet el correspondiente al de jbpm (pestaña etiquetada como Workflow ), 70

71 Capítulo 4: Validación de la propuesta Para validar la propuesta se probará cada uno de los prototipos presentado en el capítulo anterior. Para esto, se creará un caso de un proceso de negocio de una pyme. Esta será una pequeña clínica ficticia llamada Clínica1, la que se supondrá que posee cerca de 50 trabajadores, entre los cuales se encuentran, doctores, especialistas, enfermeros (as), secretarias, directores y un representante legal. La dirección de Clínica1 ha decidido probar, con la disciplina BPM, orquestar su proceso de atención a pacientes internados, debido a que se han producido anomalías y negligencias en la atención, provocados por falta de información, comunicación y/o una inapropiada toma de decisiones por parte de los participantes de la organización. Para comenzar con la implantación de la disciplina se determinaron objetivos del proyecto, participantes del proceso, acciones, decisiones y responsables. En un caso real, un proyecto de implementación debería además definir alcances, criterios de éxito, requerimientos técnicos, análisis FODA, estudios de mercado, determinación de la cadena de valor de toda la organización y un plan de proyecto detallado con fechas y duración de cada fase, reuniones entre todos los participantes para definir el proceso y sus responsables, entre otras especificaciones propias de la adopción de una disciplina. Similar a la especificación proyectos informáticos de sistemas como ERPs o CRMs. - Objetivo: Perfilar el proceso de atención de clientes internados como para ser implementado bajo BPM de manera que logre una mayor coordinación de empleados de Clínica1, evitando negligencias, obteniendo retroalimentación y mejorando la calidad del servicio. - Participantes del proceso: 71

72 o Secretaria: Registra al paciente y crea ficha médica o Doctor: Está a cargo del paciente. Toma decisiones diagnosticando, determinando un tratamiento y realizando un seguimiento del progreso del paciente. o Enfermeros: Llevan a cabo el tratamiento del doctor. Controlan y proveen medicamentos al paciente. o Especialista: Realiza diagnóstico cuando el doctor necesita de conocimientos específicos. o Paciente: Es el que hace uso del servicio de la clínica. Necesita del tratamiento de un doctor. Después de una reunión entre los participantes del proceso de la organización, los participantes lograron un bosquejo del proceso de atención de un paciente internado, tal como se presenta en la figura 4.1 que está a continuación. Figura 4.1: Bosquejo del proceso que se logró en la reunión El bosquejo anterior ahora servirá para definir el proceso y comenzar a usar BPM. Existen varios métodos, sin embargo en este caso lo más cómodo es usar BPMN para poder mostrar un diagrama formal que puede ser leído 72

73 fácilmente por los participantes para su aprobación, y, puede ser ingresado a un BPMS para su definición, ejecución y control. A continuación, en la figura 4.2, se presenta en notación BPMN el proceso definido anteriormente por los participantes. 73

74 Figura girada 4.2: Definición en BPMN del proceso bosquejado en figura anterior 74

75 El proceso fue definido con el software comercial ActiveVos. Con él, se pondrán a prueba los prototipos Prototipo A Antes de comenzar a usar el primer prototipo, se definirá el proceso en el IDE Eclipse con el plugin del diseñador de procesos de jbpm instalado. El mismo proceso definido anteriormente en ActiveVos se muestra a continuación en la alternativa código abierto que se ha escogido. Ver figura 4.3. Figura 4.3: El mismo proceso definido en ActiveVos, se definió en jbpm a través de Eclipse Como se puede observar en la figura anterior, la visualización de jbpm trabaja con un conjunto reducido de componentes basados en la notación BPMN. Algunos de los elementos faltantes son los eventos intermedios, los artefactos y swimlanes. Al marcar en la pestaña Source es posible ver la definición del proceso en formato jpdl, como en la figura 4.4 que está a continuación. 75

76 Figura 4.4: El mismo proceso en código jpdl generado automáticamente por jbpm al diseñarlo, como se muestra en la figura anterior Ahora bien, para ejecutar el proceso en el prototipo, se debe copiar el código jpdl y pegarlo en el portlet Workflow de Liferay. Para hacer esto, se debe primero presionar el botón Add Defnition, de la figura 4.5, para luego insertar la definición del proceso, como se ve en la figura 4.6. Ambas imágenes se encuentran a continuación. Figura 4.5: Portlet de jbpm. Se debe hacer clic en Add Definition para crear una nueva definición de proceso de negocio 76

77 Figura 4.6: Portlet de jbpm. Se debe hacer clic en Add Definition para crear una nueva definición de proceso de negocio Para aceptar, se presiona Save New Version, como se ve en la última figura. Posterior a eso, se pueden ver las definiciones ingresadas, donde se puede editar una definición, asignar permisos, administrar y crear una nueva instancia, tal como se puede ver en la figura

78 Figura 4.7: Se muestran los procesos definidos. Aquí se puede editar una definición, asignar permisos, administrar y crear nuevas instancias. Las funcionalidades anteriores sólo se pueden hacer si es que el usuario tiene los permisos para poder hacerlo. - Editar: Permite modificar la definición. Al guardar los cambios, jbpm no sobrescribe al proceso antiguo, si no que crea automáticamente una nueva versión. - Permisos: Permite asignar, por roles o usuarios en particular, permisos para agregar nuevas instancias de procesos definidos, modificar permisos, actualizar y ver el proceso que se está modificando. - Nueva instancia: Permite crear una nueva instancia del proceso para ser ejecutado. - Ver instancias: Permite ver las instancias creadas, buscarlas por nombre o fechas de inicio y fin, y, poder ver en que parte del proceso se encuentra. 78

79 Una vez definido el proceso, se crea una instancia para poder ejecutarlo. A continuación, en la figura 4.7, se presenta la instancia del proceso de atención de paciente internado de Clínica1 que se ha definido anteriormente. Se puede ver en aquella imagen que el motor ha comenzado a ejecutar el proceso, el cual se encuentra en el paso inicial llega paciente (ver figura 4.3) a la espera de una señal para continuar con el siguiente paso del flujo. Para hacer esto último, se debe presionar el botón signal. Figura 4.8: Se muestran las instancias algún proceso definido. En este caso, se instanció y comenzó la ejecución del proceso atención de paciente internado. Para continuar con la ejecución del proceso, se debe hacer clic en el botón de la derecha donde aparece una bandera para darle la señal a jbpm de que ha llegado un nuevo paciente para ser internado. En una nueva versión del proceso, se agregó la capacidad de que el participante del inicio del proceso pudiese agregar una descripción del paciente y la posibilidad detallar el tratamiento con el objeto de hacer el proceso más real, tal como se presenta en las imágenes a continuación, en las figuras 4.9, 4.10 y Ambas definiciones se encuentran en los anexos. También se consideró 79

80 Figuras 4.9 y 4.10: Inicio de la nueva versión del proceso de atención de paciente. 80

81 Figuras 4.11: Parte del proceso donde se especifica el tratamiento del paciente Luego, el proceso continúa con la decisión de la necesidad de un especialista para el paciente, la descripción del tratamiento, la ejecución del tratamiento y la decisión de si el paciente necesita seguir internado, sin una interacción mayor por parte del usuario. El detalle de la instalación del prototipo A se encuentra en el anexo Prototipo B El propósito del prototipo B es agregar la funcionalidad de un administrador de contenidos de nivel empresarial. A pesar de que Liferay viene con uno por defecto, este no satisface las necesidades que tendría una pyme, por lo que se recurrió a la versión comunitaria de Alfresco. Ante el fallido intento de hacer todo en un solo prototipo, causado por problemas arquitectónicos entre la versión escogida de Liferay para el funcionamiento de jbpm y la que es compatible con Alfresco, se crea un segundo prototipo con una nueva versión del portal compatible con el administrador de contenido escogido. 81

82 A continuación, en la figura 4.12, se presenta una imagen del prototipo B en funcionamiento. 82

83 Figura 4.12: Imagen del prototipo B 83

84 La necesidad de tener un contenedor de documentos de puede ver en el caso de ejemplo, donde, durante el curso de la ejecución proceso de la atención de un paciente internado en la Clinica1, posiblemente se generen varios documentos, tal como la ficha médica, la cual aparece especificada en la figura del esquema en BPMN, reportes del especialista, o una lista de medicamentos que son necesarios para el tratamiento. Se mostrará a continuación, en las figuras 4.13 a la 4.21, el funcionamiento del prototipo B (Liferay con Alfresco) considerando la necesidad de Clinica1 en el almacenamiento de documentos (u otros elementos, que bien podrían ser archivos ejecutables, presentaciones, diagramas de flujo, hojas de cálculo, entre otros dependiendo de la organización) que puedan ser creados, modificados y accesados por diferentes usuarios del sistema, en función de su rol dentro de la organización. Para partir, se crea el supuesto de que se necesite subir el documento que contiene la lista de medicamentos de un paciente internado, y, que se requiere que sea compartido entre otros usuarios del sistema, como por ejemplo el doctor y el especialista. Como el contenedor está completamente vacío, como en la figura 4.12, El primer paso es crear un espacio en Alfresco. Un espacio es similar a una carpeta en el sistema de ficheros de un sistema operativo donde se pueden poner archivos tales como documentos de texto, páginas Web, hojas de cálculo, etc. Se puede crear un espacio de dos maneras distintas, en el portlet del espacio de trabajo principal Alfresco (figura 4.13), y en el portlet denominado mis espacios (figura 4.14). 84

85 Figura 4.13: Imagen del portlet mis espacios. Alternativa para crear espacios. Figura 4.14: Imagen del porlet principal de Alfresco, lugar en el cual se pueden crear espacios, al igual que en el portlet mis espacios de la figura anterior. Una vez creado el espacio, se puede administrar en el portlet principal, como se ve en la figura

86 Figura 4.15: Imagen del porlet principal, donde se puede ver el nuevo espacio creado. Para crear nuevos elementos, como por ejemplo el documento imaginario lista de medicamentos que es creado en algún punto durante la ejecución del proceso, se puede operar de dos maneras. La primera es subir un archivo creado por algún software de escritorio, o crearlo en línea gracias al editor empotrado que posee Alfresco. En la figura 4.16 se presenta la primera opción y en las 4.17 y 4.18 la segunda. Figura 4.16 Imagen tomada en el momento de la creación de nuevo contenido. En este caso, se está subiendo un archivo creado en el equipo cliente. 86

87 Figuras 4.17 y 4.18: Imágenes tomadas en el tomento de la creación de nuevo contenido. En este caso, se está creando un archivo en el mismo servidor. Otra necesidad potencial de la pyme y del proceso, es que el archivo creado sea compartido con otros usuarios y/o grupos de usuarios para su lectura y/o modificación. Alfresco permite administrar estas propiedades desde el panel de trabajo principal, donde se puede configurar el acceso a cada elemento del espacio, o, el espacio completo, como se muestra en la figura 4.19 a continuación. 87

88 Figuras 4.19: Imagen donde se muestra la configuración del acceso al archivo. Se puede observar que se puede asignar permisos a los diferentes roles creados en el sistema. El detalle de la instalación del prototipo B se encuentra en el anexo Prototipo C El objetivo del tercer prototipo, denominado prototipo C, corresponde a cubrir la funcionalidad de monitor de actividades de negocio. El concepto se puede llevar a cabo de diferentes maneras, en función de la información que necesite una organización para tomar decisiones y de la tecnología con la cual se puedan lograr estos reportes. Una de las herramientas más poderosas, más referenciadas y de código abierto en el uso de generación de reportes, creación de cubos de datos y otros elementos para la inteligencia de negocios es Pentaho. Es por esto que se creó un prototipo donde se integra la versión con Pentaho. Para lograr la integración, se sigue un tutorial [24] que se encuentra en un sistema wiki en el sitio Web de Liferay. El resultado de la serie de pasos, que se puede encontrar en la página, es un ejemplo de la capacidad de los portlets de Pentaho donde se simula el cálculo de un presupuesto de una organización al configurar un filtro, el cual tiene su propio portlet, con un despliegue dinámico de 88

89 una serie de dashboards y la capacidad de generar reportes en formato PDF y/o enviar al correo un a ciertos destinatarios con los informes generados. Todos los portlets involucrados en el ejemplo, tanto donde se realiza el filtro como lo que generan los dashboards, se presentan en la figura 4.23, donde se puede apreciar el prototipo C en pleno funcionamiento. Figuras 4.20: Imagen del prototipo C. El portlet Filtros permite fijar un conjunto de parámetros, lo cuales determinan los valores para generar dashboads que permitan la gestión estratégica de la organización. Entonces, en el caso de nuestro ejemplo de pyme, se podría crear un nuevo portlet que permita realizar informes con el conjunto de variables que resultan del proceso de atención de un paciente internado en la Clínica1, como por ejemplo la cantidad de medicamentos, exámenes, enfermeros, visitas al especialista que se necesitaron, y/o tiempos que se tomó en mejorar o no al paciente, etc. Para poder realizar inteligencia de negocios, se deberá profundizar en el tema analítico y estratégico que permitan el desarrollo de elementos que permitan 89