Prototipo de Integración entre Aplicaciones de Software y la Metodología

PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE SOFTWARE Y LA METODOLOGÍA BPM.

CAMILO ANDRES PEREZ VALDERRAMA

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLOGICA

INGENIERIA EN TELEMÁTICA BOGOTA D.C.

PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE SOFTWARE Y LA METODOLOGÍA BPM.

CAMILO ANDRES PEREZ VALDERRAMA CODIGO: 20131378004

TRABAJO DE GRADO PARA OPTAR AL TITULO DE INGENIERO EN TELEMÁTICA

TUTOR: ING. GERARDO CASTANG MONTIEL

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLOGICA

INGENIERIA EN TELEMÁTICA BOGOTA D.C.

Nota de Aceptación

__________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________

_________________________ Firma del Tutor

_________________________ Firma del Jurado

TABLA DE CONTENIDO

6. Modelo de abstracción de la gestión de la metodología BPM: ... 46

7. Implementación de microservicios. ... 48

8. Implementar un mecanismo de verificación de la gestión de los procesos BPM: ... 50

9. Método de integración:... 50

9. Conclusiones... 52

Resumen: Actualmente es notable encontrar en las organizaciones deficiencias a nivel funcional en la infraestructura tecnológica que tienen implementada, siendo considerable aún más el que no estén integradas a la estructura organizacional y a la generación de valor, tanto de la productividad como del sistema de información; reflejando un nivel de desempeño bajo de los procesos y de las capacidades operativas, y por lo tanto, no constituye el soporte eficaz del cumplimiento de la misión empresarial y de sus lineamientos estratégicos. Es por esto que han surgido metodologías que se enfocan en optimizar procesos de la mano de la gestión tecnológica como lo es la metodología BPM, la cual ha establecido un marco de trabajo para poder optimizar dichos procesos y alinear la gestión tecnológica con la misión de la organización, creando un entendimiento mutuo entre todos los procesos y actores de la organización, estableciendo pautas de monitoreo y mejora continua.

Palabras clave: BPM, Organización, BPMS, Integración, servicios, Procesos

1.1 Titulo del trabajo.

Prototipo de integración entre aplicaciones de software y la metodología BPM.

1.2 Planteamiento del problema

Las organizaciones han entrado en la dinámica de automatizar funciones de su gestión diaria, lo que ha generado el boom de los “sistemas de información” que son una solución apropiada para lo que se planteó en el momento o lo que comúnmente se dice “ad hoc” solución para un determinado fin. Pero qué pasa cuando la tecnología avanza tan rápido y los mercados crecen en ritmo exponencial, lo que lleva a las organizaciones a entrar en nuevos mercados y enmarcar sus herramientas de gestión tecnológica en estándares de calidad y repuesta a dichos mercado. En este escenario las mencionadas soluciones “ad hoc” empiezan a verse obsoletas y se identifican problemas como lo son: las limitaciones de los sistemas en la adaptación a los nuevos casos de mercado o peor aún la obsolescencia de los sistemas ya que estos no reflejan en si la totalidad de la misión de la organización. Esto deja en evidencia un mal levantamiento de los requerimientos de la aplicación, y por lo tanto evidencia que en la actualidad muchos de los procesos de automatización de las funciones de las organizaciones hacen parte de un determinado conjunto de tareas y no de la totalidad de los procesos de la misma.

En el panorama anterior es importante enmarcar Tal como dice [1] “como los modelos actuales no son suficientes ya que se orientan a tratar temas transaccionales que dejan aparte la integración y orquestación de los procesos de toda la organización”. En esencia la falta de conocimiento de la totalidad de los procesos, y la baja automatización de los mismos. Presenta un marco donde es necesario que las organizaciones establezca un modelo donde se documente la gestión de los procesos y responsables de los mismos a su vez se describan las relaciones de cada proceso con los demás lo que permitirá generar puntos de interoperabilidad para la construcción de soluciones organizacionales y así, resolver la dinámica de los problemas aclarativos en cada etapa del software.

El siguiente proyecto pretende mostrar un panorama de los sistemas orientados a la gestión de los procesos en cómo estos optimizan el entendimiento y ejecución de las diferentes tareas de una compañía y como ayudan a construir soluciones escalables y modulares en una determinada organización.

La demostración de este prototipo pretende dar a conocer como la integración de las aplicaciones se puede realizar mediante api expuestas por los proveedores de sistemas BPM que en esta caso es BonitaBPM, permitiendo a los desarrolladores generar mecanismos de intercambio de datos y así establecer sistemas de integración y funcionamiento conjunto en pro de la ejecución de un proceso. Para la demostración de dicho prototipo se pretende la integración de una plataforma BPM, la cual esta soportada y desarrollada en la herramienta BonitaBPM, con la integración de una aplicación desarrollada sobre el estándar JEE en su versión 1.7 y a su vez integrada sobre aplicaciones móviles desarrolladas sobre lenguaje Android bajo la interoperabilidad de la definición de microservicios expuestos en el ESB Mule. Las limitaciones del sistema residen en la variabilidad y definición de los procesos que se puedan tomar de base para demostrar los procesos de integración.

1.4 Objetivos

1.4.1 General

 Diseñar e implementar un Sistema Telemático bajo el marco de la metodología BPM.

1.4.2 Específicos

 Implementar un mecanismo de integración que permita manejar procesos BPM utilizando

el api HTTP del BPMS Bonitasoft.

 Planear un modelo de abstracción de la gestión de la metodología BPM en un sistema

telemático.

 Implementar un mecanismo de verificación de la gestión de los procesos BPM.

 Implementar un conjunto de microservicios que ofrezca la posibilidad de escalar la gestión

1.5 Justificación

“El modelo de gestión que comenzó con los grandes comerciantes artesanos (en los años 1700),

que se publicó con Adam Smith, y se formalizó con las teorías administrativas de Frederick Taylor,

Henry Fayol y la práctica de Henry Ford. Fue exitoso, en la era industrial, cuando los monopolios

y oligopolios dominaban los mercados, cuando las comunicaciones eran lentas, cuando las

tecnologías no eran de fácil acceso y cuando las personas (consumidores y clientes) no eran tan

conocedoras de los productos y servicios que los mercados les ofrecían. Fue exitoso, y quizá la

mejor alternativa, pero hoy no lo es.” [3].

Las organizaciones han visto en el modelamiento y gestión de procesos una gran alternativa para poder minimizar los riesgos y alinear sus planes corporativos con los procesos y la tecnología; esto lleva a replantear enfoques en el desarrollo de software que en la mayoría fallan porque se enfrenta a modelos operativos, alejados de la estrategia del negocio. Por ello uno de los principales objetivos del diseño de sistema orientado a procesos es integrar la administración de procesos con las herramientas tecnológicas de la organización que permita adaptarse a la industria cambiante. BPM se define como una metodología que integra herramientas, técnicas y análisis para la gestión de procesos de negocio y mejora continua. En donde dichos procesos son descritos de forma gráfica en un ambiente de colaboración entre el campo técnico y la gestión organizacional, en el que se tiene como meta llegar a la representación de un modelo que permita mostrar algún proceso y como este se relaciona con los demás, dejando en claro sus responsables y restricciones, y así automatizar y monitorear el flujo de proceso con el fin de poder establecer pautas de mejora continua [4].

