Modelo de datos virtuales para API de oData: eso es lo que necesita como desarrollador con SAP Cloud SDK (javascript)
By s4pcademy
Quiero usar los resultados de mi seguimiento con los comentarios combinados que recibí para publicar más inspiraciones y ejemplos sobre SAP Cloud SDK (para javascript) porque mientras tanto veo SAP Cloud SDK dentro de su Virtual Data Model (VDM) como esencial para ¡Cada proyecto de nodeJs (o java) en BTP!
La implementación de aplicaciones/microservicios de nodeJs es la forma óptima de realizar la codificación personalizada requerida en el contexto de los proyectos de SAP Cloud al no utilizar herramientas sin código/de código bajo (p. ej., CPI).
La mayoría de las aplicaciones de nodeJs que vi dentro del contexto de SAP y BTP tenían módulos (de nodo) como «axios” en uso para realizar solicitudes REST HTTP asíncronas para enviar a sistemas como S/4 HANA.
El uso de SAP Cloud SDK para estos fines hace la vida más fácil, ¡especialmente la vida de nosotros, los desarrolladores!
El SDK, combinado con las API REST de oData descritas y estructuradas, nos permite realizar modelos de datos virtuales y simplificar y acelerar nuestras implementaciones 🙂
Los datos, por ejemplo en S/4 HANA, se almacenan en estructuras y tablas complejas y abstractas. Por lo tanto, en ABAP usamos los objetos de datos y modelos provenientes del diccionario de datos (DDIC) para lidiar con esta complejidad.
Con capacidades de dominios de datos y tipos de datos, pudimos saber más sobre los parámetros utilizados en las estructuras.
Entonces, por ejemplo, sabemos que el tipo de datos «BUKRS» tiene una longitud máxima específica (4 caracteres) y puede contener cualquier carácter.
Este tipo de detalles, disponibles en los sistemas SAP, queremos mantenerlos disponibles.
Como HANA está usando el Modelo de datos virtuales (VDM) para reflejar las estructuras abstractas y complejas del EDM de manera semántica, vamos a hacer y usar lo mismo con SAP Cloud SDK en nuestra aplicación TypeScript de nodeJs (o dentro de las aplicaciones Java, si está interesado en usar Java, echa un vistazo esta publicación por Henning Heitkoetter)
Porque no tiene sentido tirar información detallada útil sobre los parámetros suministrados en una API oData 😉
Entonces, el VDM (generado) será una representación de objeto de nuestro servicio oData, en mecanografiado, este es un cliente de tipo seguro.
Es realmente útil mientras se desarrolla la aplicación en sí. Le proporciona un montón de capacidades que le encantarán como desarrollador:
-
Escribirás menos código (repetitivo)
-
Agilizarás tu implementación (debido a los tipos existentes)
-
Recibirá advertencias (por ejemplo, por errores tipográficos) durante la implementación/tiempo de desarrollo en lugar de durante el tiempo de ejecución
-
Es fácil generar estos VDM/clientes con seguridad de tipos usando archivos EDMX (metadatos) (o archivos swagger)
Ejemplo de caso de negocio: Obtenga todos los proveedores relacionados con el código de empresa «DE01».
Eso es enfoque estándar «axios» sabemos:
Concatenamos la URL a nuestro sistema S/4, con funciones de nombre de entidad, filtro y expansión. Estamos usando «axios» para enviar la solicitud HTTP a S/4 y recibir a cambio datos json no estructurados.
La URL es una cadena simple, por lo que los errores tipográficos no serán visibles durante el tiempo de desarrollo y, en su lugar, se producirán durante el tiempo de ejecución.
El enfoque SDK:
Dentro de un «requestBuilder» vamos a obtener las entidades «getAll» dentro del filtro que agregamos. Al final, lo ejecutamos contra un destino que obtuvimos de BTP Destination-Service y recibimos un objeto estructurado de S/4.
Esto se ha escrito en cuestión de segundos, porque el VDM generó un SDK-Client y podemos implementarlo dentro del entorno de escritura segura.
La ayuda de búsqueda (aquí está en VS-Code) muestra las propiedades existentes de «supplierCompanyApi» y nos permite seleccionar la correcta de inmediato:
Además de eso, recibimos advertencias si tenemos algunos errores tipográficos (aquí: falta el guión bajo) dentro de nuestra codificación:
¡Esto es posible gracias al uso del VDM! Como la API de oData estructurada nos proporciona detalles sobre las propiedades disponibles y sus tipos.
Además del esfuerzo de ahorrar tiempo mediante la implementación más rápida de nuestras solicitudes de oData utilizando el VDM, hay más.
Tal vez ya identificó el mayor esfuerzo de todo eso en las capturas de pantalla anteriores:
public async getCompanySuppliersAxios(companyCode: string):Promise<any>{contra
public async getCompanySuppliers(companyCode: string):Promise<Array<vdmBuPa.SupplierCompany>>{¡Se trata del tipo devuelto de la función!
El consumidor de la primera función «getCompanySuppliersAxios» no sabe qué devolverá la función (además del hecho de que es una promesa). Podría ser algunacosa.
El consumidor no puede usar el esfuerzo que sale de los tipos, ya que no hay tipos definidos y relacionados con el retorno de la función:
El consumidor de la segunda función «getCompanySuppliers» sabe lo que puede esperar: una matriz de la entidad «SupplierCompany» del VDM «vdmBuPa».
Por lo tanto, conoce el tipo que recibimos y, por lo tanto, las propiedades se pueden seleccionar a través de la ayuda de búsqueda:
Vimos algunos beneficios de usar un VDM dentro de SAP Cloud SDK.
Pero el SDK nos brinda más capacidades:
Dentro del SDK de la nube y su adopción del modelo de datos virtuales, SAP proporciona funcionalidades y capacidades a los desarrolladores para que utilicen fácilmente los beneficios de las API de oData estructuradas.
En mi último proyecto, configuramos más de 30 clientes VDM diferentes, que alojamos en AzureDevOps como Artefactos (si lo desea, es como un «npm privado»). Configuramos varias canalizaciones de CI/CD para actualizar automáticamente los VDM si se cambia una API oData relacionada. Estos VDM no solo apuntaban a los sistemas S/4 HANA, sino que también se utilizaron dentro de las instalaciones R/3 onPremise y las aplicaciones CAP que se ejecutan en BTP.
Este enfoque ayudó y aceleró nuestra implementación al mismo nivel, ya que elevó la calidad de nuestra cartera de aplicaciones, quién consume/usa estos VDM. Pudimos reducir muchas apariciones de errores, ya que los problemas con las API de oData o las coincidencias de tipos ya aparecieron durante la fase de implementación.
Basado en muchos antecedentes diferentes de habilidades, puede ser un largo camino para conocer javascript, nodeJs, mecanografiado y SAP Cloud SDK dentro de VDM. Pero vale la pena: aumenta la calidad, ahorra tiempo y también es divertido 🙂
Por último, pero no menos importante: gracias al equipo detrás del SDK, planteé algunos problemas, preguntas o ideas para mejorar funciones en el repositorio oficial de github y estoy realmente impresionado por la velocidad y la calidad de las respuestas que recibo.
