Máscara de interfaz de usuario

La funcionalidad que se describe en esta sección se utiliza para tomar los datos que se almacenan en texto sin formato en la base de datos y aplicar una máscara al valor, antes de mostrarlo al usuario (o a un sistema externo). En esta función se incluye la posibilidad de permitir a determinados usuarios la visualización de los datos sin máscara mediante la configuración de seguridad. El sistema permite aplicar reglas de máscara diferentes a los distintos campos. Por ejemplo, a un número de tarjeta de crédito se le puede aplicar una máscara distinta de la que se aplicaría a un número de la seguridad social.

En los temas siguientes se describe cómo aplicar una máscara a los valores de campo.

Identificación de los campos a los que se aplica la máscara

Es necesario identificar los datos que se almacenan en texto sin formato a los que deberá aplicarse una máscara para su presentación a los usuarios. Por ejemplo, imaginemos que se han identificado un número de tarjeta de crédito y un número de identificación federal de una persona (por ejemplo, en Estados Unidos, el número de la seguridad social). Cada campo identificado podría mostrarse y mantenerse en interfaces de usuario distintas en el sistema, pero probablemente las reglas de máscara serán uniformes, con independencia de cómo se visualicen los datos.

No se pueden aplicar máscaras a las claves primarias. Un campo definido como identificador único de una fila no se puede configurar para la máscara. Si se aplica una máscara a un campo que es parte de la clave primaria, se producirá un problema al intentar actualizar el registro. Esta restricción también se aplica a elementos que forman parte de una "lista" en una columna XML de un objeto de mantenimiento. Uno o varios elementos de la lista se deben identificar como identificador primario de la lista. Asegúrese de que los elementos de clave primaria de la lista no son los que requieren la máscara.

Miembros de listas que contienen distintos "tipos". Supongamos que tiene una página con una lista que contiene los números de identificación de una persona. Se puede configurar el sistema de tal manera que el número de seguridad social de esta persona tenga reglas de máscara diferentes que las del número del permiso de conducir. Si su implantación tiene este tipo de requisito, la lista de campos con máscara debería contener una entrada para cada regla de máscara.

Si determinados usuarios van a poder ver los datos sin máscara en una o más interfaces de usuario, será necesario aplicar una configuración de seguridad en cada campo. Si se va a aplicar la máscara al valor de un campo para todos los usuarios de todas las páginas de la aplicación, la configuración de seguridad no será necesaria.

Configuración de seguridad

Defina un tipo de seguridad para cada campo con dos niveles de autorización:

1 : solo puede ver el elemento con la máscara.
2 : solo puede ver el elemento sin la máscara.

Enlace todos los tipos de seguridad a un servicio de aplicación de su elección. Recomendamos enlazar cada tipo de seguridad orientado a máscara a un único servicio de aplicación (por ejemplo, CM_MASK), ya que así se facilita la concesión de accesos.

Para cada tipo de seguridad, identifique qué usuarios pueden ver sus datos sin máscara y qué usuarios pueden ver sus datos solo con máscara. Si los usuarios con y sin máscara encajan en los grupos de usuarios existentes, no se necesitan grupos de usuarios adicionales. De lo contrario, cree nuevos grupos para los usuarios con máscara y sin máscara.

Una vez definidos los grupos de usuarios de cada tipo de seguridad, enlace cada grupo de usuarios al servicio de aplicación definido antes. Cuando se enlaza un grupo de usuarios al servicio de aplicación, se define el nivel de autorización de cada tipo de seguridad enlazado al servicio de la aplicación. Si los usuarios de un grupo de usuarios deben ver los valores de campo del tipo de seguridad sin máscara, establezca el nivel de autorización en 2; en caso contrario, establézcalo en 1.

Nota: vacíe la caché. Recuerde que, cada vez que cambie los derechos de acceso, debe vaciar la caché de seguridad (introduzca flushAll.jsp en la URL de la aplicación), si desea que el cambio tenga un efecto inmediato.

Configuración de un algoritmo de máscara

Deberá crearse un algoritmo de máscara de datos (con el valor de entidad de algoritmo Configuración de funciones - Máscara de datos) para cada combinación de reglas de máscara y tipo de seguridad. Estos algoritmos determinan si un usuario tiene derechos para ver un campo dado sin máscara y, en caso contrario, cómo se debe aplicar la máscara al campo.

El paquete base proporciona el tipo de algoritmo F1-MASK, cuyos parámetros se han diseñado para abordar la mayor parte de los requisitos de máscara. Si determinados usuarios van a poder ver los datos sin máscara, los parámetros capturarán el servicio de aplicación, el tipo de seguridad y el nivel de autorización definido antes para evaluarlo. Además, los parámetros permitirán configurar a qué cantidad de datos se aplicará la máscara y qué carácter de máscara se va a utilizar. Consulte la descripción del tipo de algoritmo para obtener más información.

