Vamos, ¡a darle a la tecla!

Hace unos meses os contaba que alguien me había pedido consejo sobre qué hacer para escribir un blog y yo le dí esencialmente uno: EMPIEZA.

Parece que me hizo caso, ahora viene el siguiente consejo: CONTINÚA.

Aquí os dejo su blog y otros dos, también de reciente creación, y que creo que pueden aportar cosas interesantes:

¿Qué os podéis encontrar ahí? Pues sobre todo temas relacionados con programación SAP: SAP Cloud Platform, SAPUI5, Fiori, ABAP… todo desde el punto  de vista personal de cada uno de los autores.

¿Y qué gano yo con esto? Lo mismo que vosotros: todo lo que ellos quieran aportar, ¿no os parece suficiente?

Por eso, desde aquí animo a que todo el que crea que tiene algo que aportar, a que se lance, que escriba, mejor o peor, pero que lo haga… después sólo es cuestión de ir mejorando.

Si esperas a tener todo “perfecto”, ya sabes lo que va a pasar: que nunca tendrás nada.

Ahora les toca a ellos, seguir dándole a la tecla… 😉

ABAP RESTful Programming Model: un paso más

En la entrada de ayer os comentaba que algo, con lo que es probable que ni os hayáis puesto aún, se estaba quedando ya obsoleto. Realmente, debería decir que ha ido evolucionando.

Si ayer hablaba del ABAP Programming Model, hoy escribo de algo que no es exactamente lo mismo: ABAP RESTful Programming Model.

Todo esto está muy relacionado con el anunciado ABAP en Cloud, que nos presentaron hace unos meses en el SAP TechEd y que se basa en lo siguiente:

    • Modelado (CDS)
    • Aprovisionamiento de servicios (OData)
    • Consumo de servicios (Fiori)

Entre otras cosas, en este modelo, deberíamos trabajar con las ABAP Development Tools (ADT), ya no hace falta entrar a la SE80 por SAP GUI, a pesar de la flamante versión 7.60 😉

El ABAP sigue vivo, aunque no será el de siempre, y hay que habituarse al uso de API’s y el modelado de datos con CDS.

Aquí os dejo el artículo donde hablan de todo esto: Evolution of the ABAP Programming Model

¿Y tú, te apuntas a la evolución o piensas seguir con tus ALV’s? 😉

SAP Fiori: opciones de implementación y recomendaciones

Confío en que a estas alturas ya tengáis todos más que claro que Fiori es un patrón de diseño o el nuevo paradigma de la experiencia de usuario en SAP, pero no un lenguaje de programación.

Por no repetirme, os remito a un artículo publicado hace año y medio: SAPUI5, OData y Fiori: pongamos un poco de orden.

Precisamente, echando la vista atrás me acordé de que en artículo en el que hablaba de la compra de Qualtrics por parte de SAP, planteé una breve encuesta utilizando la herramienta y no había compartido los resultados.

Era sólo una pregunta  (“¿Sobre qué te gustaría que escribiera en próximos artículos?”) y este fue el resultado:

Y en ello estoy, de ahí que hoy toque hablar un poco de Fiori, en concreto de las opciones de implementación que tenemos a día de hoy.

Supongamos que tenemos un backend del que queremos extraer información para consumir aplicaciones Fiori, tendríamos estos 3 escenarios posibles:

  • SAP Fiori embebido: el frontend estaría el mismo servidor que el backend.
  • SAP Fiori hub: el frontend estaría en un servidor dedicado.
  • SAP Fiori Cloud: utilizaríamos el servicio de SAP Cloud Platform y el Cloud Connector para comunicarnos con el backend.

En cualquiera de estas opciones, los procesos de negocio residen en el backend y lo único en que difieres es en la ubicación de las aplicaciones Fiori y el propio SAP Fiori Launchpad (FLP), que será el punto de acceso único a las aplicaciones.

