Opções de Arquitetura para extrair Dados do SAP com Serviços da AWS

Introdução

A Gartner descobriu que quase 97% dos dados não são usados pelas organizações e mais de 87% das organizações estão classificadas como tendo baixos níveis de maturidade em termos de inteligência de negócios e capacidade analítica. Esse déficit de capacidade pode restringir severamente o crescimento de uma empresa e introduzir riscos à sua existência, uma vez que ela não será capaz de se reinventar. Cada empresa deve agir rapidamente para avaliar suas capacidades de análise de dados e traçar um curso de transformação para uma empresa orientada a dados. É crucial ser mais responsivo aos clientes e às oportunidades de mercado, e mais ágil para lidar com a natureza rapidamente mutável da tecnologia e do mercado.

Aqui estão alguns clientes da AWS que se beneficiaram por serem empresas orientadas a dados:

• A Moderna é uma empresa de biotecnologia pioneira em uma nova classe de medicamentos de RNA mensageiro (mRNA). Aproveitando sua plataforma de mRNA e instalações de fabricação com o mecanismo de pesquisa desenvolvido na AWS, a Moderna entregou o primeiro lote clínico de sua vacina candidata (mRNA-1273) contra a COVID-19 ao Instituto Nacional de Saúde (NIH) para o teste de Fase 1 42 dias após o sequenciamento inicial do vírus. Ao implementar e escalar suas operações na AWS, incluindo SAP S/4HANA, Amazon Redshift e Amazon Simple Storage Service (S3), a Moderna é capaz de desenhar rapidamente experimentos de pesquisa, descobrir novos insights, automatizar seus processos laboratoriais e de fabricação para melhorar seu pipeline de descoberta de medicamentos e cumprir mais facilmente leis e regulamentações durante a produção e teste de vacinas e candidatos terapêuticos.
• A Zalando (a maior plataforma de moda on-line da Europa) começou a migrar seus sistemas SAP para a AWS para aumentar a agilidade, simplificar a manutenção de TI e criar uma arquitetura de dados pronta para o futuro como parte de sua transformação digital. Com um data lake híbrido na AWS que está totalmente integrado a um dos maiores sistemas SAP S/4HANA do mundo, a Zalando reduziu seu custo de obtenção de insights em 30%, ao mesmo tempo que melhorou a satisfação de seus clientes. A Zalando construiu seu data lake com serviços como Amazon Redshift, AWS Glue e Amazon S3.

O primeiro passo para aproveitar melhor seus dados SAP é trazê-los para o seu data lake da AWS, que o habilitará a descobrir novas oportunidades e solucionar desafios de negócios. Neste blog, discutiremos as opções de arquitetura para extrair dados do SAP para a AWS com base nas suas versões do SAP ERP ou do S/4HANA.

Vamos nos concentrar nos serviços da AWS, como Amazon Appflow, AWS Glue, AWS Lambda, Amazon API Gateway, bem como em soluções SAP, como SAP Data Services, SAP Data Intelligence para fornecer cenários básicos.

Há várias soluções de parceiros da AWS que podem ajudar na extração, processamento e análise de dados SAP, como Qlik, Bryteflow, HVR, Linke, Boomi e outros. No entanto, eles não serão discutidos neste blog, mas você pode visitar o AWS Marketplace ou entrar em contato com seu ponto de contato da AWS para obter mais informações. Se precisar de ajuda para implementar esses serviços da AWS, entre em contato com o AWS Professional Services ou com os parceiros da AWS, que estão listados no Portal de Descoberta de Parceiros da AWS.

Considerações sobre a solução

As principais considerações ao extrair dados dos sistemas SAP se enquadram em duas categorias principais, 1/ Comercial e 2/ Técnico.

Considerações comerciais

Comprar versus Construir

