ACTIVAR Y CONFIGURAR EN FIORI

Para configurar de forma adecuada una aplicación transaccional se deben seguir los siguientes pasos: 1.  Activar nodo ICF 2.  Servicios Odata 3. Crear catálogo y grupo , junto con asignación de aplicaciones 4.  Creación y asignación de roles 5. Roles básicos para usar Launchpad Después del paso 4, veremos a continuación los roles y permisos básicos para poder usar el Launchpad: Rol: SAP_UI2_USER_700 Rol: SAP_S_RFCACL en backend (si el sistema no es embebido) Acceso a los roles que contengan los grupos y catálogos Acceso a los servicios oData de las aplicaciones Acceso a los objetos de autorización :  S_PBCHIP /UI2/CHIP

Cuando estamos activando aplicaciones en Fiori es muy importante conocer la teoría de catálogos y grupos y como aplicarla correctamente, así que comencemos. En los catálogos es donde residen los tiles o mosaicos de las aplicaciones como tal y en los grupos se definen las aplicaciones a las que tendrá acceso el usuario (el usuario debe tener acceso al catálogo y el grupo para poder visualizar las aplicaciones en el Launchpad). Es importante destacar que se debe tener un catálogo definido por  cada ROL. Los grupos se usan también para unir aplicaciones de grupos distintos. En un ejemplo practico, podemos ubicarnos en un estacionamiento. Los puestos serán las aplicaciones, vamos a separar los puestos por bloques: BLOQUE A, BLOQUE B, BLOQUE C. Dentro de cada bloque hay 4 filas para estacionar. Diremos que los bloques son los grupos y las filas los catálogos. Entonces si te dan un ticket que pertenece al bloque B fila 3, quiere decir que si deseas estacionarte en o...

La mayoría de las aplicaciones estándar que consisten en una aprobación por parte del usuario requieren una configuración adicional, la cual es: tarea de Workflow. El workflow hace referencia al flujo de trabajo con el que va a trabajar la aplicación, por ejemplo si se desea visualizar las ordenes que debe ser aprobadas o rechazadas, también si solo se desean ver las ordenes que ya fueron procesadas. Así que esto se usa para trabajar con el flujo de información deseado. Usaremos la referencia de implementación de la siguiente aplicación: App Implementation: Approve Purchase Orders Iremos al apartado:  Configuration Tasks -  Workflow En este segmento se especifica la ruta a seguir para poder asignar las tareas de workflow para la aplicación. Estas tareas son de personalización así que debemos ingresar en la transacción SPRO (Recomiendo ingresar en el idioma EN para navegar con mas facilidad en el menu ya que las guías  de SAP están  en Ingles) ...

     Para el uso de las aplicaciones Fiori e incluso para el manejo y acceso de la información en el sistema son necesarios los roles, ya que estos contienen los objetos de autorización que necesita el usuario para tener los accesos necesarios para trabajar en el sistema. Esto tomando en cuenta que no todos los usuarios necesitan los mismos permisos para trabajar, como es el claro ejemplo entre un usuario común y un administrador.   ¿Cómo visualizamos y asignamos roles? Fácil. Usamos la transacción PFCG.   En el campo ROL, colocaremos el rol que deseamos visualizar o crear.   Hagamos una prueba con el ROL: SAP_S_RFCACL. Seleccionamos modificar y tendremos lo siguiente:      Luego iremos a la pestaña de Autorizaciones y generamos el perfil de autorización       Para poder generar correctamente el perfil de autorización, en el apartado Actualizar datos de autorización y generar perfil ir...

     A pesar de que no es algo que debería pasar muy seguido, suele suceder que una vez que ejecutamos todas las tareas de configuración algo pasa y deben crear un backup del sistema o una copia de otro mandante. ¿Esto nos afecta? la respuesta es sí. Ahora bien, es bueno saber en que nos afecta y que no. Esto no va a afectar la mayor parte de nuestras tareas de configuración en el sistema, pero hay una que sí y es importante, es nuestra configuración para que funcionen las aplicaciones fact sheets.     Como saben, las aplicaciones fact sheets funcionan con unos conectores de búsqueda, los conectores ESH.   Para verificar los conectores usaremos la transacción de SAP ESH_COCKPIT (desde el backend).      También podemos ingresar  directamente en nuestro navegador a través de la dirección : http://<Backendserver>:<Backendport>/sap/bc/webdynpro/sap/esh_admin_ui_component?sap-language=ES#     ...

Lo que diferencia las aplicaciones fact sheets de las transaccionales es lo siguiente: En el Launchpad las aplicaciones transaccionales son mostradas con un mosaico o tile, en cambio las fact sheets son mostradas en el menú de la barra de búsqueda del Launchpad, ademas una diferencia significativa es que las aplicaciones fact sheets son solo de lectura, en cambio las transaccionales permiten: Visualizar, Modificar,  Crear y Eliminar registros. Veamos: Aplicaciones transaccionales: Aplicaciones Fact sheets: En lo que respecta al servicio ICF, asignación de roles, catálogos y grupos, es idéntica a las aplicaciones transaccionales. La diferencia radica al añadir su servicio OData. Para que el sistema cargue correctamente estos servicios OData primero se deben crear los conectores ESH, estos son los que proporcionan el modelo de datos que usan estas aplicaciones para buscar la información general en el sistema. ¿Y como se crean estos conectores? Vamos a ver los pasos...