¿Por qué elijo una opción u otra? Hay distintos criterios, pero aquí tenéis alguno:

  • Si tengo distintos backends que no sean S/4HANA, de los que quiero consumir datos: SAP Fiori embedido.

  • Si tengo un sistema S/4HANA (que ya trae la parte Fiori incluida siempre) y otros anteriores: SAP Fiori embebido.

  • Si añadimos un nuevo sistema S/4HANA al escenario anterior: SAP Fiori embebido.

  • Si tengo múltiples sistemas S/4HANA, puedo utilizar el propio los que vienen en el propio sistema: SAP Fiori embebido.

  • También es cierto que en el caso anterior, podría optar por tener un sistema para centralizar el acceso a los distintos FLPs que hay por detrás: SAP Fiori hub.

  • Si no quiero complicarme con la parte de infraestructura y me valen las aplicaciones Fiori que me ofrece el servicio, la opción sería SAP Fiori Cloud.

Evidentemente, aparte de decidir esto, después hay que ver cómo intercambiamos esa información entre el backend y el frontend, donde ahí tendríamos que hablar de gateway, OData y cosas así, pero de eso ya os cuento algo otro día.

Aquí os dejo un gráfico con las opciones:

Aparte de lo comentado, es evidente que cada una de las opciones tiene sus ventajas y sus inconvenientes, y podéis encontrar toda esa información aquí: SAP Fiori Deployment Options and System Landscape Recommendations (January 2019, Version 2.2)

Confío en que seáis más disciplinados que Bart y os hayáis aprendido la lección… 😉

SAP Fiori 3.0: próximamente en sus pantallas

Ayer os hablaba de SAP Insider y realmente llegué a esto revisando una presentación del último SAP TechEd celebrado en Las Vegas en 2018, concretamente esta: LT144 – SAP Fiori 3

Ahí podéis ver un vídeo de 20 minutos en el que nos cuentan la evolución que ha tenido Fiori desde su creación, allá por 2013, hasta ahora: Fiori 2.0 ha muerto, ¡viva Fiori 3.0!

Lo cierto es que mucha información no hay. De hecho, si vas a la página oficial de SAP, de momento, hace referencia a Fiori 2.0: SAP Fiori UX

Imagino que a lo largo de 2019 se hará el lanzamiento oficial, pero de momento os cuento alguna de las características, que podéis ver en el vídeo de la sesión:

  • Se han tenido en cuenta distintas aplicaciones, para definir el nuevo diseño.

  • Diseño armonizado, posibilidad de estructurar la información, posibilidad de generar contenido tanto estático como dinámico, uso de patrones de diseño…

  • Diseño consistente, con una gestión simplificada de los patrones de colores y fuentes.

  • Unificación del shell, para no tener distintos diseños por aplicación, permitiendo configurar la forma de navegar. Uso del CoPilot, acciones específicas por producto y posibilidad de saltar de un producto a otro.

Yo que tú me iría enterando de qué va todo esto, antes de que llegue Fiori 4.0… 😉

SAP Fiori Launchpad te simplifica la vida

Olvídate de navegar por carpetas y de acordarte de raros nombres de transacciones. Sí, ya sé que estás acostumbrado a eso, pero es que eso que pregonas de “la gestión del cambio” también va contigo… 😉

Como ya he comentado alguna vez, SAP Fiori Launchpad debería ser la puerta de acceso a cualquier aplicación SAP en el futuro más inmediato. Es decir, ayer.

Y para ello, aquí te dejo algunas pistas para que lo configures:

Básicamente, se trata de aplicar el sentido común y seguir reglas del tipo:

  • Muestras sólo las aplicaciones que necesitas habitualmente: ¿o eres de los que tienes el escritorio de Windows lleno de iconos?
  • Organiza las aplicaciones de manera coherente: utiliza los grupos y ponles títulos significativos.
  • Deja que el usuario personalice su pantalla: por muy intuitiva que te parezca la que has diseñado por defecto, cada uno tenemos nuestra forma de organizar la información; además, siempre hay la posibilidad de deshacer los cambios y volver a la original.

Y recuerda que no todo tiene que estar en la página de inicio, también tenemos el buscador de aplicaciones y el menú de navegación.

Estos consejos y algunos más, los podéis ver en el artículo original: SAP Fiori Launchpad – Setting Up the Right Environment

