En esta publicación de blog, exploraremos una solución alternativa para usar roles de aplicación en SAP Build Apps que no es compatible hasta ahora. Veremos un ejemplo de implementación que adapta los componentes de UI de una aplicación web según el rol del usuario, evitando así la necesidad de crear una aplicación web separada para cada rol de usuario en SAP Build Apps.

en un Publicación anterior, creamos una aplicación web simple con SAP Build Apps, que se conecta a una API REST a través de un destino en Business Technology Platform (BTP) para leer y mostrar registros. El usuario conectado sólo puede ver sus datos. Sin embargo, nuestro servicio backend admite dos roles: un usuario normal que solo puede obtener sus registros y un usuario administrador que puede recuperar los registros de todos los usuarios.

Nuestro objetivo ahora es ajustar la aplicación web para que un usuario administrador pueda elegir ver todos los registros. La aplicación web debe verificar si el usuario conectado tiene la función de administrador de la aplicación y mostrar los componentes de la interfaz de usuario adecuados en consecuencia.

Suponemos que tendremos dos roles: Administrador y Usuario. Así es como ajustamos la interfaz de usuario en SAP Build Apps:

1. Agregue un nuevo punto final de datos: Actualmente, tenemos un punto final de datos llamado “misDevoluciones” que devuelve solo los registros de usuario conectados. Para obtener los registros de todos los usuarios, debemos consultar un punto final diferente llamado “todas las devoluciones”. Luego lo agregamos en la pestaña Datos de la misma manera que lo hicimos con “misDevoluciones”. También agregamos la variable de datos correspondiente en la página de lista de registros para usarla en esa vista.

Agregar una nueva integración de API REST en SAP Build Apps

2. Agregue componentes de interfaz de usuario para el usuario administrador: En nuestro caso, agregamos un botón de cambio en la pantalla de lista retornable. Este botón solo debería aparecer para el usuario administrador y, si está activado, la lista debería actualizarse con los registros de todos los usuarios.

3. Haga que el botón sea visible solo para administradores: Para lograr esto, editamos la propiedad visible del botón y agregamos la siguiente fórmula:

   SOME<scope>(systemVars.currentUser.scopes, CONTAINS(scope, "Administrator"))​

   Los alcances de roles asignados al usuario conectado se recuperan y registran automáticamente en la variable del sistema de la aplicación `systemVars.currentUser.scopes`. La fórmula verifica si el alcance del «Administrador» existe y devuelve verdadero si existe.

Ajustar la visibilidad de los componentes de la interfaz de usuario según los roles de los usuarios

3. Cree una variable de página booleana «verTodo»: Esta variable está vinculada a la propiedad de valor del interruptor de palanca. En la lista, actualizamos el valor «repetir con» con la siguiente fórmula:

   SORT_BY_KEY( IF(pageVars.seeAll, data["All returns1"], data["My Returns1"]), "date","desc").​

   Según el valor de la variable «seeAll», estará vinculada a la «mi regreso» o el “Todos regresan” recopilación de datos.

   

5. Cree e implemente la aplicación: ¡Con estos pasos, la aplicación debería estar lista para funcionar!

La implementación creará una instancia de UAA (servicio de administración de confianza y autorización) que maneja las autorizaciones de usuario para la aplicación web. La instancia creada no contiene ningún alcance o función, por lo que necesitaremos mejorarla.

Hemos creado un archivo «xs-security.json» en el que podemos definir los alcances y roles de nuestra aplicación UI. Por ejemplo, definimos dos ámbitos: `Administrador` y `Usuario`, y dos plantillas de roles correspondientes: `myPackAdmin` y `myPackUser`.

{
  "xsappname": "appgyver-web-app-22991",
  "tenant-mode": "dedicated",
  "scopes"        : [
    {
      "name"        : "$XSAPPNAME.User",
      "description" : "User"
    },
    {
      "name"        : "$XSAPPNAME.Administrator",
      "description" : "Administrator"
    }
  ],
  "role-templates": [
    {
      "name"             : "myPackUser",
      "description"      : "User access",
      "scope-references" : [
        "$XSAPPNAME.User"
      ]
    },
    {
      "name"                 : "myPackAdmin",
      "description"          : "Admin access",
      "scope-references"     : [
        "$XSAPPNAME.Administrator" 
      ]
    }
  ]
} 

Para su caso, puede utilizar el mismo contenido de archivo y personalizar alcances y roles según sus requisitos. Simplemente reemplace la propiedad xsappname con el nombre de su aplicación.
Para ubicar el nombre de la aplicación en la cabina de BTP después de la implementación, navegue hasta instancias y suscripciones. Busque instancias que comiencen con appgyver-web-app-xx-uaa y copie el nombre excluyendo el sufijo -uaa.

Localice la instancia uaa creada para la aplicación web

Para actualizar la instancia existente «appgyver-web-app-xx-uaa» con nuestra nueva configuración, usamos la siguiente línea de comando en la terminal:

cf servicio de actualización appgyver-web-app-22991-uaa -p aplicación -c xs-security.json.

Para su aplicación, debe reemplazar “appgyver-web-app-xx-uaa” con el nombre de su instancia UAA y proporcionar la ruta correcta del directorio donde creó el archivo xs-security.json.

Se debe instalar la CLI de Cloud Foundry para ejecutar la línea de comando.

Para ver el botón de cambio, la función de administrador debe estar asignada a su usuario. Para hacer esto, creamos una colección de roles y la asignamos al usuario deseado desde la subcuenta en la cabina de BTP.

Puede encontrar los nuevos roles en Seguridad > Roles. Creamos una nueva colección de roles, como «myPackAdmin», e incluimos tanto el rol de administrador de backend como el nuevo rol de administrador de UI. asignamos esta colección de roles al usuario.

Creación de una nueva colección de roles desde SAP BTP Cockpit

Ahora, cuando inicie sesión como administrador, debería ver el botón de cambio. Puede activarlo para ver todos los registros de usuarios. Es posible que deba cerrar sesión e iniciar sesión nuevamente o probar en un navegador diferente para que se considere la nueva asignación de función.

Recuerde, en el modo de vista previa, su usuario no tendrá los roles, por lo que solo funcionará en la versión implementada de la aplicación web.

El botón de cambio aparece para el usuario administrador conectado

¡Y ahí lo tienes! Una solución alternativa simple para lidiar con diferentes roles de usuario en sus SAP Build Apps hasta que la función esté disponible de forma nativa. Espero que esta solución le resulte útil para evitar duplicaciones en la creación de la interfaz de usuario.