Introducción
Cuando se usa el conector de Web Service de Bizagi para configurar integración con sistemas externos, usted puede navegar las propiedades de cada interfaz configurada para usar la configuración avanzada.
Las Interfaces creadas a través del Asistente de interfaces, ya sea en el sexto paso del Asistente de Proceso (Definir interfaces) o como una tarea de evento al Salir, también se pueden ver en el módulo de Sistemas.
Las Interfaces creadas con el asistente se crean inmediatamente bajo un sistema de auto-generado llamado Default.
Para localizar este conjunto de interfaces, vaya a la vista de Experto y dé clic en el módulo Sistemas Externos.
Crear interfaces
Para crear una nueva interfaz desde la vista de Experto, asegúrese de tener un Sistema creado con la propiedad activa Habilitar interfaces en este sistema:
A continuación, haga clic derecho en Interfaces de su Sistema creado y haga clic en la opción Nueva interface:
La siguiente ventana se mostrará:
Tenga en cuenta que, por defecto, la nueva interfaz será tratada como una interfaz de servicio web SOAP (tipo de servicio = SOAP).
Los siguientes campos se presentan:
•Nombre : Nombre único y requerido que identifica a la interfaz. Éste no debe contener espacios.
•Tipo de Servicio: Opciones de SOAP o REST. Al elegir resto como el tipo de servicio, no habrá campo para especificar método del servicio.
•Interfaz de propiedades de la tabla: Un conjunto de valores de configuración orientada a entornos del proyecto (desarrollo, prueba o producción Este conjunto incluye:
Propiedad |
Descripción |
|---|---|
URL Servicio Web |
La URL de acceso al servicio. Para servicios REST, este campo tendrá la URL Base |
Nombre de usuario |
Cuando el servicio requiere autenticación HTTP básico, este nombre de usuario se requiere para el acceso al servicio. |
Contraseña |
Cuando el servicio requiera la autenticación básica HTTP, esta contraseña se requiere para el acceso al servicio. |
Dominio |
Cuando el servicio requiera autenticación HTTP básica, este campo es opcional para complementar el nombre de usuario, para el acceso al servicio. |
Umbral para registro (en seg) |
El tiempo en segundos que define un umbral de servicio esperado para la interfaz. Si la invocación supera esta definición en ejecución, entonces se registra una línea de trace en el registro .csv log en .\Temporary\SOA\Log\ de su proyecto (por defecto, queda una archivo por cada servicio web, creado como C:\Bizagi\Projects\[su_proyecto]\Temporary\SOA\Log\[su_interface]Log_1.csv). Este log es especialmente útil para el monitoreo dado que cada invocación que exceda o produzca un timeout dejará registro con el siguiente detalle: Fecha (DateTime), Descripción (ErrorDescription), idCase, Tarea (Task_Name), URL, Método (Method_Name), y Registro de tiempo (InterfaceTime) en formato MM:ss:mmm.
El valor predeterminado se establece en 30 segundos, por lo que siempre se registra si la invocación tarda más que este tiempo. |
Tiempo de espera (en seg) |
El tiempo en segundos que define el tiempo de espera para cualquier intento de invocación de una interfaz. Si la invocación supera esta definición en ejecución, se genera un error y se registra en una línea de trace en el registro. csv en la ruta .\Temporary\SOA\Log\ de su proyecto (por defecto, queda una archivo por cada servicio web, creado como C:\Bizagi\Projects\[su_proyecto]\Temporary\SOA\Log\[su_interface]Log_1.csv). Este log es especialmente útil para el monitoreo dado que cada invocación que exceda o produzca un timeout dejará registro con el siguiente detalle: Fecha (DateTime), Descripción (ErrorDescription), idCase, Tarea (Task_Name), URL, Método (Method_Name), y Registro de tiempo (InterfaceTime) en formato MM:ss:mmm.
Por defecto esta opción no se utiliza (su valor inicial es -1). La invocación hará timeout de acuerdo a esta propiedad, o la propiedad en la actividad si la invocación se realiza en una actividad asíncrona (se disparará cualquier timeout de los 2, el cual tenga el menor valor). |
Nombre del puerto |
Cuando el usuario necesita ejecutar una interfaz SOAP en la cuál, el servicio tiene diferentes puertos (p.ej, SOAP 1.1, SOAP 2.0, etc.), este campo permite al usuario escribir el nombre específico del puerto por donde se conectará el servicio. Este nombre del puerto puede ser configurado de acuerdo al ambiente (por ejemplo, Desarrollo, Test, Producción .en donde se ejecuta la interfaz. Los nombres de los puertos se especifican al final del WSDL del servicio:
|
Máximo de bytes del búfer |
Edite su valor (por incrementar) en caso de que necesite enviar información muy extensa a su servicio Web (p.e un adjunto de gran tamaño). Útil cuando se excede el límite por defecto de la cantidad de información que se permite en el envío. Corresponde al atributo maxBufferSize del elemento bindings del archivo de configuración del Windows Communication Foundation (WCF). Establece el tamaño máximo de los encabezados SOAP. |
Máximo de memoria en el pool del búfer |
Edite su valor (por incrementar) en caso de que necesite enviar información muy extensa a su servicio Web (p.e un adjunto de gran tamaño). Útil cuando se excede el límite por defecto de la cantidad de información que se permite en el envío. Corresponde al atributo maxBufferPoolSize del elemento bindings del archivo de configuración del Windows Communication Foundation (WCF). Establece la máxima cantidad permitida de memoria (en bytes). |
Máximo de caracteres permitidos en el XML |
Edite su valor (por incrementar) en caso de que necesite enviar información muy extensa a su servicio Web (p.e un adjunto de gran tamaño). Útil cuando se excede el límite por defecto de la cantidad de información que se permite en el envío. Corresponde al atributo maxStringContentLength del elemento readerQuotas del archivo de configuración del Windows Communication Foundation (WCF). Establece la longitud máxima de la cadena de respuesta. |
Máximo de longitud de matriz en los datos recibidos |
Edite su valor (por incrementar) en caso de que necesite enviar información muy extensa a su servicio Web (p.e un adjunto de gran tamaño). Útil cuando se excede el límite por defecto de la cantidad de información que se permite en el envío. Corresponde al atributo maxArrayLength del elemento readerQuotas del archivo de configuración del Windows Communication Foundation (WCF). Establece la longitud máxima permitida del arreglo de datos. |
Máximo de bytes permitidos por lectura |
Edite su valor (por incrementar) en caso de que necesite enviar información muy extensa a su servicio Web (p.e un adjunto de gran tamaño). Útil cuando se excede el límite por defecto de la cantidad de información que se permite en el envío. Corresponde al atributo maxBytesPerRead del elemento readerQuotas del archivo de configuración del Windows Communication Foundation (WCF). Establece el máximo de bytes permitido que se retorna en cada lectura. |
Máximo de caracteres en el nombre de tabla |
Edite su valor (por incrementar) en caso de que necesite enviar información muy extensa a su servicio Web (p.e un adjunto de gran tamaño). Útil cuando se excede el límite por defecto de la cantidad de información que se permite en el envío. Corresponde al atributo maxNameTableCharCout del elemento readerQuotas del archivo de configuración del Windows Communication Foundation (WCF). Establece el numero máximo de caracteres en el nombre de una tabla. |
|
Los valores y tipos de datos de los atributos de la especificación Windows Communication Foundation (WCF) de Microsoft explicados anteriormente (por ej. correspondientes a los parámetros finales como: maxbuffersize, maxbufferpoolsize, maxstringcontentlength, maxarraylength, maxbytesperread, y maxnametablecharcount), corresponden a la definición del archivo de configuración XML como se presentan en la siguiente imagen:
Esta será la estructura que Bizagi construye para la invocación del Servicio Web. |
•Opciones avanzadas para la seguridad del servicio web:
Dé clic en el enlace para configurar el tipo de seguridad que se utiliza en su servicio web.
Par ello utilice el botón de Adicionar, seleccione el tipo de seguridad e ingrese las credenciales/tokens para el acceso autorizado.
Tenga presente que esta definición difiere de las credenciales que se especifican en las propiedades anteriores (usuario, contraseña y dominio) ya que las anteriores son utilizadas principalmente para que Bizagi acceda a los recursos físicos (p.e el WSDL) de la definición del servicio web, mientras que esta configuración determinará cómo debe Bizagi autenticarse ante la ejecución del servicio web.
Las opciones que configuración de seguridad que podrá usar y que soporta Bizagi son:
Opción |
Descripción |
Especificación |
|---|---|---|
Plain Header Token |
Envía el token de usuario (usernameToken) en el encabezado del mensaje SOAP de acuerdo a la especificación de WS-Security. |
Según la definición en: https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf |
Secure Conversation Header Token |
Envía el token de usuario de acuerdo a la especificación, teniendo un certificado adecuado instalado en el cliente. |
Según la definición en: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 |
Basic HTTP Authentication |
Envía las credenciales que aplican cuando el end-point especificado del servicio está protegido (a nivel de autenticación básica).
Por defecto, Bizagi intentará usar este tipo de seguridad si no se especifica alguno, y se cuenta con autenticación básica a nivel del recurso (usando las credenciales definidas en las propiedades de usuario, contraseña y dominio). |
Según la definición en: |
•No generar proxy en ejecución (generarlo ahora):
Bizagi genera una definición (.cs, .dll) del proxy de cada servicio Web que se integra al proceso cuando éste se ejecuta sobre una plataforma .NET.
Por defecto, este proxy se genera la primera vez que se haga el look-up y se invoque el servicio durante la ejecución.
Al utilizar esta opción y si desea generarlo previamente (desde Bizagi Studio), Bizagi utilizará esta definición en ejecución en vez de generar una nueva en ese momento.
Esta opción es muy útil cuando el servicio Web en el ambiente de producción está muy restringido y sus recursos no pueden ser accedidos de manera sencilla (hay esquemas o el WSDL que tienen restricciones importantes de seguridad).
Con esta opción, puede generar el proxy a partir del WSDL configurado para otro ambiente (p.e ambiente de desarrollo).
Para hacerlo, utilice la opción Use y genérelo desde para seleccionar el ambiente a partir del cuál se generará el proxy.
|
Para la correcta ejecución al utilizar esta característica, deberá cerciorarse de que el WSDL utilizado para generar el proxy sea exactamente el mismo que se utilizará en ejecución, en dicho ambiente. |
Editando una interfaz existente
Una vez que se hayan definido interfaces ya configuradas en algún punto de los procesos, es posible también editar su información desde esta vista.
De manera similar a la creación de la misma, las opciones para editar una interfaz permitirán principalmente: editar o incluir las credenciales usadas en la autenticación HTTP básica, o administrar la URL del servicio.
Para editar una interfaz existente, dé clic derecho sobre la interfaz y seleccione sus Propiedades.
Usted será capaz de especificar o editar las propiedades descritas en la sección anterior.
|
La edición de servicios REST contempla ciertas consideraciones al momento de editar la URL Base. Vea las consideraciones relacionadas a interfaces de servicios REST. |
Eliminando una interfaz
Para eliminar una interfaz, dé clic derecho sobre la misma y seleccione la opción de Eliminar interfaz.
Tenga en cuenta que no es posible eliminar interfaces que se encuentren en funcionamiento en el ambiente de producción. Bizagi ejecutará las validaciones de su motor de dependencia de manera que se permita eliminar aquellas interfaces que no están siendo utilizadas en alguna versión de proceso.
Interfaces en producción
Las interfaces listadas en esta vista de Bizagi Studio, permiten la definición inicial de sus valores en sus diferentes ambientes (desarrollo, pruebas y producción).
Una vez que estas interfaces se encuentre en producción, su administración se realizará directamente sobre cada ambiente por separado, como se describió en el capítulo Administración de Sistema, directamente con Management Console.
Last Updated 1/27/2023 9:37:04 AM