Sincronizando usuarios via servicios web

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Bizagi Studio > Definición de Seguridad > Seguridad del Portal de Trabajo > Autenticación > Autenticación avanzada >

Sincronizando usuarios via servicios web

Introducción

Bizagi soporta diferentes tipos de autenticación, algunos de los cuales están ya tienen integrados mecanismos de autenticación que utilizan proveedores de identidad externos como servicios federados o sistemas LDAP.

Independiente del tipo de autenticación seleccionado, usted necesita asegurarse de que los usuarios estén previamente registrados en la base de datos de Bizagi antes de que dichos usuarios intenten acceder al Portal de Trabajo.

 

Inicialmente, registrar los usuarios significa crearlos o sincronizarlos en la entidad WFUser de Bizagi y para esto, usted puede utilizar los servicios web de Bizagi SOAP.

 

note_pin

Tenga en cuenta que específicamente para el tipo de autenticación LDAP, usted puede utilizar el módulo de importación de LDAP descrito en Importar usuarios LDAP,

 

 

¿Qué necesita hacer en Bizagi?

Para utilizar los servicios web de Bizagi SOAP, considere los siguientes pasos:

1. Habilitar los servicios web SOAP para su proyecto.

2. Desarrollar un cliente para consumir los servicios web de Bizagi.

 

Los detalles adicionales de cada paso se describe a continuación.

 

Pasos

Siga estos pasos:

 

1. Habilitar los servicios web SOAP para su proyecto.

La habilitación de los servicios web SOAP se hace con Bizagi Studio como se describe en Habilitar el API de Bizagi.

Tenga en cuenta que se recomienda utilizar los servicios web con soporte de WS-Security, para los cuales necesita considerar el usode certificados X509.

 

2. Desarrollar un cliente para consumir los servicios web de Bizagi.

Una vez los servicios web de su proyecto están habilitados, considere que el método a utilizar se llama saveEntityAsString (desde el servicio web EntityManagerSOA).

Para detalles técnicos o referencuas sobre este método web, consulte SaveEntitiesAsString.

 

En los siguientes ejemplos, se mostrará cómo invocar y enviar la información de los usuarios en Bizagi:

 

Ejemplo de creación de un usuario (útil para llenar la información inicial de los usuarios)

El siguiente ejemplo crea tres usuarios con la información básica obligatoria (organization (organización), domain (dominio) más username (nombre de usuario), fullName (nombre completo), contactEmail (correo electrónico), enabledForAssignation (habilitado para asignación) y enabled (habilitado)).

 

<BizAgiWSParam>

<Entities>

<WFUSER>

 <fullName>Tom Hall</fullName>

 <userName>tomh</userName>

 <domain>agilityCorp</domain>

 <enabled>1</enabled>

 <enabledForAssignation>1</enabledForAssignation>

 <contactEmail>tomh@agilityCorp.com</contactEmail>

 <Organizations>

         <idOrg key="1"/>

 </Organizations>

</WFUSER>

<WFUSER>

 <fullName>Martha Lewis</fullName>

 <userName>marthal</userName>

 <domain>agilityCorp</domain>

 <enabled>1</enabled>

 <enabledForAssignation>1</enabledForAssignation>

 <contactEmail>marthal@agilityCorp.com</contactEmail>

 <Organizations>

         <idOrg key="1"/>

 </Organizations>

</WFUSER>

<WFUSER>

 <fullName>Piotr Blanter</fullName>

 <userName>piotrb</userName>

 <domain>agilityCorp</domain>

 <enabled>1</enabled>

 <enabledForAssignation>1</enabledForAssignation>

 <contactEmail>piotrb@agilityCorp.com</contactEmail>

 <Organizations>

         <idOrg key="1"/>

 </Organizations>

</WFUSER>

</Entities>

</BizAgiWSParam>

 

Observe que un usuario puede pertenecer a más de una organización, a pesar de que el ejemplo anterior considere enlazar los usuarios con la organización por defecto que ya está registrada en el proyecto de Bizagi (las organizaciones adicionales necesitan definición y por lo tanto requiere asignar los identificadores a la definición de key).

Se requiere que los usuarios pertenezcan al menos a una organización, de lo contrario, dicho usuario no podrá realizar acciones en el Portal de Trabajo (como crear casos, ejecutar consultas, etc).

Se enviará una respuesta exitosa del servicio web con los identificadores únicos de sistema de cada usuario creado:

 

SaveEntityWFUser

 

Ejemplo completo de creación de usuarios (considera las definiciones de usuarios organizacionales)

El siguiente ejemplo crea un usuario con la información básica además de las definiciones organizaciones como el área y la ubicación (las predeterminadas) y adicionalmente, detalles muchos a muchos que incluyen roles, habilidades o posiciones (dos roles predefinidos, sin habilidades y la posiciones predeterminada).

 

<BizAgiWSParam>

<Entities>