actuales donde es entendible ya que por temas gerenciales, contractuales y de gestión no se construye una única plataforma para la compañía, sino aplicaciones que van dando solución de manera independiente, fraccionada y que en su resultado final no interactúan entre sí. Por esto surge la necesidad de poder establecer un medio de comunicación entre todas ellas. Por ello BPM busca aplicar el concepto de muchas piezas de software trabajando independientemente encaminadas a la mejora continua de los procesos de una organización. El cual tiene como pilar fundamental la optimización de procesos con base a pautas de buena definición de los elementos que enmarcan la visión de una determinada organización y su escalabilidad e interoperabilidad en un futuro, lo que permitirá un bajo costo y alto rendimiento en la gestión del objetivo de negocio, apoyada en su infraestructura tecnológica. Por otro lado se debe ser consciente que en mucho casos no se debe desarrollar la llamada “automatización de la automatización” todo debe partir de la documentación y entendimiento de la totalidad de los procesos en donde la implementación tecnológica debe estar enfocada en definir y crear sistemas flexibles y escalables que comprendan la idea de negocio y tengan una mejora continua, con reutilización de código adecuado y servicios bien definidos.

A nivel gerencial se debe representar de forma explícita la estructura de los procesos organizacionales donde se define actores, roles y la integración de los mismos ya no en un ámbito de unas cuantas dependencias si no en un proceso trasversal para la organización el cual involucra a todas las dependencias de la misma, permitiendo que al implementar BPM se establezca mecanismos de monitoreo, análisis y mejoras en los procesos [2].

1.6 Marco de Referencia

1.6.1 Marco teórico.

BPM:

métodos ya probados y establecidos de gestión de procesos con una nueva clase de herramientas de software empresarial. Ha posibilitado adelantos muy importantes en cuanto a la velocidad y agilidad con que las organizaciones mejoran el rendimiento de negocio. Con BPM: _ Los directores de negocio pueden, de forma más directa, medir, controlar y responder a todos los aspectos y elementos de sus procesos operacionales. _ Los directores de tecnologías de la información pueden aplicar sus habilidades y recursos de forma más directa en las operaciones de negocio. _ La dirección y los empleados de la organización pueden alinear mejor sus esfuerzos y mejorar la productividad y el rendimiento personal. _ La empresa, como un todo, puede responder de forma más rápida a cambios y desafíos a la hora de cumplir sus fines y objetivos.

La dimensión de negocio es la dimensión de valor y de la creación de valor tanto para los clientes como para los “stakeholders” (personas interesadas en la buena marcha de la empresa como empleados, accionistas, proveedores, etcétera). BPM facilita directamente los fines y objetivos de negocio de la compañía: crecimiento sostenido de los ingresos brutos y mejora del rendimiento mínimo; aumento de la innovación; mejora de la productividad; incremento de la fidelidad y satisfacción del cliente y niveles elevados de eficiencia del personal. BPM incorpora más capacidad que nunca para alinear actividades operacionales con objetivos y estrategias. Concentra los recursos y esfuerzos de la empresa en la creación de valor para el cliente. BPM también permite una respuesta mucho más rápida al cambio, fomentando la agilidad necesaria para la adaptación continua.

El proceso: la dimensión de transformación La dimensión de proceso crea valor a través de actividades estructuradas llamadas procesos. Los procesos operacionales transforman los recursos y materiales en productos o servicios para clientes y consumidores finales. Esta “transformación” es el modo en que funciona un negocio; el elixir mágico de la empresa. Mientras más efectiva sea esta transformación, con mayor éxito se crea valor. La ciencia aplicada de procesos y transformación abarca la historia de la gestión industrial moderna. BPM incorpora estas metodologías de forma completa y las acelera con sistemas de definición, medida, análisis y control mejorados de forma espectacular. Mediante BPM, los procesos de negocio son más efectivos, más transparentes y más ágiles. Los problemas se resuelven antes de que se conviertan en asuntos más delicados. Los procesos producen menos errores y estos se detectan más rápido y se resuelven antes.

forja el éxito empresarial. Antes de BPM, construir y aplicar estas herramientas engendraba una mezcla poco manejable de automatización de clase empresarial, muchas herramientas de escritorio aisladas, métodos y técnicas manuales y fuerza bruta. Con BPM, puede aunar todos los sistemas, métodos, herramientas y técnicas de desarrollo de procesos y la gestión de procesos en un sistema estructurado, completo, con la visibilidad y los controles necesarios para dirigirlo y afinarlo [8].

Ciclo PHVA

El ciclo PHVA o ciclo de Deming fue dado a conocer por Edwards Deming en la década del 50, basado en los conceptos del estadounidense Walter Shewhart. PHVA significa: Planificar, hacer, verificar y actuar. En inglés se conoce como PDCA: Plan, Do, Check, Act.

Este ciclo constituye una de las principales herramientas de mejoramiento continuo en las organizaciones, utilizada ampliamente por los sistemas de gestión de la calidad (SGC) con el propósito de permitirle a las empresas una mejora integral de la competitividad, de los productos ofrecidos, mejorado permanentemente la calidad, también le facilita tener una mayor participación en el mercado, una optimización en los costos y por supuesto una mejor rentabilidad.

Por su dinamismo puede ser utilizado en todos los procesos de la organización y por su simple aplicación, que si se hace de una forma adecuada, aporta en la realización de actividades de forma organizada y eficaz.

A través de cada uno de los pasos del ciclo PHVA las empresas pueden:

Planificar: En esta etapa se definen los objetivos y cómo lograrlos, esto de acuerdo a políticas organizacionales y necesidades de los clientes. Puede ser de gran utilidad realizar grupos de trabajo, escuchar opiniones de los trabajadores y utilizar herramientas de planificación como por ejemplo: 5W2H en la cual se responden 7 preguntas claves cuyas palabras en inglés inician con W y H : ¿Qué (What), ¿Por qué (Why), ¿Cuándo (When) ¿Dónde (Where) ¿Quién (Who), ¿Cómo (How) y ¿Cuánto (How much).

Hay que recordar que esta etapa es muy importante y es la que permite el desarrollo de las otras, lo que indica que si no planeamos bien los resultados en las otras 3 etapas no serán confiables.

Verificar: En esta etapa comprobamos que se hayan ejecutado los objetivos previstos mediante el seguimiento y medición de los procesos, confirmando que estos estén acorde con las políticas y a toda la planeación inicial.

Actuar: Mediante este paso se realizan las acciones para el mejoramiento del desempeño de los procesos, se corrigen las desviaciones, se estandarizan los cambios, se realiza la formación y capacitación requerida y se define como monitorearlo.

En conclusión la adopción del ciclo PHVA es de gran ayuda para actuar sobre los procesos y no sobre las personas, pues es frecuente que en las organizaciones se culpen a los trabajadores por los malos resultados cuando en realidad lo que falla es el proceso, de ahí la gran importancia que tiene el compromiso gerencial, pues es en este nivel en donde se deben buscar las estrategias que le permita a las empresas liderar el mercado, ser auto-sostenibles y rentables.

Requisitos de la mejora continúa

Para su adecuado desarrollo, la mejora continua requiere que se cumplan algunos aspectos en el ambiente de trabajo, como los que se mencionan seguidamente:

 Apoyo en la gestión.

 Retroalimentación (Feedback) y revisión de los pasos en cada proceso.  Claridad en la responsabilidad.

 Poder de decisión para el trabajador.

 Forma tangible de realizar las mediciones de los resultados de cada proceso.

