En esta publicación, veremos las opciones de implementación para los diferentes entornos de desarrollo de SAP Business Technology Platform.

Algunos puntos a tener en cuenta al considerar estas opciones de implementación incluyen lo siguiente.

La estructura de la SAP BTP aprovisionamiento en términos de cuenta global, subcuentas y espacios: cualquier configuración, como conectarse a un sistema local específico o configuración de seguridad, es específica en una instancia de subcuenta de la plataforma. Por lo tanto, si está implementando una aplicación que es, digamos, específica para finanzas, entonces es mejor tener una subcuenta separada solo para finanzas. Si se utiliza la misma subcuenta para todas las áreas, existe la posibilidad de que se sobrescriban las configuraciones o surjan conflictos y confusiones.

Para cada entorno, como desarrollo, prueba y producción, necesita subcuentas separadas. De hecho, dado que cada subcuenta estaría vinculada a la instancia central del sistema transaccional subyacente, que puede estar en las instalaciones SAP S/4 HANA, Por ejemplo. Idealmente, tiene vínculos uno a uno entre los entornos de esta instancia de SAP S/4HANA y la subcuenta correspondiente. Este enfoque garantiza las pruebas con los sistemas back-end y la seguridad, todo sincronizado, sin riesgos de implementación.

Se proporcionan espacios para una clasificación adicional en la subcuenta, que es un concepto heredado de Cloud Foundry. Pero este concepto también se puede utilizar para agrupaciones lógicas de desarrollos.

Despliegue en SAP BTP, Neo Environment

Para las aplicaciones desarrolladas en SAP BTP, entorno Neo, el primer punto de entrada a la arquitectura de implementación suele ser a través de SAP Web Dispatcher.

SAP BTP, entorno Neo, también admite la implementación de aplicaciones multidestino (MTA), pero no en el entorno de la nube.

Cuando se crea una aplicación en SAP BTP, entorno Neo, creará un proyecto en SAP Web IDE, enviará el código a GitHub y luego tendrá tres opciones para guardar la aplicación: guardar localmente, confirmar cambios en GitHub o enviar el aplicación a la instancia de SAP BTP. Los principales tiempos de ejecución disponibles en SAP BTP, entorno Neo, admiten el desarrollo utilizando Java, JavaScript, SAP HANAy HTML5/SAPUI5. Los entornos de desarrollo están disponibles en Eclipse y en SAP Web IDE. Los entornos de desarrollo están disponibles en Eclipse y en SAP Web IDE. Para el desarrollo de XS-JS, puede usar complementos de Eclipse o el banco de trabajo de desarrollo basado en web de SAP HANA. Una aplicación se puede ejecutar localmente para pruebas unitarias pero, en este estado, no está disponible para otros usuarios. Solo cuando se publique en SAP BTP y se active, la aplicación estará lista para ejecutarse en la nube. Como se muestra en la figura a continuación, algunos servicios están disponibles en la cabina de SAP BTP, mientras que las funcionalidades de implementación y control de versiones están disponibles a través de SAP Web IDE para Neo.

A diferencia de otros entornos, SAP Business Application Studio no tiene una hoja de ruta para admitir entornos Neo hasta el momento.

La siguiente figura muestra las capacidades de control de versiones dentro de SAP BTP, entorno Neo.

Despliegue en SAP BTP, Cloud Foundry Environment

Cuando se implementa una aplicación en Cloud Foundry desde el espacio de trabajo del desarrollador a SAP BTP, Cloud Foundry usa diferentes contenedores, por ejemplo, varios contenedores de aplicaciones y contenedores de bases de datos. Dado que la arquitectura que usa Cloud Foundry es completamente diferente a la de Neo, estas aplicaciones también se implementan y ejecutan de manera diferente.

Los tiempos de ejecución disponibles en Cloud Foundry incluyen Java, HTML5, Nodo.js para aplicaciones backend y algoritmos de aprendizaje automático en Pitón. Si bien SAP Web IDE aún es compatible con el desarrollo de pila completa, incluidas las capacidades de desarrollo frontend, los modelos de base de datos y la lógica comercial integrada en las capacidades backend, el IDE más nuevo llamado Estudio de aplicaciones empresariales de SAP es ahora el entorno de desarrollo e implementación preferido para las aplicaciones nativas de la nube (a menos que se utilice ABAP).

En Cloud Foundry, la implementación de MTA es posible. Veamos un ejemplo de creación de una aplicación usando la arquitectura Cloud Foundry y luego usando MTA para implementar la aplicación. En nuestro ejemplo, consideraremos una aplicación nativa de la nube simple con una interfaz y un esquema en la base de datos de SAP HANA con algunas vistas de cálculo, que consume algunos servicios de otros sistemas, tal vez SAP S/4HANA a través de una vista de CDS. En esta figura se muestra el aspecto que debe tener la arquitectura de implementación.

