Opciones de Arquitectura para la extracción de datos SAP con servicios AWS

Introducción

Gartner encontró que casi el 97% de los datos no son utilizados por las organizaciones, y más del 87% de las organizaciones están clasificadas con bajos niveles de madurez en términos de inteligencia empresarial y capacidad analítica. Este déficit de capacidad podría restringir severamente el crecimiento de una empresa e introducir riesgos para su existencia, ya que no puedrá reinventarse a sí misma. Toda empresa debe moverse rápidamente para evaluar sus capacidades de análisis de datos y trazar un curso de transformación a una empresa basada en datos (data-driven). Es crucial para lograr ser más receptivo con los clientes y a las oportunidades del mercado, incluso más ágil para afrontar la naturaleza cambiante de la tecnología y el mercado.

Estos son algunos clientes de AWS que se beneficiaron al ser una empresa data-driven:

• Moderna es una compañía de biotecnología pionera en una nueva clase de medicamentos de ARN mensajero (ARNm). Aprovechando su plataforma de ARNm y sus instalaciones de fabricación con el motor de investigación impulsado por AWS, Moderna entregó el primer lote clínico de su vacuna candidata (mRNA-1273) contra COVID-19 al Instituto Nacional de Salud (NIH) para el ensayo de Fase 1 42 días después de la secuenciación inicial del virus. Implementando y  escalando sus operaciones en AWS, que incluyen SAP S/4HANA, Amazon Redshift y Amazon Simple Storage Service (S3),  Moderna puede diseñar rápidamente experimentos de investigación, descubrir nuevos insights, automatizar sus procesos de laboratorio y fabricación para mejorar su proceso de descubrimiento de fármacos y cumplir fácilmente con las leyes y regulaciones durante la producción, prueba de vacunas y candidatos terapéuticos.
• Zalando (la plataforma de moda en línea más grande de Europa) comenzó a migrar sus sistemas SAP a AWS para aumentar la agilidad, simplificar el mantenimiento de TI y crear una arquitectura de datos preparada para el futuro como parte de su transformación digital. Con un data lake híbrido en AWS que está estrechamente integrado con uno de los sistemas SAP S/4HANA más grandes del mundo, Zalando ha reducido su costo de obtención de insights en un 30 % al mismo tiempo que mejora la satisfacción del cliente. Zalando construyó su data lake con servicios como Amazon Redshift, AWS Glue, Amazon S3.

El primer paso para sacar más provecho de sus datos de SAP es llevarlos a su data lake de AWS, esto le permitirá descubrir nuevas oportunidades y resolver desafíos comerciales. En este blog, analizaremos las opciones de arquitectura para extraer datos desde SAP a AWS en función de sus versiones de SAP ERP o S/4HANA.

Nos centraremos en servicios de AWS como Amazon Appflow, AWS Glue AWS Lambda, Amazon API Gateway, así como en soluciones de SAP como SAP Data Services,  SAP Data Intelligence con el fin de proporcionar una línea base de escenarios.

Hay una serie de soluciones de partners de AWS que pueden ayudar con la extracción, el procesamiento y el análisis de datos de SAP, como Qlik, Bryteflow, HVR, Linke, Boomi y otros. Sin embargo, no se discutirán en este blog, pero puede visitar AWS Marketplace o ponerse en contacto con su punto de contacto de AWS para obtener más información. Si necesita ayuda para implementar estos servicios de AWS, puede ponerse en contacto con los servicios profesionales de AWS o con los socios de AWS, que se enumeran en AWS Partner Discovery Portal.

Consideraciones sobre la solución

Las consideraciones clave al extraer datos de los sistemas SAP se dividen en dos categorías principales, 1/ Comercial y 2/ Técnico.

Consideraciones comerciales

Comprar vs Construir

Para integrar AWS con SAP, los desarrolladores pueden implementar breves líneas de código. Si bien ejecutar código personalizado puede ser rentable al principio, normalmente requiere de mantención. Por otro lado, hay una serie de soluciones SAP (como SAP Data Services), servicios administrados de AWS (como Amazon AppFlow) u otras soluciones comerciales listas para usar (COTS), que son altamente especializadas. Vienen con un gran conjunto de capacidades preconstruidas para facilitar su uso. Recordar que siempre es importante considerar el costo total de propiedad (TCO).