Y no, por favor, no vengáis con cosas del tipo: “es que para tener esto, tenemos que tener HANA”… que no sería la primera vez que lo oigo… 😉

10 afirmaciones sobre Fiori y S/4HANA sin fundamento

Hay gente a la que le gusta hacer las cosas siempre con fundamento, pero no siempre es así y vamos a ver una serie de cuestiones sobre Fiori y S/4HANA, que quizás hayas oído en alguna ocasión.

Puedo usar S/4HANA sin SAP Fiori.

Poder, puedes, pero ¿debes? Ni “todo en S/4 es Fiori”, como han dicho algunos, ni “te recomiendo que no hagas nada con Fiori, que es muy difícil”, que han dicho otros.

Todo lo de SAP Fiori y SAP S/4HANA UX viene activo de fábrica y/o la activación de SAP Fiori es una tarea puramente técnica.

Sí, por supuesto, sólo es cuestión de meter “diskettes” y darle a “siguiente”… 😉

Hay una aplicación SAP Fiori para cada transacción SAP GUI.

Una no, dos. De verdad, ¿sigues pensando que esto es lo mismo de siempre pero en “azulito”?

Las aplicaciones de SAP Fiori deben tener todas las características de las transacciones de SAP GUI equivalentes.

Por supuesto, que sea todo igual, que la tecnología no ha cambiado apenas en los últimos años…

El uso del Fiori Visual Theme convierte las transacciones SAP GUI y las aplicaciones Web Dynpro ABAP en aplicaciones SAP Fiori.

Sí, no te preocupes, no tienes que modificar/adaptar nada, sólo contratar buenos profesionales que te den una mano de pintura en tus sistemas.

Todo lo que tenemos que hacer es seleccionar las aplicaciones disponibles y es responsabilidad del usuario organizar su página de inicio.

Efectivamente, pongamos todo en el Launchpad y que el usuario se busque la vida…

Todo se ejecutará en dispositivos móviles sin ningún esfuerzo adicional.

Claro, hombre, puedes instalar SAP en una Gameboy…

Los desarrolladores de Fiori de Business Suite o Suite en HANA están listos para desarrollar en SAP S/4HANA.

Eso no hace falta ni decirlo, un desarrollador debe saber manejar a la perfección: ABAP, BSP, SAPScript, Adobe Forms, Web Dynpro Java, Web Dynpro ABAP, SAPUI5, OData, Gateway, Javascript, Fiori..

HANA significa no tener que hacer nunca ajustes de rendimiento.

Claro, claro, como está todo en memoria y es todo infinito y baratísimo, sólo es cuestión de echar más “madera”…

Train GIF - Find & Share on GIPHY

La experiencia del usuario es una parte menor y/o técnica de un proyecto SAP S /4HANA.

Esto y las autorizaciones, déjalo siempre para el final, que no tiene ninguna importancia. Nadie se ha estrellado por eso…

…………………………………

Bueno, si no os han convencido mis “sesudas” explicaciones, aquí os dejo un artículo donde lo cuentan desde otro punto de vista: Fiori for S/4HANA – Top 10 Myths & Misconceptions to Avoid

En el artículo os lo dan todo ya cocinado, sólo os queda añadir un poco de perejil y listo 😉

SAP Fiori Overview Pages

Hace año y medio cuando se empezó a hablar del concepto de Fiori 2.0 aparecieron las Overview Pages, que son algo más que “esas páginas chulas”, como dicen algunos…

Utilizando distintos tipos de componentes, de los llamados SAP Fiori Elements, podré construir estas páginas, que me presentan la información dentro de un contexto y de manera intuitiva para el usuario, pudiendo además navegar para consultar el detalle de la misma.

En este video podéis ver un ejemplo de una Overview Page:

En una próxima entrada, veremos cómo crear una, pero de momento os dejo con un enlace donde podéis encontrar las que hay disponibles, a día de hoy en la Fiori Apps Library, para las distintas versiones S/4HANA: aplicaciones estándar Fiori con Overview Page

Evidentemente, antes de ponernos a crear una, habría que revisar si ya existe algo parecido a lo que necesito, ¿no? 😉