Proceso Unificado de Desarrollo.

[17] Metodología de desarrollo de software que está basado en componentes e interfaces bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

Es un proceso que puede especializarse para una gran variedad de sistemas de software, en diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. UP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Principales Elementos

Como UP es un proceso, en su modelación define como sus principales elementos:

 Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de un

individuo, grupo de individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo. Ellos realizan las actividades y son propietarios de elementos.

 Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada por un

trabajador y manipula elementos.

 Artefactos (“qué”): Productos tangibles del proyecto que son producidos, modificados y

usados por las actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.

 Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por trabajadores y que

produce un resultado de valor observable.

Características Principales

 Unifica los mejores elementos de metodologías anteriores.  Preparado para desarrollar grandes y complejos proyectos.  Orientado a Objetos.

 Principales ventajas

 Coste del riesgo a un solo incremento.

 Reduce el riesgo de no sacar el producto en el calendario previsto.  Acelera el ritmo de desarrollo.

 Se adapta mejor a las necesidades del cliente.

Ciclo de vida:

 Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros necesitan y

desean, lo cual se capta cuando se modela el negocio y se representa a través de los requerimientos. A partir de aquí los casos de uso guían el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo).

 Centrado en la arquitectura: La arquitectura muestra la visión común del sistema completo

en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo que describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. UP se desarrolla mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la arquitectura. El modelo de arquitectura se representa a través de vistas en las que se incluyen los diagramas de UML.

 Iterativo e Incremental: Una iteración involucra actividades de todos los flujos de trabajo,

aunque desarrolla fundamentalmente algunos más que otros.

Flujo de Trabajo

 Se han agrupado las actividades en grupos lógicos definiéndose 9 flujos de trabajo

principales, los 6 primeros son conocidos como flujos de ingeniería y los tres últimos como flujos de apoyo.

 Modelo del Negocio: Describe los procesos de negocio, identificando quiénes participan y

 Requerimiento: Define qué es lo que el sistema debe hacer, para lo cual se identifican las

funcionalidades requeridas y las restricciones que se imponen.

 Análisis y Diseño: Describe cómo el sistema será realizado a partir de la funcionalidad

prevista y las restricciones impuestas (requerimientos), por lo que indica con precisión lo que se debe programar.

 Implementación: Define cómo se organizan las clases y objetos en componentes, cuáles

nodos se utilizarán y la ubicación en ellos de los componentes y la estructura de capas de la aplicación.

 Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.

 Instalación o despliegue: Produce release del producto y realiza actividades (empaque,

instalación, asistencia a usuarios, etc.) para entregar el software a los usuarios finales.  Administración del proyecto: Involucra actividades con las que se busca producir un

producto que satisfaga las necesidades de los clientes.

 Administración de configuración y cambios: Describe cómo controlar los elementos

producidos por todos los integrantes del equipo de proyecto en cuanto a: utilización/actualización concurrente de elementos, control de versiones, etc.

 Ambiente: Contiene actividades que describen los procesos y herramientas que soportarán

el equipo de trabajo del proyecto; así como el procedimiento para implementar el proceso en una organización.

Fases

Cada fase representa un ciclo de desarrollo en la vida de un producto de software:

 La fase de concepción o inicio: tiene por finalidad definir la visión, los objetivos y el

 La fase de elaboración tiene como principal finalidad completar el análisis de los casos de

base de la comprensión del sistema completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido.

 La fase de construcción está compuesta por un ciclo de varias iteraciones, en las cuales se

van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones el sistema que satisfacen los principales casos de uso. Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración.

 La fase de transición se inicia con una versión “beta” del sistema y culmina con el sistema

en fase de producción. operativo proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a las funciones del teléfono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla en un lenguaje de programación muy conocido como es Java.

Los componentes principales del sistema operativo de Android:

 Aplicaciones: las aplicaciones base incluyen un cliente de correo electrónico, programa de

SMS, calendario, mapas, navegador, contactos y otros. Todas las aplicaciones están escritas en lenguaje de programación Java.

 Marco de trabajo de aplicaciones: los desarrolladores tienen acceso completo a los mismos

 Bibliotecas: Android incluye un conjunto de bibliotecas de C/C++ usadas por varios

componentes del sistema. Estas características se exponen a los desarrolladores a través del marco de trabajo de aplicaciones de Android; algunas son: System C library (implementación biblioteca C estándar), bibliotecas de medios, bibliotecas de gráficos, 3D y SQLite, entre otras.

 Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor

parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros y corre clases compiladas por el compilador de Java que han sido transformadas al formato.dex por la herramienta incluida "dx".

 Núcleo Linux: Android depende de Linux para los servicios base del sistema como

seguridad, gestión de memoria, gestión de procesos, pila de red y modelo de controladores. El núcleo también actúa como una capa de abstracción entre el hardware y el resto de la pila de software.

JEE:

Java Platform, Enterprise Edition (Java EE) es el estándar en software empresarial impulsado por la comunidad. Java EE se desarrolla utilizando la Java Community Process, con las aportaciones de expertos de la industria, organizaciones comerciales y de código abierto, Java User Group, y un sinnúmero de personas. Cada versión integra nuevas características que se alinean con las necesidades de la industria, mejora la portabilidad de las aplicaciones y aumenta la productividad del desarrollador.

El modelo de aplicación Java EE comienza con el lenguaje de programación Java y la

El modelo de aplicación Java EE define una arquitectura para la implementación de servicios como, aplicaciones de múltiples niveles que ofrecen la escalabilidad, accesibilidad y capacidad de administración.

La plataforma Java EE utiliza un modelo de aplicación de varios niveles distribuido por la empresa

 Componentes de cliente de nivel se ejecutan en la máquina cliente.  Componentes de nivel Web se ejecutan en el servidor Java EE.

 Componentes de la capa de negocio se ejecutan en el servidor Java EE.

Figura 1: Arquitectura JEE.

Microservicios Java

El término "Arquitectura de Microservicio” ha surgido en los últimos años para describir una forma particular de diseñar aplicaciones de software suites, como de los servicios de forma independiente desplegables. Si bien no existe una definición precisa de este estilo arquitectónico, hay cierta característica común en torno a la organización en torno a la capacidad del negocio, el despliegue automatizado, la inteligencia en los puntos finales, y el control descentralizado de Los lenguajes y bases de datos.[14]

