Creación de Roles y departamentos para Reparación de mensajes y Nuevo envío
La reparación de mensajes y el nuevo envío implican las cuatro operaciones diferentes siguientes:
Reparación de un mensaje que ha producido un error en la validación
Comprobación de la reparación (incluida la regeneración de claves)
Aprobación de la reparación
Creación de un nuevo mensaje
Para realizar una de estas operaciones, un usuario debe asumir el rol asociado a la operación. El rol también debe formar parte del departamento de procesamiento (descrito a continuación). Para enviar el mensaje después de realizar una fase en el flujo de trabajo, el usuario debe firmar el mensaje con un certificado válido asociado al usuario.
Creación de departamentos y roles
Consulte la documentación del cliente web de perfil.
Reglas de uso de roles
A4SWIFT usuarios, roles y departamentos deben cumplir las reglas siguientes:
El flujo de trabajo completo de un mensaje reparado consiste en reparar, comprobar y, a continuación, aprobar el mensaje. El flujo de trabajo completo de un mensaje creado consiste en crear, reparar, comprobar y, a continuación, aprobar el mensaje. Los pasos de comprobación y aprobación son opcionales.
El flujo de trabajo de un departamento debe comenzar con un rol de creación o reparación. Si un flujo de trabajo incluye los pasos de creación y reparación (un flujo de trabajo para un mensaje creado), el paso de creación debe aparecer inmediatamente antes del paso de reparación.
Un flujo de trabajo para un mensaje creado debe contener uno y solo un rol que tenga la capacidad de crear.
Cada flujo de trabajo debe contener uno y solo un rol que tenga una funcionalidad de reparación.
Un usuario de A4SWIFT se puede asociar a más de un rol, pero ningún usuario puede ejecutar más de un paso en un único flujo de trabajo. Por ejemplo, si el usuario A repara un mensaje y el usuario B comprueba el mensaje, ni el usuario A ni el usuario B pueden aprobar el mensaje.
No hay ninguna comprobación en el orden de los roles con la funcionalidad de RekeyVerify o Aprobar en relación con otros roles con la funcionalidad de RekeyVerify o Approve.
Si un mensaje que ya ha reparado produce un error de validación, vuelve a la bandeja de entrada de reparación en la biblioteca de documentos del sitio MRSR. Cuando esto sucede, las limitaciones anteriores de los roles de verificación y aprobador (en función de quién ya ha realizado un rol en el flujo de trabajo) ya no se aplican. Por ejemplo, si el usuario A repara un mensaje, el usuario B rechaza el mensaje en la comprobación y el usuario A repara el mensaje una segunda vez, un usuario distinto del usuario B podría comprobar el mensaje. Si es así, el usuario B podría aprobar el mensaje. Otro ejemplo es que si el usuario A crea un mensaje, el usuario B rechaza el mensaje en la comprobación y el usuario C repara el mensaje, el usuario A podría comprobar el mensaje.
Un usuario A4SWIFT que crea un mensaje también puede reparar ese mensaje si se produce un error en la validación.
Solo A4SWIFT los usuarios del departamento asociados a un flujo de trabajo pueden realizar un paso en el flujo de trabajo. Cuando un usuario de A4SWIFT envía un mensaje, A4SWIFT comprueba que el usuario tiene un rol en el departamento asociado al mensaje (a través de los perfiles de usuario (en caso de que el departamento no sea predeterminado) en el cliente web de perfil).
Un administrador puede dar a un solo A4SWIFT usuario varios roles dentro de un departamento. Un solo usuario puede realizar reparaciones, comprobación, aprobación o creación, o cualquier subconjunto de esos roles, sujeto a las limitaciones de cualquier flujo de trabajo descrito anteriormente.
Certificados
Para enviar un mensaje en el equipo local después de reparar, comprobar, aprobar o crear, el usuario A4SWIFT debe firmar el mensaje con su certificado. Para obtener más información sobre cómo crear certificados, consulte Instalación de certificados.
Para poder reparar, comprobar, aprobar o crear un mensaje mediante el acceso al sitio MRSR desde un equipo cliente remoto, el usuario debe agregar su certificado en el almacén Certificados: usuario actual, personal o certificados de su equipo cliente (el usuario no tiene que ser administrador para hacerlo). Además, un administrador del servidor debe agregar el certificado del usuario (y los de cualquier otro usuario que acceda al servidor desde su equipo cliente) al almacén certificados (equipo local)/Otros Personas/Certificados en el servidor.
Un solo usuario puede tener varios roles asignados y debe usar el mismo certificado al realizar cualquiera de esos roles.