Introducción
Bizagi presenta una capa de integración que permite una fácil configuración para la integración con aplicaciones externas mediante diversas alternativas.
A través de esta capa de integración, los Procesos en Bizagi pueden invocar servicios de sistemas externos para obtener información de ellos o actualizar su información.
La funcionalidad principal de la capa de integración es el Conector de servicios Web, el cuál le permite a sus procesos invocar servicios externos a través de protocolos estándar de web (p.e SOAP).
|
Otras alternativas para la integración entre diferentes negocios (B2B), como por ejemplo los Conectores Bizagi, se describen en Conectores de Bizagi. |
Antes de comenzar
Bizagi tiene una opción de configuración de Proxy disponible para conectar con servicios externos tal como el conector de servicios Web.
¿Cuándo utilizar el Conector de servicios Web?
Considere a manera de ejemplo, un Proceso de Solicitud de crédito donde posiblemente se tendrá dentro de los requerimientos, poder consultar en un buró de crédito (o cualquier otro sistema) si el solicitante se encuentra en la Lista Negra, o la capacidad de endeudamiento.
Como se enseña en la imagen siguiente, los Procesos pueden tener varios puntos de integración donde deben invocar servicios externos:
En Bizagi, la configuración de este tipo de integración se realiza por medio de un conector genérico llamado Web service connector, el cual soporta la integración con Servicios Web SOAP o con servicios de tipo REST (en aplicaciones en la intranet o en Internet).
¿Cómo funciona?
La invocación de servicios externos desde Bizagi permite el envío de información de negocio desde las instancias de los Procesos como datos de entrada para el servicio.
De vuelta, la respuesta del servicio externo se almacenará automáticamente en Bizagi (en el Modelo de datos del Proceso).
El intercambio de información entre Bizagi y el servicio, sea configurado en un Bus ESB, en la nube o directamente disponible por otro sistema, se realiza por medio de XMLs.
De esta manera, la integración es independiente de las plataformas o tecnologías involucradas, y del lenguaje de programación de la implementación del servicio.
Para configurar la invocación a un servicio Web (sea SOAP o de tipo REST), el conector de servicios Web (Web service connector) presenta una serie de pasos gráficos en los cuales no se requiere de programación.
Importante
Para invocar servicios externos dentro de Procesos en Bizagi, se recomienda definir estos puntos de integración como Tareas de Servicio BPMN.
Utilizando Tareas de Servicio para configurar puntos de integración, usted puede especificar si la invocación a servicios externos se hace de manera síncrona o asíncrona.
Para ver más información acerca de configuración de esos puntos de integración para ejecución asíncrona, consulte Actividades Asíncronas.
Acerca del Asistente de Interfaces
Los puntos donde hay integración en un Proceso, se definen en el paso #6 del Asistente de Procesos en Bizagi Studio (Definir interfaces de integración).
En este paso, se configuran las invocaciones de servicios externos a través del conector de servicios Web:
Una vez que se seleccione la tarea de servicio que representa el punto de integración, Bizagi presentará el conector de servicios Web para una configuración guiada en 4 pasos.
Tenga en cuenta que las opciones presentadas podrán diferir ligeramente de acuerdo a las opciones seleccionadas (por ejemplo, el tipo de servicio: SOAP o REST).
Estándares soportados por el conector de servicios Web
El Conector de servicios Web es un conector genérico y poderoso el cual consume cualquier servicio Web, sea a través del Bus corporativo (ESB), de la nube, o configurado directamente desde un sistema externo.
En servicios Web de tipo SOAP, se soporta lo siguiente:
•Servicios Web construidos en SOAP 1.1
•Servicios Web construidos en SOAP 1.2
|
Considere las siguientes notas: •El método Web para invocar servicios Web de tipo SOAP debe ser POST. •Al invocar servicios REST, se debe emplear formato XML para el envío y la recepción de la información. •Se soporta WSDL en su versión 1.0. WSDL 2.0 no es soportado. |
Adicionalmente, las siguientes extensiones a los servicios Web (WS-*) también se soportan:
•WS-Addressing
•WS-Policy
•WS-Trust
•WS-SecureConversation
•WS-Security: Autenticación por tokens de usuario (Username tokens), y por tokens de seguridad binaria.
En la autenticación por tokens de seguridad binaria, la protección del mensaje (cifrado) requiere que el servicio exponga la llave pública en el WSDL.
|
El conector para servicios Web soporta WSDLs que publiquen múltiples métodos y múltiples puertos. Esta última opción mediante la Configuración avanzada de interfaces. Este conector no soporta WSDLs que publiquen múltiples servicios. |
Si desea invocar un servicio Web SOAP con algún estándar que no se encuentre en la lista anterior (p.e WS-Discovery), o para considerar un escenario que no soporte el conector (p.e invocar un mismo servicio N veces por cada registro de una tabla), deberá hacerlo mediante la funcionalidad de Conectores de Bizagi (enfoque preferido) o de Librería de componentes. Vea Cómo escoger la función de integración adecuada.
Comparación entre servicios SOAP y REST
Considere la siguiente información como punto de partida para una idea sobre las diferencias entre los servicios SOAP y los REST.
|
Servicios web tipo SOAP |
Servicios REST |
|---|---|---|
Concepto y objetivo |
Atado a su estricto protocolo de definición, y orientado a exponer porciones de lógica de aplicación como servicios (operaciones). |
Enfocado a exponer recursos nombrados públicamente bajo URIs (es independiente del protocolo), y optimizado a aplicaciones en Internet y acceso a móviles (expone datos). |
Formatos |
Completamente diseñado para intercambiar información via XMLs. |
Potencia el uso del formato JSON el cual es más liviano --optimizado para las aplicaciones en Internet y uso de móviles. Puede emplear otros formatos como XML. |
Métodos HTTP (verbos) |
Utiliza principalmente POST. Algunos servicios web services pueden soportar el uso de GET (aunque no es tan frecuente). Sin embargo no necesariamente es atado a HTTP/HTTPS. |
Utiliza POST (para crear), GET (para obtener), PUT (para actualizar), DELETE (para eliminar). Algunos servicios extienden el potencial de la actualización por medio del verbo PATCH que envia únicamente la información que ha cambiado. |
Seguridad |
Usualmente implementa WS-Security y otras especificaciones de WS-* que son propias como tal. Esto es aparte de tener TLS/SSL encima. |
Usualmente se apoya en OAuth para proteger los recursos. TLS/SSL puede ir sobre esta medida. |
Ventajas y desventajas |
•Común en entornos corporativos en la intranet, cuando hay valor agregado si se necesita distribuir y manejar transacciones con un nivel mayor de sofisticación (p.e. ACID) y con mayor confiabilidad. •Los servicios SOAP utilizan un descriptor para que los clientes los consuman de manera estándar, con relativamente baja complejidad (dado que las máquinas pueden interpretar las entradas y salidas que utilizan). |
•Orientado a aplicaciones modernas y tecnologías, donde incluso se dice que cuenta con mejor rendimiento y escalabilidad. •Los servicios REST se construyen de manera más ágil. Sin embargo, los clientes que consumen dichos servicios no necesariamente serán ágiles de construir, dado que este tipo de servicios no se apoyan en un archivo descriptor bajo el cual se pueda deducir automáticamente las entradas y salidas, en donde cada servicio en particular puede diferir. |
Ejemplos
Consulte el artículo correspondiente presentado para cada uno de los escenarios de integración:
•Invocar un servicio Web desde Bizagi.
•Invocar un servicio REST desde Bizagi.
Last Updated 1/26/2022 4:17:33 PM