Una aplicación Java EE monolítica se define normalmente en un archivo .war o .ear. Toda la funcionalidad de la aplicación se concentra y empaqueta en una sola unidad.. Todas las páginas web están la raíz de la aplicación, todas las clases Java se encuentran dentro de WEB-INF/classes y los recursos dentro de /META-INF, algunas de las reglas en común para poder empezar a tratar temas de división de aplicación es entender reglas en común como lo son:

 Separación de los aspectos de funcionalidad, por ejemplo utilizando MVC.  Alta cohesión y bajo acoplamiento utilizando APIs bien definidas.

 No repetirse así mismo (DRY - Don't Repeat Yourself)

 API de Interfaces e implementaciones por separados y aplicando la Ley de Deméter, Las

clases no llaman a otras clases directamente, ya que se encuentran en el mismo archivo.  El uso de Diseño Guiado por Dominio para mantener objetos relacionados entre dominio y

componente.

 YAGNI o: No hacer algo que no se necesita ahora.

En resumen, la arquitectura de microservicios es una aproximación al desarrollo de una sola aplicación como un conjunto de servicios pequeños, cada uno que se ejecuta en su propio proceso y la comunicación con los mecanismos de peso ligero, a menudo una API recurso HTTP. Estos servicios se basan en el negocio de las capacidades de despliegue totalmente automatizados y maquinaria de forma independiente de despliegue. Hay un mínimo de una gestión centralizada de los hilos de servicios, que puede estar escrito en diferentes lenguajes de programación y el uso de diferentes tecnologías de almacenamiento de datos.

usuario), una base de datos (que consta de muchos cuadros insertados en una, gestión de base de datos común, y por lo general relacional sistema), y una aplicación del lado del servidor. La aplicación del lado del servidor se encargará de las peticiones HTTP, ejecutar la lógica de dominio, recuperar y actualizar datos de la base de datos y seleccionar y rellenar los puntos de vista de HTML que se envía al navegador. Esta aplicación del lado del servidor es un monolito - un único ejecutable lógico. Cualquier cambio en el sistema consiste en la construcción y despliegue de una nueva versión de la aplicación del lado del servidor.

Un servidor monolítico es una forma natural de acercarse a la construcción de la mayoría de sistemas de software. Toda la lógica para manejar una petición se ejecuta en un solo proceso, permitiendo que el que utilice las funciones básicas de la aplicación para dividir el proceso en clases, funciones y espacios de nombres. Con un poco de cuidado, puede ejecutar y probar la aplicación en la computadora portátil de un desarrollador, y el uso de una tubería de implementación para asegurar que los cambios que se están debidamente probados y desplegados en la producción. Puede escalar horizontalmente el monolito ejecutando muchos casos detrás de un equilibrador de carga. Aplicaciones monolíticas pueden tener éxito, pero cada vez más personas están sintiendo frustración con ellos - especialmente a medida que más aplicaciones se están desplegando a la nube. En muchos casos un cambio realizado en una pequeña parte de la aplicación, requiere todo el monolito que ser reconstruida y desplegado. Con el tiempo, a menudo es difícil mantener una buena estructura modular, por lo que es más difícil mantener los cambios que deberían afectar a un solo módulo dentro de ese módulo. Escalamiento requiere descamación de toda la aplicación en lugar de partes que requieren gran recurso [15]:

Ventajas de una arquitectura basada en microservicios [16]:

 Combinar los servicios como nos interesen. Incluso, reutilizarlos para distintos uso dentro

de la empresa. Como piezas de puzzle podemos crear aplicaciones que usen una misma lógica de negocio sin estar cautiva en una aplicación monolítica.

 Escalar a nivel de microservicios. Cada uno de ellos expone una funcionalidad, así

podemos distribuirlo según nuestras necesidad pensando en la demanda y el balanceo de carga de cada aplicación. Esto contrapone la idea poco eficiente de replicar aplicaciones enteras cargadas de funcionalidad por unas pocas que represente la mayor carga.

 Simplificamos el mantenimiento. Cumplen a la perfección el principio SOLID. Podemos

nuestra aplicación. Es más fácil tirar algo que no usemos a la basura que mantenerlo como código legacy dentro de una aplicación monolítica.

 Su fallo no arrastra a todo el sistema. Si un componente no funciona correctamente no

afecta al resto. Se puede aislar y manejar el error, desplegando por separado.

 El despliegue puede ser progresivo sin parar todo de golpe. Empezamos a ver más luz a la

integración continua alcanzando mayores cifras de disponibilidad. Aunque recuerda que esto implica que ya no tienes un único contenedor, sino que hay que estar pendiente de n contenedores de aplicaciones.

Bus De Servicios:

Cuando se habla de arquitecturas orientadas a servicios, se habla intrínsicamente de los componentes necesarios para tener una arquitectura SOA. Sin duda alguna, uno de los componentes más importantes de una arquitectura orientada a servicios es el Enterprise Service Bus - ESB.

Conforme las organizaciones van moviéndose hacia las arquitecturas orientadas a servicios, se dan cuenta que están trabajando con un “mix” entre lo nuevo y lo viejo. Un ESB es básicamente la integración de lo nuevo y lo viejo, brindándo un lugar central para los servicios, las aplicaciones, y recursos de TI en general que se desean conectar. En otras palabras, lo que se busca es una infraestructura y un sistema de eventos que me permitan conectar cualquier recurso de TI sin importar la tecnología que utiliza el recurso. Esta infraestructura debería permitir administrar los cambios en los requerimientos sin causar problemas a los servicios ya instalados. Esta infraestructura debe de ser confiable y robusta. Aquí es donde entra el concepto de ESB.

Un ESB no solamente permite combinar y re ensamblar servicios, sino que también debe permitir conectar nuevas aplicaciones, servicios web y cualquier otro tipo de aplicaciones tales como aplicaciones LOB ( Line of Business ), archivos batch, legacy middleware a través de adaptadores; todo esto manteniendo la abstracción del manejo de mensajes a través del patrón publicar-suscribir.

Funcionalidades ESB.:

 Transparencia de Ubicación: El ESB ayuda a desligar el consumidor del servicio de la

comunicarse con cualquier aplicación requerida sin ligar el recibidor del mensaje con el que envía el mensaje.

 Conversión de Protocolo de Transporte: Un ESB debe de tener la capacidad de integrar de

forma transparente a través de diferentes protocolos de transporte tales como HTTP(s), JMS, FTP, SMTP, TCP, etc.

 Transformación de Mensaje: El ESB brinda funcionalidad para transformar mensajes desde

un formato hasta otro formato basado en estándares tales como XSLT y XPath.  Ruteo de Mensajes: El ESB determina el destino de los mensajes entrantes.

 Mejora del Mensaje: El ESB puede brindar funcionalidad para agregar información faltante

basada en los datos del mensaje de entrada.

 Seguridad: Autenticación, autorización, y funcionalidad de encriptación se proveen a través

del ESB para asegurar los mensajes entrantes. Igualmente estas funcionalidades se aplican a mensajes salientes para satisfacer requerimientos de seguridad del proveedor del servicio a consumir.

 Monitoreo y Administración: Un ambiente de monitoreo y administración del ESB es

fundamental para configurar el ESB para que sea confiable y tenga un alto desempeño; al mismo tiempo, nos permite monitorear la ejecución de los mensajes y su flujo dentro del ESB.

Mule y otros ESBS ofrecen un valor real en escenarios en los que hay al menos unos pocos puntos de integración o, al menos, 3 aplicaciones para integrar. También son muy adecuadas para escenarios donde se requiere la articulación flexible, escalabilidad y robustez.

A continuación se muestra una lista de selección rápida ESB, donde se enumeran factores a considerar en una integración ESB:

1. ¿se integrara tres o más aplicaciones / servicios?

2. ¿Será necesario que conecte más aplicaciones en el futuro?

3. ¿Es necesario utilizar más de un tipo de protocolo de comunicación?

4. ¿Necesita capacidades de enrutamiento de mensajes, como se bifurcan y de agregar los flujos de mensajes, o encaminamiento basado en el contenido?

1.6.2 Marco Conceptual