Determinación del modo de presentación de los campos

La configuración de la máscara varía en función de cómo se recupera un campo para acceder a la interfaz de usuario. De esta forma, para una máscara de un campo “lógico" (como el número de seguridad social de una persona), podrían ser necesarias varias entradas de configuración para cubrir todos los métodos de acceso. Revise cada interfaz de usuario donde aparezca un campo determinado y cree las categorías siguientes:

El campo es un elemento que se recupera mediante la llamada a un objeto de negocio, un servicio de negocio o un script de servicio.
El campo aparece en una página de mantenimiento fija (y, por tanto, se recupera mediante la llamada a un servicio de página).
El campo aparece en una página de búsqueda fija (y, por tanto, se recupera mediante la llamada a un servicio de búsqueda).
El campo se almacena como una característica ad hoc

Creación de una configuración de funciones para cada elemento con máscara

Cree una configuración de funciones con el Tipo de función Máscara de datos. Será necesario disponer de una entrada de opción con un tipo Máscara de campo para cada combinación de campo al que se aplicará la máscara y método utilizado para mostrar los datos. El valor contendrá abreviaciones nemotécnicas que hacen referencia al algoritmo de máscara de datos adecuado, junto con la configuración, que variará en función del modo en que se recupera el campo para su presentación, como se describe a continuación.

Máscara de campo de objetos basados en esquema

En el caso de los datos a los que se accede mediante una llamada a un objeto basado en esquema y que se muestran en un mapa de UI, el campo al que se aplica la máscara deberá hacer referencia a un nombre de campo de metadatos en su definición de esquema: field="fld_name", alg="algorithm name"

Si el elemento hace referencia a mdField en el esquema, este será el campo utilizado para identificar la regla de máscara. Si no existe ninguna referencia a mdField, sino una única referencia a mapField, este será el campo que se utilice para identificar la regla de máscara. Por ejemplo, si deseamos aplicar una máscara a un número de tarjeta de crédito, imaginemos que el campo se define en el esquema de la siguiente manera:

<creditCard mdField="CCNBR" mapField="EXT_ACCT_ID"/>

En este caso, el valor de opción sería field="CCNBR", alg="algorithm name". Un valor de opción de field="EXT_ACCT_ID", alg="algorithm name" no daría como resultado una máscara.

También se puede especificar una cláusula "where". Esta resultará de utilidad para los datos que residan en una lista en la que solo deba aplicarse la máscara a determinado tipo de datos: field="fld_name", alg="algorithm name", where="fld_name='value'"

Por ejemplo, una persona puede disponer de una recopilación de identificadores y solo aplicar la máscara a los correspondientes al número de seguridad social, con tipo 'SSN'. Si los datos de la persona, incluida la recopilación de identificadores, aparecen en un mapa de UI mediante una llamada a un objeto de negocio, supongamos que la recopilación se define de la siguiente manera:

<personIDs type="list" mapChild=CI_PER_ID">
  <isPrimaryId mapField="PRIM_SW"/>
  <idType mapField="ID_TYPE_CD"/>
  <personIdNumber mapField="PER_ID_NBR"/>
</personIds>

El valor de opción podría tener este aspecto: field="PER_ID_NBR", alg="algorithm name", where="ID_TYPE_CD='SSN'"

Deben tenerse en cuenta los puntos siguientes importantes para las máscaras basadas en esquema:

Limitación del campo 'where'; aunque el uso principal de la cláusula 'where' para elementos orientados a esquema es el de aplicar la máscara a determinados elementos de una lista basados en un 'tipo', también se puede aplicar la máscara a un único campo del esquema, en función del valor de otro campo. Por ejemplo, imaginemos que un cliente envía un formulario de registro que define un tipo y un valor de ID. Aunque estos datos no se encuentran en una lista, puede que la implantación solo intente aplicar la máscara al valor de ID si el tipo de dicho ID es "SSN", un número de la seguridad social. El marco solo podrá aplicar una máscara a un elemento del esquema según una cláusula 'where' si el elemento de dicha cláusula es un "hermano" en el esquema.
- Si elemento al que se va a aplicar la máscara está en una lista, el elemento de la cláusula 'where' deberá estar en la misma lista.
- Si el elemento al que se va a aplicar la máscara se asigna a una columna real de una tabla, el elemento de la cláusula 'where' también deberá asignarse a una columna real de la tabla.
- Si el elemento al que se va a aplicar la máscara se asigna a una columna XML en la tabla como elemento único, el elemento de la cláusula 'where' deberá asignarse a la misma columna XML como elemento único.
Varias entradas de opción de función para el mismo campo. Puede que distintos esquemas del sistema compartan un tipo de datos similar a los que se aplique la máscara, en función de distintas condiciones. Imaginemos, por ejemplo, que una implantación tiene distintos esquemas que capturan o hacen referencia a identificadores personales de distintas formas:
- Un esquema captura un ID de persona único sin ningún registro de "tipo" correspondiente y siempre debe aplicarse la máscara mediante el algoritmo CM_SSN_MASK:
```
<personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
```
- Un esquema captura un ID de persona y un tipo de ID correspondiente, y debe aplicarse la máscara con el algoritmo CM_SSN_MASK si el tipo es "SSN" y con CM_FEIN_MASK si el tipo es "FEIN".
```
<personIdType mapXML=BO_DATA_AREA mdField=ID_TYPE_CD/>
<personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
```
- Un esquema captura un ID de persona y el tipo de ID correspondiente; tiene las mismas reglas de máscara que el esquema anterior pero hay un nombre de campo diferente que se utiliza para el código de tipo de ID. Este escenario se puede producir si, por ejemplo, se desea disponer de una etiqueta diferente para el tipo de ID en la interfaz de usuario para este esquema.
```
<personIdType mapXML=BO_DATA_AREA mdField=CM_ID_TYPE/>
<personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
```
Para este escenario, las opciones de función podrían tener este aspecto:
1. field="PER_ID_NBR", alg="CM_SSN_MASK"
2. field="PER_ID_NBR", alg="CM_SSN_MASK", where="ID_TYPE_CD='SSN'"
3. field="PER_ID_NBR", alg="CM_FEIN_MASK", where="ID_TYPE_CD='FEIN'"
4. field="PER_ID_NBR", alg="CM_SSN_MASK", where="CM_ID_TYPE='SSN'"
5. field="PER_ID_NBR", alg="CM_FEIN_MASK", where="CM_ID_TYPE='FEIN'"
Para cada esquema, el sistema buscará primero si el elemento se aplica a cualquier opción de máscara. Encontrará 5 opciones de máscara para el campo PER_ID_NBR. A continuación, determinará si existen elementos hermanos que coincidan con la cláusula 'where'.
- Si existe más de un elemento hermano coincidente con la cláusula 'where', se emitirá un error en tiempo de ejecución. Por ejemplo, si un esquema incluye un elemento que hace referencia a "mdField=ID_TYPE_CD" y un elemento que hace referencia a "mdField=CM_ID_TYPE", se producirá un error. Además, en caso de que haya varios elementos que hacen referencia a mdField=ID_TYPE_CD", también se producirá un error.
- Si existe un único elemento hermano coincidente con la cláusula 'where', el valor del elemento se comparará con los definidos en la cláusula 'where'. Si encuentra una coincidencia con el valor, se aplicará el algoritmo de máscara adecuado. Si no se encuentra ninguna coincidencia (por ejemplo, el tipo de ID de persona es "LICENSE") el elemento se mostrará tal cual.
- Si no hay ningún elemento hermano que coincida con una cláusula 'where' y existe una opción de función sin cláusula 'where' (opción 1 anterior), se aplicará el algoritmo de máscara de la opción sin cláusula 'where'.
Cambio del valor en la cláusula 'where'. Si la implantación incluye usuarios a los que se les permite modificar registros y en dichos registros existen datos a los que se aplica una máscara según una condición, será recomendable diseñar la interfaz de usuario de tal forma que restaure el valor con máscara cuando cambie el valor en la cláusula 'where'. Por ejemplo, si un usuario no puede ver el número de seguridad social de una persona pero sí puede hacer actualizaciones en el registro de esta, el cambio del valor del tipo de ID de persona debería restaurar el número de ID de persona. De esta forma, se garantiza que el usuario no puede eliminar la máscara del número de la seguridad social con solo cambiar el tipo de ID.

Registros que se mantienen con el mantenimiento de página

En el caso de aquellos datos a los que se accede mediante una llamada al servicio de mantenimiento de página, se indicará el nombre de la tabla y el nombre del campo en los que residen los datos: table="table_name", field="fld_name", alg="algorithm name"

Por ejemplo, si el registro de persona y su recopilación de identificadores se muestran y mantienen utilizando el mantenimiento de página, el valor de opción debería ser table="CI_PER_ID", field="PER_ID_NBR", alg="algorithm name"

También se puede especificar una cláusula "where": table="table_name", field="fld_name", where="fld_name='value'", alg="algorithm name"

