Si no sabes lo que es la navegación OBN, no te preocupes, que te lo voy a explicar rápidamente. De momento, no estamos en Fiori, sino en SAP Portal o en NetWeaver Business Client (NWBC). Pero luego más adelante vamos a ver qué tiene esto que ver con Fiori.
La navegación OBN (Object Based Navigation) consiste, básicamente, en determinar qué aplicación se abre mediante dos elementos: Un Business Object y una acción.
Lo que tendremos será una aplicación o iView origen, que mediante código hace la llamada OBN, y otra aplicación o iView destino, que habremos configurado para que esté escuchando esa llamada y, cuando se produce, ¡zas!, se abre.
¿Y para que sirve? Para poder crear múltiples configuraciones de una misma aplicación Web Dynpro y, dependiendo de quién la abra, se cargara una u otra. Eso lo determinaremos mediante los roles que tenga el usuario asignado. Cuando se produce la navegación OBN de la primera aplicación, buscamos entre los roles del usuario qué aplicación está configurada para abrirse con esa llamada.
Para poner un ejemplo real, existe una aplicación de HCM donde podemos hacer las evaluaciones del desempeño de nuestros empleados. La aplicación inicial tenemos el listado de todos nuestros minions, con el estado actual de las calificaciones (en planificación, en revisión, finalizada...). Si pulsamos sobre uno de los empleados, se nos abre otra aplicación con la evaluación del desempeño específica de ese empleado.
Yo tengo mi listado de empleados a evaluar. En mi caso, sólo tengo un lacayo, ¡pero menudo lacayo! Cuando pulso sobre uno de ellos, me sale el documento para evaluarlo |
Es ahí, cuando pulso sobre un empleado para que me salga su calificación, donde se está haciendo la llamada OBN. Se mirará entre nuestros roles para ver qué iView/aplicación se ha configurado para abrirse tras esa llamada. Así que podemos crear dos o más roles distintos, uno para cada tipo de manager, para abrir configuraciones diferentes.
¿Pero esto que tiene que ver con Fiori?
Vale, ahora hagamos un flashback, como si estuviésemos en el pueblo de Amanece que no es poco, y revisemos el post de los palabros de Fiori, en la parte en la que explicamos los target-mappings y los tiles, a ver si nos resulta conocido.
Y es que la navegación por intención que usa Fiori (mediante objeto semántico y acción) funciona igual: Hacemos una llamada al pulsar el tile y buscamos el target-mapping que escucha dicha llamada.
Pues vamos a ver si, tras todo este discurso, podemos simular esa funcionalidad en Fiori. En la versión on-premise, hoy no nos toca pasearnos por la nube.
Para ello, vamos a construir lo siguiente:
- Una aplicación que muestra un texto, que depende de un parámetro que le pasaremos en la URL.
- Dos catálogos, con un target-mapping cada uno que llame a esa aplicación. Ambos target-mapping usan la misma navegación por intención, pero le pasarán un valor distinto al parámetro de la aplicación.
- Un catálogo con un tile que hace la llamada a la navegación por intención.
- Tres roles PFCG, uno para cada catálogo. Todos los usuarios tendrían el catálogo que tiene el tile y sólo uno de los roles que tienen un target-mapping.
Podríamos hacerlo de otra manera (por ejemplo, que cada target-mapping lea una entrada distinta en la LPD_CUST), pero me ha apetecido hacerlo así. La idea de la práctica sería la misma, y además aprendemos a recuperar parámetros de entrada.
Así que manos a la obra, vamos paso por paso.
Aplicación SAP UI5
Para el ejemplo nos creamos una aplicación sencilla. Sólo vamos a visualizar un texto en pantalla, que será "Mi nombre es...". El nombre es un valor que se lo vamos a pasar como parámetro URL.
El controlador recupera los parámetros de inicio y busca uno llamado nombre. Lo asignamos a un modelo de datos y lo enlazamos a la vista. Aquí podemos ver de qué iba esto del binding.
Y tras esto, lo desplegamos en nuestro servidor SAP.
Creando los target-mappings
Creamos un catálogo de ejemplo, al que le asignamos un target-mapping. Yo me creé el objeto semántico ZExample y, como acción, saludo. Si no te quieres crear un objeto semántico para esto, siempre puedes usar uno estándar e inventarte la acción. Total, es una prueba.
Sólo nos interesa el primer target-mapping, el "Saludo" |
Configuramos el target-mapping para que ejecute la acción correspondiente, llamando a la aplicación que nos hemos creado.
Además, le pasamos un parámetro llamado nombre con un determinado valor, 'Iñigo Montoya'. Ya sabéis, el magnífico espadachín al que le habían matado al padre.
Después, creamos un segundo catálogo y le asignamos un target-mapping exactamente igual.
La única diferencia es que el parámetro que le vamos a pasar es distinto, "Bond, James Bond".
Crear el tile
Para el tile, nos vamos a crear otro catálogo y le asignamos un único tile, que hará la llamada que habíamos configurado en nuestros target-mappings, ZEXAMPLE-saludo.
Roles en la PFCG
Para asignarnos las aplicaciones, nos creamos tres roles en la PFCG, uno para cada catálogo. Y le asignamos a nuestro usuario el rol con el catálogo del tile y el rol con el catálogo del primer target-mapping.
Y listos
Abrimos el portal, donde vamos a encontrar nuestro bonito tile, y lo pulsamos.
¿Y qué tenemos? Al espadachín presentándose.
Pero si cambiamos el catálogo que tenemos asignado y nos ponemos el segundo catálogo, cuando abramos la aplicación, será el agente secreto menos secreto del mundo en que nos saludará.
Y eso es todo. Efectivamente, el funcionamiento de los tiles y los target-mappings es el mismo que el de la navegación OBN. Esto nos va a permitir poder asignar los mismos tiles, pero abriendo diferentes configuraciones de aplicación, dependiendo de los roles que tengamos asignados.
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.