Para integrar a AWS ao SAP, os desenvolvedores podem implementar poucas linhas de código. Embora a execução de código customizado possa ser econômica no início, ela geralmente requer a manutenção deste código customizado. Por outro lado, existem várias soluções da SAP (como SAP Data Services), serviços gerenciados pela AWS (como o Amazon AppFlow) ou outras soluções de negócios prontas para uso (COTS), que são altamente especializadas. Elas vêm com um grande conjunto de recursos pré-construídos para facilidade de uso. Lembre-se de que é sempre importante considerar o custo total de propriedade (TCO).

Plataformas de Software de Middleware versus Nativas em Nuvem

Utilizar as plataformas de middleware para integração entre a SAP e a AWS significa esforço administrativo adicional (instalação, aplicação de patches e atualização), bem como custos de tempo de execução (licença de software). Para resolver isso, a AWS introduziu um serviço gerenciado que elimina o esforço administrativo e os custos de tempo de execução para integrar a SAP e a AWS. O Amazon AppFlow oferece uma opção sem necessidade de código e de provisionar e gerenciar servidores para extrair dados do SAP, bem como reescrever esses dados de volta ao SAP.

Impacto nas licenças SAP

Ao extrair dados do SAP e reescrevê-los de volta para o SAP, você precisará considerar seus requisitos de licenciamento do SAP.
Nota: Antes de implementar a extração de dados ou escrita de/para sistemas SAP, verifique seu contrato de licença.

Preço versus Valor

Ao comprar um software pronto para uso, como o SAP Data Services, você pode obter uma licença perpétua que permite usar o software por um período indefinido pagando uma taxa única. Com uma licença perpétua, pode ser difícil determinar os custos versus o valor comercial de uma determinada iniciativa. Quando você usa serviços nativos da nuvem, como o Amazon Appflow, você paga por uso com base no número de fluxos e no volume de dados necessários para o seu caso de uso. Esse modelo de pagamento conforme o uso, ou utilitário, permite que você entenda o custo real versus o valor comercial de uma determinada iniciativa.

Considerações técnicas

Realizar o Pull versus Push dos Dados

Em um alto nível, existem dois tipos de mecanismos para extrair dados do SAP:

• Extraia (pull) dados do SAP e envie-os para serviços da AWS, como o Amazon S3. Esse método geralmente é executado em lotes (batch) e requer que um sistema SAP seja acessível por ferramentas de extração. Alguns clientes podem ter preocupações de Segurança em relação a essa abordagem e, portanto, esta pode ser menos preferida por eles.
• . Esse método é mais adequado para extração “quase” em tempo real (near real-time) usando, por exemplo, o SAP Intermediate Documents (IDOC).

Gestão de Deltas

Para tabelas relativamente pequenas, por exemplo, tabelas de dados mestres, cargas completas repetitivas podem ser aceitáveis no momento da extração dos dados do SAP. Para tabelas grandes, por exemplo, tabelas de dados transacionais, é possível que haja preferência pela transferência de deltas por motivos de desempenho e custos. Com a extração delta, somente os dados que foram alterados desde a última extração são identificados. Os mecanismos SAP mais comuns para delta são Application Link Enabling (ALE) Change Pointers, Operational Data Provisioning (ODP) Delta Queues, Change Data Capture (CDC) e o uso de campos timestamp como marcadores de tempo para consultar a data e hora da última modificação.

Impacto da atualização do SAP

Para os clientes da SAP que usam o SAP ECC 6.0 ou anterior (SAP Business Suite), uma preocupação é o impacto da atualização do mecanismo de extração de dados do SAP que está sendo estabelecido. Esse desafio pode levar a uma solução que evite a extração no nível do banco de dados, devido ao fato de que mudanças significativas no esquema do banco de dados podem ser esperadas quando uma atualização para o S/4HANA é feita.

Árvore de Decisão

Levando em conta as considerações de solução acima e os aspectos práticos dos sistemas SAP, criamos uma árvore de decisão (abaixo) para ajudar a guiar os clientes na escolha de qual método é apropriado para extrair seus dados do SAP.