Middleware Software Platforms vs Cloud Native

Aprovechar las plataformas middleware para la integración entre SAP y AWS significa un esfuerzo administrativo adicional (instalación, aplicación de parches y actualización), así como costos de tiempo de ejecución (licencia de software). Para abordar esto, AWS introdujo un servicio administrado que elimina el esfuerzo administrativo y los costos de tiempo de ejecución para integrar SAP y AWS. Amazon AppFlow proporciona una opción serverless sin necesidad de código para extraer datos de SAP, así como volver a escribir estos datos en SAP.

Impacto en licencias SAP

Al extraer datos de SAP y volver a escribir datos en SAP, deberá tener en cuenta sus requisitos de licenciamiento SAP.
Nota: Antes de implementar la extracción de datos o volver a escribir a/desde sistemas SAP, verifique su acuerdo de licencia.

Precio vs Valor

Cuando compra software, como SAP Data Services, puede obtener una licencia perpetua que le permite usar el software por un período de tiempo indefinido pagando una tarifa única. Con una licencia perpetua, puede ser difícil determinar los costos frente al valor comercial de una determinada iniciativa. Cuando utiliza servicios nativos de la nube como Amazon Appflow, paga por uso en función del número de flujos y el volumen de datos que necesita su caso de uso. Este modelo de pago por uso, o utilidad, le permite comprender el costo real frente al valor comercial de una iniciativa.

Consideraciones técnicas

Pull vs Push

A un alto nivel existen dos tipos de mecanismos para extraer datos SAP:

• Extraer (Pull) datos de SAP y, a continuación, enviarlos a servicios de AWS como Amazon S3. Este método generalmente se ejecuta en lotes (Batch) y requiere que un sistema SAP sea accesible por las herramientas de extracción. Algunos clientes pueden tener problemas de seguridad en torno a este enfoque y, por lo tanto, puede ser menos preferido.
• Enviar datos (Push) desde SAP a los servicios de AWS. Este método es el más adecuado para la extracción “casi” en tiempo real utilizando, por ejemplo, SAP Intermediate Documents (IDOC).

Manejo de deltas

Para tablas relativamente pequeñas, por ejemplo, tablas de datos maestros, las cargas completas repetitivas pueden ser aceptables al momento de la extracción. Para tablas grandes, por ejemplo, tablas de datos transaccionales, se puede preferir la transferencia de deltas por razones de rendimiento y costo. Con la extracción mediante deltas, se identifican solo los datos que han cambiado desde la última extracción. Los mecanismos más comunes de SAP son Application Link Enabling (ALE) Change Pointers, Operational Data Provisioning (ODP) Delta Queues, Change Data Capture (CDC),  y el uso de campos timestamp como marca de tiempo para la consulta de la última fecha y hora de modificación.

Impacto de la actualización de SAP

Para los clientes de SAP que ejecutan SAP ECC 6.0 o anterior (SAP Business Suite), una preocupación es el impacto de actualización del mecanismo de extracción de datos de SAP que se está estableciendo. Este desafío puede conducir a una solución que evite la extracción a nivel de base de datos, debido al hecho de que se pueden esperar cambios importantes en el esquema de la base de datos cuando se realiza una actualización a S/4HANA.

Árbol de decisión

Teniendo en cuenta las consideraciones de solución anteriores y los aspectos prácticos de los sistemas SAP, hemos creado un árbol de decisión (a continuación) para ayudar a guiar a los clientes a elegir qué método es apropiado para extraer sus datos de SAP.

Una consideración práctica importante es la disponibilidad de SAP Gateway. SAP Gateway le permite aprovechar el protocolo OData para consumir datos de SAP medianto el uso de APIs RESTful. OData (Open Data Protocol) es un estándar OASIS aprobado por ISO/IEC. Soporta conectividad segura a través de Internet y el uso de soluciones híbridas multi-cloud con capacidad para escalar junto con el volumen de datos. SAP Gateway le proporcionará una amplia gama de opciones para extraer datos de SAP, sin limitarse a un protocolo heredado como RFC o IDOC.

