Introducción
Bizagi proporciona una capa de integración que permite una integración sencilla con aplicaciones existentes a través de múltiples alternativas.
Mediante esta capa de integración, los procesos de Bizagi pueden comunicarse directamente con sistemas externos para recuperar información de negocio o actualizar datos. Una de sus principales funcionalidades es el Conector de servicios Web, que permite que los procesos invoquen servicios externos mediante protocolos web estándar como SOAP.
|
Para otras alternativas de integración B2B, incluidos los Conectores de Bizagi, consulte Conectores de Bizagi. |
Antes de comenzar
Bizagi incluye una opción de configuración de Proxy que puede utilizarse al conectarse a servicios externos mediante el Conector de servicios Web.
¿Cuándo debe utilizar el Conector de servicios Web?
Considere un Proceso de Solicitud de Crédito en el que necesita consultar una Central de Riesgo u otro sistema externo para verificar si un solicitante aparece en una lista negra o para evaluar su capacidad de endeudamiento.
Como se ilustra a continuación, los procesos de negocio suelen incluir múltiples puntos de integración donde deben invocarse servicios externos:
En Bizagi, este tipo de integración se configura mediante el Conector de servicios Web, que puede conectarse a servicios web SOAP estándar y servicios RESTful alojados tanto dentro de una red interna (intranet) como en Internet.
Cómo funciona
Cuando un proceso invoca un servicio externo, Bizagi envía información de la instancia del proceso como entrada a dicho servicio.
La respuesta del servicio luego se mapea automáticamente de vuelta a Bizagi y se almacena en el modelo de datos del proceso.
El intercambio de información entre Bizagi y el servicio externo, ya sea que el servicio esté alojado en un Bus de Servicios Empresariales (ESB), en la nube o en otro sistema, se realiza mediante mensajes XML estándar. Este enfoque hace que la integración sea independiente de las plataformas, tecnologías o lenguajes de programación utilizados para implementar el servicio.
Para configurar una invocación de servicio web, ya sea SOAP o RESTful, el Conector de servicios Web proporciona una experiencia de configuración guiada y gráfica que no requiere programación.
Importante
Para invocar servicios externos desde procesos de Bizagi, se recomienda definir puntos de integración utilizando Tareas de Servicio BPMN.
El uso de Tareas de Servicio permite especificar si la invocación del servicio se ejecuta de forma síncrona o asíncrona. Para obtener más información sobre la ejecución asíncrona, consulte Actividades Asíncronas.
|
Cuando el valor devuelto por un servicio supera la longitud máxima del atributo String de destino en Bizagi, el valor se trunca automáticamente para ajustarse al tamaño del atributo. |
Acerca del Conector de servicios Web
Los puntos de integración se configuran en el Paso 6 del Asistente de Procesos en Bizagi Studio, Integrar, seleccionando la opción Definir interfaces de integración.
Desde este paso, puede configurar invocaciones a servicios externos mediante el Conector de servicios Web.
Después de seleccionar la Tarea de Servicio donde se configurará la integración, Bizagi inicia un asistente de configuración guiado de cuatro pasos.
Las opciones disponibles pueden variar según el tipo de servicio seleccionado, SOAP o RESTful.
Para servicios RESTful, Bizagi recomienda utilizar Conectores de Bizagi siempre que sea posible. Los Conectores de Bizagi proporcionan capacidades avanzadas como encabezados personalizados y autenticación OAuth.
Estándares soportados por el Conector de servicios Web
El Conector de servicios Web es un componente de integración genérico que puede consumir servicios web alojados en un ESB, la nube o aplicaciones externas.
Para servicios web SOAP, se soportan los siguientes estándares:
•Servicios web compatibles con SOAP 1.1.
•Servicios web compatibles con SOAP 1.2.
|
•Las invocaciones de servicios web SOAP deben utilizar el método HTTP POST. •Las solicitudes y respuestas de servicios REST deben utilizar formato XML. •WSDL 1.0 es soportado. •WSDL 2.0 no es soportado. |
También se admiten las siguientes extensiones WS-*:
•WS-Addressing
•WS-Policy
•WS-Trust
•WS-SecureConversation
•WS-Security, incluyendo:
oAutenticación Username Token.
oAutenticación Binary Security Token (WS-Security 1.1).
Para la autenticación Binary Security Token, el cifrado de mensajes requiere que el servicio publique una llave pública en su definición WSDL.
|
•El Conector WS soporta WSDL que exponen múltiples métodos y múltiples puertos. •La compatibilidad con múltiples puertos se configura mediante Configuración avanzada de interfaces. •Los WSDL que exponen múltiples servicios no son soportados. |
Si necesita invocar un servicio web SOAP que dependa de especificaciones WS-* no soportadas, como WS-Discovery, o si su escenario de integración requiere funcionalidades no compatibles con el conector, como invocar un servicio una vez por cada registro de una colección, utilice una de las siguientes alternativas:
•Conectores de Bizagi (recomendado).
•Librería de Componentes.
Para obtener orientación, consulte Cómo escoger la función de integración adecuada.
Comparación entre servicios SOAP y REST
La siguiente comparación proporciona una visión general de alto nivel de las diferencias entre los servicios SOAP y RESTful.
|
Servicios web SOAP |
Servicios RESTful |
|---|---|---|
Concepto y objetivo |
Vinculado a una definición estricta de protocolo, SOAP está orientado a exponer partes de la lógica de la aplicación como servicios (operaciones). |
Centrado en exponer recursos con nombre mediante URI. Dado que es independiente del protocolo, es adecuado para aplicaciones de Internet y acceso móvil, donde el objetivo principal es exponer datos. |
Formatos |
Depende en gran medida de XML para el intercambio de información. |
Utiliza comúnmente JSON, un formato ligero que es óptimo para aplicaciones de Internet y entornos móviles.
También pueden utilizarse otros formatos, como XML. |
Métodos HTTP (verbos) |
Utiliza principalmente POST.
Algunos servicios web también pueden utilizar GET, aunque esto es menos común.
SOAP no está necesariamente vinculado a HTTP o HTTPS. |
Utiliza: •POST para crear recursos. •GET para recuperar recursos. •PUT para actualizar recursos. •DELETE para eliminar recursos.
Algunos servicios amplían las capacidades de actualización mediante la implementación del método PATCH, que envía únicamente la información modificada. |
Seguridad |
Normalmente implementa WS-Security y otras especificaciones WS-*.
Estas capacidades están disponibles además de TLS/SSL. |
Normalmente depende de OAuth para proteger los recursos.
También puede utilizarse TLS/SSL. |
Ventajas y desventajas |
•Se utiliza comúnmente en intranets empresariales, especialmente cuando existe la necesidad de distribuir y administrar transacciones con un nivel más alto de sofisticación, como transacciones ACID, y una confiabilidad mejorada. •Los servicios web SOAP utilizan un archivo descriptor que permite a los clientes consumirlos de manera estandarizada con relativa facilidad, ya que las máquinas pueden interpretar automáticamente sus entradas y salidas. |
•Es adecuado para aplicaciones y tecnologías modernas, y con frecuencia se considera que proporciona un mejor rendimiento y escalabilidad. •Los servicios RESTful generalmente son más rápidos de desarrollar. Sin embargo, las aplicaciones cliente que consumen servicios RESTful pueden requerir un esfuerzo adicional porque los servicios RESTful no utilizan un archivo descriptor estándar. Sus entradas y salidas dependen de la implementación de cada servicio y no existe una única definición estándar que se aplique a todos los servicios RESTful. |
Ejemplos
Para obtener información adicional y ejemplos prácticos, consulte:
•Invocar un servicio Web desde Bizagi.
•Invocar un servicio REST desde Bizagi.
Last Updated 9/22/2026 9:59:36 AM