Utiliza la lista de tareas SAP_GATEWAY_ADD_SYSTEM para conectar un sistema SAP (backend) a un sistema SAP Gateway (frontend). Esta tarea debe ser ejecutada en el frontend Pasos 1. Usaremos la transaccion STC01 2. Lista de tareas SAP_GATEWAY_ADD_SYSTEM 3. Generamos la lista de tareas 4. Antes de comenzar la ejecución de la lista de tareas, asegúrese de haber seleccionado la casilla de verificación Ejecutar para la lista de tareas respectiva y configure los parámetros en consecuencia: Verificar la autorización para el usuario actual en el Sistema SAP (Rol para usar RFC). Crear / Seleccionar solicitud de personalización (SE09) [Mantenimiento de parámetros] Crear / Seleccionar destino RFC ABAP confiable para el sistema SAP (SM59) [Mantenimiento de parámetros] Establecer parámetro de perfil: login / accept_sso2_ticket = 1 (RZ10) Establecer parámetro de perfil: login / create_sso2_ticket = 2 (RZ10) Configurar ticket de inicio de sesión para inicio de sesió...

Ayuda para solventar error de carga de metadatos al intentar generar un servicio OData CDS: Al añadir un servicio OData usando la transacción /N/IWFND/MAINT_SERVICE, si este servicio es uno CDS, es decir, que utiliza una anotación, primero debe existir el modelo de anotación para que este pueda crear el servicio, de resto vas a tener un error de carga de metadatos al intentar generarlo. Uno de los errores mas comunes es el siguiente: Solución: 1. Ejecutar transacción /N/IWBEP/REG_VOCAN 2. Crear modelo de anotación. 3. Escribe el modelo o nombre del servicio 4. Clase de anotación: /SSB/CL_SSB_RUNTIME_APC_EXT 5. Añadir descripción y continuar 6. Añadir asignación para el modelo creado y el alias de sistema. 7. Asignar el nombre del servicio técnico (OData) 8. Ejecutar IWFND/MAINT_SERVICE y ya se pueden cargar los metadatos y crear el servicio. Ejemplo: Al continuar el sistema te va a pedir un paquete de transporte, para el ejemplo, yo lo haré local. ...

Si nuestro usuario tiene un error de autorización, esto lo podemos ver usando la transacción SU53, si se tiene un error de autorización, aquí podemos ver cuales son los objetos a los que no tenemos acceso y en que ámbito. Como podemos observar, este usuario no tiene acceso a 2 objetos de autorización: - S_ALV_LAYR - S_ALV_LAYO Ahora bien, lo que debemos hacer es añadir ese objeto de autorización a un rol que posea nuestro usuario o buscar un rol general que lo tenga y asignarlo .  Hay 2 acciones que podemos tomar dependiendo de nuestra autorización en el sistema: 1. Si no tenemos los permisos necesarios para modificar roles, tendremos que hablar con el administrador y solicitar que nos de acceso a estos objetos. 2. Si tenemos el acceso para modificar roles, buscaremos un rol que tenga ese objeto y lo asignaremos a nuestro usuario, esto lo haremos de la siguiente forma (usaremos el objeto S_ALV_LAYR de ejemplo): Pasos: a. Ejecutar la transacción SUIM....

RFC de confianza Si estamos trabajando con un sistema que no es embebido, entonces tendremos el frontend y el backend en sistemas distintos. Para que exista una comunicación efectiva entre ambos, la RFC que los conecta debe ser de confianza, esto quiere decir que el backend va a confiar en las solicitudes del frontend sin pedir datos de autorización (ya que se le proporcionaron al momento de crear la conexión). El usuario con el que haremos la conexión RFC, debe tener el rol   SAP_S_RFCACL asignado (en ambos sistemas). Primero debemos crear la conexión RFC entre el frontend y backend (esto debe ser realizado desde el backend). Pasos: 1. Entrar en la transacción SM59 2. Seleccionar "Conexión ABAP" y crear una nueva conexión. 3. Asignar nombre de conexión RFC y descripción. SAP establece como mejores practicas que este nombre sea: ID de sistema destino+CLNT+Cliente al que te vas a conectar. Ejemplo: FIQCLNT100 4. Tipo de conexión: 3 4. En la...

Error en SU53: Si estamos haciendo unas pruebas y tenemos el siguiente error de autorización  para acceder al servicio OData por parte del usuario, debemos crear un rol para asignar este objeto de autorización, el cual se puede hacer de dos formas: Primero crearemos el rol: ZME2STAR 1. Agregamos directamente el objeto de autorización en forma general. Entramos en el apartado Actualizar datos de autorización y generar perfil -Modificar datos de autorización. No tomar modelos( X ). Selecionaremos la opción para a;adir manualmente un objeto: Seleccionamos el objeto que deseamos agregar Seleccionamos: Nombres de módulos de programas(para editar) Grabamos y generamos el perfil 2. Agregamos una propuesta de autorización con el nombre del servicio específicamente para ese servicio OData. Se debe crear una propuesta de autorización Importante: Revisar que el usuario este correctamente ajustado, si no es a...