viernes, 11 de noviembre de 2016

Fiori para programadores con muy poco tiempo I

Aprendiendo Fiori

En internet hay una ENORME cantidad de recursos para aprender Fiori. Voy a intentar resumir en una serie de entradas en este blog los conceptos más importantes, de manera concisa y práctica.

Es difícil encontrar una definición concreta de que es exactamente SAP Fiori. Si buscamos por internet encontraremos gran cantidad de documentación que puede llegar a confundirnos un poco. Pero toda esa documentación podemos resumirla en lo siguiente:
  • SAP Fiori es el nuevo concepto de SAP para su interfaz de usuario:
    • Es un cambio importante en el que se modifican muchos términos. El más llamativo es el concepto de "Interfaz de Usuario" (En inglés "Graphic User Interface" o GUI) que ahora pasa a llamarse "Experiencia de Usuario" (En inglés "User eXperience" o UX). Por eso nos encontramos por todas partes la expresión "SAP Fiori UX"
  • SAP Fiori UX se compone de:
  • Aplicaciones con tecnología Fiori:
    • Aunque todo el mundo habla de "Programar en Fiori", este concepto es incorrecto. Las aplicaciones con tecnología fiori se desarrollan usando tres tecnologías:
      • HTML5 + CSS para la interfaz de usuario
      • Java Script para la lógica de la aplicación
      • jQuery para las interfaces de datos
      • A estas tres tecnologías, usadas conjuntamente, SAP las denomina SAPUI5
      • SAP ha creado una librería hecha en y para HTML5 (y CSS y javascript) con componentes (botones, etiquetas, layouts, etc.) que podemos usar en nuestras aplicaciones. Esa librería se conoce como SAPUI5. (Muchas gracias al gurú de Fiori que me ha comentado este pequeño error)

Primeros Pasos

SAP nos brinda una oportunidad excelente para aprender tecnología Fiori SAP HANA Cloud Platform, developer edition.

Comenzaré creándome un portal Fiori:





Una vez creado el portal, usando las herramientas de contenido, podríamos crear catálogos, grupos y roles adicionales (ya hablaré en otras entradas más adelante que son esas cosas) pero por ahora simplemente usaremos los de ejemplo que aparecen ya creados por defecto (Sample Catalog, Sample Group y los roles Anonymous y Everyone).

Para que el portal esté disponible tenemos que publicarlo:




Primera aplicación fiori

Desde el SAP Web IDE voy a crear mi primera aplicación FIORI:




En otras entregas entraré más en detalle de que ficheros se han creado, para nuestros primeros pasos me limitare a modificar un texto en un fichero que personalizará el texto que muestra la aplicación:


Guardamos y procedemos a desplegar la aplicación en HCP



Una vez desplegada, tenemos la posibilidad de registrarla en el portal FIORI creado previamente:




Podemos modificar su título, el icono y otras propiedades



Y por fin, seleccionamos el portal, catálogo y grupo en el que queremos publicar nuestra aplicación:


Puede ser un buen momento para guardar el código fuente en su propio repositorio Git.

Ejecutando nuestra primera aplicación

Vamos a nuestro portal:



Y pulsando es nuestra aplicación la ejecutamos:


Y para ser nuestra primera aplicación Fiori, yo creo que ya hemos hecho bastante.

viernes, 4 de noviembre de 2016

Repositorio Git remoto

Aplicaciones HTML5 y repositorios Git en HCP

En HCP tenemos un repositorio Git centralizado donde mantener una gestión de nuestras aplicaciones HTML5:

Tenemos tres opciones para crear un nuevo repositorio:
  • Crear uno directamente con el botón "New Repository"
  • Crear una aplicación HTML5 desde la sección "Applications"
  • Crear una aplicación HTML5 desde el WebIDE y luego hacer un deploy de la misma a HCP.
Veamos esta última opción:


  • Desde WebIDE creo una aplicación (MUY IMPORTANTE: No podemos inicializar el repositorio Git hasta después de hacer el deploy a HCP. De otra manera será prácticamente imposible conseguir vincular el repositorio Git local y el remoto) y en el momento que quiera, simplemente hago un deploy:



  • Si ahora acudimos a los repositorios HCP:

Los repositorios HCP tienen un URL que es el que nos permitirá poder usarlos en un entorno remoto para que diversos equipos puedan participar del desarrollo de la aplicación (Que es el propósito de los repositorios Git)


Si vamos a la URL del browser del repositorio veremos que hemos hecho el deploy de nuestra aplicación, y por lo tanto la aplicación como tal estará en HCP, pero no así sus fuentes. Es el momento de hacer un push de las fuentes al repositorio remoto. Para ello inicializamos el repositorio Git y lo vinculamos con el repositorio remoto:


Para que se cree el enlace entre la aplicación que está en HCP y sus fuentes, tenemos que hacer un fetch:


Realmente no traemos nada, porque el repositorio estaba completamente vacío. Pero esta acción crea el vinculo entre el repositorio remoto y el local. Para Git, aunque no hayamos traído nada, existen en nuestro espacio de trabajo cambios del repositorio remoto y cambios del local. Antes de poder mandar cosas al remoto tenemos que hacer un "merge":




Ahora simplemente metemos todos los ficheros en el stage y hacemos un "commit and push" lo que llevará los fuentes al repositorio:


Puede que tengamos algún error de que falten ficheros obligatorios o algo de la configuración, pero si queremos seguir adelante bastará con seleccionar el botón "Push" y después seleccionar sobre que rama queremos hacer el push.

Una vez finalizado el Push podremos ver en el repositorio remoto nuestras fuentes.

Clonando un repositorio externo

Supongamos que tenemos que trabajar en una aplicación que ya ha creado otro y ha guardado en su correspondiente repositorio Git (o bien hemos optado por las otras dos opciones posibles para crear un repositorio remoto). Lo primero que tenemos que hacer en nuestro entorno de desarrollo es clonar el repositorio Git remoto:


El usuario y la contraseña serán necesarios si nos queremos conectar a un repositorio que no sea en de nuestra propia HCP
Cuando clonamos un repositorio, WebIDE nos creara un fichero gitignore con los ficheros del sistema que recomienda ignorar en la gestión de versiones. Automáticamente nos recomienda hacer un commit y push de ese fichero al repositorio remoto. Podemos hacerlo mas tarde si queremos. Si en el repositorio remoto ya existe ese fichero es posible que nos haga esta pregunta.

Cuando clonamos un repositorio remoto tenemos que recordar:
  • Fetch nos traerá los últimos cambios del "head" del repositorio remoto
  • Merge nos mezclara los cambios del repositorio remoto con los nuestros (pueden existir conflictos que haya que arreglar manualmente)
  • Push llevará nuestros cambios al repositorio remoto
A fecha de hoy (31-Octubre-2016) WebIDE y HCP Git Repository no permiten la creación de ramas en el repositorio remoto. Por lo que podremos crear ramificaciones locales en el WebIDE pero todos los push irán a la rama principal del remoto. Aunque supongo que usando unc liente remoto de Git podremos crear ramas adicionales en el repositorio HCP e incluso hacer merge de las mismas (Pero es solo una suposición, no lo he llegado a probar)

Hacer un push no implica que llevemos la aplicación a HCP, si no que solo subiremos las fuentes. Para llevar la última versión a HCP tendremos que hacer un deploy.

Y con esto doy por terminada mi aventura con el repositorio Git (al menos por ahora...)