Uma consideração prática importante é a disponibilidade do SAP Gateway. O SAP Gateway permite que você aproveite o protocolo OData para consumir dados do SAP por meio de APIs RESTful. O OData (Open Data Protocol) é um padrão OASIS aprovado pela ISO/IEC, e roda no protocolo HTTPS. Ele suporta conectividade segura pela Internet e o uso de soluções híbridas  multi-cloud com a capacidade de escalar junto com o volume de dados. O SAP Gateway fornecerá uma ampla variedade de opções para extrair dados do SAP, não se limitando a um protocolo legado, como RFC ou IDOC.

• Se você tiver o SAP Gateway, a próxima consideração é a versão do SAP ERP que você está executando atualmente:
  • Se você estiver executando a versão mais recente do SAP S/4HANA, terá muitos serviços OData pré-compilados que pode aproveitar para a extração de dados. Na versão mais recente do S/4HANA, existem mais de 2000 serviços OData pré-construídos. A maioria desses serviços OData é criada com a Interface de Usuário Fiori em mente. Para uma extração massiva de dados, é possível aproveitar os extratores SAP BW por meio do ODP, por incluirem mecanismos de gerenciamento de deltas, de monitoramento e de solução de problemas. Os extratores SAP BW fornecem um contexto de aplicação, reduzindo assim o trabalho de transformação no sistema de destino ou no data lake.
  • Se você estiver executando o ECC 6.0 EHP7/8, terá serviços OData pré-compilados limitados, mas ainda poderá aproveitar os extratores SAP BW por meio do ODP para a maioria da extração.
• Se você não tiver o SAP Gateway, provavelmente está executando o SAP ECC 6.0 EHP8 ou anterior. Você pode estar preocupado com o impacto nos mecanismos de extração após realizar um upgrade do sistema SAP. Para minimizar esse impacto, recomendamos o uso de extratores SAP BW Padrão usando ODP, BAPIs Padrão ou IDocs Padrão.
  • Métodos customizados de extração do BW, BAPIs, IDocs, bancos de dados e arquivos são viáveis. No entanto, eles podem aumentar seu TCO (Total Cost of Ownership), pois você mesmo precisará criar, operar e manter o código personalizado.

Você ainda pode usar RFCS/BAPIs e IDocs no S/4HANA, no entanto, como estes são protocolos legados, suas escolhas de ferramentas de extração e opções de conectividade de rede podem ser restritas devido ao fato de que estes protocolos foram criados para ambientes LAN e WAN. Haverá desafios ao usar conexões de internet e esses protocolos podem não funcionar de forma ideal em um ambiente de nuvem híbrido. Portanto, a recomendação continua sendo considerar o OData como a primeira opção, pois é um protocolo de dados abertos que é flexível de implementar e é compatível com ambientes híbridos multi-cloud.

Figura 1. Árvore de Decisão de diretrizes para extrair dados do SAP com os serviços da AWS.

Características do padrão de projeto arquitetônico

Abaixo está um resumo dos Padrões de Design de Arquiteturas e suas características, que são categorizados na árvore de decisão acima. Isso ajudará você a decidir sobre um método de extração para seus dados SAP.

Conclusão

Neste blog, discutimos padrões arquitetônicos para extrair dados do SAP para a AWS. Cada um dos padrões é descrito junto com seus prós e contras com base em considerações importantes, como gerenciamento de deltas, licenças, custos de funcionamento e o impacto de uma atualização. Com a árvore de decisão fornecida, você pode avaliar e decidir qual padrão é adequado para o seu cenário.

Aqui estão algumas referências adicionais que podem ser úteis. Elas descrevem cenários fim a fim que se tornam possíveis quando seus dados SAP são extraídos para 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.

Você pode obter mais informações sobre SAP na AWS, Amazon AppFlow, AWS Glue, AWS Lambda, por meio da Documentação da AWS.

Este artigo foi traduzido do Blog de AWS en Inglês