<WFUSER>

 <fullName>Juliette Leroy</fullName>

 <userName>juliettel</userName>

 <domain>agilityCorp</domain>

 <enabled>1</enabled>

 <enabledForAssignation>1</enabledForAssignation>

 <contactEmail>juliettel@agilityCorp.com</contactEmail>

 <Organizations>

         <idOrg key="1" />

 </Organizations>

 <idArea>1</idArea>

 <idLocation>1</idLocation>

 <Roles>

         <idRole key="1" />

 </Roles>

 <Roles>

         <idRole key="9998" />

 </Roles>

 <Positions>

         <idPosition key="1" />

 </Positions>

 <Skills />

</WFUSER>

</Entities>

</BizAgiWSParam>

 

El servicio web mostrará una respuesta exitosa igual a la presentada previamente.

Observe que un usuario puede pertenecer máximo a un área y ubicación; pero puede pertenecer a más de un rol, habilidad o posición. Cuando considere estas definiciones, recuerde que necesita definirlas previamente y buscarlas por sus identificadores (para modificar la definición key):

 

SaveEntityOrganization

 

 

Ejemplo de creación de usuario con nuevas definiciones organizacionales

El siguiente ejemplo crea un usuario nuevo, atado a una nueva definición de área de la organización (podrá crear nuevos elementos que no tengan una relación mucho a muchos con la entidad de usuario).

 

<BizAgiWSParam>

<Entities>

<WFUSER>

 <fullName>John Garcia</fullName>

 <userName>johng</userName>

 <domain>agilityCorp</domain>

 <enabled>1</enabled>

 <enabledForAssignation>1</enabledForAssignation>

 <contactEmail>johng@agilityCorp.com</contactEmail>

 <Organizations>

         <idOrg key="1" />

 </Organizations>

 <idArea>

         <areaName>Investigacion</areaName>

         <areaDisplayName>Investigacion y desarrollo</areaDisplayName>

         <areaDescription>A cargo de innovar</areaDescription>

 </idArea>

 <idLocation>1</idLocation>

</WFUSER>

</Entities>

</BizAgiWSParam>

 

El servicio web mostrará una respuesta exitosa igual a la presentada previamente.

Observe que con este ejemplo, Bizagi crea de manera automática el ID para el área nueva, y se la asocia al usuario.

Como se menciona anteriormente, nuevas definiciones organizacionales para roles, habilidades, posiciones u organizaciones, deberán ser ingresadas manualmente en Bizagi antes de asociarlos a usuarios.

 

Ejemplo de sincronización de usuarios existentes (útil como una invocación programada)

El siguiente ejemplo actualiza la información de uno de los usuario creados en el ejemplo anterior utilizando la definición de businessKey.

 

<BizAgiWSParam>

<Entities>

<WFUSER businessKey="userName='juliettel' AND domain='agilityCorp'">

 <fullName>Juliette Leroy-Brown</fullName>

 <userName>juliettel</userName>

 <domain>agilityCorp</domain>

 <enabled>1</enabled>

</WFUSER>

</Entities>

</BizAgiWSParam>

 

Observe que el campo que actualizamos es el nombre completo (fullName) y como no necesitamos actualizar otra información, podemos omitir dicha definición (es decir, se mantienen los valores).

El servicio web responderá exitosamente con el mismo mensaje de los ejemplos anteriores (ya sea creando por primera vez o actualizando, la respuesta envía el identificador de cada registro involucrado en la invocación).

 

Asignar Stakeholders a usuarios

Es posible añadir el nodo StakeHolders en su request para asignarle un Stakeholder a un usuario dado. El siguiente ejemplo hace uso de la definición businessKey para lograrlo:

 

<BizAgiWSParam>
<Entities>
<WFUSER businesskey="username='juliettel'">
  <StakeHolders>
      <stakeholderName1>
          <stakeholderAttribute>value</stakeholderAttribute>
      </stakeholderName1>
      <stakeholderName2>
          <dummy></dummy>
      </stakeholderName2>
  </StakeHolders>
</WFUSER>
</Entities>
</BizAgiWSParam>

 

Tenga en cuenta que los Stakeholders pueden o no contener atributos. En caso que desee actualizar esta información, el atributo debe ser añadido como un nodo del Stakeholder. En este caso el atributo stakeholderAttribute para stakeholderName1. En cambio, si el Stakeholder no contiene atributos o no se desea actualizar, se debe incluir un nodo dummy. Para este caso el nodo dummy para stakeholderName2.

 

Notas importantes

Considere:

Debe asegurarse de que los siguientes valores no estén repetidos en sus usuarios (estos valores deben ser únicos): contactEmail (Correo electrónico) y la combinación de domain (dominio) y username (nombre de usuario).

La propiedad Enabled (Habilitado) debe varias si un usuario en su repositorio está deshabilitado o no.

Para los proyectos on-premise de Bizagi, es importante que considere el número de usuarios licenciados (que limita directamente la cantidad de usuarios habilitados).

 

Por último, asegúrese de programar la invocación de este servicio web para asegurarse de que sus usuarios estén constantemente sincronizados (e.g, deshabilitados o que se tomen en consideración los usuarios nuevos).