El AppRouter es el primer punto de entrada cuando un usuario llama a su aplicación a través de un navegador web. El AppRouter también maneja las consideraciones de seguridad y autentica al usuario. La llamada va desde esta aplicación al microservicio, a través de un servicio HTTP o un servicio REST.

2

La aplicación se puede implementar en diferentes contenedores de aplicaciones, según los microservicios utilizados. Cloud Foundry tiene servicios de contenedores y servicios de respaldo. Con cada contenedor, también se implementan partes centrales del servidor de aplicaciones. Por ejemplo, un microservicio puede usar diferentes idiomas. Esta operación multilingüe está respaldada por servicios de respaldo, que contienen todos los recursos adjuntos para su aplicación, por ejemplo, objetos de persistencia o programadores de trabajos.

Si bien los artefactos típicos se crean a través de SAP Business Application Studio (o SAP Web IDE full-stack), si usa un idioma que aún no es compatible con SAP Business Application Studio/SAP Web IDE, puede conectar una herramienta de desarrollo externa para cualquier idioma. a través de Git. Todo el código de todas sus aplicaciones se puede almacenar en un repositorio de Git. Los servicios de implementación disponibles en Cloud Foundry pueden actuar como el componente central para administrar el ciclo de vida de la aplicación. Estos servicios permiten a los MTA, que empaquetarán todas las diferentes partes de la aplicación en un único .yaml archivo, para ser transportado a través de diferentes paisajes. El MTA dividirá la aplicación en módulos: por ejemplo, un módulo puede ser para la base de datos de SAP HANA para el contenido de la base de datos (vistas de CDS, vistas de cálculo), mientras que otro módulo puede contener Java/Node.js para el código de back-end. Un tercer módulo puede ser un módulo HTML5 para el contenido de la interfaz HTML. La funcionalidad de implementación también contiene información de configuración para la seguridad y otras dependencias, como los servicios que necesita la aplicación. Se encargará de llevar el código del espacio de trabajo del desarrollador a las partes relevantes de Cloud Foundry (p. ej., contenedores HDI en la tabla/vistas/bases de datos, frontend/backend en contenedores de aplicaciones, etc.).

Una vez construido el desarrollo, se genera el .yaml archivo a través del menú gráfico o usando la CLI en SAP Business Application Studio. También deberá ingresar algunos detalles en los archivos descriptores para una Modelo de programación de aplicaciones en la nube de SAP-aplicación basada. Luego, se construirá esta aplicación, que genera el .mtar archivo en el .mta carpeta de archivo. La ventaja de este enfoque de compilación e implementación es que conoce todas las dependencias y secuencias y se ocupa de la generación de los diferentes códigos en diferentes lenguajes. Una vez el .mtar se genera el archivo, puede implementar esta aplicación, que luego verá en su espacio de desarrollo (suponiendo que primero implemente en un entorno de desarrollo antes de pasar a otros entornos), incluidos los registros para la implementación de cada módulo (por ejemplo, .srv para los servicios web o .ui para el módulo de interfaz de usuario).

Nota: Se puede encontrar una guía detallada para las implementaciones de Cloud Foundry en http://s-prs.co/v550429.

Implementación en SAP BTP, Kyma Runtime

Después de que se crea la aplicación, ya sea un microservicio o una función, se incluye en contenedores mediante contenedores Docker y se expone como estándar en el marco de trabajo de Kubernetes, y es posible hacer que estos sean escalables. Para requerimientos complejos, esta es la opción a elegir. Luego, la imagen de Docker se puede implementar en SAP BTP, el tiempo de ejecución de Kyma, utilizando la consola de Kyma. Después de la implementación en SAP BTP, el tiempo de ejecución de Kyma, el estado se puede verificar en el tablero de Kyma a través de la salida del registro. Los registros están disponibles para cada espacio de nombres y también para funciones lambda particulares.

Los microservicios se pueden implementar a través de implementaciones como archivos YAML Ain’t Markup Language (YAML) o JavaScript Object Notation (JSON). Las canalizaciones de integración continua/implementación continua (CI/CD) usan kubectl.

Despliegue en SAP BTP, Ambiente ABAP

Los desarrollos ABAP se crean como componentes de software en «paquetes» en ABAP. Cuando libera el código, los paquetes se almacenan en el Git repositorio, que maneja la implementación como un todo. Se despliega todo el código.

Organizadores de transporte en ADT en Eclipse se utilizan para implementar programas ABAP en servidores de aplicaciones configurados en SAP Business Application Studio. Los servicios OData se crean y luego se implementan en el servidor de aplicaciones en la nube. Los transportes se manejan usando ALM en la nube de SAP o CTS basado en Git (gCTS).

El código ABAP también se puede colocar en el repositorio abapGit, desde donde se puede manejar la implementación. Sin embargo, abapGit actualmente solo está disponible como un complemento para ADT.

Nota del editor: Esta publicación ha sido adaptada de una sección del libro. Desarrollo de aplicaciones con SAP Business Technology Platform por Gairik Acharya, Govind Bajaj, Avijit Dhar, Anup Ghosh y Asidhara Lahiri.