• Si tiene SAP Gateway, la siguiente consideración es la versión de SAP ERP que está ejecutando actualmente:
  • Si está ejecutando la última versión de SAP S/4HANA, tendrá muchos servicios OData precompilados que puede aprovechar para la extracción de datos. En la última versión de S/4HANA, hay más de 2000 servicios OData preconstruidos. La mayoría de estos servicios OData se crean teniendo en cuenta la interfaz de usuario de Fiori. Para una extracción de datos masiva, es posible aprovechar los extractores SAP BW usando ODP que incluyen mecanismos de manejo de deltas, monitoreo y solución de problemas. Los extractores de SAP BW proporcionan un contexto de aplicación, reduciendo así los trabajos de transformación en el sistema de destino o data lake.
  • Si ejecuta ECC 6.0 EHP7/8, tendrá servicios OData precompilados limitados, pero aún puede aprovechar los extractores de SAP BW.
• Si no tiene SAP Gateway, lo más probable es que esté ejecutando SAP ECC 6.0 EHP8 o anterior. Es posible que le preocupe el impacto en los mecanismos de extracción después de realizar una actualización del sistema SAP. Para minimizar este impacto, recomendamos el uso de los extractores estándar SAP BW mediante ODP, BAPIs estándar o IDOCs estándar.
  • Los métodos personalizados de extracción de BW, BAPIs, IDOCs, bases de datos y archivos son viables, sin embargo, pueden aumentar su TCO porque tendrá que construir, operar y mantener el código personalizado usted mismo.

Siempre puede usar RFCs/BAPIs e IDOCs en S/4HANA, sin embargo, dado que estos son protocolos heredados, sus opciones de herramientas de extracción y opciones de conectividad de red pueden estar restringidas debido a que estos protocolos se crearon para entornos LAN y WAN. Existirán desafíos al usar conexiones de internet e incluso estos protocolos pueden no funcionar de manera óptima en entornos híbridos. Por lo tanto, la recomendación sigue siendo considerar OData como primera opción porque es un protocolo de datos abiertos que es flexible de implementar y es compatible con un entornos híbridos multi-cloud.

Figura 1. Árbol de decisiones de directrices para extraer datos de SAP con servicios de AWS.

Características del patrón de diseño de arquitectura

A continuación se muestra un resumen de los patrones de diseño de arquitectura y sus características, que están etiquetadas en el árbol de decisión anterior. Estos lo ayudarán a decidir un método de extracción para sus datos SAP.

Conclusión

En este blog, hemos analizado los patrones de arquitectura para extraer datos de SAP a AWS. Cada uno de los patrones se describe junto con sus pros y contras en función de consideraciones clave como el manejo de deltas, licencias, costos de funcionamiento y el impacto de una actualización. Con el árbol de decisión proporcionado, puede evaluar y decidir qué patrón es adecuado para su escenario.

Aquí hay algunas referencias adicionales que pueden resultarle útiles. Describen los casos de uso y las posibilidades que se hacen realidad una vez que sus datos de SAP se han extraído a AWS.

• Extract data from SAP ERP and BW with AppFlow.
• Building data lakes with SAP on AWS.
• SAP on AWS Beyond – Lab Repository.
• How to connect SAP solutions running on AWS with AWS accounts and services.
• Query SAP HANA using Athena Federated Query and join with data in your Amazon S3 data lake.
• Data Extraction from Data Lake and Amazon Redshift Using SAP Data Services.
• Data Federation Between SAP Data Warehouse Cloud and Amazon Redshift.
• Extend your SAP business processes using Amazon AppFlow and AWS native services.

Puede obtener más información sobre SAP en AWS, Amazon AppFlow, AWS Glue, AWS Lambda,  en la documentación de AWS.

Este artículo fue traducido del Blog de AWS en Inglés