SnapMSV3service –desarrollo de productos en la nube en la práctica
El buen funcionamiento de una infraestructura informática depende en gran medida de unas interfaces adecuadas. Esto es especialmente cierto en el entorno SAP. Por eso resulta aún más sorprendente que la comunidad SAP dedique mucha atención a la transición a la nueva versión S/4 Hana del componente SAP Core, pero apenas hable de los ajustes absolutamente necesarios en el ámbito de la integración. Sin embargo, el paso a la nube también da lugar a problemas completamente nuevos, especialmente con las interfaces, que requieren enfoques radicalmente diferentes.
Integración significa adaptación
Una mirada retrospectiva muestra que SAP ha estado haciendo ajustes desde el principio: cuando se lanzó en 1992, SAP R/3 ya era al principio un sistema bastante abierto, para el que se podían programar fácilmente interfaces utilizando las tecnologías clásicas: RFC, ALE, BAPI e IDOC. A lo largo de los años, SAP se ha reinventado y modernizado una y otra vez, especialmente en el ámbito de la integración. Mientras que en el pasado fue la apertura a protocolos estandarizados de Internet o la introducción de conceptos (y productos) de middleware, hoy en día los usuarios de SAP nos enfrentamos cada vez más a nuevos conceptos como API-First y la comunicación basada en eventos, especialmente en el entorno de la nube.
Y entonces llegó la nube
Muchos clientes no han seguido esta evolución y siguen en la era BAPI/IDOC/RFC con sus conceptos de interfaz. Sin embargo, el paso a la nube (pública) no es posible porque en los últimos años han entrado en juego, y con fuerza, requisitos y conceptos completamente nuevos. Cada vez son más los componentes de los procesos empresariales tradicionales que se trasladan a la nube, incluido el propio backend de SAP. Sin embargo, como casi ninguna empresa mapea sus procesos únicamente en la nube por primera vez, están surgiendo entornos de TI híbridos formados por instalaciones en la nube y locales, que traen consigo muchas cuestiones nuevas en términos de interfaces y conectividad.
Además, existen enfoques tecnológicos como API First o la comunicación basada en eventos que, al igual que la nueva tecnología de interfaz estratégica Fiori, aumentan la necesidad de integración. Y además de todo esto, la seguridad es una cuestión transversal de suma importancia para poder implementar requisitos específicos de una manera técnicamente limpia y conforme.
Muchos profesionales y programadores experimentados de SAP se centran en el "viejo mundo Abap" debido a sus muchos años de experiencia, como podemos comprobar por nuestra propia experiencia. Especialmente cuando se trata de interfaces, han llegado a amar y dominar los conceptos de BAPIs o IDOCs.
Sin embargo, según el concepto de núcleo limpio, estas tecnologías conocidas ya no son la primera opción. Tampoco estarán disponibles en las instancias de SAP Public Cloud. Se sustituirán por tecnologías nuevas y modernas como oData o las API SOAP. Pero, ¿son realmente equivalentes? ¿O es necesario replantearse completamente las interfaces?
Comprobación práctica
Para encontrar respuestas a las numerosas preguntas, nos hemos dedicado al tema con una aplicación práctica específica. Como desarrolladores de software en el entorno SAP, siempre tenemos la "nariz pegada a la piedra de afilar" cuando se trata de identificar los puntos débiles de nuestros clientes y ofrecerles soluciones. Este es también el caso de nuestro último producto: SnapMSV3service es un proceso de disponibilidad de entregas y pedidos para farmacias hospitalarias integrado en SAP BTP y basado en el protocolo industrial MSV3. Nuestro producto ayuda a los hospitales a reconocer los cuellos de botella en el suministro de medicamentos y a reaccionar ante ellos en una fase temprana.
El objetivo inicial era apoyar a las farmacias hospitalarias en el proceso de adquisición de medicamentos. Incluso antes del proceso de pedido, el objetivo era aclarar si un medicamento estaba disponible en un proveedor farmacéutico concreto y, en caso negativo, si se podían considerar productos alternativos u otras fuentes de suministro.
Las bases de datos farmacéuticas debían integrarse en el proceso digital de consulta y pedido de los proveedores farmacéuticos. La solución también tenía que estar profundamente integrada con los procesos estándar de SAP y cumplir los requisitos de protección de datos del GDPR. Hasta ahora, el requisito se había resuelto de varias maneras: en forma de procesos analógicos, con sistemas de información internos, con una conexión MSV3 directa con los proveedores pertinentes o con el módulo snap GHT APM, una solución local basada en una interfaz gráfica de usuario.
Tras la investigación necesaria, pronto quedó claro que la solución debía ser una aplicación en la nube, entre otras cosas por tres ventajas clave: Una base de datos estandarizada y siempre actualizada para todos los clientes, conectividad central con todos los fabricantes y proveedores farmacéuticos a través del protocolo MSV3, y extensibilidad a clientes no pertenecientes a SAP. Nuestras competencias existentes en materia de tecnología y procesos, así como la "capacidad de nube" del requisito previsto, nos animaron a realizar la solución en BTP. Otro factor decisivo fue la independencia alcanzable, tanto de las versiones SAP como de los procesos especiales de gestión de materiales SAP de los clientes potenciales.
Buenas soluciones, costes moderados
Por supuesto, también nos fijamos en los costes antes de empezar el proyecto. Los factores más relevantes son las soluciones BTP necesarias (= "servicios"). En otras palabras, ¿qué entorno de ejecución se requiere (Cloud Foundry/Kyma o BTP Abap) y qué base de datos es posible con él? BTP Abap solo está disponible junto con una base de datos Hana, otros tiempos de ejecución también permiten PostgreSQL u otras bases de datos. Además, siempre se requieren algunos "servicios básicos", como Business Application Studio como entorno de desarrollo o Identity Services para la administración de usuarios. Y, por supuesto, como se mencionó al principio, la integración es una cuestión clave. Para snapMSV3service, optamos por la solución estándar SAP Integration Suite con el producto de middleware Cloud Integration en la Basic Edition. Nuestro aprendizaje: se pueden construir buenas soluciones en la BTP a un coste comparativamente bajo. Sin embargo, hay que familiarizarse con el catálogo de servicios y las diferentes métricas de los servicios necesarios, y la arquitectura deseada debe estar clara desde el principio.
Proceso integrable separado
La "capacidad de nube" previamente definida de nuestra solución se basa en el hecho de que se trata de un proceso que puede separarse fácilmente (del núcleo SAP) e integrarse con el núcleo SAP. Este proceso comprende tres niveles o sistemas: el backend de SAP, el portal propiamente dicho -es decir, la aplicación snapMSV3service- y el lado del proveedor de MSV3. El componente central para la comunicación entre estos tres niveles es SAP Cloud Integration (SAP CI), que establece la conexión segura entre la red local del cliente (on-prem) o la instancia en la nube S/4 Hana del cliente y nuestra instancia SAP BTP a través de SAP Cloud Connector. Los requisitos se generan en el backend SAP del cliente X y se transmiten al portal. Allí, un usuario del portal del cliente procesa estos requisitos, realiza comprobaciones de disponibilidad con los proveedores de MSV3 y responde a sus comentarios. El proceso de pedido comienza entonces con una particularidad importante: antes de realizar un pedido al proveedor de MSV3, debe generarse en SAP el correspondiente número de pedido para que pueda introducirse como referencia en el pedido de MSV3.
Nuevas API: similares, no idénticas
Este proceso denominado "crear/modificar un pedido memorizado en el backend SAP del cliente" (y recibir de vuelta inmediatamente el número de pedido correspondiente, por lo que estamos hablando de una interfaz estrictamente sincrónica) es un ejemplo de lo mucho que difiere el "nuevo" mundo de la nube del "viejo" mundo on-premises. Antes, el resultado deseado se conseguía con las llamadas BAPI_PO_CREATE1 y BAPI_PO_CHANGE, que eran autoexplicativas para muchos "veteranos de Abap". En el "nuevo" mundo de la nube, las APIs oData (versión 4) son necesarias para esto y las tareas deseadas se completan con su ID de servicio "API_PURCHASEORDER_2" (Post o Patch, si quieres añadir una nota de borrado a algunos ítems entonces también Delete).
No sólo ya no está disponible la conocida función original, sino que la sintaxis y la función son completamente diferentes. Para encontrar la funcionalidad deseada, el Business Accelerator Hub (api.sap.com) ofrece un buen primer paso (también directamente con ejemplos y opciones de prueba). Sin embargo, falta información detallada, por ejemplo, qué hace cada propiedad o qué valor debe establecerse para una funcionalidad concreta. Por tanto, lo que hacen las nuevas API es similar, pero en absoluto idéntico, a lo que estamos acostumbrados.
Factores de éxito de la nube
Basándonos en nuestra experiencia con snapMSV3service, podemos resumir los siguientes factores clave para el éxito de las soluciones en la nube: El proceso planificado debe estar "preparado para la nube", es decir, debe poder separarse del núcleo SAP e integrarse en él. La cuestión de la integración debe aclararse lo antes posible. El conjunto de competencias de los arquitectos debe ser el adecuado y la arquitectura debe ultimarse en una fase temprana.
Para entender las nuevas interfaces de la nube, también necesita conocimientos especializados -sobre SAP Integration Suite, por ejemplo- que debería adquirir lo antes posible.
Para realizar realmente soluciones económicas, es necesario conocer los servicios de BTP y sus métricas de licencia. Y sin duda merece la pena familiarizarse con las nuevas API técnicas para la realización de tareas empresariales específicas. Y mejor cuanto antes.
A la entrada de socios:
DE
EN
ES