BonitaBPM:

Para el desarrollo de este modelo de integración se ha seleccionado la herramienta de diseño BPM llamada BonitaBPM en su versión comunity y para el desarrollo de la aplicación se ha seleccionado el lenguaje JAVA en su edición JEE.

BonitaBPM es una suite ofimática para la Gestión de procesos de negocio (BPM) y realización de Workflows, creada en 2001. Es código abierto y puede ser descargado bajo GPL v2. Su desarrollo comenzó en el National Institute for Research in Computer Science, y entonces ha estado en proceso de incubación varios años dentro de la compañía científica francesa Bull. Desde 2009, el desarrollo de Bonita está soportado por una empresa dedicada a esta actividad: Bonitasoft. Bonitasoft se ha expandido más allá de su base en el mercado de EMEA para satisfacer mejor la creciente demanda global. En octubre de 2010 abrió su primera oficina en América del Norte (San Francisco).

Características:

Diseño:

Tiene todo lo que se necesita para construir potentes aplicaciones basadas en procesos, desde el modelado del proceso en BPMN 2.0 al igual que un editor de interfaces.el cual permite adaptar la plaicacion a las necesidades de las organizaciones.

Modelamiento de la mano del cliente:

 Modelar procesos con el sencillo editor gráfico

 Asignar actores y mapearlos con la organización para gestionar asignaciones

 Gestionar los datos complejos de manera sencilla con el sistema de gestión de datos de

negocio

 Colabora usando el repositorio compartido de procesos

Conectar y personalizar:

de conectores con un framework extensible y las herramientas de integración fácilitan a través de las APIs disponibles y extensibles mediante Java o REST.

Apache Córdova:

Apache Córdova es un marco de desarrollo móvil de código abierto. El cual Permite utilizar las tecnologías estándar web como HTML5, CSS3 y JavaScript para desarrollo multiplataforma, evitando el lenguaje de desarrollo nativo cada plataforma móvil. Las Aplicaciones se ejecutan dentro de envolturas para cada plataforma y dependen de enlaces estándares (API) para acceder a cada dispositivo sensores, datos y estado de la red.

Apache Córdova se graduó en octubre de 2012 como un proyecto de nivel superior dentro de la Apache Software Foundation (ASF). A través del ASF, el futuro desarrollo por Cordova asegurará administración abierta del proyecto ya que Siempre permanecerá libre y de código abierto bajo la licencia Apache, versión 2.0. Usar Apache Cordova permite:

 establecer una aplicación móvil desarrollada y extender la misma a varias plataformas, sin

tener que re implementarse para cada una.

 un desarrollo enfocado a lenguaje web el cual brinda un estándar en el desarrollo de las

aplicaciones móviles.

 Un desarrollo enfocado a la apariencia visual enriquecida gracias a su interacion con css y

jquery mobile

En la siguiente imagen se muestra la arquitectura de Apache Córdova, en cual se muestra el proceso de renderizacion de un lenguaje web, a una plataforma movil

Figura 2: arquitectura Cordova

Componentes básicos

Apache Cordova se basan en un archivo común config.xml archivo que proporciona información acerca de la aplicación y especifica los parámetros que afectan a cómo funciona, como si responde a la orientación en cada plataforma. Este archivo se adhiere a la especificación de Empaquetado de la aplicación Web, widget, o de la W3C.

La misma aplicación se implementa como una página web, un archivo local llamado index.html, que hace referencia a cualquier CSS, JavaScript, imágenes, archivos multimedia u otros recursos son necesarios para que se ejecute de forma predeterminada. La aplicación se ejecuta como un WebView dentro de la envoltura de la aplicación nativa, que distribuye a tiendas de aplicaciones. El WebView Cordova-habilitado puede proporcionar la aplicación con su interfaz de usuario completa. En algunas plataformas, también puede ser un componente dentro de una aplicación híbrida más grande, que mezcla la vista Web con componentes de la aplicación nativa.

Una interfaz plugin está disponible para Cordova y componentes nativos para comunicarse con los demás. Esto te permite invocar un código de JavaScript. Idealmente, las API de JavaScript para ese código nativo son consistentes a través de múltiples plataformas de dispositivos. A partir de la versión 3.0, las extensiones proporcionan enlaces a APIs estándar. Plugins de terceros proporcionan enlaces adicionales a funciones no necesariamente disponibles en todas las plataformas. En apache cordova existen dos formas de desarrollar una aplicación móvil:

 Flujo de trabajo multiplataforma (CLI): este flujo de trabajo se utiliza para ejecutar en los

sistemas operativos móviles como sea posible, con poco necesidad específica de la plataforma nativa de desarrollo. Este flujo de trabajo se centra en la cordova utilidad, también conocido como el CLI, que fue introducido con 3.0 Cordova Cordova. El CLI es una herramienta de alto nivel que permite construir proyectos para muchas plataformas a la vez, muy lejos de la funcionalidad de scripts de shell de bajo nivel de abstracción. La CLI copia un conjunto común de web activos en subdirectorios para cada plataforma móvil, hace que cualquier cambio de configuración necesarias para cada uno, construir secuencias de comandos para generar los binarios de la aplicación ejecuta. La CLI también proporciona una interfaz común para aplicar plugins para su aplicación.

 Flujo de trabajo centrado en plataforma: este flujo de trabajo se utiliza en la construcción de

adaptan para cada plataforma soportada y una utilidad de Plugman separada que le permite aplicar plugins. Mientras este flujo de trabajo puede utilizar para crear aplicaciones multiplataforma, es generalmente más difícil porque la falta de una herramienta de alto nivel significa construir diferentes ciclos y modificaciones de plugin para cada plataforma. Aún así, este flujo de trabajo permite un mayor acceso a opciones de desarrollo proporcionadas por cada SDK.

ESB Mule.

[20] Mula, es un motor en tiempo de ejecución de la plataforma AnyPoint, es un ligero bus de servicio empresarial basada en Java (ESB) en donde se brinda una plataforma de integración que permite a los desarrolladores de aplicaciones conectarse de forma rápida y fácil, lo que les permite intercambiar datos. Es de fácil integración con los sistemas existentes, independientemente de las tecnologías que las diferentes aplicaciones de usuario manejen, incluyendo JMS, Servicios Web, JDBC, HTTP, y mucho más. La ESB puede ser desplegada en cualquier lugar, se puede integrar y orquestar los eventos en tiempo real o por lotes, y tiene conectividad universal.

La principal ventaja de un ESB es que se han encontrado diferentes integraciones para comunicarse entre sí, actuando como un sistema de transporte de datos entre las aplicaciones dentro de la empresa o a través de Internet. Mule tiene capacidades de gran alcance que incluyen:

 Creación de servicios y hosting : exponer servicios reutilizables, utilizando el ESB como un

contenedor de servicio ligero

 La mediación de servicios: servicios de blindaje de formatos y protocolos de mensajes, la

lógica de negocio separada de mensajería, y permitir que las llamadas de servicio

específico. Mula es independiente del proveedor, por lo que diferentes implementaciones de otros proveedores pueden conectar a ella. Nunca estamos encerrados en un proveedor específico cuando se utiliza Mule.

Primefaces:

PrimeFaces es una librería de componentes visuales open source desarrollada y mantenida por Prime Technology, una compañía Turca de IT especializada en consultoría ágil, JSF, Java EE y Outsourcing. Las principales características de Primefaces son:

 soporte nativo de Ajax, incluyendo Push/Comet.  kit para crear aplicaciones web para móviles.

 es compatible con otras librerías de componentes, como JBoss RichFaces.

 uso de javascript no intrusivo (no aparece en línea dentro de los elementos, sino dentro de un bloque <script>).



1.7 Factibilidad

1.7.1 Técnica

El diseño de este prototipo permitirá integrar metodologías de desarrollo e integración optimas al permitir a los clientes y desarrolladores de software entender las necesidades de los proyecto y elaborar aplicaciones encaminadas a la visión de la compañía que estén acordes a las tecnologías disponibles y en tiempos razonables de implementacion.

1.7.2 Económica

 Costo de personal: el porcentaje de trabajo diario en jornada de 8 horas 5 días a la semana.  Costo Hora de trabajo Ingeniero: 16.000

Costo software: las herramientas necesarias para la construcción del prototipo no requieren de ningún costo por licencia.

 Java versión "1.7.0_75". Licencia open source.

 Android 5.1 lollipop. Licencia Apache 2.0 y GNU GPL 28.  Jboss AS 7.1 Licencia GNU.

 Mule versión community  Apache Cordova

 BonitaBPM 6.5 Licencia Community, listado de criterios elección BonitaBPM

1.7.3 Operativa

2 Fase de análisis

2.1 Análisis de Requerimientos

El desarrollo de este prototipo está enfocado en la posibilidad de implementar características de la metodología BPM en procesos de desarrollo de software, con el fin de poder generar aplicaciones que estén enfocadas a los lineamientos y procesos de los entornos para los que son diseñados, permitiendo alinear las herramientas de software con los planes corporativos de las organizaciones.

Al comprender este panorama se plantea la idea de permitir gestionar un modelo que permita integrar una óptima gestión de procesos y aplicaciones de software es aquí donde surge la idea de crear un mecanismos que permitiese integrar una capa de negocios, capa de presentación, capa de datos en pro de poder alimentar un modelo de procesos ya establecido sin perder la modularidad e integridad de las aplicaciones de software encaminadas a la mejora continua de los procesos de una organización. Este marco permite entender la necesidad de establecer flujos organizados que interactúen y asignen responsabilidad en cada uno de los procesos de las organizaciones. Donde se tenga control y monitoreo de muchas aplicaciones y responsables de las mismas.

3 Fase de diseño

Desarrollando la metodología UP en la implementación del sistema de integración BPM, se evidencia la necesidad de implementar un modelo de abstracción y control de todos los elementos relacionados en la gestión de los procesos, es por ello que se realiza un análisis de los actores y elementos que conformaran el sistema para así asignar responsabilidades únicas a cada elemento e identificar los posibles subsistemas que puedan aparecer.

3.1 Diagrama de actividades.

3.1.1 consultar Tareas.

3.1.2 Registrar Tarea

3.2 Diagrama de Clases.

Fuente: Elaboración Propia

3.3 Diagrama de Estados Tarea.

3.4 Diagrama de comunicación.

3.4.1 login aplicación web

Fuente: Elaboración Propia

3.4.2 consulta tareas asignadas

3.4.3 registro de tareas

Fuente: Elaboración Propia

3.5 Diagrama de secuencia

3.5.1 Login aplicación web

3.5.2 Consulta de tareas.

3.5.3 Registrar Tarea.

3.6 Diagrama de componentes

Fuente: Elaboración Propia

3.7 Diagrama de Despliegue

4. Fase de Implementación.

En el momento de empezar con la construcción de la aplicación de negocio con enfoque BPM, se presentan una infinidad de posibilidades, una de ellas y la más utilizada es la utilización de herramientas de presentación que se exponen en los BPMS, en el caso de BonitaBPM en la codificación del proceso y despliegue del mismos en los servidores antes mencionados se generan formularios básicos en HTML con soporte transaccional en lenguaje java, dicha solución es muy eficiente y rápida en cuanto al desarrollo de aplicaciones que parten desde cero. Pero en la mayoría de casos presentan limitaciones a la hora de enriquecer la presentación de la aplicación, ya que dichos formularios tomaran los estilos y layaout definidos en él .war del BPMS desplegado en el servidor web. Para solventar este problema muchos BPMS han implementado un API que permite acceder al core del sistema BPM donde se ubican las reglas y funcionas propias de la gestión BPM. Lo que genera posibilidades de integración de aplicaciones externas con la gestión BPM, dicha integración en el caso de BonitaBPM se realiza por tres medios (EJB, HTTP, TCP).

Teniendo en cuenta eso pueden construir aplicaciones que generen conexión con el core BPM en cualquiera de estos medios. El API proporcionado por BonitaBPM [7], muestra que son JAR los que permiten la integración con el BPM, a través de una serie de objetos y funciones que encapsulan las funcionalidades, este aspecto resulta algo negativo cuando la aplicación de negocio no está desarrollada en java y dichos JAR no se puede usar; una solución rápida seria hacer funciones que consuman los JAR y exponerlas como servicios web la cual sería muy viable, pero pensando en esto BonitaBPM ha pensado un API permita consumir funciones del sistema BPM desde cualquier otro cliente por un api REST, solo codificando el cliente de dichos servicios en cualquier plataforma.

Figura 3: Diseño de componentes API bonita [7].

La forma de integración con dicho API permite exponer una aplicación de negocio con: JSF 2.2, Primefaces 5.1, CSS, JQUERY. Para mostrar la posibilidad de diseñar aplicaciones ricas visualmente y robustas bajo estándares como lo son JEE y .NET. a modo de ejemplo se puede utilizar la arquitectura JEE, con un modelo de acceso a datos bajo JPA, apoyándose en el ORM(Mapeo de Objetos relacionales) Hibernate, la lógica de negocio y del BPM bajo el API EJB 3.1, en cuanto a patrones de diseño se implementa MVC(Modelo Vista Controlador) propio de primefaces. La integración de los elementos tanto plataforma BPM, como plataforma de negocio en distintos servidores de aplicaciones. Lo cual funciona de forma eficiente, pero en algunos casos por temas de organización y monitoreo generaría un trabajo extra como lo son observar dos log de proceso y verificación de los mismos. Por ello la idea de unificar todo en un servidor de aplicaciones no está mal y se ahorraría gestión de administración de aplicaciones, en el siguiente diagrama de componentes se muestra un posible esquema de integración entre una plataforma BPM y algunas tecnologías.

Figura 4: Esquema de integración de diferentes plataformas con BMP Fuente: Elaboración Propia

gestores documentales(alfresco), web services SOAP, LDAP, herramientas de reportes (jasperreport), calendario Google, mensajería snmp.

Teniendo en cuenta lo anterior, el modelo BPM ya no tendría como único punto de integración un API BPM, si no que respondería a una serie de piezas que permitirían construir tareas que efectuaran integraciones específicas, quitando esta responsabilidad a la aplicación de negocio y asignándosela al BPM; integrando funcionalidades de toda la compañía en pro de la gestión de los procesos sobre BPM, implementadas ya sea desde una Aplicación de negocios o desde el sistema BPM.

