Escenarios de fallos

En esta sección se describen ocho escenarios de fallos y se comparan dos implementaciones: una con persistencia de sesiones y otra sin ella.

• La implementación con persistencia de sesiones incluye afinidad de sesiones en un equilibrador de carga. La implementación consta de diversas instancias en un clúster que tienen habilitado algún tipo de persistencia de sesiones de manera que los cambios de sesión se graben en un nodo de depósito físicamente diferenciado.

• La implementación sin persistencia de sesiones incluye afinidad de sesiones en un equilibrador de carga y diversas instancias que no forman parte de un clúster.

Escenario 1: fuera del flujo de trabajo

Descripción del escenario

El usuario final o el administrador editan un formulario no perteneciente a un flujo de trabajo. Deja de funcionar la instancia donde el usuario ha establecido la sesión.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. Tras enviar el formulario, se devuelve al usuario a la página de inicio de sesión.

Acciones de recuperación: El usuario reintroduce su nombre de usuario y contraseña. A continuación, Identity Manager procesa el formulario y presenta los resultados en la página inmediatamente posterior a la de inicio de sesión.

Con persistencia de sesiones

Experiencia de usuario: El formulario del usuario se envía y los resultados se devuelven sin que salga de la sesión y deba volver a iniciarla.

Acciones de recuperación: No es necesaria ninguna acción del usuario.

Otros escenarios de ejemplo

• Un usuario final ha iniciado una sesión y ha recuperado los resultados de búsqueda de usuarios u otros objetos del depósito cuando la instancia deja de funcionar.

• Un administrador está a punto de enviar una solicitud de restablecimiento de contraseña o de edición de usuario a través de la interfaz de administración cuando la instancia deja de funcionar.

Escenario 2: Con flujo de trabajo en curso

Descripción del escenario

El usuario final o el administrador han enviado un formulario que ha activado un flujo de trabajo. La instancia donde se ejecuta el flujo de trabajo y donde se encuentra la sesión del usuario suele ser la misma, excepto con algunas tareas programadas, que pueden realizarse en distintas instancias. Esta instancia deja de funcionar mientras el flujo de trabajo está en curso.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. El envío del formulario devuelve el usuario a la página de inicio de sesión. La instancia de la tarea del flujo de trabajo que se está ejecutando debe estar en el depósito, pero como el nodo de ejecución no funciona, el estado del flujo de trabajo es "terminado".

Acciones de recuperación: El flujo de trabajo debe volver a enviarse. Para ello hay que regresar al mismo formulario y reintroducir la misma información que sirvió para activar el flujo de trabajo antes de que fallara el nodo.

Enviar los mismos datos de solicitud no siempre funciona. Si el flujo de trabajo abastece más de un recurso durante su ejecución y alguno de esos recursos se había abastecido antes del fallo, el reenvío del flujo de trabajo por parte del usuario tendría que asumir los recursos ya abastecidos. No olvide que el flujo de trabajo terminado persiste en el depósito hasta que resultLimit caduca en el objeto TaskInstance .

Con persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. El usuario no logra cerrar la sesión porque es persistente y se restablece en la nueva instancia. Sin embargo, el envío del formulario seguramente generará un error, porque el flujo de trabajo se habrá terminado. Se trata de una conmutación por error no transparente, ya que son necesarias acciones de recuperación.

Acciones de recuperación: Las mismas que sin persistencia de sesiones. El usuario debe reenviar la solicitud que desactivó el flujo de trabajo anterior con parámetros iguales o modificados.

Otros escenarios de ejemplo

• Un usuario final acaba de enviar una solicitud de registro automático para crear una cuenta de Identity Manager y la instancia deja de funcionar.

• Un administrador acaba de enviar una solicitud de restablecimiento de contraseña que se halla en curso cuando la instancia deja de funcionar.

Escenario 3: Flujo de trabajo suspendido o postergado

Descripción del escenario

Este escenario abarca situaciones en que el flujo de trabajo ha comenzado, pero está esperando que un aprobador realice una acción manual.

Sin persistencia de sesiones

Experiencia de usuario: Conmutación por error transparente con respecto al aprobador siempre que éste aún no haya iniciado la sesión. Tras fallar el nodo, cuando el aprobador inicia la sesión todavía aparece la solicitud de aprobación en su bandeja de entrada, incluso aunque la solicitud haya sido activada desde un nodo que ha quedado inactivo.

Acciones de recuperación: No es necesaria ninguna acción del usuario.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Otros escenarios de ejemplo

• El flujo de trabajo está suspendido, por ejemplo, una acción manual pendiente de una fecha inicial o final de un empleado.

• Un administrador envió una solicitud de creación cuya aprobación se halla a la espera de que un aprobador inicie la sesión. El nodo desde donde se envió la solicitud ha fallado antes de que el aprobador pueda aprobarla.

Escenario 4: Edición de un elemento de trabajo

Descripción del escenario

Este escenario incluye los casos en que un usuario está editando un elemento de trabajo y el nodo donde se halla la sesión del usuario deja de funcionar antes de poder enviar el elemento de trabajo.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. Cuando se envía el formulario de edición del elemento de trabajo, se cierra la sesión del usuario, que vuelve a la página de inicio de sesión.

