Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 1 de 67
INTEGRACIÓN APLICACIONES SANITARIAS
MEDIANTE BP...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 2 de 67
INDICE
1 INTRODUCCIÓN.............................
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 3 de 67
1 INTRODUCCIÓN
El paradigma actual imperante en...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 4 de 67
Por otro lado disponemos de SOA (Service Orient...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 5 de 67
La tecnología de workflow no sólo es capaz de s...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 6 de 67
2 BPM
La Gestión de Procesos de Negocio engloba...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 7 de 67
2.1 BPMN (Business Process Modeling Notation)
B...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 8 de 67
Evento: un evento se representa con un círculo....
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 9 de 67
Objetos conectores
Los objetos de flujo se cone...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 10 de 67
Para los diseñadores que necesiten un nivel má...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 11 de 67
Las pools se usan cuando un diagrama implica d...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 12 de 67
Artefactos
BPMN fue diseñado para permitir a l...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 13 de 67
Los modeladores pueden crear sus propios tipos...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 14 de 67
Procesos B2B colaborativos
Un proceso B2B cola...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 15 de 67
A continuación tenemos un ejemplo de procesos ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 16 de 67
¿Cual es el valor de modelar en BPMN?
Los miem...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 17 de 67
ejecutados para alcanzar el
objetivo de un pro...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 18 de 67
Los estándares para orquestación de procesos i...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 19 de 67
BPEL
(Web Services) Business Process Execution...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 20 de 67
• Un modelo de lenguaje extensible de componen...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 21 de 67
Si ubicamos en cada componente las tecnologías...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 22 de 67
3 Modelado de Procesos Sector Sanitario
Como a...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 23 de 67
• El siguiente paso, por tanto, es un o-exlusi...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 24 de 67
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 25 de 67
La etapas mostradas en el dibujo número de 2 (...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 26 de 67
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 27 de 67
3.2 Modelado EPC con ARIS Express
Pasamos a co...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 28 de 67
Utilizando ARIS Express primeramente se muestr...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 29 de 67
Model graphic:
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 30 de 67
3.3 Modelado BPMN con ARIS Express
Se utiliza ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 31 de 67
El siguiente subproceso que se ha modelado es ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 32 de 67
• Bizagi Process Modeler es un Freeware que cu...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 33 de 67
Vemos que en este Diagrama de Nivel 0 ya nos a...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 34 de 67
Podemos visualizar una vez mas el proceso a ni...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 35 de 67
También podemos añadir texto formateado para d...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 36 de 67
4 SOA
La arquitectura orientada a servicios de...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 37 de 67
Podemos resumir los conceptos subyacentes fund...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 38 de 67
Una arquitectura concreta se desarrolla en un ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 39 de 67
• Enlazar: el cliente del servicio invoca o in...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 40 de 67
Para alcanzar los objetivos de interoperabilid...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 41 de 67
• La seguridad: el ESB posee la capacidad de i...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 42 de 67
procesos donde se definieron los procesos de n...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 43 de 67
5 Estrategia BPM + SOA
En este capítulo se rea...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 44 de 67
El modelo de integración que se presenta y que...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 45 de 67
participantes del workflow y, donde sea requer...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 46 de 67
entonces el sistema de workflow tampoco lo har...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 47 de 67
• Es adecuado para utilizarlo como APIs. Esto ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 48 de 67
El modelo de integración tiene por objetivo lo...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 49 de 67
Los componentes de la infraestructura son un c...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 50 de 67
El enfoque automático provee una mayor flexibi...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 51 de 67
6 Productos de Mercado
En este capítulo vamos ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 52 de 67
Pasamos a describir cada uno de los productos:...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 53 de 67
o Modificación y gestión sencilla de la normas...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 54 de 67
o Trabaja con lenguajes y herramientas que ya ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 55 de 67
o Libera desarrolladores para que trabajen en ...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 56 de 67
o Permite interoperar con otros sistemas que s...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 57 de 67
Rhapsody ofrece una completa, potente integrac...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 58 de 67
6.3 Mirth
Mith es un motor con interfaz HL7 de...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 59 de 67
Las características de Mirth son las siguiente...
Trabajo Final – 30 de Septiembre de 2011
Vicenç Robert Butí
Página 60 de 67
• Desarrollar y gestionar aplicaciones de form...
Integracion Aplicaciones Sanitarias con BPM + SOA
Integracion Aplicaciones Sanitarias con BPM + SOA
Integracion Aplicaciones Sanitarias con BPM + SOA
Integracion Aplicaciones Sanitarias con BPM + SOA
Integracion Aplicaciones Sanitarias con BPM + SOA
Integracion Aplicaciones Sanitarias con BPM + SOA
Integracion Aplicaciones Sanitarias con BPM + SOA
Próxima SlideShare
Cargando en…5
×

Integracion Aplicaciones Sanitarias con BPM + SOA

784 visualizaciones

Publicado el

The current prevailing paradigm in a Company is the Orientation Process. Processes based organizations can translate the strategies defined by the Direction in real actions on the organization and can define key performance indicators at all levels and successfully manage processes to improve outcomes.

Publicado en: Software
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
784
En SlideShare
0
De insertados
0
Número de insertados
7
Acciones
Compartido
0
Descargas
15
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Integracion Aplicaciones Sanitarias con BPM + SOA

  1. 1. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 1 de 67 INTEGRACIÓN APLICACIONES SANITARIAS MEDIANTE BPM Y SOA Trabajo Final primer curso de Master TIC Salud (2010-2011)
  2. 2. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 2 de 67 INDICE 1 INTRODUCCIÓN.................................................................................................... 3 2 BPM.......................................................................................................................... 6 2.1 BPMN (Business Process Modeling Notation) ................................................ 7 2.2 Orquestación y Coreografía de los Procesos de Negocio............................... 16 2.3 De BPMN a BPEL (Business Process Execution Language)......................... 18 3 Modelado de Procesos Sector Sanitario ................................................................. 22 3.1 Modelado EPC con MS Visio ........................................................................ 22 3.2 Modelado EPC con ARIS Express................................................................. 27 3.3 Modelado BPMN con ARIS Express............................................................. 30 3.4 Modelado BPMN con BizAgi ........................................................................ 31 4 SOA ........................................................................................................................ 36 4.1 Modelo de Referencia, Arquitectura y Plataforma......................................... 37 4.2 CORBA .......................................................................................................... 39 4.3 ESB (Enterprise Service Bus)......................................................................... 40 5 Estrategia BPM + SOA .......................................................................................... 43 5.1 EAI (Enterprise Application Integration)....................................................... 44 5.2 Sistemas de Workflow.................................................................................... 44 5.3 Integración basada en SOA y BPM................................................................ 46 6 Productos de Mercado ............................................................................................ 51 6.1 Ensemble de Intersystems .............................................................................. 52 6.2 Rhapsody de Orion Health ............................................................................. 56 6.3 Mirth............................................................................................................... 58 6.4 TIBCO ............................................................................................................ 59 6.5 WebMethods de SAG..................................................................................... 62 7 Conclusiones........................................................................................................... 64 8 Bibliografía............................................................................................................. 67
  3. 3. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 3 de 67 1 INTRODUCCIÓN El paradigma actual imperante en la empresa es la Orientación a Procesos. Las organizaciones basadas en procesos pueden traducir las estrategias definidas por la dirección en acciones reales sobre la organización, pueden definir indicadores clave de rendimiento a todos los niveles y gestionar correctamente los procesos para mejorar los resultados. Podemos comprobar que las compañías de éxito son capaces de sincronizar y alinear sus objetivos estratégicos con la ejecución táctica y diaria de sus procesos correspondientes. Es por ello que debemos trasladar estas ventajas competitivas al Sector Sanitario para obtener los mismos resultados. El objetivo de ese trabajo es realizar un estudio sobre la situación y los componentes de la Orientación a Procesos, mediante la Gestión de Procesos de Negocio (BPM: Business Process Management) y complementarlo con su soporte TI necesario que tiene como máxima expresión la Arquitectura Orientada a Servicios (SOA). El correcto desarrollo de ambas aproximaciones permitirá el éxito de la solución a desplegar. Ambas tecnologías se complementan y son los dos caras de la misma moneda, la empresa orientada a la consecución de sus objetivos estratégicos, sus resultados y su capacidad de supervivencia. El Sector Sanitario sólo puede alcanzar sus objetivos de manera eficiente si sus empleados/médicos/enfermeras/auxiliares/etc. y los sistemas de información se polarizan en la misma dirección, siendo los procesos de negocio quienes facilitan esta colaboración. En las compañías en general suele haber una brecha entre los aspectos organizacionales del negocio y la tecnología de información. Es importante hacer mínima esta brecha porque el mercado suele forzar a dar más y mejores productos a los clientes. Los productos que son exitosos hoy, pueden no serlo mañana. El mercado puede inclinarse hacia quien ofrezca el mejor producto y que sea más barato, con más calidad y con más eficiencia. En un nivel organizacional, los procesos de negocio son esenciales para comprender cómo funciona una organización. Aunque también son importantes para el diseño e implementación de sistemas de información flexibles. Estos sistemas proveen la base para la creación rápida de nueva funcionalidad que cree nuevos servicios, y también para adaptar rápidamente funcionalidad existente a requerimientos del negocio. BPM es por tanto una estrategia para gestionar y mejorar el rendimiento de una organización optimizando sus procesos a través de la modelización, ejecución y medida de rendimiento dentro de un ciclo de mejora continua.
  4. 4. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 4 de 67 Por otro lado disponemos de SOA (Service Oriented Architecture o Arquitectura Orientada a Servicios) que es otro paradigma que va mucho más allá de la arquitectura de software que implementa. La arquitectura SOA permite diseñar, construir, desplegar e integrar los servicios independientes de los lenguajes en los que estén codificados y de las plataformas en las que se ejecutan. Estos servicios están vinculados entre sí y se definen a través de procesos de negocio formando servicios compuestos que llevan a cabo las funciones empresariales. Algunos ejemplos de servicios que se pueden enumerar dentro del mundo real son: la localización de la información de facturación para el paciente, solicitud de transacciones recientes de cuenta financiera, identificación del propietario de un vehículo registrado, control de inventario de almacén para un determinado producto, o solicitud de una lista de vuelos disponibles para un determinado destino. En este marco, los servicios pueden compartirse y reutilizarse en varios procesos de negocio. El resultado es un entorno altamente adaptable, con menores costos para el desarrollo de aplicaciones, mejoras en la integración y despliegue rápido. Una simple SOA basada en servicios puede, de hecho, ser reutilizada ampliamente a lo largo de una empresa por muchos procesos de negocio. Y estos procesos de negocio pueden modificarse en cualquier momento a solicitud de otros nuevos y diferentes servicios. Una vez que se despliega SOA para las funciones principales del negocio, la capacidad de añadir dinámicamente nuevas capacidades a través de servicios pueden ayudar a reducir los costos de desarrollo y casi eliminar el tradicional ciclo de desarrollo más rápidamente, para ofrecer nuevos servicios al cliente y abrir nuevos canales de mercado. Un error común es creer que una SOA es una nueva versión de los Web Services. SOA define un modelo para la ejecución de un determinado proceso. Los Web Services, por otra parte, pueden facilitar la aplicación táctica del modelo SOA. De este modo, los Web Services son esencialmente sólo una de las muchas maneras en que puede construirse una SOA. El desarrollo de SOA y BPM están vinculados con la utilización del workflow. El logro principal que se busca alcanzar aquí es la representación explícita de las estructuras de los procesos a través de modelos, y la representación controlada de los procesos basándonos en los modelos creados con anterioridad. El término workflow consiste en la automatización de un proceso de negocio, en su totalidad o en parte, y en el cual se intercambian documentos, información o tareas de un participante a otro, para provocar la acción de acuerdo a un conjunto de reglas procedimentales. Un sistema de gestión de workflow permite definir, crear y manejar la ejecución de flujos de trabajo a través del uso de software, puede correr en uno o más motores, y es capaz de interpretar la definición del proceso, interactuar con los participantes del workflow y, donde sea requerido, invocar el uso de herramientas y aplicaciones de tecnología de la información.
  5. 5. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 5 de 67 La tecnología de workflow no sólo es capaz de soportar procesos de negocio dentro de un sistema dado o dentro de un conjunto de aplicaciones, lo que permite efectivamente integrar estos sistemas, sino que posibilita también representar procesos en los que hay seres humanos activamente involucrados, y así mejorar la colaboración entre los trabajadores con conocimiento.
  6. 6. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 6 de 67 2 BPM La Gestión de Procesos de Negocio engloba 2 visiones dentro de la empresa: el punto de vista de los analistas de negocio y el punto de vista de las Tecnologías de la Información TI. Los analistas de negocio desean modelizar, gestionar y optimizar los distintos proceso de negocio de la empresa con la subordinación de las Tecnologías de la Información. Por lo contrario los departamentos de TI consideran prioritario el uso adecuado de los Sistemas de Información y menos relevantes los aspectos de negocio y de modelizado de procesos. El objetivo debe ser la conciliación de ambos puntos de vista, la alineación de resultados comunes mediante el correcto uso de los paradigmas BPM y SOA. Business Process Management (BPM) es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales. BPM es un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno. BPM es una colaboración entre personas de negocio y tecnólogos para fomentar procesos de negocio efectivos, ágiles y transparentes. BPM abarca personas, sistemas, funciones, negocios, clientes, proveedores y socios. BPM combina 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 se alcanzan diversos objetivos: • 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. Para representar un proceso de negocio es preciso acordar una notación posible de modo que cada símbolo tenga un significado unívoco. Esta posible e importante notación es la que se conoce como BPMN.
  7. 7. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 7 de 67 2.1 BPMN (Business Process Modeling Notation) BPMN (Business Process Modeling Notation): El Business Process Management Initiative (BPMI) ha desarrollado una notación estándar llamada Business Process Modeling Notation (BPMN). El objetivo principal de BPMN es definir una notación que sea rápidamente comprensible por todos los profesionales de los negocios, desde el analista de negocio que hace el borrador inicial de los procesos, pasando por los desarrolladores técnicos responsables de implementar la tecnología que llevarán a cabo dichos procesos, llegando finalmente a la gente de negocio que gestionará y monitorizará esos procesos. Además, BPMN está apoyado en un modelo interno que genera el ejecutable BPEL4WS. Así, BPMN crea un puente estandarizado para el gap entre el diseño de los procesos de negocio y la implementación de procesos. BPMN define un Business Process Diagram (BPD), que se basa en una técnica de grafos de flujo para crear modelos gráficos de operaciones de procesos de negocio. Un modelo de procesos de negocio, es una red de objetos gráficos, que son actividades (trabajo) y controles de flujo que definen su orden de rendimiento. Un BPD está formado por un conjunto de elementos gráficos. Estos elementos permiten un fácil desarrollo de diagramas simples que serán familiares para la mayoría de analistas de negocio (diagrama de flujo). Los elementos han sido elegidos para ser distinguibles los unos de los otros y para usar formas familiares para la mayoría de modeladores. Por ejemplo, las actividades son rectángulos y las decisiones son diamantes. Debe notarse que uno de los objetivos del desarrollo de BPMN es crear un mecanismo simple para crear modelos de procesos de negocio, y al mismo tiempo que sea posible gestionar la complejidad inherente en dichos procesos. El método elegido para gestionar estos dos conflictivos requisitos fue organizar los aspectos gráficos de la notación en categorías específicas. Esto ofrece un pequeño grupo categorías que alguien que lea un BPD pueda reconocer fácilmente los tipos básicos de elementos y pueda entender el diagrama. Dentro de las categorías básicas de elementos, se puede añadir información y variaciones adicionales para dar soporte a los requerimientos complejos sin cambiar dramáticamente el look-and-feel básico del diagrama. Las cuatro categorías básicas de elementos son: • Objetos de flujo • Objetos conectores • Artefactos • Swimlanes Objetos de flujo Un BPD es un pequeño conjunto (tres) de elementos básicos, que son los Objetos de Flujo, de modo que los modeladores no tienen que aprender y reconocer un gran número de formas diferentes. Los tres objetos de flujo son:
  8. 8. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 8 de 67 Evento: un evento se representa con un círculo. Es algo que “pasa” durante el curso del proceso de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa (trigger) o un impacto (resultado). Los eventos representados con un círculo con centro abierto permiten a los marcadores internos diferenciar diferentes triggers y resultados. Hay tres tipos de eventos, basados en cuando afectan al flujo: Inicio , Intermedio, y Final. Un evento se representa con un círculo. Es algo que “pasa” durante el curso del proceso de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa (trigger) o un impacto (resultado). Los eventos representados con un círculo con centro abierto permiten a los marcadores internos diferenciar diferentes triggers y resultados. Evento Inicio Evento Intermedio Evento final Actividad: una actividad se representa con un rectángulo redondeado y es un término genérico para el trabajo que hace una compañía. Una actividad puede ser atómica o compuesta. Los tipos que hay son: Tarea y Sub-Proceso. El Sub-Proceso se distingue por una pequeña marca de suma en la parte central inferior de la figura. Gateway (compuerta): una gateway se representa por la típica figura de diamante y se usa para controlar la divergencia o convergencia de la secuencia de flujo. El gateway determina las tradicionales decisiones, así como la creación de nuevos caminos, la fusión de estos o la unión. Los marcadores internos indicarán el tipo de control de comportamiento.
  9. 9. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 9 de 67 Objetos conectores Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio. Hay tres objetos conectores que hacen esta función. Estos conectores son: Sequence Flow: el flujo de secuencia se representa por una linea sólida con una cabeza de flecha sólida y se usa para mostrar el orden (la secuencia) en el que las diferentes actividades se ejecutarán en el Proceso. El término “control flow” normalmente no se usa en BPMN. Message Flow: el flujo de mensaje se representa por un linea discontinua con una punta de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del proceso separados (entidades de negocio o roles de negocio). En BPMN, dos pools separadas en el diagrama representan los dos participantes. Association: una asociación se representa por una linea de puntos con una punta de flecha de lineas y se usa para asociar datos, texto, y otros artefactos con los objetos de flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades. Para los modeladores que requieren o desean más precisión para crear modelos de proceso por motivos de documentación y comunicación, los elementos básicos más los conectores dan la posibilidad de crear fácilmente diagramas comprensible.
  10. 10. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 10 de 67 Para los diseñadores que necesiten un nivel más alto de precisión, para análisis detallado o que sean gestionados por un Business Process Management System (BPMS), existen detalles adicionales que se pueden añadir a los elementos básicos. Swimlanes (canales) Muchas metodologías de modelado de procesos usan el concepto de swimlanes como un mecanismo para organizar actividades en categorías separadas visualmente para ilustrar diferentes capacidades funcionales o responsabilidades. BPMN soporta los swimlanes con dos constructores principales. Los dos tipos de objetos swimlanes o canales son: • Pool: una pool representa un Participante de un Proceso. Además actúa como un contenedor gráfico para particionar un conjunto de actividades desde otros pools, normalmente en el contexto de B2B • Lane: una lane es una sub-partición dentro de un pool y extiende la longitud del pool, verticalmente u horizontalmente. Las lanes se usan para organizar y categorizar actividades.
  11. 11. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 11 de 67 Las pools se usan cuando un diagrama implica dos entidades de negocio o participantes separados y están físicamente separados en el diagrama. Las actividades dentro de pools separadas se consideran procesos autocontenidos. Así, el flujo de secuencia no debe cruzar el límite de un pool. El flujo de mensajes se define como el mecanismo para mostrar las comunicaciones entre dos participantes, y, de este modo debe conectar dos pools (o los objetos dentro de las pools). Las pistas (lanes) están más estrechamente relacionadas con las metodologías tradicionales de las swimlanes. Las pistas se suelen usar para separar las actividades asociadas con la función o rol de una compañía específica. El flujo de secuencia puede cruzar los límites de las pistas dentro de un pool, pero el flujo de mensajes no puede ser usado entre objetos de flujo en pistas de mismo pool.
  12. 12. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 12 de 67 Artefactos BPMN fue diseñado para permitir a los modeladores y las herramientas de modelado un poco de flexibilidad a la hora de extender la notación básica y a la hora de habilitar un contexto apropiado adicional según una situación específica, como para un mercado vertical (por ejemplo, seguros o banca). Se puede añadir cualquier número de artefactos a un diagrama como sea apropiado para un contexto de proceso de negocio específico. La versión actual de la especificación de BPMN sólo tiene tres tipos de artefactos BPD predefinidos, los cuales son: • Data Object: los objetos de datos son un mecanismo para mostrar como los datos son requeridos o producidos por las actividades. Están conectados a las actividades a través de asociaciones. • Group: un grupo es representado por un rectángulo redondeado con linea discontinua. El agrupamiento se puede usar documentación o análisis, pero no afecta al flujo de secuencia. • Annotation: las anotaciones son mecanismos para que un modelador pueda dar información textual adicional.
  13. 13. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 13 de 67 Los modeladores pueden crear sus propios tipos de artefactos, que añaden más detalle sobre como se ejecuta el proceso. Sin embargo, la estructura básica del proceso, determinada por las actividades, gateways, y flujos de secuencia, no se cambia por añadir artefactos al diagrama. El modelado de procesos de negocio se usa para comunicar una amplia variedad de información a diferentes audiencias. BPMN está diseñado para cubrir muchos tipos de modelados y para permitir la creación de segmentos de proceso así como procesos de negocio end-to-end, con diferentes niveles de fidelidad. Dentro de la variedad de objetivos de modelado de procesos, hay dos tipos de modelos básicos que se pueden crear con un BPD: - Procesos B2B colaborativos (públicos) - Procesos de negocio internos (privados)
  14. 14. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 14 de 67 Procesos B2B colaborativos Un proceso B2B colaborativo ilustra las interacciones entre dos o más entidades de negocio. Los diagramas para estos tipos de procesos están generalmente desde un punto de vista global. Esto es, no toman la visión de un participante en particular, pero muestra las interacciones entre los participantes. Las interacciones están ilustradas como una secuencia de actividades y los patrones de intercambio de mensajes entre participantes. Las actividades para los participantes son los “touch-points” entre participantes; el proceso define las interacciones que son visibles al público para cada participante. Cuando miramos un proceso en un solo Pool (por ejemplo, para un participante), un proceso público también se llama proceso abstracto. Los procesos reales (internos) son como tener más actividades y detalle que lo que se enseña en los procesos B2B colaborativos. Procesos de negocio internos Un proceso de negocio interno se enfocará generalmente en el punto de vista de una única organización de negocio. Aunque los procesos internos suelen mostrar interacciones con participantes externos, definen las actividades que generalmente no están visibles para el público, esto es, privadas. Si se usan swimlanes entonces un proceso interno estará contenido dentro de un solo Pool. El flujo de secuencia del proceso está por lo tanto contenido dentro de un Pool y no puede cruzar los límites del Pool. El fujo de mensajes puede cruzar los límites del Pool para mostrar las interacciones que existen entre procesos de negocios internos separados. Así, un solo diagrama de procesos de negocio puede mostrar múltiples procesos de negocio privados. Propósitos diferentes – diferentes niveles de precisión El modelado de procesos de negocio suele empezar capturando actividades de alto nivel para luego ir bajando de nivel de detalle dentro de diferentes diagramas. Pueden haber múltiples niveles de diagramas, dependiendo de la metodología usada para desarrollar los modelos. De todas formas, BPMN es independiente de cualquier metodología.
  15. 15. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 15 de 67 A continuación tenemos un ejemplo de procesos de alto nivel, capturados para un caso de estudio de BPMN. Se trata de una serie de sub procesos con tres puntos de decisión A continuación se baja de nivel para mostrar en detalle el primer sub proceso: dos pools, una para los clientes y otra para la compañía suministradora Este diagrama muestra un proceso de negocio interno para la compañía y un proceso abstracto para el cliente.
  16. 16. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 16 de 67 ¿Cual es el valor de modelar en BPMN? Los miembros de BPMI Notation Working Group representan un gran segmento de la comunidad de modelado de procesos de negocio y han llegado a un consenso y presentan BPMN como la notación de modelado de procesos de negocio estándar. El desarrollo de BPMN es un paso importante para reducir la fragmentación que existe con la gran cantidad de herramientas de modelado de procesos y notaciones. El BPMI Notation Working Group aportan una gran experiencia con muchas de las notaciones existentes y trabajan para consolidar las mejores ideas de todas estas notaciones para crear una sola notación estándar. Como ejemplos de otras notaciones o metodologías que existen y fueron revisadas por el BPMI tenemos: • Diagramas de actividades de UML • UML EDOC Business Processes, • IDEF • ebXML BPSS • Diagrama de flujo de actividades-decisiones (ADF) • RosettaNet • LOVeM, • Cadenas de Eventos-Procesos (EPCs: Event-driven Process Chain). 2.2 Orquestación y Coreografía de los Procesos de Negocio Los procesos de negocio atraviesan la estructura organizativa y definen sus reglas independientemente del proceso. Los servicios resuelven funcionalidades concretas requeridas dentro de cada unidad organizativa y se componen para realizar los procesos de negocio a través de su orquestación y coreografía. En la tabla siguiente se presenta una comparación entre ambos conceptos fijando como patrones a contrastar, el objetivo de cada uno, el modelo o metáfora que siguen, el enfoque que se le da y el fundamento para su uso. ORQUESTACIÓN COREOGRAFÍA Objetivo Componer servicios para cumplir con un proceso de negocio dentro de una organización Componer servicios para colaboración entre organizaciones Modelo Jerárquico. Pregunta-Respuesta Peer – to –Peer Enfoque Componer servicios y el orden en que son Definir la manera en que múltiples partes colaboran
  17. 17. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 17 de 67 ejecutados para alcanzar el objetivo de un proceso de negocio para conformar una transacción de negocio Fundamento Constituye un servicio en sí mismo Define la interacción del negocio La orientación a procesos implica independizarse de la estructura organizativa, pensar las actividades según la manera en que se ejecutan en lugar de dónde se realizan. Los servicios resuelven aspectos funcionales directamente vinculados a la ubicación de la unidad funcional dentro de la estructura. Una buena resolución de procesos garantiza una buena solución orientada a servicios y no viceversa. La noción de una aplicación o servicio compuesto se basa en la idea de la construcción de nuevas aplicaciones o servicios, interconectando las partes existentes. La orquestación juega un papel importante en esto, ya que es quien aglutina estas partes al coordinar la ejecución de cada servicio discreto. La orquestación resuelve el problema de la ejecución de la aplicación de forma centralizada. En ella debe existir un mecanismo que dirige las actividades. Estas actividades son en realidad interacciones entre servicios, es decir, servicios que se invocan unos a otros, pero no de forma desordenada, sino de manera controlada por el orquestador que es quien conoce el detalle de todas las tareas que se deben llevar a cabo para completar el proceso. La construcción del proceso de negocio se realiza en dos pasos: primero se publican los servicios y luego se orquestan, es decir, se integra cada servicio al proceso en su lugar y momento adecuado. En la orquestación de servicios hay varios actores involucrados. Entre ellos encontramos la especificación del proceso de negocio, un motor de ejecución de procesos que contiene los procesos de negocios y sus reglas, y los consumidores de los servicios que se exponen. A diferencia de la orquestación, la coreografía plantea un esquema en donde no hay un control centralizado del proceso, sino un control “declarativo” que sólo especifica cuáles son las interacciones permitidas entre dos pares. De esta forma, dadas las reglas correctas, las partes interactuarán unas con otras en un estilo “peer-to-peer” y el proceso de negocio estará definido de forma implícita. De ahí su nombre (coreografía), ya que se asemeja a un estilo en donde cada parte hace su trabajo bajo ciertas reglas y se obtiene un resultado final conjunto. Para implementar coreografía se puede usar BPEL aún cuando éste está pensado para orquestación. La diferencia reside en que se especifica una serie de procesos entre cada par que interactuará y cada uno de estos procesos especificados representa la interacción válida entre dichos pares.
  18. 18. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 18 de 67 Los estándares para orquestación de procesos incluyen: • WSBPEL: cada proceso WSBPEL se expone como un Web Service usando WSDL que describe la entrada de datos y los puntos de salida del proceso. • BPEL4People: es una extensión del estándar WSBPEL que inserta tareas humanas en la orquestación. • BPMN: una notación visual para modelar procesos. diseñado para ilustrar los procesos y mapearlos a los lenguajes de ejecución como BPEL El estándar número uno para ejecutar procesos de negocios y controlar en forma centralizada (orquestar) servicios, es BPEL (Business Process Execution Language). BPEL es un lenguaje ejecutable que especifica la interacción entre Web Service. El estándar fue construido por un comité y hoy es mantenido por OASIS. Dicho comité se planteó ciertos objetivos, tales como usar Web Service, usar XML, poder administrar el ciclo de vida del proceso y poder gestionar transacciones a largo plazo. 2.3 De BPMN a BPEL (Business Process Execution Language) Para ayudar a aliviar el vacío técnico de modelado, un objetivo clave para el desarrollo de BPMN era crear un puente entre la notación de modelado de procesos de negocios y los lenguajes de ejecución respecto a las Tecnologías de la Información que implementan los procesos que hay dentro de un sistema. A partir de un diagrama BPMN, más un buen número de atributos de sus objetos, se puede hacer un mapeado al denominado Business Process Execution Language para Web Services (BPEL4WS). A continuación tenemos un segmento de un proceso de negocio que marca el mapeo con BPEL4WS.
  19. 19. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 19 de 67 BPEL (Web Services) Business Process Execution Language, WS-BPEL (en castellano, Lenguaje de Ejecución de Procesos de Negocio con Servicios Web), es un lenguaje estandarizado por OASIS para la composición de servicios web. Está desarrollado a partir de WSFL y XLANG, ambos lenguajes orientados a la descripción de servicios Web. Básicamente, consiste en un lenguaje basado en XML diseñado para el control centralizado de la invocación de diferentes servicios Web, con cierta lógica de negocio añadida que ayuda a la programación en gran escala (programming in the large). Antes de su estandarización se denominaba BPEL4WS. BPEL es un lenguaje de orquestación, no un lenguaje coreográfico. La diferencia mayor entre ambos es el ámbito. Un modelo de orquestación provee un ámbito específicamente enfocado en la vista de un participante en particular (ej: un modelo par-a-par). En cambio, un modelo coreográfico abarca todos los participantes y sus interacciones asociadas, dando una vista global del sistema. Las diferencias entre orquestación y coreografía están basadas en analogías: la orquestación describe un control central del comportamiento como un director de orquesta, mientras que la coreografía trata sobre el control distribuido del comportamiento donde participantes individuales realizan procesos basados en eventos externos, como en una danza coreográfica donde los bailarines reaccionan a los comportamientos de sus pares. A través de un documento XML BPEL, un analista de negocio es capaz de representar la lógica asociada y los elementos con los que se verá relacionado. Estos elementos serán servicios Web y la lógica el proceso BPEL. Si imaginamos un flujo de negocio determinado, con una entrada A y una salida Z, este se podría componer de muchos procesos internos que se lanzarían dependiendo de valores y respuestas anteriores. BPEL sería el encargado de orquestar todo el proceso ordenando qué proceso ejecutar (servicio Web) y en qué momento. Este lenguaje fue concebido por grandes de la informática como Oracle, BEA Systems, IBM, SAP y Microsoft entre otros. Es un lenguaje de alto nivel que lleva el concepto de servicio un paso adelante al proporcionar métodos de definición y soporte para flujos de trabajo y procesos de negocio El enfoque sobre procesos de negocios modernos más el bagaje de los lenguajes WSDL y XLANG, guiaron a BPEL a adoptar los servicios Web como su mecanismo de comunicación externa. Así las facilidades de mensajería BPEL dependen del uso del WSDL para describir los mensajes entrantes y salientes. Adicionalmente a proveer facilidades para habilitar el envío y recepción de mensajes, el lenguaje de programación BPEL también posibilita: • Un mecanismo de correlación de mensajes basado en propiedades. • Variables del tipo XML y WSDL.
  20. 20. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 20 de 67 • Un modelo de lenguaje extensible de componentes para permitir escribir expresiones y consultas (queries) en múltiples lenguajes: BPEL soporta Xpath 1.0 predeterminadamente. • Construcciones de programación estructurada incluyendo "if-then-elseif- else", "while", "sequence" (posibilita la ejecución de comandos en orden) y "flow" (posibilita la ejecución de comandos en paralelo). • Un sistema de ámbito (scoping) que permite el encapsulamiento de lógica con variables locales, manejadores de fallo, manejadores de compensación y manejadores de eventos. • Ámbitos serializados para controlar los accesos a las variables. Objetivos del diseño de BPEL • Definir procesos de negocio que interactúan con entidades externas mediante operaciones de un servicio Web definidas usando WSDL 1.1 y que se manifiestan a sí mismas como servicios Web. • Definir procesos de negocio utilizando un lenguaje basado en XML. No definir una interpretación gráfica de procesos o proveer de una metodología de diseño en particular. • Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio. • Proveer sistemas de control jerárquicos y de estilo gráfico, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos. • Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control. • Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar. • Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida. • Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo. • Usar servicios Web como modelo para la descomposición y ensamblaje de procesos. • Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible. La siguiente figura muestra una visión global de la Arquitectura SOA y todos sus componentes principales.
  21. 21. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 21 de 67 Si ubicamos en cada componente las tecnologías que nos parecen más apropiadas para el despliegue tenemos la siguiente figura En ella vemos el papel relevante de BPEL como tecnología para la composición de servicios ya existentes para conseguir construir los procesos de negocio que permitirán conseguir los objetivos empresariales deseados.
  22. 22. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 22 de 67 3 Modelado de Procesos Sector Sanitario Como aplicación práctica se presenta a continuación el modelado de un proceso sanitario: el Proceso de Ingreso en Cirugía: Mediante el modelado de este proceso se intenta mostrar y validar distintos tipos de diagramas y herramientas para poder comparar la efectividad y las facilidades de uso. Los posibilidades y alternativa presentadas en este trabajo son las siguiente: • Primeramente se realizará una descripción del proceso de Ingreso en Cirugía y su correspondiente modelado BPM mediante diagramas EPC (Event- driven Process Chain) o Evento-Función. Para este primer paso de utiliza la herramienta VISIO de Microsoft, herramienta que se utiliza sólo como herramienta gráfica, sin ningún tipo de validación del proceso diagramado. • A continuación se presenta una parte del proceso de Ingreso en Cirugía con el mismo tipo de diagrama EPC pero mediante la herramienta ARIS Express de Software AG. Dicha herramienta permite realizar distintas comprobaciones en relación a la corrección del diagrama presentado. No se hace en su totalidad porque se comprueba que a este nivel no aporta funcionalidad adicional y los esquemas resultan más pesados y difíciles de manipular en un portátil. • Después se realiza el modelado del Proceso de Ingreso en Cirugía con la herramienta ARIS Express pero utilizando la notación BPMN que es la que se considera más idónea en la actualidad y es la que se ha descrito con cierto detalle en este documento. • Finalmente se utiliza la herramienta BizAgi para realizar los mismos diagramas que se han desarrollado con ARIS Express para poder comparar ambas herramientas. 3.1 Modelado EPC con MS Visio Se describe a continuación lsa etapas mostradas del Proceso de Ingreso en Cirugía y los elementos del esquema EPC (Event-driven Process Chain): • Evento Realizar Ingreso Cirugía: Es el inicio del proceso de ingreso. • Función Búsqueda Paciente: El auxiliar administrativo accede al menú de pacientes del Sistema de Información Hospitalario (SIH) y busca mediante la identificación del paciente si el paciente ya está dado de alta en el Sistema. Puede que el paciente esté dado de alta o por lo contrario no esté dado de alta.
  23. 23. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 23 de 67 • El siguiente paso, por tanto, es un o-exlusivo, es decir hay 2 alternativas y sólo se pueden realizar una u otra. Las alternativas son operador o- exclusivo: o Existe paciente en el SIH o No existe paciente en el SIH • Evento Si Existe Paciente: El auxiliar administrativo sólo tiene que validar los datos administrativos del paciente: nombre, apellidos, DNI, domicilio, teléfono, correo electrónica, etc. • Evento Si NO Existe Paciente: El auxiliar administrativo tiene que registrar los datos administrativos del paciente: nombre, apellidos, DNI, domicilio, teléfono, correo electrónica, etc. En el siguiente paso se juntan los 2 caminos del o-exclusivo y se pasa a la siguiente función: • Función Confirmación Origen: El auxiliar administrativo confirma o introduce el origen del paciente: programado desde consultas externas, derivado de otros centros, gestionado por lista de espera, etc. • A continuación volvemos a tener 2 alternativas y sólo se pueden realizar una u otra. Las alternativas son operador o-exclusivo: o Existe paciente en el SIH o No existe paciente en el SIH • Evento Si Existe Paciente: El auxiliar administrativo sólo tiene que validar los datos de cobertura económica y filiación del paciente: paciente privado, mutua, seguridad social, etc. • Evento Si NO Existe Paciente: El auxiliar administrativo tiene que registrar los datos cobertura económica y filiación del paciente: paciente privado, mutua, seguridad social, etc. En el siguiente paso se juntan los 2 caminos del o-exclusivo y se pasa a la siguiente función. • Función Comprobación Historia y Episodio: El auxiliar administrativo comprueba la historia clínica y el episodio. El paciente y el episodio quedan asignados al servicio clínico correspondiente al ingreso.
  24. 24. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 24 de 67
  25. 25. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 25 de 67 La etapas mostradas en el dibujo número de 2 (ver más abajo), continuación del número 1 tenemos: • Evento Paciente y Episodio Asignados: a continuación sigue. • Función Preasignación de Cama: El auxiliar administrativo accede al Mapa de Camas del Sistema de Información Hospitalario (SIH) y realiza una preasignación de cama o unidad de enfermería. • Función Confirmación de Reserva de Quirófano: El auxiliar administrativo consulta la Planificación Quirúrgica del HIS y comprueba la reserva de quirófano. • La siguiente es la Función es la Validación de Otros Datos: El auxiliar administrativo validad los otros datos clínicos: médico, diagnóstico al ingreso, medicación preoperatoria, solicitudes de pruebas, informe de ingreso, etc. • Ahora se pasa a la Función de Aceptación Firmada: El auxiliar administrativo imprime la Hoja de Consentimiento y otros documentos de aceptación legal que debe firmar el paciente. • Finalmente se realiza la Función de Confirmación Ingreso: El auxiliar administrativo confirma en el SIH el ingreso del paciente a cirugía. • Se alcanza el Evento de Ingreso Realizado y finaliza el proceso de Ingreso en Cirugía Comentarios: - Para la claridad del esquema del Ingreso de Cirugía se ha omitido algunos elementos que eran evidentes, como por ejemplo en alguna función no se ha indicado que la realiza el auxiliar administrativo, o tampoco se ha indicado en alguna otra función que se accede al SIH (Sistema de Información Hospitalaria), todo ello para simplificar el esquema.
  26. 26. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 26 de 67
  27. 27. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 27 de 67 3.2 Modelado EPC con ARIS Express Pasamos a continuación a mostrar el mismo esquema (o parte de él) utilizando la herramienta ARIS Express. ARIS Express, que es una herramienta integral que permite diagramar de forma integrada varios tipos de esquemas,: • Diagrama de Organización • Proceso de Negocio a alto nivel • Proceso de Negocio • Modelo de Datos • Infraestructura TI • Sistemas TI • Diagrama según modelo BMPN • Diagrama tipo general A continuación se muestra la pantalla de inicio de modelado de ARIS Express
  28. 28. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 28 de 67 Utilizando ARIS Express primeramente se muestra el Esquema del Proceso de Ingreso de Cirugía a alto nivel (Nivel 0) y podemos afirmar que hay cuatro funciones importantes: • Validar / Registrar Datos Pacientes • Comprobar Historia Clínica y Episodio • Preasignación de Cama y Quirófano • Firma de Consentimiento. Model graphic: A continuación se desarrolla el esquema de parte del Proceso de Ingreso de Cirugía utilizando ARIS Express. Como se puede ver no aporta, a nivel de esquema, ninguna novedad en relación a los esquemas realizados con VISIO, pero en cambio hay que resaltar que todos los esquemas están integrados. Además ARIS sólo permite realizar determinadas acciones y comprueba en todo momento la integridad y coherencia de la información introducida. En contraposición con VISIO sólo se ha realizado un dibujo o esquema, de forma libre, y sin ninguna restricción. Otra característica importante de ARIS Express es que genera los capítulos y apartados de la documentación de forma automática. En el diagrama se han introducido comentarios adicionales, utilizando las cuadros de comentario de ARIS Express para complementar el esquema.
  29. 29. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 29 de 67 Model graphic:
  30. 30. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 30 de 67 3.3 Modelado BPMN con ARIS Express Se utiliza en este apartado la misma herramienta ARIS Express pero basándonos en los diagramas BPMN que son los más adecuados para un modelado profesional y correctamente validado, y que permite posteriormente generar instrucciones BPEL de forma inmediata para la construcción del proceso de negocio. Los diagramas BPMN permite definir los Diagramas de Proceso de Negocio (BPD) mediante Tareas y SubTareas / Subprocesos lo que facilita una visión de distintos niveles del proceso de negocio a diagramar. Primeramente se presenta el BPD de nivel 0, en que sólo hay los Tareas Principales que serán descompuestas en los siguientes diagramas de nivel 1. Como hemos indicado anteriormente el Proceso de Ingreso de Cirugía a alto nivel y podemos decir que hay cuatro subprocesos importantes: • Validar / Registrar Datos Pacientes • Comprobar Historia Clínica y Episodio • Preasignación de Cama y Quirófano • Firma de Consentimiento. El proceso se inicia con el correspondiente Evento de Inicio (círculo verde) y finaliza con el Evento de Finalización (círculo rojo) Cada uno de las tareas anteriores debe descomponerse en sus correspondientes procesos. A continuación se modela el Subproceso de Validar / Registrar los Datos de Paciente y para ello se utiliza la compuerta exclusiva XOR , que implica que de varias alternativas presentadas sólo puede utilizarse una.
  31. 31. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 31 de 67 El siguiente subproceso que se ha modelado es el Preasignación de Cama y Quirófano como se muestra a continuación. 3.4 Modelado BPMN con BizAgi Pasamos a desarrollar los diagramas del Proceso de Ingreso en Cirugía utilizando BizAgi. BizAgi es una suite ofimática con dos productos complementarios, un Modelador de Procesos (bizagi Process Modeler) y una Suite de BPM (bizagi BPM Suite):
  32. 32. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 32 de 67 • Bizagi Process Modeler es un Freeware que cuenta con miles de usuarios a nivel mundial y es utilizado para diagramar y documentar procesos usando la notación estándar BPMN (Business Process Modeling Notation) • Bizagi BPM Suite es una solución de Gestión de procesos de negocio (BPM) que le permite a las organizaciones ejecutar/automatizar procesos o flujos de trabajo (workflows). Bizagi BPM Suite se integra con aplicaciones como SAP, Documentum, Sharepoint y correo electrónico. Existe una edición de nivel de entrada (Edición Xpress) y dos ediciones corporativas (Enterprise .NET y Enterprise JEE). Bizagi Limited es una compañía privada establecida en 1989, y su nombre significa agilidad de negocio (Business Agility). Volvemos a diagramar el BPD de novel 0 con los correspondientes subprocesos: • Validar / Registrar Datos Pacientes • Comprobar Historia Clínica y Episodio • Preasignación de Cama y Quirófano • Firma de Consentimiento.
  33. 33. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 33 de 67 Vemos que en este Diagrama de Nivel 0 ya nos aparece el concepto de Canal o Lanes para indicar la propiedad o pertenencia del Proceso. Pasamos ahora a analizar los distintos subprocesos. Primeramente desarrollamos el diagrama del Subproceso de Validar / Registrar Datos de Pacientes Una vez realizado el diagrama podemos comprobar el subproceso de Validar / Registrar Datos de Pacientes puede visualizarse dentro del proceso principal si se considera necesario. La herramienta BizAgi permite este tipo de representaciones que facilita la comprensión de los diagramas: A continuación desarrollamos el Subproceso de Preasignación de Cama y Quirófano con sus 3 tareas correspondientes:
  34. 34. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 34 de 67 Podemos visualizar una vez mas el proceso a nivel 0 (BPD0) y su descomposición, en el mismo diagrama, con los subprocesos correspondientes. Pasamos ahora a mostrar distintos formas de enriquecer los diagramas y mejoras la comprensión de ellos mediante comentarios explicativos.
  35. 35. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 35 de 67 También podemos añadir texto formateado para disponer de información adicional para la comprensión del proceso diagramado. Finalmente en la definición del subproceso de Consentimiento se han utilizado los denominados Artefactos para mostrar que el Sistema genera un documento que el Paciente debe aceptar y firmar. En este caso se generan 2 documentos: la Hoja de Consentimiento y Otros Documentos Legales.
  36. 36. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 36 de 67 4 SOA La arquitectura orientada a servicios de cliente (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. SOA define las siguientes capas de software: • Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; • De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web); • De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración; • De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio; • De entrega - donde los servicios son desplegados a los usuarios finales. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. Conceptos y definiciones Comenzaremos definiendo el concepto de una arquitectura de software para poder comprender mejor la idea de una Arquitectura Orientada a Servicios. Según IEEE una arquitectura de software es la organización fundamental de un sistema, reflejado por sus componentes, relaciones entre ellos y entorno, así como los principios que regirán su diseño y evolución. Según OASIS, se define como la estructura o estructuras de un sistema de información formado por entidades y sus propiedades externamente visibles, así como las relaciones entre ellas (Modelo de Referencia para SOA 1.0 – Agosto de 2006). Adaptándose a la definición de OASIS, se define SOA como un paradigma capaz de organizar y utilizar las capacidades distribuidas, que pueden estar bajo el control de distintas organizaciones, y de proveer un medio uniforme para publicar, descubrir, interactuar y usar los mecanismos oportunos para lograr los efectos deseados.
  37. 37. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 37 de 67 Podemos resumir los conceptos subyacentes fundamentales en este paradigma en los siguientes: Proveedor: entidad (organización o persona) que ofrece el uso de capacidades mediante servicios. • Necesidad: carencia de una empresa para resolver la actividad de su negocio. • Consumidor: entidad (organización o persona) que busca satisfacer una necesidad particular a través de las capacidades ofrecidas por servicios. • Capacidad: tarea que el proveedor de un servicio puede proporcionar al Consumidor • Servicio: mecanismo que permite el acceso a una o más capacidades alcanzables por medio de una interfaz preestablecida, y que se llevará a cabo de forma consistente con las normas establecidas para él. • Descripción del servicio: información necesaria para hacer uso del servicio. • Interacción: actividad necesaria para hacer uso de una capacidad con el objeto de obtener efectos deseados 4.1 Modelo de Referencia, Arquitectura y Plataforma SOA es un modelo de referencia para entender las relaciones más significativas dentro del dominio de un problema concreto y facilitar el desarrollo de estándares o especificaciones. Se fundamenta en un pequeño número de conceptos para explicar el modelo a profanos y busca producir una semántica sin ambigüedades. SOA es un modelo de referencia para: • La creación y utilización de servicios a lo largo de su vida útil • La definición de la infraestructura que permita intercambiar datos entre diferentes aplicaciones • La participación de los servicios en los procesos de negocios independientemente del sistema operativo, los lenguajes de programación y si los procesos son internos o externos a la organización Los conceptos y sus relaciones, definidas en el modelo de referencia SOA, deben ser la base para describir la arquitectura. Una arquitectura SOA concreta será el producto de aplicar la arquitectura de referencia desarrollada según el modelo de referencia y los patrones de esa arquitectura, así como los requerimientos necesarios, incluyendo los impuestos por los entornos tecnológicos. La aplicación de un modelo de referencia para lograr una arquitectura completa, equivale a pasar de una etapa de análisis a una de diseño en analogía con las etapas del ciclo de vida del software. Implica dar un paso más en el nivel de detalle y comenzar a buscar metodologías para aplicar sobre los conceptos analizados.
  38. 38. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 38 de 67 Una arquitectura concreta se desarrolla en un contexto predefinido donde se fijan protocolos, perfiles, especificaciones y estándares. La plataforma SOA combina estos elementos a los efectos de generar un producto operativo. La Figura siguiente presenta un marco general entre la noción de marco de referencia, arquitectura de referencia y arquitectura específica, que muestra qué aporta y en qué consiste cada una de ellas, así como el paso de lo más abstracto hacia lo más concreto. Según los conceptos subyacentes a SOA descriptos con anterioridad, el modelo de interacción es uno de los más relevantes dado que aporta la manera en que los servicios se comunican entre sí. Este modelo de interacción sigue el paradigma triangular de Publicar - Buscar – Ejecutar. En este paradigma, los proveedores registran sus servicios en un registro público. Los consumidores utilizan este registro para buscar servicios que cumplan con cierto criterio. Si el registro posee tal servicio, el mismo provee al consumidor con un contrato y un punto de acceso para el servicio. • Publicar: para que un servicio sea usado, su descripción de servicio debe ser publicada • Descubrir / Encontrar: el consumidor busca una descripción de servicio directamente, o hace una búsqueda de servicios. La operación se puede hacer en dos puntos del ciclo de vida del cliente: durante el diseño o durante la ejecución
  39. 39. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 39 de 67 • Enlazar: el cliente del servicio invoca o inicia la interacción con el mismo durante la ejecución, contando con los detalles en la descripción del servicio para localizarlo, contactarlo e invocarlo 4.2 CORBA El mecanismo de integración vía un broker o agente de mensajes es el marco conceptual sobre el que se sustenta CORBA. CORBA (Common Object Request Broker Architecture) fue el proyecto de middleware más importante y ambicioso de la industria de la informática de fines de la década del ‘90. Es producto de un consorcio que aglutinó a 650 compañías (entre las que NO se encuentra Microsoft que compitió con DCOM (Distributed Componente Object Model). El bus de objetos de CORBA define la forma de los componentes que viven dentro de él y cómo interoperan. CORBA constituye un estándar de la OMG4 que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. CORBA fue diseñado para permitir que componentes inteligentes (pensadas en términos de objetos) se descubran unas a otras e interoperen. Pero trasladar el paradigma de la orientación a objetos a un entorno distribuido implica sin duda agregar conceptos que están ausentes en un entorno único o local como lo son: • Transaccionalidad • Seguridad • Cerramiento y/o Aislamiento • Persistencia
  40. 40. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 40 de 67 Para alcanzar los objetivos de interoperabilidad se definió el IDL (Interface Definition Language). Es un lenguaje puramente declarativo, no provee detalles de implementación y provee independencia del lenguaje de programación y del sistema operativo. Un IDL se usa para: • Especificar atributos de los componentes • Heredar clases de un padre • Levantar excepciones • Emitir eventos tipificados • Declarar los métodos que soporta el componente La gramática IDL es un subconjunto de C++ con palabras claves adicionales para soportar conceptos distribuidos. El ORB (Object Request Broker) es el middleware que establece la relación solicitud/proveedor entre objetos distribuidos. Las interfaces mediante las cuales especificar los servicios que se proveen, están definidas en el lenguaje IDL de OMG y los objetos distribuidos son identificados por medio de referencias que implementan la interfaz remota. Por último, CORBA define un conjunto de servicios distribuidos, definidos en el nivel superior del ORB, para soportar la integración e interoperabilidad de objetos distribuidos. Estos servicios resuelven los aspectos mencionados anteriormente acerca de los objetos distribuidos como lo son la transaccionalidad, seguridad, cerramiento y/o aislamiento y persistencia 4.3 ESB (Enterprise Service Bus) En función de las motivaciones presentadas en el paradigma SOA, resulta evidente la necesidad de contar con una infraestructura de IT que apoye la gestión de los servicios. Sobre una arquitectura SOA se puede definir un bus de servicios empresariales (Enterprise Service Bus o ESB) como una plataforma de software que da soporte a muchas funcionalidades resueltas a nivel de la capa de aplicación en los enfoques tradicionales de construcción de aplicaciones. Tales funcionalidades son: • La comunicación: el ESB se ocupa del enrutamiento de los mensajes entre los servicios. • La conectividad: el ESB resuelve la conectividad entre extremos mediante la conversión de protocolos entre solicitante y servicio. • La transformación: es responsabilidad del ESB resolver la transformación de formatos de mensajes entre solicitante y servicio. • La portabilidad: los servicios serán distribuidos independientemente del lenguaje de programación en el que estén escritos y del sistema operativo subyacente.
  41. 41. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 41 de 67 • La seguridad: el ESB posee la capacidad de incorporar los niveles de seguridad necesarios para garantizar servicios que puedan autenticarse, autorizarse y auditarse. Actualmente existen dos tendencias mayoritarias para la implementación de un ESB: los que requieren un servidor de aplicaciones y los que son totalmente distribuidos y, por lo tanto, no lo requieren. Funcionalmente, cualquiera de las dos tendencias conserva sus propias características pero se puede afirmar que un ESB totalmente distribuido que no requiere de un servidor de aplicaciones tendrá mayor independencia de la plataforma y será capaz de ofrecer una mayor ubicabilidad de los servicios que gestiona. Más allá de la estructura interna, el concepto de bus, lo componen los mecanismos de comunicación que hacen que todos los elementos conectados al ESB puedan conectarse entre sí, sin necesidad de conocerse unos a otros. Un ESB centraliza el control y distribuye el procesamiento. Para lograr este objetivo los ESB evolucionaron desde la integración por adaptadores, donde se centralizaba tanto el control como el procesamiento. Los ESB representan una suerte de federación de adaptadores a gran escala donde la configuración centralizada es un concepto que se implementa de manera distribuida En la siguiente Figurase muestra el resultado de la implementación de un ESB. El nodo de Configuración y Control de Servicios tiene línea punteada para ilustrar su construcción lógica. Cuando las soluciones tecnológicas brindan herramientas completas para gestionar los servicios desde los procesos de negocios, los ESB están dirigidos por los servidores de
  42. 42. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 42 de 67 procesos donde se definieron los procesos de negocios y es dicho servidor quien gestiona y orquesta las solicitudes a través del ESB. Tal es el caso de la solución de IBM mediante su línea de WebSphere BPM. En este marco, podemos afirmar que, hoy por hoy, los Web Services no constituyen un ESB por sí mismos, pero sí pueden ser parte de él.
  43. 43. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 43 de 67 5 Estrategia BPM + SOA En este capítulo se realiza un análisis evolutivo del estado del arte respecto a la integración de aplicaciones y se estudian las características principales de esta evolución para poder plantear un nuevo modelo de integrabilidad entre SOA y BPM. Este modelo se basa en la premisa de obtener soluciones a los problemas de las organizaciones, que cuenten con una integración completa y esté guiada por una metodología. Como vimos en el capítulo 4, SOA es una metodología de desarrollo de software que se enfoca en crear una arquitectura más flexible que pueda atravesar múltiples dimensiones mientras que BPM, por su parte, se enfoca puramente en optimizar la manera de trabajo real. En el capítulo 2, al describir BPM, vimos que representa una manera de analizar y medir el negocio o la realidad, en términos de procesos de negocios que atraviesan la organización y los límites de los sistemas. Si bien los primeros esbozos de realizar reingeniería de procesos fueron un aporte importante en el sentido de que se basaban en la idea de la mejora de los mismos, no dejaban de enfocarse en la automatización de la tarea y no en la optimización de la misma. Además tenían la particularidad de que los procesos se gestionaban por herramientas construidas ad-hoc. La evolución natural fue entonces hacia la definición de una estrategia para gestionar y mejorar el rendimiento de un negocio a través de la optimización continua de sus procesos dentro de un ciclo de modelado, ejecución y medida. BPM es tal estrategia o disciplina. BPMS (Sistemas o Suite para BPM) proveen un conjunto de herramientas integradas que soportan el diseño, media, monitorización, análisis y mejoras continuas al proceso de negocio. BPM es el complemento natural de SOA, y un mecanismo a través del cual una organización puede aplicar SOA a sus procesos de negocio. BPM aporta valor en el mundo real mientras que SOA facilita la integración de soluciones y provee tecnologías para gestionar los componentes técnicos de un proceso de negocio. Los analistas de procesos de negocio usan BPM para crear y optimizar modelos de procesos de negocio, encontrar servicios de negocio que implementen las actividades modeladas, volcándolos en un BPMS. Lo deseable es que el resultado de esta producción culmine en procesos desplegados como servicios, registrados en un repositorio y expuestos a los consumidores.
  44. 44. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 44 de 67 El modelo de integración que se presenta y que surge de un análisis del estado del arte en términos de integración de aplicaciones, define un conjunto de componentes tanto tecnológicos como de negocios, que dan una visión unificada e integradora de la solución alcanzada. 5.1 EAI (Enterprise Application Integration) Este modelo se basa en la construcción de un nodo central y un conjunto de repetidores directamente asociados a éste, aunque los repetidores no se encuentran conectados entre sí. De esta manera, el middleware está representado por la integración centralizada de aplicaciones, y las aplicaciones que deben ser integradas son reflejadas por los repetidores. Las mismas interactúan entre ellas por medio de la integración centralizada de aplicaciones. Las aplicaciones pueden interactuar de formas muy diversas, desde invocaciones simples hasta interacciones complejas entre múltiples aplicaciones. Estas últimas consisten en una serie de actividades representadas por una invocación a una aplicación, además de existir restricciones de ejecución entre las mismas. Este esquema de agentes y mensajes tiene ciertos inconvenientes. El primero de ellos es que el agente contiene cierta lógica, oculta en las reglas. La programación de éstas puede volverse una labor compleja debido a las dependencias que pueden darse entre las mismas, y el hecho de cambiar una regla puede tener implicancias en el comportamiento global del sistema. La razón principal de estos problemas es la “pérdida” conceptual que se da en la integración de aplicaciones, ya que la integración de datos y de procesos requiere gran actividad de programación y configuración de bajo nivel, tanto de adaptadores como de los agentes de mensajes. La integración de datos suele darse mediante actividades de mapping, lo cual requiere un modelo de datos acordado entre todas las aplicaciones y que reside en los agentes. Este modelo global suele no ser explícitamente desarrollado, pero es común encontrarlo oculto en las reglas de mapeo de datos efectuadas por los adaptadores. 5.2 Sistemas de Workflow El término workflow consiste en la automatización de un proceso de negocio, en su totalidad o en parte, en el cual se intercambian documentos, información o áreas de un participante a otro, para provocar la acción de acuerdo a un conjunto de reglas procedimentales. Un sistema de gestión de workflow es un sistema que permite definir, crear y manejar la ejecución de flujos de trabajo a través del uso de software, que corre en uno o más motores, y que es capaz de de interpretar la definición del proceso, interactuar con los
  45. 45. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 45 de 67 participantes del workflow y, donde sea requerido, invocar el uso de herramientas y aplicaciones IT. La integración de aplicaciones es efectuada por el sistema de gestión de workflow, usando adaptadores similares a los que se usan en un ambiente tradicional de aplicaciones empresariales. La tecnología de workflow es capaz de soportar procesos de negocio dentro de un sistema dado o dentro de un conjunto de aplicaciones, lo que permite efectivamente integrar estos sistemas. Sin embargo esta tecnología posibilita también representar procesos en los que hay seres humanos activamente involucrados, y así mejorar la colaboración entre los trabajadores con conocimiento. El sistema de workflow cubre todos los aspectos del proceso de negocio correspondiente: el Flujo, la Gente y los Efectos La tecnología de gestión de workflow puede ser utilizada para facilitar la modificación de la lógica del proceso realizado por aplicaciones. Las funciones de una aplicación son pasos en el workflow, y cada componente usa un modelo de workflow para representar las funciones. Por la modificación de la lógica del proceso especificada en los modelos de workflow, se puede modificar el comportamiento de las aplicaciones sin codificar. Workflow no es: – Un sistema de gestión de documentos (trabaja con ellos) – Un sistema de e-mail o groupware (trabaja con ellos) – Un sistema de distribución de datos entre sistemas (para ello workflow utiliza EDI, WebForms, XML, SOAP, http, etc.) – Una transacción para secuenciar pantallas – Administración de datos temporales – Una herramienta que se utilice para realizar funciones no existentes en el sistema (si no se puede ejecutar la función manualmente en el sistema,
  46. 46. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 46 de 67 entonces el sistema de workflow tampoco lo hará) Se presenta a continuación algunos esquemas de workflow. Hoy en día, la mayor cantidad de aplicaciones empresariales, como las aplicaciones de planificación, poseen un componente workflow que facilita la adaptación flexible de los procesos de negocio dentro de estos sistemas. Podemos concluir que una aplicación de workflow única consiste de actividades y su correspondiente ordenamiento causal y temporal, donde las mismas son realizadas por un sistema común. Los workflow de aplicación múltiple contienen actividades que son realizadas por sistemas de múltiples aplicaciones, proveyendo así una integración de las mismas. 5.3 Integración basada en SOA y BPM El software de workflow utilizado para integrar aplicaciones siguiendo el paradigma de SOA y BPM y puede cubrir cuatro aspectos: • Ser un componente de aplicaciones verticales. Un software de workflow es ágil a la hora de adaptarse a los cambios de procesos y cambios organizacionales. Esta es una realidad en muchas aplicaciones verticales.
  47. 47. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 47 de 67 • Es adecuado para utilizarlo como APIs. Esto es así si cuenta con soporte para Java que permite integrarse tanto para aplicaciones Web como para otras aplicaciones de IT. • Constituye el elemento unificador para aplicaciones colaborativas, tanto desde el punto de vista de aplicaciones que se construyen como composición de otras bajo la filosofía de Web Services, como del de la automatización de procesos basados en reglas. • Se ajusta a la implementación de Web Services. Pero en una aplicación donde el proceso de negocio sea realmente un conjunto de tareas cuyos participantes son Servicios Web, provoca inevitablemente un desorden dentro del workflow y surge la necesidad de interoperar y describir procesos ejecutables. La interoperabilidad se logra a través de la adopción de estándares como XML y WSDL, mientras que la descripción de procesos ejecutables se puede llevar a cabo a través de BPEL Los desarrollos en arquitectura de software empresarial y en BPM están relacionados con la gestión de workflow. El logro principal que se busca alcanzar aquí es la representación explícita de las estructuras de los procesos a través de modelos, y la representación controlada de los procesos basada en los modelos creados con anterioridad. Para la realización de aplicaciones de composición en un ambiente de orientación a servicios, se utilizan técnicas de composición de servicios. El middleware de integración de aplicaciones en general, y el middleware de bus de servicios empresariales en particular, proveen una base técnica aceptable para realizar composición de servicios, debido a que proveen interfaces estándar que pueden ser utilizadas en desarrollos de composición. El middleware típico para la integración de aplicaciones empresariales presenta un componente de workflow de sistema, que puede o bien usar un código propietario o bien usar código BPEL (Lenguaje de ejecución de procesos de negocio para Web Services). La composición de servicios es una idea de especial interés para el desarrollo de nuevas aplicaciones, basándose en funcionalidad ya existente. Así, la composición describe la forma en que se relacionan los distintos servicios, es decir que se están describiendo estructuras de proceso. Como resultado, una composición BPM como la nueva metodología para satisfacer los objetivos de una organización a través de la gestión de procesos de negocio, no plantea una visión completamente renovadora y de empezar de cero, sino que es necesario contemplar todo el trabajo realizado con anterioridad dentro de la empresa, de manera de apuntar a la integración. Aquí es donde se insertan los conceptos de SOA, Web Services y BPEL, de manera tal de lograr construir una aplicación real, integrada e insertada en un entorno B2B, y por sobre todo, orientada a procesos.
  48. 48. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 48 de 67 El modelo de integración tiene por objetivo lograr una integración completa, segura y confiable de un conjunto de sistemas de software existentes, maximizando la reutilización de código, manteniendo un bajo acoplamiento y favoreciendo el mantenimiento ágil y a bajo costo. Los elementos de este modelo de integración llevan a analizar los tipos de integración posible, los métodos aplicados para llevar a cabo la integración, los componentes de infraestructura requerida y los actores que participan. Este análisis realizado tiene por finalidad aportar criterios a la hora de decidir cuáles de todos los elementos se elegirán para componer un modelo de integración. Tipos de integración Si bien existen diversas taxonomías acerca de los posibles tipos de integración existentes, los más frecuentes, teniendo en cuenta el enfoque que se abordará, se refieren a la integración desde dos aspectos posibles: • Integración a nivel de datos: se enfoca en el movimiento de datos entre aplicaciones con el objetivo de compartirlos. Es una integración relativamente simple si se comparten formatos y estructuras, de lo contrario se establecen protocolos o acuerdos entre las partes para poder realizar la integración. (Ejemplo: integración por XML) • Integración a nivel de aplicaciones: se basa fundamentalmente encompartir funcionalidad. Es una integración basada en APIs que exponen su funcionalidad a través del uso de interfaces que serán tanto más portables dependiendo del lenguaje utilizado para definirse. (Ej: IDL de CORBA o WSDL de los Web Services) Tanto desde el punto de vista de los datos como de las aplicaciones, el modelo de integrabilidad aborda cualquiera de estos tipos de integración con la visión de los mismos como servicios coordinados por procesos. La integración de datos dirigida por procesos ayuda a enriquecer los servicios de negocios SOA y los procesos BPM a través de una secuencia de servicios de datos combinados de manera reusable que incorpora la intervención de tareas humanas transformando la información en exacta, consistente y oportuna. La integración de aplicaciones tiene por objetivo entender y usar las interfaces para acceder a la funcionalidad requerida y enmascarar u ocultar las diferencias tecnológicas usadas por cada interfaz en su acceso. Esto último se lleva a cabo con servicios que exponen sus interfaces. La idea subyacente es que los procesos de integración se encuentren separados de los procesos de negocio en sí mismos. Esto requiere examinar los sistemas existentes, extraer datos y procesos y obtener una manera de meta-anotación Componentes de infraestructura para la integración
  49. 49. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 49 de 67 Los componentes de la infraestructura son un conjunto de servicios agrupados según la funcionalidad que resuelven y que conforman la base sobre la que se construirá el modelo de integrabilidad. Analizamos cada uno en detalle dando una idea de su implementación posible. Comunicación La comunicación asegura a los desarrolladores un nivel de abstracción tal, que pueden independizarse de los detalles de bajo nivel asegurando que proveedor y consumidor de servicio puedan encontrarse. Pueden utilizarse sistemas de comunicación asincrónicos basados en mensajería o bien sincrónicos vía un broker de objetos o bien un ESB. Estos middleware usan protocolos estándar como SOAP (Simple Object Access Protocol), HTTP, TCP/IP, IIOP (Internet Inter-ORB Protocol) • Enrutamiento y mediación: el enrutamiento y mediación es un nivel que adapta el nivel de comunicación entre aplicaciones de tal modo que las mismas puedan interoperar. Entre las responsabilidades que tiene este nivel está la de lograr que datos provenientes de distintas fuentes representen un concepto de negocio. Este nivel utiliza metadatos para definir las aplicaciones participantes, los métodos, los mensajes, las interfaces y las secuencias de operación invocados. • Transformación: La transformación de las estructuras de datos ha sido siempre un problema resuelto de manera puntual, escribiendo código ad- hoc que leía y transformaba al formato destino de manera puntual. La aparición de los lenguajes de marcado y en particular el XML como estándar de facto para el intercambio de datos, otorgaron un mayor nivel de madurez a la transformación de los datos. La transformación hoy puede considerarse como un servicio provisto por las máquinas de transformación basadas en XSLT (EXtensible Stylesheet Language for Transformations) que producen transformaciones independientes del lenguaje y la plataforma. • Coordinación/Orquestación: En un enfoque dirigido por procesos es preciso sincronizar las actividades de integración definiendo formalmente los servicios que requieren los procesos y las aplicaciones, secuenciándolos en una orquestación. En este sentido, una infraestructura de integración debe contar con algún mecanismo de coordinación inter- procesos o intra-procesos que ordene los pasos a seguir para conducir los servicios. La orquestación ha evolucionado desde el enfoque manual al automatizado. En el primer caso, se reducía a código inyectado en las plicaciones que resolvía integración punto a punto y que tenía embebida la lógica del workflow. Esto resultaba difícil de mantener y de modificar.
  50. 50. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 50 de 67 El enfoque automático provee una mayor flexibilidad, desacoplando procesos de datos y produciendo un servicio de datos independiente que inicia una tarea de integración de datos de bajo nivel como parte del proceso de workflow. Este último enfoque, el automático, es solamente posible si los servicios están construidos de modo adecuado como módulos autocontenidos sin las dependencias típicas de la programación procedural. • Transacción: Uno de los principales aportes al definir una infraestructura de integración es la de proveer un mecanismo para llevar a cabo las operaciones de modo transaccional, esto es, la capacidad de invocar operaciones sobre diferentes sistemas soportando la semántica del modelo transaccional bajo las propiedades ACID (Atomicity, Consistency, Isolation, Durability). Estas propiedades garantizan la preservación de la consistencia del sistema, aíslan las operaciones entre sí, otorgan persistencia a los cambios y además son atómicas. • Seguridad: Desde el punto de vista de la integración, la seguridad conlleva los mismos conceptos tradicionales: autorización, autenticación y auditoría. En este sentido, la infraestructura de la integración debe proporcionar los medios para limitar el acceso al sistema, hacerlo de una manera unificada y dejar rastros de dichos accesos
  51. 51. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 51 de 67 6 Productos de Mercado En este capítulo vamos a valorar y comparar distintos productos de mercado que aplican los paradigmas de SOA y BPM. Estos productos presentan distintos grados de madurez respecto a la evolución de SOA y además algunos de ellos son de aplicación genérica para todo tipo de empresas o negocio y otros específicos para el Sector Sanitario. Los productos que vamos a supervisar son los siguientes: • Específicos para el Sector Sanitario o Ensemble de Intersystems o Rhapsody de Orion Health o Mirth (Open Source) • Generalistas o TIBCO o WebMethods de Software AG En la siguiente figura del Informe Forrester de ESB para el inicio del año 2011 podemos ver que los dos productos generalistas TIBCO y WebMethods (Software AG) están posicionados en primera posición como líderes, seguidos por las soluciones de Oracle, IBM, etc. También aparece MuleSoft que es el ESB que utiliza Mirth
  52. 52. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 52 de 67 Pasamos a describir cada uno de los productos: 6.1 Ensemble de Intersystems Ensemble es una plataforma de integración que implementa la última generación de ESB y las últimas especificaciones de SOA. Utilizar Ensemble® implica trabajar con un software líder en sistemas interconectados para el Sector Salud. Ensemble permite que las aplicaciones podrán conectarse fácilmente a diversos sistemas, servicios y procesos de negocio. Y también consigue mejorar rápidamente las aplicaciones existentes (sin reescribirlas) con sólo añadir: • Interfaces Web potentes • “Workflow”adaptable • Procesos de reglas de negocio • Monitorización de la actividad de Negocio • Otras funciones nuevas Las características principales de Ensemble son las siguientes: • Motor de Mensajería: o Soluciones con direccionamiento basado en publicación / suscripción, orientado a eventos y basada en contenidos o Direccionamiento de mensajería inteligente con un motor de normas ampliable
  53. 53. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 53 de 67 o Modificación y gestión sencilla de la normas de direccionamiento mediante un editor de normas gráfico para programadores y analistas de negocio o Acceso en tiempo real a mensajes en directo y procesados previamente para la monitorización de la actividad de negocio, alta fiabilidad y capacidad de recuperación para procesos de negocio de larga duración o Soporte bidireccional para XML, SOAP, servicios Web y otros formatos de mensajería estándar, incluidos HL7 y X12 en asistencia sanitaria. o Creación rápida de transformaciones de datos personalizadas con un editor de transformación de datos gráfico y basado en XML • Base de datos de objetos incorporada y compatible con SQL o Indexación de mapa de bits transaccional para acceso en tiempo real tanto a mensajes en directo como procesados previamente para monitorización de la actividad de negocio (BAM), auditoría, informes basados en SQL y gestión o Alta fiabilidad, capacidad de recuperación y rendimiento para procesos de negocio de larga duración o Un repositorio compartido de mensajes y metadatos posibilita una integración más rápida, un desarrollo rápido, una gestión más sencilla y mayores posibilidades de ampliación o La base de datos ya probada soporta miles de usuarios concurrentes y terabytes de datos o Evita la sobrecarga de rendimiento y los costes superiores de una base de datos relacional de terceros • Tecnología de abstracción avanzada o Proporciona una representación de objetos coherente y eficiente de diversos modelos de programación y formatos de datos o Desarrollo rápido de aplicaciones compuestas a través de la potente abstracción de reglas y datos o Puede hacer que los recursos abstractos estén disponibles para el proyecto en diversos formatos que incluyen COM, .NET, ODBC, Java, JDBC, EJB, XML y servicios Web o Permite el uso de las últimas herramientas y tecnologías de desarrollo para acceder a datos y funciones existentes como componentes .NET o J2EE reutilizables, servicios Web o XML o Proporciona tanto soporte para J2EE como para .NET y puede ampliarse fácilmente para los futuros modelos de objetos y infraestructuras tecnológicas o Permite acceder a diversos sistemas de gestión de bases de datos como una sola base de datos "federada • Entorno rápido de integración y desarrollo o Desarrollo rápido, orientado a servicios, de aplicaciones compuestas que aprovechan los datos y las funciones existentes
  54. 54. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 54 de 67 o Trabaja con lenguajes y herramientas que ya son familiares para los desarrolladores o Simplifica y acelera el modelado y la automatización de los procesos de negocio para los analistas de negocio y los desarrolladores o Combina y compatibiliza el desarrollo gráfico, con XML y con código para cubrir el rango más amplio de escenarios de integración o Desarrollo automático de adaptadores aprovechando los servicios SOAP o Integración inmediata con herramientas de gestión de procesos de negocio de terceros a través del soporte del estándar BPEL • Transformaciones de datos o Acelera la terminación de los proyectos al eliminar las barreras que surgen por las diferencias en la semántica y los esquemas de datos entre las aplicaciones o los servicios o Los asistentes de transformación y un editor de transformación gráfico reducen la curva de aprendizaje y agilizan el desarrollo de transformaciones o Las transformaciones pueden utilizar fórmulas o búsquedas sencillas en tablas de datos internas o externas o Ampliable hasta cualquier grado de complejidad añadiendo funciones personalizadas • Orquestación de los procesos de negocio o El modelado gráfico permite a los desarrolladores y a los analistas de negocio centrarse en los procesos de negocio en lugar de en la tecnología o Combinar y compatibilizar los enfoques de integración sincronizados (gráfico, documentos XML o código) para resolver eficientemente el mayor rango de proyectos de integración o Orquestar y mantener el estado de los procesos de negocio de cualquier duración o Cambiar el comportamiento de los procesos de negocio en funcionamiento mediante normas fácilmente editables, en lugar de mediante código o Incorporar el flujo de trabajo del personal a procesos automatizados o Monitorizar la actividad y el estado de todo el sistema y de los indicadores de rendimiento clave • Motor de normas de negocio o Los analistas de negocio y el personal de soporte pueden configurar y cambiar rápidamente los puntos de decisión en un proceso de negocio en marcha o Reduce los costes ocasionados por los cambios
  55. 55. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 55 de 67 o Libera desarrolladores para que trabajen en proyectos nuevos, en lugar de en modificaciones de proyectos antiguos o Las normas están separadas de las reglas de negocio y pueden reutilizarse y modificarse tan fácilmente como otros objetos de Ensemble • Monitorización de la actividad empresarial o Aprovecha el almacenamiento de mensajes y metadatos de la base de datos incorporada para obtener más conocimientos operativos sobre los procesos de negocio y el rendimiento del sistema o Conocimiento inmediato de los eventos de negocio y los cambios en los indicadores de rendimiento claves o Las pantallas de los paneles de mandos gráficos ayudan en la toma de decisiones de gestión adecuadas y a tiempo o Reduce los costes y acelera la ejecución de las estrategias de negocio o Las medidas empresariales definidas por Ensemble pueden iniciar procesos de negocio automáticos para tomar acciones correctivas y proporcionar notificaciones • Motor de flujo de trabajo adaptable o Totalmente integrado con el entorno de desarrollo o Asignación eficiente de las tareas o Mejor control sobre la ejecución de las tareas o Las tareas pueden reutilizarse fácilmente en cualquier proceso de negocio o Incorporación sencilla de las interacciones manuales complejas, que abarquen divisiones geográficas, tecnológicas y departamentales, en aplicaciones compuestas. o Separación de las definiciones de procesos de usuario a partir de las reglas de negocio para obtener un desarrollo más sencillo y más fiable • Infraestructura y biblioteca de adaptadores o Conectividad y transformaciones de datos predefinidas para un amplio rango de aplicaciones, servicios, orígenes de datos y tecnologías o Ampliación rápida de los adaptadores existentes y creación de adaptadores nuevos mediante el entorno de desarrollo de Ensemble, la herencia de objetos y los servicios SOAP para minimizar el esfuerzo de desarrollo necesario o Todos los adaptadores comparten capacidades comunes para conseguir una integración sencilla y coherente, así como operaciones y gestión fiables • Soporte de estándares o Amplio soporte de los estándares de muchos sectores
  56. 56. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 56 de 67 o Permite interoperar con otros sistemas que soportan los mismos estándares o Aprovecha los conocimientos que han obtenido los desarrolladores utilizando los mismos estándares en otros proyectos o Protección de la inversión • Gestión en todos los niveles o La interfaz basada en la Web permite la gestión local o remota desde cualquier dispositivo o Optimización de los niveles de servicio y reducción de la carga de trabajo del personal mediante la definición de consolas de gestión personalizadas y alertas para monitorizar los recursos críticos o Diagnóstico rápido y depuración de problemas durante el desarrollo y las operaciones reales utilizando Visual Trace o Utilización de cualquier herramienta SQL para consultar y generar informes personalizados a partir del almacén de mensajes para auditorías y otras necesidades de gestión o Visión en tiempo real de los procesos de negocio así como del rendimiento del sistema 6.2 Rhapsody de Orion Health Las principales ventajas del Motor de Integración de Rhapsody son las siguientes: • Rendimiento y Robustez: Diseñado teniendo en cuenta un alto rendimiento y de disponibilidad, incluso durante la administración y mantenimiento del sistema • Fácil de Usar: El motor de Rhapsody es fácil de configurar a través de un intuitivo de arrastrar y soltar, mientras que la supervisión del sistema utiliza una familiar interfaz basada en Web que es fácil de usar y tiene una potente capacidad de búsqueda • Experiencia en Sector Salud: Diseñado para organizaciones de salud, por lo que ofrece la experiencia única y la funcionalidad que necesita y que otros productos no pueden ofrecer. • Flexibilidad y Funcionalidad: El uso de la tecnología Java estándar y API específicos para desarrolladores puede ofrecer un alto grado de personalización y programación, así como la compatibilidad multiplataforma • Sin costes escondidos: Rhapsody ofrece un bajo coste de propiedad (TCO) debido a los costes bajos de licencia y a la facilidad de su implementación.
  57. 57. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 57 de 67 Rhapsody ofrece una completa, potente integración back-end para las empresas del Sector Salud El motor de integración Rhapsody asegura una integración sin esfuerzo entre los sistemas sanitarios. Rhapsody dispone de apoyo para los distintos protocolos de comunicación. en distintos formatos de mensaje. Esto permite Rhapsody actuar como un mediador de mapeo y traducción entre sistemas incompatibles. Los mensajes se entregan de forma fiable y precisa, independientemente del tipo de formato o el transporte requerido Las facilidades de Rhapsody para arrastrar y soltar permiten la configuración compleja de enrutamiento y procesamiento de forma fácil y sus potentes herramientas basadas en la Web de monitorización permiten una resolución rápida y eficaz de los problemas o el reprocesamiento de los mensajes. Rhapsody ofrece un alto rendimiento de almacenamiento de mensajes para asegurar la trazabilidad completa y un rendimiento óptimo. Los mensajes se archivan en el almacén de mensajes.
  58. 58. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 58 de 67 6.3 Mirth Mith es un motor con interfaz HL7 de plataformas cruzadas de código abierto que permite el envío birideccional de mensajes HL7 entre sistemas y aplicaciones sobre múltiples capas de transporte. Utilizando un bus framework de servicio empresarial y una arquitectura orientada a canales, Mirth permite el filtrado de mensajes, el transformado, y el enrutamiento de los mismos en base a una reglas definidas por el usuario. Permite crear interfaces HL7 para los sistemas de forma fácil utilizando la interfaz web y el asistente para crear canales que asocian las aplicaciones con los componentes del motor Mirth. Para integrar los servicios con los sistemas HL7 se debe implementar una capa de adaptación para transformar los mensajes entre el dominio de la aplicación y el del dominio de HL7. Mirth hace que este paso sea fácil proporcionando el framework para la conexión de sistemas dispares con los protocolos establecidos en los adaptadores y las herramientas de transformación de mensajes. Mirth utiliza una arquitectura basada en canales para conectar los sistemas con otros sistemas HL7. Los canales consisten en terminales (de entrada y de salida), filtros, y transformadores. Múltiples filtros y una cadena de transformadores se pueden asociar con un canal. La interfaz web de Mirth permite la reutilización de filtros y transformadores en múltiples canales. Los terminales se utilizan para configurar las conexiones y los detalles de los protocolos. Los terminales de entrada se utilizan para designar el tipo de “listerner” para los mensajes de entrada, como por ejemplo TCP/IP o un servicio web. Los terminales de salida se utilizan para designar el destino de los mensajes de salida, como por ejemplo a una aplicación servidora, una cola JMS, o una base de datos.
  59. 59. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 59 de 67 Las características de Mirth son las siguientes: • Amplia variedad de conectores. Mirth puede configurarse para escuchar y enviar mensajes HL7 y conectar una variedad de protocolos: o TCP/MLLP o Bases de datos (MYSQL, Postgres, Oracle, MS SQL, ODBC) o Archivos (sistema de archivos locales y compartición de redes) o JMS o FTP/SFTP o SOAP (sobre HTTP) • Plataforma cruzada. Mirth soporta la mayoría de sistemas operativos (aquellos que soporten la máquina virtual de Java en su versión 1.5. • Creación o utlización de filtros y perfiles de valildación. El sistema de filtrado de Mirth permite elegir el tipo de mensajes que se acptan y se encaminan. Multiples destinatarios se pueden seleccionar automáticamente especificando los filtros HL7. • Creación o utilización de transformadores. Una interfaz de Mirth permite la creación de transformadores y mapeos de datos HL7. Simplementente seleccionando y arrastrando con el puntero del ratón fragmentos de mensajes HL7 creamos mapeos, o utilizar una variedad de funciones para hacer consultas en la bases de datos, enviar correos electrónicos. Las transformaciones disponibles son las siguientes: • Transformador de mapeo: Mapea los datos desde los mensajes entrada hasta las variables. • Transformador de script: Ejecuta scripts definidos en los mensajes (por ejemplo, JavaScript, Python, Tcl). • Generador de mensajes HL7: construye mensajes HL7 a partir de una fuente de datos. • Transformador XSLT: Ejecuta transformacioens XLS sobre mensajes de entrada HL7 v3 o XML. Todos los mensajes y transacciones se registran en una base de datos interna. Se puede configurar para que se genere de forma automática respuestas de reconcocimiento HL7 (ACK). • Motor ESB robusto: Mirth está basado en el motor Mule ESB para proporcionar velocidad, estabilidad y seguridad en un entorno flexible. 6.4 TIBCO Los productos de TIBCO se centran en hacer realidad la visión de la compañía para su estrategia de "Enterprise 3.0" y SOA. TIBCO ofrece la tecnología de la información correcta en el lugar correcto en el momento adecuado con el contexto correcto, dando a las empresas y organizaciones una ventaja significativa en el servicio a sus clientes y la gestión de sus operaciones. TIBCO ha identificado los siguientes requisitos fundamentales para Entreprise 3.0: • Gestionar eventos a gran escala
  60. 60. Trabajo Final – 30 de Septiembre de 2011 Vicenç Robert Butí Página 60 de 67 • Desarrollar y gestionar aplicaciones de forma universal • Conectar a los profesionales con a la tecnología de forma natural TIBCO es una plataforma tecnológica neutral diseñado para simplificar el desarrollo de aplicaciones, implementación y administración de la gestión de compuestos de procesos empresariales (BPM) y arquitecturas orientadas a servicios (SOA). La familia ActiveMatrix incluye productos para la creación de servicios e integración, redes de servicios y distribución de datos, aplicaciones empaquetadas, BPM y el gobierno. Las principales características de TIBCO son: • Integración, Orquestación y entorno la creación personalizado: o ActiveMatrix BusinessWorks ofrece una rica gama de facilidades para conectar, integrar, enrutar, transformar y distribuir datos XML o no XML, tales como cuadernos COBOL a través de diferentes protocolos como HTTP, JMS, FTP y correo electrónico. o Dispone de un potente conjunto de servicios, orquestación, integración, manejo de excepciones, y las capacidades de transacciones distribuidas, incluyendo BPEL 2.0. o La creación de servicios gráficos con la importación / exportación mediante un solo clic de definiciones de servicios de / a los registros. • Alto rendimiento, escalabilidad y confiabilidad a través de un sistema distribuido, basado en Arquitectura Gris o Las capacidades avanzadas de fiabilidad y capacidad de recuperación como el soporte para control de flujo, o el seguimiento de la dependencia, y la capacidad de automatizar la auto-corrección que ha ayudado a las empresas a alcanzar el 99,99% o mayor tiempo de actividad. • Entorno integrado de servicios

×