¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Cómo solucionar el error de navegación en Launch Fiori App via LDP Cust - sap.ushell.renderers.fiori2.Shell.controller

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 21 Vistas
0
Cargando...

¡Hola a todos!

Actualmente estoy intentando "abusar" de la opción de mapeo de destino "Launch Fiori App via LDP Cust", que funciona para WebDynpro ABAP y Transacciones para Páginas del Portal (Tipo de Aplicación POP). Desafortunadamente, la consola de JavaScript me dice:

Modo de navegación no reconocido - sap.ushell.renderers.fiori2.Shell.controller


¿Esto en general no es compatible o hay alguna posibilidad de que esté haciendo algo mal (si es compatible, por supuesto profundizaría en lo que hice)?

La razón por la que espero que funcione de esta manera es que nuestro concepto de acceso se supone que funciona completamente a través de autorizaciones mantenidas en roles de R/3 y el Launchpad de WDA (LPD_CUST) actualmente lo permite. Queremos evitar tener que crear iViews independientes para incluir en nuestro FFP con mapeos separados a roles de R/3 redundantes desde el punto de vista organizativo (así era en los sistemas <EHP5 con el llamado "Homepage Framework" si alguien aún lo recuerda).

¡Saludos, Lukas!

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Bump. Guess my question is either very daft or very good (since it has no comments yet).


Has nobody ever come across this requirement? Or maybe I'm overlooking something obvious which renders the requirement useless? Might even be, that my design-approach itself is bonkers.


What I want to achieve : Quiero que la distribución, es decir, la visibilidad, de las aplicaciones que usamos en nuestro portal sea controlada de forma centralizada a través de autorizaciones en roles de R/3. Por lo tanto, pensé en utilizar un único rol de portal personalizado que contenga todo el contenido que los usuarios podrían tener (pero no necesariamente tienen) para nuestro contenido remoto (es decir, lo que proviene del FES en nuestro Gateway). La ventaja que veo personalmente al hacer esto es que podemos tener un rol de portal y un rol de R/3 mapeado (como ancla) como conexión técnica. Por lo tanto, cuando se agrega contenido a nuestro entorno, solo sería necesario agregar los catálogos remotos a este rol de portal único y asignar roles de R/3 dedicados que contengan la autoridad para estos catálogos (es decir, si no tienes la autoridad de R/3 no puedes ver el contenido aunque esté técnicamente disponible en el rol de portal) y, al asignar el rol de R/3 respectivo, asumiendo que se utilizan grupos, el usuario respectivo verá automáticamente el nuevo contenido (grupo con catálogos) en su portal.


What I want to avoid : Soy consciente de que el contenido remoto y el contenido de portal dedicado a través de iViews/Pages se pueden usar simultáneamente, pero con mi conocimiento actual veo los siguientes problemas: Si asigno un iView a un rol de portal, el usuario final no "tiene" automáticamente el mosaico en su FLP, es decir, tiene que ir manualmente al Explorador de aplicaciones y agregarlo a un grupo. Otra observación extraña que hice es que aparentemente esto se puede hacer independientemente de las autorizaciones en el backend, lo que significa que pude agregar un mosaico de un iView para el cual no tenía autorización en el backend. Por lo tanto, esto significa para mí que no puedo simplemente colocar todo el contenido del portal en un rol, porque los usuarios verán cosas que no deberían. Una vez más, esto significa que tendría que construir roles de portal dedicados y luego mapearlos y fusionarlos con roles de R/3 dedicados, además, probablemente, hacer fusiones de roles de portal, etc. (como era en el Framework de la página de inicio hace 10 años). Todo esto parece demasiado complicado en contraste con el Launchpad de WDA actual, donde puedo controlar todo de forma centralizada sin importar la fuente.

Cualquier pensamiento/comentario es muy apreciado. Mucha buena karma vendrá hacia ti.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Mi problema no se trata en última instancia de autorizaciones, tal vez no fui claro... es que quiero que todo mi contenido o más bien la navegación del contenido se mantenga en FLP en el FES porque entonces, posteriormente, puedo controlar la asignación de contenido de manera más "centralizada" que si tuviera contenido en el FLP y contenido en el Portal que se mantiene en iViews/Pages y que luego tengo que mezclar en un Rol del Portal con el Contenido Remoto del FES, lo que posteriormente hace que la autorización sea más complicada innecesariamente.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

La autoridad en FIORI Launchpad puede ser controlada a nivel de Grupo de FIORI Launchpad.

1. Crea grupos de Launchpad por roles comerciales.

2. Agrega tiles a los grupos respectivos.

3. Luego configura roles PFCG por roles comerciales identificados y asigna los grupos de Launchpad a los roles PFCG.

De esta manera, dependiendo del rol del usuario, los tiles aparecerán automáticamente. No debería ser necesario configurar roles de portal.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Limpiando mis hilos antiguos.

Aparentemente, el requisito no es técnicamente posible en el estándar; ahora tengo contenido solo en el FLP-designer, en el FLP-Designer y LPD-Cust y Portal Content todo mezclado en un Rol de Portal. El resultado funciona de maravilla, pero la redundancia en la parte trasera realmente es una lástima y un gran paso atrás en contraste con el Launchpad basado en WebDynpro ABAP. 😞

/hilo

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?