Ampliando un OData on-prem en BAS con CAPm

Últimamente no paro de escuchar palabras como extension, cloud, side by side… todo esto nos lleva a lo siguiente, ¿como podemos ampliar nuestro OData publicado en SAP Gateway usando SAP?

Pues bien, lo primero es que cuando ampliamos un OData con CAP («para no modificar el estàndard en la parte onpremise») estamos haciendo en parte trampas. Y esto es un tema que antes de entrar en materia me gustaria desarrollar un poco.

Realmente, estas ampliaciones consisten en que nuestro CAP actuará de proxy entre nuestra base de datos cloud y on-premise, por lo que internamente lo que hará nuestro cap es replicar nuestra llamada hacia el Gateway.

Esto puede parecer poco relevante, pero cuando necesitamos cruzar datos o mover una gran cantidad de datos es un tema importante a tener en cuenta.

Y dicho esto, vamos a por nuestra ampliación.

OData on-premise

Para hacer la ampliación partiremos de un OData de los clásicos creado des de la SEGW. Para acelerar este proceso, en este caso utilizaremos un OData ya creado, el OData candidato sera el de vuelos que viene por defecto en la instalación.

Validaremos si esta publicado mediante la transacción /IWFND/MAINT_SERVICE

Lo siguiente será revisar que el OData esta publicado y extraer su metadata, para ello podemos ir al cliente instalado en el gateway.

Una vez el en cliente HTTP, realizaremos la llamada para obtener el metadata y copiaremos el contenido de este metadata en un fichero que llamaremos SampleFlight.edmx

* Truco: una vez tenemos el metadata, con botón derecho podemos guardar el fichero resultante

Ya tenemos todo lo que necesitamos de la parte backend preparada. El para el siguiente paso necesitaremos el BAS.

Creando un CAP extendido

Creando un CAP nuevo

Esta parte tiene muchas alternativas ya que podemos usar el comando «cds init» o mediante el template.

A modo sugerencia estos son los parámetros que voy a utilizar, como veis para el ejemplo tampoc lo vamos a complicar, activamos todas las opciones, aunque no son relevantes para la extensión.

Añadiendo la definición OData del servicio externo

Una vez nuestro CAP esté apunto, añadiremos el fichero descargado del Gateway en la raiz del proyecto.

Para importar la definición a nuestro proyecto ejecutaremos el siguiente comando:

cds import SampleFlight.edmx

Este es el resultado:

Como veis, el propio comando nos da la información para poder usarlo en nuestros CAP. Deberemos importar la definición tal y como se indica en el texto en verde.

Está seria la manera de añadirlo en el servicio:

Con estos pasos ya tenemos añadido el servicio. Para probarlo podemos ejecutar el comando «cds watch». Este es el resultado:

Aunque si accedemos a la API de TravelAgencies no tenemos resultados. Esto es porque de momento estamos ejecutando un modelo local.

Conectando la extensión mediante destination

Una vez tenemos nuestro CAP a punto, es momento de conectarlo con nuestro sistema on-premise. Para ello tenemos que modificar la configuración del fichero package.json:

Esta es la configuración que añadiremos, la destination y el path a utilizar:

Solo nos queda añadir la lógica para conectar al backend, para ello, crearemos un fichero nuevo en la carpeta «srv» llamado «cat-service.js». Este será su contenido:

const cds = require('@sap/cds');

module.exports = cds.service.impl(async function() {
	const { entitySet } = this.entities;
	const service = await cds.connect.to('SampleFlight');
	this.on('READ', entitySet, request => {
		return service.tx(request).run(request.query);
	});
});

En la sentencia «cds.connect.to(‘SampleFlight’);» añadiremos el alias de la CDS, lo podemos encontrar en el fichero «cat-service.cds»:

Ya lo tenemos todo, si hemos parado el comando cds watch lo volvemos a ejecutar y…

Vaya, otro error… Bueno, esto es porque con la configuración actual de nuestro BAS no podemos detectar la destination ya que no tenemos el servicio de destination bindeado.

Añadiendo la configuración de destination para BAS

Nos queda un último paso para poder utilizar la extensión en BAS. Para conseguirlo crearemos un fichero extra llamado «default-env.json» en la raíz del proyecto.

Este es el contenido que añadiremos. ¡Acordaros de no añadir este fichero en GIT ya que tendra vuestro password!

La parte inicial de la URL coincidirá con nuestra configuración en cloud connector.

Y por fin, el resultado:

---

Con estos pasos rápidos ya podremos extender nuestro backend des de cualquier sistema OData hacia CAP. Si veo que esta entrada despierta interés, seguiré con algun capitulo más

Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última. Vota Like / Dislike para aportar feedback.