Esto resultará de utilidad en el caso de datos que residan en una tabla secundaria donde solo deba aplicarse una máscara a los datos de determinado tipo. En el caso del ejemplo del ID de persona: table="CI_PER_ID", field="PER_ID_NBR", alg="algorithm name", where="ID_TYPE_CD='SSN'"

Datos de característica

Para aquellos datos que se almacenan como una característica, simplemente deberá indicarse el tipo de característica: CHAR_TYPE_CD='char type', alg="algorithm name"

Solo será necesario definirlo una vez, con independencia de la entidad en la que pueda residir el tipo de característica. Debe tenerse en cuenta que solo se soportan características ad hoc.

Máscara de campos en zonas del explorador o cadenas de información

Con frecuencia, los datos de las zonas del explorador se recuperan utilizando directamente el SQL, a partir de la base de datos. En este caso, no se aplica ninguna máscara de modo automático. Si existen datos en los resultados de la zona del explorador a los que deba aplicarse una máscara, deberá hacerse mediante la llamada a un servicio de negocio.

De forma similar, un algoritmo de información de objeto de mantenimiento no podrá utilizar la interacción con el objeto de negocio para obtener los datos. Se puede acceder a los datos mediante SQL para incrementar la eficiencia. Al recuperar los datos mediante SQL no se aplica la máscara. Para aplicar la máscara a una cadena antes de incluirla en una cadena de información, deberá hacerse a través de una llamada a un servicio de negocio.

El sistema ofrece dos servicios de negocio a los que llamar, para determinar si se aplican reglas de máscara para un campo específico.

F1-TableFieldMask. Aplicar la máscara a un campo de tabla. Este servicio de negocio recibe un nombre de tabla, un nombre de campo y uno o más valores de campo. Si se aplica la máscara, se devuelve el valor con máscara.
F1-SchemaFieldMask. Aplicar la máscara a un campo de esquema. Este servicio de negocio recibe un nombre y un tipo de esquema, un XPath y un valor de campo. Si se aplica la máscara, se devuelve el valor con máscara.

Resultados de servicio de búsqueda

Los datos que se muestran en una página de búsqueda 'fija' se recuperarán mediante una llamada a un servicio de búsqueda. Se indica el nombre de la búsqueda y el campo adecuado al que se aplicará la máscara, junto con el algoritmo de máscara. Por ejemplo: search="SearchServiceName", field="PER_ID_NBR", where="ID_TYPE_CD='SSN'", alg="algorithm name"

Para encontrar el nombre del servicio de búsqueda, lance la búsqueda en cuestión, pulse con el botón derecho en el área de filtro y seleccione la opción de inspección. Busque "serviceName". En esta lista se incluirá el nombre de servicio. Para localizar el nombre de campo que desea enmascarar, busque la "información de widget". Deberían aparecer dos resultados, uno para el área de filtro y otro para el área de resultados. El área de resultados incluye el texto "SEARCH_RESULTS" como prefijo para cada campo. Los nombres de campos serán los que aparecen después de x$. Al definir el nombre de campo, no incluya x$. Debe tenerse en cuenta que la sentencia "where" solo se puede aplicar a los campos que también formen parte de los resultados de la búsqueda.

Información adicional sobre la máscara

A continuación se proporciona información adicional para ayudarle a configurar la máscara:

Si la base de datos de demostración incluye una configuración de funciones de máscara de datos, revise la configuración; probablemente contenga reglas de máscara que coincidirán con las suyas.
En las páginas de introducción de datos, un usuario podría introducir o cambiar datos con máscara, como, por ejemplo, un número de cuenta bancaria, pero a partir de ahí no ver lo que se ha añadido o modificado.
Los sistemas externos pueden solicitar información realizando una llamada de servicio mediante un servicio web. Tenga en cuenta que algunas solicitudes de servicio web necesitan que se apliquen máscaras a los datos y otras no. Por ejemplo, una solicitud de un sistema externo para sincronizar la información de persona necesita que el número de la seguridad social de la persona no tenga máscara, mientras que una solicitud de una aplicación de autoservicio web para recuperar la misma información de persona para su presentación necesita que el número de la seguridad social de la persona tenga máscara. Para implantar este tipo de requisito, es preciso asociar a los distintos usuarios con cada una de las solicitudes y estos usuarios deben pertenecer a grupos de usuarios independientes, con distintos derechos de acceso.
Si un objeto de mantenimiento contiene un campo que incluye un documento XML y una llamada de servicio llama directamente al programa de servicio del objeto de mantenimiento, el sistema aplicará la máscara a los elementos XML individuales del campo, si se ha introducido el algoritmo Determinar objeto de negocio en el objeto de mantenimiento y los elementos del esquema del objeto de negocio correspondiente se han protegido, según se acaba de describir.