Y es que esto no es "asignar una url y punto, tirando millas". Tenemos que seguir una serie de pasos: Crear el tile que se muestra, crear el target mapping que determina la aplicación y guardar en algún sitio la ubicación de la aplicación a ejecutar. Ojo, que no tiene por qué ser en ese orden, pero lo explico así porque parece más natural, aunque a la hora de hacerlo se haga al revés.
Y "ese sitio para guardar la ubicación" no es ni más ni menos que el launchpad del front-end (o rampa de lanzamiento), la transacción LPD_CUST. Ojo, no confundirlo con el Fiori Launchpad porque no tiene nada que ver aunque tenga el mismo nombre. El Launchpad es el "García" de SAP.
La configuración mediante la LPD_CUST
Esta es la configuración tradicional, aquella con la que nos hemos peleado siempre. No entraremos en detalle, porque esto es muy básico y el objetivo es otro, pero hagamos un breve resumen.
Lo primero que tenemos es el tile, con la correspondiente navegación por intención (mediante un objeto semántico y una acción). Esto no nos cambia en ninguna de las dos configuraciones mencionadas en este post.
Después tenemos el target mapping, que está atento a que se solicite esa "navegación por intención" para ver qué aplicación carga.
¿Y cómo determina el target mapping la aplicación? Consultándolo en la LPD_CUST.
Para ello, dentro del target mapping indicamos el launchpad (transacción LPD_CUST) dónde está guardada la información de la aplicación. Así que, básicamente con este método, el target mapping no sabe "qué aplicación se ejecuta" sino que sabe "dónde buscar la aplicación que se ejecuta".
Los parámetros son:
- Launchpad Role y Launchpad Instance para saber qué entrada de la LPD_CUST tiene que leer.
- Application Alias para buscar, dentro de ese launchpad, la aplicación que tenga este alias asignado.
 |
| Que el Launchpad Role se llame "Role" no tiene nada que ver con autorizaciones... ya le podían haber puesto otro nombre, que luego uno siempre tiene que estar explicándolo |
Con esa información nuestro target mapping ya sabe dónde tiene que buscar:
La configuración sin LPD_CUST
Pero ahora vamos al objetivo del post, que me enrollo más que Deadpool rompiendo la cuarta pared. ¿Por qué narices tenemos que guardar las cosas en la LPD_CUST? ¿No sería más sencillo guardarlo en el propio target maping?
Esto viene de antiguo... ojo, que decir "esto viene de antiguo" de una tecnología de 4 años tiene su tela. Está claro que se necesitaba un sitio donde guardar las apps. Y como la LPD_CUST ya estaba ahí (que ha sido muy útil para el Employee Self-Service y el Manager Self-Service en Web Dynpro ABAP, por mencionar algo), pues supongo que se decidieron a aprovecharla.
Pero, a partir del SAP UI Add-On 2.0 (la librería de SAP UI5 de la 1.30 para arriba), para nuestro Fiori Launchpad ya podemos configurar el target mapping sin necesidad de usar la LPD_CUST.
Simplemente, al crear el target mapping, en el desplegable Application Type elegimos la opción "SAPUI5 Fiori App". Ahora nos olvidamos del launchpad e indicamos los dos siguientes parámetros:
- URL: Para indicar la url relativa de la aplicación, incluyendo el path que siempre asigna SAP para sus aplicaciones SAP UI5: /sap/bc/ui5_ui5/sap/<nombre_de_la_app>.
- ID: Para indicar el nombre del componente, que podemos descubrir en el código del Component.js. en el declare (quitándole el .Component del final).
Así que si nos creamos un tile y un target mapping sin pasar por la LPD_CUST... ¿realmente funcionará?
 |
| La aplicación Ejemplo 1 no está configurada con la LPD_CUST |
Pues sí, parece que funciona.
Ojo, que esto nos vale no sólo para las aplicaciones SAP UI5. También tenemos una entrada para poder configurar Web Dynpros, URLs y transacciones sin tener que recurrir a la LPD_CUST. En estos casos, si el back-end es distinto del front-end, nos tocará crearnos una RFC de tipo H que usaremos después como System Alias. Su nombre será <System_Alias>_HTTP o <System_Alias>_HTTPS, según corresponda.
Una pregunta, cuando configuramos sin LPD_CUST en la url /sap/bc/ui5_ui5/sap/ se debe subir la aplicacion primero? no entendi eso, yo hice mi aplicacion en eclipse pero no se como hacerle deploy :/
ResponderEliminarLa configuración de este post se hace en el SAP front end, así que efectivamente la aplicación debe estar desplegada.
ResponderEliminarPara desplegar con eclipse hay una opción, es un post que tengo pendiente hacer :(
Hola luego de varios intentos si pude hacerle deploy a mi aplicacion que consume odata pero lo que estoy haciendo ahora es cambiar un poco la estructura porque yo tenia mi odata programado en el front end y me dijeron que por cuestion de performance es mejor hacerlo en el backend y ya el resto seria igual
EliminarSí, si tienes front-end y back-end en dos entornos distintos, la aplicación va al front-end pero el odata se programa en back-end. Al fin y al cabo, los datos maestros los tienes en back-end, no puedes consultarlos desde front-end. Lo que pasa es que te creas una conexión en el Gateway del front-end para poder consultar tu oData del back-end
EliminarFront-End => Aplicación + Alias en el Gateway apuntando al back-end + Exposición de servicio oData remoto (creado en back-end)
Back-End => Programación del oData
Buenas tardes, donde podría consultar cuales son las autorizaciones a nivel de usuario que necesita un tile, me explico anteriormente consultabamos que usuarios podían ingresar a una transacción directo ya que el acceso antes era solo por backend normal, ahora con los tile, catalogos etc, como es posible verificar que si un usuario puede acceder a esa misma transacción desde fiori ? Gracias
ResponderEliminarLas autorizaciones de negocio se tienen que asignar en el backend. En el frontend donde tengas Fiori, lío que asignas es el catálogo con las aplicaciones (roles) oportunas, y lío haces a través de un rol de la pfcg (el catálogo se indica en la pestaña de menú, con una entrada de tipo Fiori Catálog, pero no es necesario crear nada en la pestaña de autorización), y eso va a darle acceso al tile en el Launchpad. Aparte de eso, posiblemente también tendrás que asignar una autorización para acceder al servicio oData que devuelve los datos (a través de otro rol en la pfcg), pero sólo para acceder al propio servicio oData, los datos que proporciona ese servicio oData ya habrán sido previamente revisados por la autorización sobre los datos de negocio que hemos dicho al principio.
Eliminar-Accedes al tile.
-La aplicación ve que tienes autorización sobre el servicio oData y hará la consulta en backend.
-En backend se determinan los datos que has solicitado (con tus autorizaciones de negocio) y devuelve esa información al front-end mediante el servicio oData.
En la Fiori library apps siempre te indica los roles pfcg estándar disponibles para cada aplicación que puedes usar como partida para tu propia configuración.
Como es la relación entre una url(aplicación)front-end, transacciones y objetos de autorización del backend.
ResponderEliminar