Para el diseño del prototipo se ha decidido tomar como marco de referencia la teoría de microservicios expuesta en apartados anteriores, siguiendo el principio de responsabilidades por objetos y componentes uno de los pilares del acrónimo SOLID, se propone desarrollar un conjunto de elementos los cuales estarán encargados de gestionar funciones particulares en el marco de la integración de la metodología BPM con tecnologías del lado del servidor enmarcadas bajo el estándar JEE y tecnologías móviles bajo el lenguaje Android; a continuación se describirá cada componente utilizado en el prototipo planteado.

5. Sistema BPM: Implementación mecanismo de integración procesos BPM api

HTTP del BPMS Bonitasoft

Desarrollo Implementación sistema BPM.  Servidor de aplicaciones: JBOSS 7.1.1.

 Motor BPM: BonitaSoft 6.5.3 versión community

 JDK: Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)  Base de datos: postgrest 9.4

El sistema BPM ofrece un marco de seguridad bajo el estándar JAAS, el cual es parametrizable en la configuración de la organización antes mencionada. Brindado un sistema de roles y grupos de trabajo. Lo que permite ofrecer trazabilidad de las tareas asignadas a cada usuario. Cuando se habla del sistema BPM ofrecido por BonitaSoft en su versión community se debe tener en cuenta que la herramienta ofrece dos modos de gestión de la plataforma uno como administrador y otro como usuario de la aplicación. El perfil Administrador es el encargado de:

 Desplegar organización

 Ver información de los procesos y tareas de los mismos

El sistema BPM permite el despliegue y monitoreo de los procesos diseñados, dicho despliegue siempre debe ser desde este sistema bajo el rol administrador, para mayor información. Es por ello que es importante conocer la organización y procesos de implementación al momento de trabajar la metodología BPM, como se dijo anteriormente los procesos de la misma deben ser orientados de forma transversal a toda la organización así al momento de desplegar un diseño de organización y unos procesos diseñados para la misma se evidenciara la totalidad de responsables e insumos de valor en la terminación de dicho proceso.

proceso las cuales nos permiten dar un flujo de navegación al proceso a través de cada tarea, evitando persistir toda la información al modelo BPM dándole independencia a los datos de negocio y así lograr un entendimiento y mejora al momento de escalar la aplicación, al dividir los datos en datos de negocio y datos de proceso se establece reportes claros y manejo de la información de forma más independiente sin depender de la herramienta BPM y su normalización.

Una característica importante del sistema BPM es su integración hacia otras herramientas, siguiendo otro de los principios SOLID, ahora enfocado a estar abierta para su extensión y cerrada para su modificación, en este marco se diseña tareas que utilicen conectores propios de BonitaBPM lo que dan un ahorro en tiempo de desarrollo y diseño de interfaces de integración: para este prototipo se utiliza dos funciones principales de sus extensiones la primera radica en la posibilidad de adjuntar documentos a cada proceso gestionado por BonitaBPM ofreciendo un margo de gestión documental de la información, ahorrándonos la configuración y despliegue de gestores documentales en servidores externos, la segunda radica en el consumo de diseño de tareas específicas encargadas de consumir servicios web para poder monitorear estado de variables externas y así poder dar continuidad al flujo del proceso.

Proyecto EJB (estandar EJB 3.1):

Figura 6: estructura proyecto gestión EJB. Fuente: Elaboración propia

Proyecto Web:

El proyecto web está construido sobre primefaces 5.0, mojarra 2.1, el cual permite lograr independencia del modelo visual implementado por la plataforma BonitaBPM, generando la posibilidad de gestionar un modelo visual acorde a las necesidades del cliente, en este caso se utiliza los temas proporcionados por primefaces con algunas adaptaciones de bootstrap, lo que permite dar una apariencia de diseño responsive, Este proyecto web permite la gestión de toda la lógica BPM y de negocio de cara al usuario, gracias a la integración por medio de Maven de los proyectos comunes y proyectos EJB diseñados, es por esto que en los ManagedBeans se construye controladores de vista con base a operaciones realizadas en la plataforma BPM o en el modelo de negocio.

6. Modelo de abstracción de la gestión de la metodología BPM

Desarrollo Implementación aplicación web que se integre con el sistema BPM e Implementación mecanismo de integración que permita gestionar procesos BPM utilizando el api HTTP del BPMS Bonitasoft.

 Servidor de aplicaciones: JBOSS 7.1.1.  Framework java: Primefaces 5.0, mojarra 2.1

 Base de datos: MYSQL

En el prototipo propuesto se planteado la posibilidad de no utilizar el entorno visual de la plataformaBPM y así lograr una personalización de las aplicación web según las necesidades del cliente y así aplicando otro principio del acrónimo SOLID, en donde se diseña varias interfaces de integración en lugar de una sola, esto es posible gracias al api de integración de la plataforma BonitaBPM el cual ofrece un conjunto de librerías las cuales permiten gestionar toda la lógica del motorBPM desde cualquier aplicación. Siguiendo esta premisa se construye un proyecto común bajo el estándar JSE el cual estará desplegado como librería en nuestro servidor de aplicaciones JBOSS AS 7.1 el cual esta encargado de brindar una interface de comunicación al servidor BPM, para asi llevar la gestión de los procesos y tareas diseñadas. En la elaboración de este proyecto JSE se realiza la abstracción del modelo BPM en estas clases:

 CasosBonita: encargado de gestionar todo lo relacionado con creación y monitoreo de

instancias de proceso

 TareasBonita: encargado de gestionar todo lo relacionado con asignación, monitoreo de

tareas que conforman un proceso

 Usuarios Bonita: encargado de gestionar todo lo relacionado con los usuarios de la

organización diseñada

 ProcesosBonita: encargado de gestionar todo lo relacionado con las versiones y procesos

Figura 5: estructura proyecto gestión api Bonita, jar de integración Fuente: elaboración propia

7. Implementación de microservicios.

Proyecto web servicios:

Al presentar de forma ordenada todas las posibles integraciones hacia el sistema de manejo de Procesos.

Implementación de un conjunto de micro servicios que permitan la gestión de las operaciones BPM desde cualquier sistema. Proyecto encargado de brindar una interfaz de comunicaciones para el modelo de Negocio y gestión de datos BPM , en este proyecto web radican las interfaces de servicios web que serán utilizados por las aplicaciones móviles y bus de servicio, para poder gestionar los procesos móviles y de integración con otros sistemas. Las tecnologías utilizadas están basadas en los estándares JAX-WS y JAX-RS, lo que permite versatilidad de los clientes y gestión BPM. Al implementar esta tecnología se crea la posibilidad de ofrecer un entorno escalable al prototipo de integración ya que ofrece un punto administrable de integración rápida y robusta de los diferentes módulos y servicios que necesite una aplicación en un futuro, con esto se establece un punto importante en la modularidad y gestión de las aplicaciones, al salir de un modelo Monolitico de software a uno de microservicios.

En el proyecto de ejemplo se utiliza la gestión de un ESB por medio de Mule, para ofrecer un punto de integración de todos los servicios de gestión hacia las plataformas moviles desarrolladas en Apache Cordova, como se mencionó antes el entorno de Bonita BPM también ofrece una interfaz de servicios REST para poder gestionar dicho entono, es por esto que se toma la decisión de centralizar toda esta gestión en el ESB, ofreciendo un marco de seguridad y monitoreo de la gestión de estos servicios consumidos por otras aplicaciones ajenas al contenedor jboss de BonitaBPM o de la aplicación web.