Acciones de recuperación: Tras reenviar las credenciales de inicio de sesión, el elemento de trabajo del usuario se marca como completado y el flujo de trabajo puede reanudarse a partir de ese punto. El flujo de trabajo debe seleccionarse en el nuevo modo para ejecutarlo a partir del punto en que se ha marcado como completada la acción manual del usuario.

Con persistencia de sesiones

Experiencia de usuario: Cuando se envía el formulario de edición del elemento de trabajo, el usuario ve el resultado de dicho envío; por ejemplo, el siguiente formulario del flujo de trabajo personalizado si lo hay o un mensaje satisfactorio.

Acciones de recuperación: No es necesaria ninguna acción del usuario.

Otros escenarios de ejemplo

• Un usuario final está rellenando un formulario asociado a una acción manual en un flujo de trabajo personalizado, por ejemplo, para solicitar acceso a determinados recursos. Antes de que el usuario pueda enviar la solicitud, sucumbe el nodo donde se halla la sesión del usuario.

• Un administrador ha iniciado la sesión en Identity Manager y ha abierto una solicitud de aprobación para editar. Antes de poder enviar la solicitud, falla el nodo donde se halla la sesión del administrador.

Escenario 5: Tareas programadas en curso

Descripción del escenario

Este escenario abarca los casos en que falla un nodo mientras está en curso una reconciliación o durante la ejecución de un informe.

Sin persistencia de sesiones

Experiencia de usuario: La tarea programada termina durante el proceso.

Acciones de recuperación: Hay que reiniciar la tarea programada que estaba realizándose. La tarea volverá a empezar desde el principio. (La tarea no se reiniciará a partir del punto de fallo.) Es parecido a crear e iniciar una tarea nueva.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Otros escenarios de ejemplo

• Un adaptador de Active Sync está configurado para ejecutarse en el nodo fallido.

Escenario 6: Tarea programada en suspensión

Descripción del escenario

Este escenario abarca los casos en que el flujo de trabajo personalizado de un usuario tiene una tarea programada para ejecutarse en una fecha posterior en un nodo específico. Antes de la fecha programada, falla el nodo donde estaba programada la tarea.

Sin persistencia de sesiones

Experiencia de usuario: La conmutación por error es transparente con respecto a las acciones de recuperación necesarias para asegurar la ejecución de esta tarea en la fecha prevista.

Acciones de recuperación: Cualquier nodo activo asume la tarea programada cuando llega la fecha de ejecución prevista.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Otros escenarios de ejemplo

• Mientras se crea una cuenta de usuario, se utiliza el Analizador de tareas aplazadas para implementar la habilitación de una cuenta en una fecha inicial o para implementar la deshabilitación de la cuenta en una fecha final. Antes de que llegue la fecha inicial o final, falla el nodo donde se había programado la tarea.

• Se ha programado un informe para que se ejecute en una fecha futura o una reconciliación para que se ejecute a una hora concreta, pero antes de ese momento falla el nodo donde se había programado la tarea.

Escenario 7: Solicitud de flujo de trabajo de servicios webaún no recibida por Identity Manager

Descripción del escenario

Este escenario abarca los casos en que no se utiliza la GUI de Identity Manager para iniciar el abastecimiento. En su lugar, la interfaz de usuario la suministra una aplicación que realiza una llamada interna a Identity Manager a través de SPML u otra interfaz de servicio web personalizada. La sesión relacionada con el usuario a través de la interfaz de usuario se administra mediante la aplicación que realiza la llamada. Para Identity Manager, todas las solicitudes se inician como asunto del administrador de SOAP (“soapadmin”).

En tal caso de uso, este escenario de fallo abarca las situaciones en que aún no se ha recibido la solicitud por medio del punto final de Identity Manager y falla el nodo de destino.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error transparente. Las credenciales del administrador de SOAP se transmiten con cada solicitud de SOAP, ya sea mediante conexión o dentro de Identity Manager con un valor de configuración Waveset.properties. En tanto que el nodo que debía recibir esta solicitud de SOAP no la ha recibido antes de fallar, la conmutación por error es transparente con o sin persistencia de sesiones.

Acciones de recuperación: No es necesaria ninguna acción. La solicitud de SOAP se envía a un nodo activo que la ejecuta.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Escenario 8: Solicitud de flujo de trabajo de servicios web en curso por Identity Manager

Descripción del escenario

Es similar al escenario 7. La única diferencia es que el flujo de trabajo se está efectuando cuando el nodo falla, o que el nodo ha recibido la solicitud de SOAP cuando falla.

Sin persistencia de sesiones

Experiencia de usuario: Es similar al escenario 2 (flujo de trabajo en curso). El flujo de trabajo se marca como terminado y el usuario ve un error como resultado de la solicitud de SOAP.

Acciones de recuperación: El usuario debe reenviar el formulario con parámetros iguales o modificados (según dónde se produzca el fallo en el flujo de trabajo) a través de la interfaz de usuario en la aplicación de terceros.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.