Bytes tecnológicos de SAP: uso de destinos durante el desarrollo local: conceptos básicos de Cloud Foundry n.º 4
By s4pcademy
Este byte técnico de SAP trata sobre cómo consumir destinos BTP de SAP durante el desarrollo local, cubriendo destinos tanto a nivel de instancia como a nivel de subcuenta.
El código fuente de esta publicación de blog se puede encontrar en https://github.com/SAP-samples/sap-tech-bytes/tree/cloud-foundry-basics/post4.
Sobre la base de la publicación de blog anterior de esta serie «Fundamentos de Cloud Foundry», donde aprendimos cómo consumir datos usando destinos, aprenderemos cómo usar destinos durante el desarrollo local hoy. Imagine un escenario en el que desea utilizar datos de back-end reales para probar y crear su aplicación utilizando un destino SAP BTP (Cloud Foundry) existente, en lugar de simularlo todo localmente. Esta publicación de blog cubrirá dos variaciones de estos escenarios:
- En el primer escenario, estamos usando el aprobador independiente que ya creamos en la publicación de blog anterior junto con un destino de nivel de instancia.
- Para el segundo escenario estamos usando el Herramientas SAP Fiori – Herramientas UI5 y SAP Business Application Studio para consumir un destino de nivel de subcuenta en la zona.
La diferencia fundamental entre esos escenarios son los diferentes tipos de destinos utilizados. Entonces, antes de comenzar, debemos asegurarnos de comprender bien la diferencia entre los destinos de nivel de instancia y nivel de subcuenta en SAP BTP.
En esta serie de publicaciones de blog hasta ahora, hemos creado y consumido un destino a nivel de instancia, lo que significa que creamos una instancia del Servicio de destino que vive en un espacio de Cloud Foundry:
Dicha instancia de destino se puede vincular a aplicaciones independientes específicas («vinculación de aplicaciones»), por ejemplo, un aprobador, lo que permite llamar al destino desde dentro de la aplicación (consulte la información de vinculación en la captura de pantalla anterior). Por el contrario, los destinos de nivel de subcuenta se crean, como su nombre lo indica, en el nivel de subcuenta y, por lo tanto, no residen en un espacio de Cloud Foundry:
Dicho destino de nivel de subcuenta no puede vincularse a aplicaciones independientes específicas (que residen en un espacio de Cloud Foundry). Por lo tanto, el consumo de un destino de nivel de subcuenta difiere y requiere herramientas diferentes. Más sobre eso más abajo.
Para este primer escenario, estamos utilizando el aprobador independiente que ya creamos e implementamos en las publicaciones de blog anteriores. Cuando se ejecuta en la nube, podemos ver que el aprobador está sirviendo los datos de back-end a través del destino (a través de /backend).
El aprobador estaba vinculado a nuestro destino de nivel de instancia durante la implementación, ya que configuramos el atributo «servicios» en el manifiesto.yaml archivo:
---
applications:
- name: my-web-page
...
services:
...
- backendDestinationPero, ¿qué pasa si queremos trabajar en nuestra aplicación UI5 localmente y necesitamos los datos de back-end para eso? Si dónde simplemente iniciar nuestro aprobador localmente (a través de inicio de npm) obtenemos un error de «destino desconocido»:
La solución para esto es bastante sencilla, siempre que hayamos implementado previamente una aplicación que esté vinculada al destino al que queremos llamar. Simplemente tenemos que copiar las variables de entorno del aprobador desplegado en nuestro entorno local. Otra opción sería crear una clave de servicio y usar sus credenciales. Luego, el aprobador local puede conectarse al destino en Cloud Foundry. Las variables de entorno local se pueden establecer a través de un predeterminado-env.json archivo en el nivel raíz del proyecto aprobador. Podemos obtener las variables de entorno para nuestra aplicación a través de la cabina de SAP BTP (o alternativamente a través de la cf env mi-página-web dominio).:
Simplemente copie todo el objeto «VCAP_SERVICES» en el predeterminado-env.json archivo, por lo que se ve así:
Es importante nunca (¡nunca!) cometer el predeterminado-env.json archivo al control de fuente (por ejemplo, GitHub), ya que contiene secretos de clientes y otra información confidencial. Está destinado únicamente a su entorno de desarrollo personal. Por eso creamos un nuevo .gitignore archivo:
Si comenzamos nuestro approuter ahora (a través de inicio de npm) y échale un vistazo, obtenemos un extraño error de autorización:
Esto se debe a que no hemos agregado la nueva URL de nuestro aprobador (el local) a las redirecciones OAuth permitidas en el xs-seguridad.json archivo. Esto es lo que parece para mí usar SAP Business Application Studio, pero el suyo puede ser diferente (p. ej. http://localhost:5000/iniciar sesión/devolución de llamada) ya que esto depende del entorno en el que esté trabajando (asegúrese de agregar /iniciar sesión/devolución de llamada):
Después de editar el xs-seguridad.json tenemos que actualizar la instancia de servicio en Cloud Foundry para que el cambio surta efecto:
cf update-service my-xsuaa -c xs-security.jsonNota:
Hay un gran inconveniente cuando se usa este enfoque de nivel de instancia combinado con un aprobador durante el desarrollo local, especialmente cuando está creando una aplicación front-end y realiza cambios frecuentes en su código: tendrá que reiniciar el aprobador después de cada cambio que realice. Esto puede ser muy engorroso. Consulte el segundo escenario (usando destinos de nivel de subcuenta) a continuación para conocer las herramientas que pueden ayudar con eso.
Para este segundo escenario, crearemos un nuevo proyecto en SAP Business Application Studio. Podríamos usar una de las plantillas de SAP Fiori proporcionadas, pero para fines de aprendizaje me gusta recrear cosas desde cero, para que entendamos lo que hacen las piezas individuales.
Primero, movamos la aplicación existente del primer escenario fuera del camino a un directorio separado llamado approuter-local-instancia-nivel-destino. Perdón por el nombre largo, me gustan las cosas específicas y explícitas. A continuación, podemos crear una nueva approuter-local-subcuenta-nivel-destino (de nuevo, lo siento) directorio y agregar nuevo paquete.json archivo con el siguiente contenido:
{
"name": "approuter-subacc-level-dest",
"version": "0.0.1",
"scripts": {
"start": "fiori run --open \"index.html\""
},
"dependencies": {
"@sap/ux-ui5-tooling": "^1.8.6",
"@ui5/cli": "^2.0.0"
}
}La estructura de nuestro proyecto ahora se ve así:
+ approuter-local-instance-level-dest/
- approuter-local-subaccount-level-dest/
- package.jsonEn la sección de dependencias podemos ver que estamos usando tanto el Herramientas SAP Fiori – Herramientas UI5 (@sap/ux-ui5-tooling) y el Herramientas UI5 sí mismo (@ui5/cli) en nuestro proyecto. La combinación de esas herramientas es muy poderosa ya que incluyen middlewares como proxies y una recarga en vivo para el desarrollo.
La herramienta UI5 espera que las aplicaciones frontend vivan en un Aplicación Web directorio, así que vamos a crear eso. Pongamos también un minimalista índice.html y manifiesto.json archivo que contiene una aplicación UI5 dentro de ese directorio:
índice.html:
<!DOCTYPE html>
<html>
<head>
<script
id="sap-ui-bootstrap"
src="https://openui5.hana.ondemand.com/resources/sap-ui-core.js"
data-sap-ui-theme="sap_horizon"
data-sap-ui-libs="sap.m"
data-sap-ui-compatVersion="edge"
data-sap-ui-resourceroots="{
"sap.cfbasics": "./"
}">
</script>
<script>
sap.ui.require([
"sap/ui/core/mvc/View",
"sap/m/Page",
"sap/m/List",
"sap/m/StandardListItem",
"sap/ui/model/json/JSONModel"
], function (View, Page, List, StandardListItem, JSONModel) {
"use strict"
fetch("/V4/Northwind/Northwind.svc/Products")
.then(response => response.json())
.then(data => {
new View({
content: [
new List({
items: {
path: "/value",
template: new StandardListItem({
title: "{ProductName}"
})
}
})
]
}).setModel(new JSONModel(data)).placeAt("content")
})
})
</script>
</head>
<body class="sapUiBody" id="content">
</body>
</html>manifiesto.json:
{
"sap.app": {
"id": "sap.cfbasics",
"type": "application"
}
}La estructura de nuestro proyecto ahora se ve así:
+ approuter-local-instance-level-dest/
- approuter-local-subaccount-level-dest/
- webapp/
- index.html
- manifest.json
- package.jsonLa herramienta UI5 también espera una ui5.yaml en el nivel raíz del proyecto. Este es el archivo donde ocurre toda la magia. Podemos configurar el fiori-herramientas-proxy middleware que manejará la conexión al destino del nivel de subcuenta por nosotros. Lo hacemos especificando un camino y pasando el nombre único del destino – que tiene que vivir en el misma subcuenta (!) como SAP Business Application Studio que estamos utilizando. Esto también significa que otros entornos de desarrollo (como VS Code) no funcionarán con este escenario.
También configuramos el fiori-herramientas-appreload middleware para beneficiarse de las recargas en vivo del servidor UI5 cuando el archivo cambia en el Aplicación Web directorio se están detectando, lo que resulta muy útil durante el desarrollo.
Este es el completo ui5.yaml archivo:
specVersion: "2.5"
metadata:
name: approuter-subacc-level-dest
type: application
server:
customMiddleware:
- name: fiori-tools-proxy
afterMiddleware: compression
configuration:
backend:
- path: /V4/Northwind/Northwind.svc/
destination: Northwind
- name: fiori-tools-appreload
afterMiddleware: compression
configuration:
port: 35729La estructura de nuestro proyecto ahora se ve así:
+ approuter-local-instance-level-dest/
- approuter-local-subaccount-level-dest/
- webapp/
- index.html
- manifest.json
- package.json
- ui5.yamlLas propiedades adicionales son muy importantes para la conexión entre SAP Business Application Studio y el destino, así que asegúrese de agregarlas.
Actualicemos nuestra aplicación:
Genial, podemos ver los datos que se llamaron con la ayuda del destino. Observe cómo nunca mencionamos el dominio de nuestro backend (https://servicios.odata.org) en cualquier parte de nuestro proyecto. Esto demuestra que en realidad estamos utilizando el destino; de lo contrario, no obtendríamos ningún dato. Esto también significa que podríamos cambiar la fuente de datos que consume nuestra aplicación sin tocar el código de la aplicación, hablar de separación de intereses!
No dude en comunicarse en caso de que tenga alguna pregunta.
Estén atentos para más publicaciones de blog que cubren los conceptos básicos de Cloud Foundry.
SAP Tech Bytes es una iniciativa para brindarle información breve sobre todo tipo de temas, en video y escrito formato. ¡Disfrutar!