Aplicación Móvil:

servicios expuestos ya sea en el proyecto web o en un intermediario que en este caso es representado por un bus de servicios. En la implementación de este sistema se utiliza el desarrollo hibrido proporcionado por apache Córdova el cual permite utilizar html acoplado con jquery Mobile, para generar las vistas en la aplicación Móvil y realizar peticiones Ajax a los servicios expuestos. En el desarrollo de esta aplicación móvil se ha implementado la comunicación y gestión de datos por medio de petición Ajax dirigidas al bus de servicio donde será redirigidas al proyecto de integración web Services.

8. Implementación mecanismo de verificación de la gestión de los procesos BPM

Para el proceso de verificación de la gestión de los procesos BPM, se ha decidido crear un módulo de consulta de historial de usuario donde se llevara el registro de todos los cambios y actores involucrados en la gestión de cada proceso, dicho desarrollo será implementado por medio del modelo de abstracción mencionado en capítulos anteriores, y expuesto en la aplicación web por medio de primefaces.

Por otro lado se implementa un conjunto de gráficos de control, permitiendo al usuario ver de forma estadística controles de tareas y procesos en determinados tiempo, con la implementación de dicho mecanismo se evidencia que la metodología BPM brinda las herramientas suficientes para establecer un marco de retroalimentación en la implementación y análisis de proceso al momento de integrarlas con herramientas de software. Mostrando a la organización un modelo de trazabilidad y control al momento de tomar decisiones, encaminando la visión organizacional con las herramientas de software implementadas.

9. Método de integración

Al momento de establecer el sistema de integración se ha implementado un proyecto común que se integra por medio de peticiones HTTP a los Servlet expuestos por la aplicación web de BonitaBPM permitiendo controlar todos los eventos del sistema BPM, dichos eventos serán gestionados por Managed Beans los cuales controlaran las peticiones al proyecto común por medio de instancias de objetos de abstracción del modelo BPM explicado anteriormente, por otra parte la gestión de las reglas de negocio propias del proceso y almacenamiento de información propia de la organización será controlada por los Managed Beans en función de los EJB y Entidades siguiendo el modelo de la arquitectura de JEE dentro del contenedor de EJB jboss AS 7.1.

9. Conclusiones.

La optimización de procesos en las compañías se ha convertido en un mecanismo para generar características de eficiencia con base a monitoreo y mejora continua de los mismos, en dicho proceso se evidencia la falta de articulación de los procesos con las herramientas tecnológicas diseñadas, generando inconvenientes en la gestión de las tareas de la organización. La metodología BPM permite optimizar los procesos y a su vez integrar la plataforma tecnológica existente para dar un enfoque de innovación y soporte a la misión y visión de la organización.

En el momento de implementar un modelo BPM se debe tener claro un esquema de integración con la totalidad de los servicios de la organización, dejando el sistema BPM trasversal a toda la gestión tecnológica de la compañía y así determinar cuál de los diferentes métodos de integración es mejor adoptar. La idea no es integrar múltiples servicios sin antes diseñar un modelo robusto y de fácil gestión de las múltiples aplicaciones en la compañía y si es el caso cambiar el modelo de implementación a una arquitectura orientada a servicios. La división de cada herramienta y articulación de un elemento central de gestión como lo es el BPM no debe verse como una dependencia del total de aplicaciones, sino como un punto de monitoreo y control que debe ser atendido como tal, dotándolo de buenas características de hardware y software.

Referencias

[1]Lic. P. Bazán. “Un modelo de integrabilidad con SOA y BPM”. Tesis de maestría en Redes de Datos. Facultad de Informática Universidad Nacional de La Plata. Buenos Aires. Argentina Diciembre 2009.

[2] G. González. “Cambiando los paradigmas del mundo de la Ingeniería de Software”. 2012. disponible en http://www.emb.cl/gerencia/articulo.mvc?xid=440. Consulta: Junio 2016

[3]J. Sepúlveda Hermes,”BPM se está posicionando en el mundo como el modelo de gestión organizacional por excelencia”. Disponible en http://www.club-bpm.com/Noticias/art00112.htm. Consulta: Junio 2016

[4]J. R. País Curto.”BPM”. “BPM (Business Process Management). Páginas 137-166.Editorial BPMteca. 2013.

[5]Lic. P. Bazán, “Tecnologías para implementar un marco integrador de SOA y BPM”, LINTI (Laboratorio de Investigación en Nuevas Tecnologías Informáticas) Facultad de Informática Universidad Nacional de La Plata, Mayo 2010

[6]J. Hoskins, “The Dynamic Business Network”. Paginas 23-32. “Achieving Business Agility with IBM BPM and SOA Connectivity”, editorial Maximun press. 2010

[7]Documentación oficial BonitaBPM, disponible en http://documentation.bonitasoft.com/product-bos-sp/development, sección: Development, Consulta : Agosto 2016.

[8] Kiran Garimella, Michael Lees, Bruce Williams, BPM (GERENCIA DE PROCESOS DE NEGOCIO) Disponible en: http://www.konradlorenz.edu.co/images/publicaciones/

suma_digital_sistemas/bpm.pdf. Consulta: Mayo 2016

[10] Hugo González, HERRAMIENTAS PARA LA MEJORA CONTINUA Disponible en https://calidadgestion.wordpress.com/2012/07/11/herramientas-para-la-mejora-continua/, 2012. Consulta: Junio 2016

[11] Yuli Paola Sanchez Moreno, CICLO PHVA Disponible en http://www.gerencie.com/ciclo-phva.html. Consulta: Julio 2016

[12] Ivar Jacobson, Grady Booch, James Rumbaugh, “El proceso Unificado de Desarrollo de Software “. Páginas: 1-29 . “El Proceso Unificado de Desarrollo de Software”. Editorial Addison Wesley. 2000.

[13] Documentación oficial Apache Córdova Disponible en:

http://cordova.apache.org/docs/en/latest/guide/overview/index.html, Consulta: Julio 2016

[14] Marisol, Diego Silva, “Convirtiendo Aplicaciones Java EE monolíticos a Microservicios”, 2015, Disponible http://www.apuntesdejava.com/2015/09/convirtiendo-aplicaciones-java-ee.html, Consulta: Julio 2016

[15] James Lewis, Martin Fowler, “Microservices”, 2014,

http://martinfowler.com/articles/microservices.html. Consulta: Julio 2016

[16] Txema Rodríguez, “Trabajar con microservicios: evitando la frustración de las (enormes) aplicaciones monolíticas”, 2014, Disponible en: http://www.genbetadev.com/paradigmas-de- programacion/trabajar-con-microservicios-evitando-la-frustracion-de-las-enormes-aplicaciones-monoliticas. Consulta: Julio 2016

[17] E.V.A. UCI, I. D. S. Conferencia #1. Introducción a la Ingeniería de Software, ISW 1.,

“Proceso Unificado de Desarrollo”, 2015, Disponible en:

http://www.ecured.cu/Proceso_Unificado_de_Desarrollo. Consulta: Julio 2016

[19] BonitaSoft, “Conoce Bonita BPM 7”. Disponible en: http://www.bonitasoft.com/products#feature-block-1. Consulta: Julio 2016

[20] MuleSoft, “What is Mule ESB?”. Disponible en: