Resposta direta: há quatro caminhos para levar dados do SAP ao Microsoft Fabric: os conectores SAP nativos do Data Factory (Fabric SAP connector), o espelhamento via SAP Datasphere, ferramentas de parceiros certificados pela SAP e a extração por arquivos. A escolha depende da versão do SAP, do volume, da frequência de atualização e das regras contratuais de acesso aos dados, que precisam ser validadas com a SAP.
O Fabric SAP connector é a primeira coisa que o time de TI procura quando decide levar o ERP para o Microsoft Fabric. Mas o conector é só uma das peças. A integração do SAP é o ponto em que mais projetos de dados travam, e quase sempre pelos mesmos motivos: estrutura de tabelas difícil, volume alto e dúvida sobre o que o contrato permite. Este guia mostra os caminhos disponíveis, os cuidados e como começar pelo primeiro módulo.
Por que o SAP é a parte mais difícil da integração?
Porque o SAP organiza o dado para o funcionamento do sistema, e a análise precisa de outra organização. Três fatores pesam:
- Estrutura de tabelas. Nomes técnicos curtos (VBAK, BSEG, MARA), milhares de tabelas e regras de negócio espalhadas entre elas. Montar um faturamento exige juntar várias.
- Volume. Tabelas de documentos contábeis e de movimento de material crescem rápido. Carga completa diária fica inviável.
- Regras de acesso. O caminho técnico de extração precisa respeitar o contrato de licenciamento da SAP. Esse ponto mudou nos últimos anos.
Quais caminhos existem para integrar SAP e Fabric?
O Fabric oferece conectores nativos, espelhamento e integração com parceiros. A tabela resume as opções a partir da documentação de conectividade SAP do Microsoft Fabric e da página oficial de espelhamento SAP:
| Caminho | Fontes SAP | Prós | Contras | Quando usar |
|---|---|---|---|---|
| Conector SAP Table (pipeline) | S/4HANA, ECC | Lê tabelas, views e CDS views; particiona grandes volumes | Exige gateway on premises e driver SAP .NET Connector | Extração direta de tabelas em lote |
| Conector SAP HANA (pipeline, Copy Job, Dataflow Gen2) | HANA, HANA Cloud, Datasphere, BW on HANA | Consultas SQL parametrizadas, particionamento | Depende de acesso ao banco HANA | Quem tem SAP sobre HANA e acesso liberado |
| Conectores SAP BW e BW OpenHub | BW, BW/4HANA | Aproveita modelos já tratados no BW | Herda o desenho do BW | Empresas com BW consolidado |
| OData | S/4HANA, ECC, SuccessFactors | Interface padrão de serviços | Menos performático para grandes volumes | Volumes moderados, serviços já expostos |
| Espelhamento via SAP Datasphere | S/4HANA, ECC, BW, BW/4HANA, Datasphere | Carga inicial e alterações contínuas no OneLake; computação de replicação gratuita no Fabric | Exige SAP Datasphere e cobrança de Premium Outbound Integration da SAP | Quem quer caminho suportado pela SAP e quase tempo real |
| Parceiros certificados (open mirroring) | Diversas | Captura de alterações (CDC) e conectores especializados | Licença adicional do parceiro | Volumes altos e necessidade de CDC |
| Extração por arquivos | Qualquer | Simples para começar | Manual, frágil, sem governança | Prova de conceito ou fontes pontuais |
Todos os conectores SAP nativos rodam pelo gateway de dados on premises (OPDG), com os drivers SAP instalados no servidor do gateway, segundo a Microsoft.
Preciso de licença extra da SAP para extrair dados?
Pode precisar, e isso deve ser confirmado com a SAP ou com o parceiro de licenciamento antes do projeto. Este artigo não é orientação jurídica.
O ponto de atenção mais conhecido é a Nota SAP 3255746. Segundo empresas do setor que publicaram análises da nota, como a Theobald Software, a SAP atualizou a nota em fevereiro de 2024 para informar que clientes e aplicações de terceiros não têm permissão para usar as APIs RFC do framework ODP para acessar fontes ABAP. Em julho de 2024, a SAP passou a indicar o SAP Datasphere para cenários de replicação.
Na prática, isso significa:
- Ferramentas que dependem de ODP via RFC precisam ser reavaliadas.
- O caminho pelo SAP Datasphere é o que a SAP indica, mas tem custo próprio.
- Conectores de tabela e OData têm outras regras. Valide cada caminho no seu contrato.
Recomendação beAnalytic: levar a decisão do caminho de extração ao comitê com TI, jurídico e o parceiro SAP antes de qualquer desenvolvimento.
Como evitar cargas completas diárias do SAP?
Com carga incremental desde o primeiro dia. Recarregar BSEG ou MSEG inteiras todos os dias consome capacidade, tempo e janela do servidor SAP.
As técnicas mais usadas:
- Campos de data de alteração nas tabelas de documento, quando existem e são confiáveis.
- CDS views com delta, expostas pelo S/4HANA.
- Espelhamento ou CDC de parceiros, que já entregam só as alterações.
- Partições por período para a carga histórica inicial, feita uma única vez.
Um cuidado: o gateway on premises vira gargalo se for dimensionado como servidor de arquivos. Ele precisa de CPU, memória e rede compatíveis com o volume.
Como modelar os dados do SAP no Lakehouse?
Em camadas, separando o dado bruto do SAP do dado pronto para o negócio. O padrão que usamos é a arquitetura medalhão com bronze, prata e ouro:
| Camada | O que entra | Exemplo SAP |
|---|---|---|
| Bronze | Tabelas como vêm do SAP | VBAK, VBAP, BKPF, BSEG, EKKO |
| Prata | Dados limpos, com nomes de negócio e chaves tratadas | Pedidos de venda com cliente e material |
| Ouro | Fatos e dimensões por área | Vendas, contas a receber, compras e estoque |
Começar por uma área (vendas, financeiro ou suprimentos) e entregar o painel dessa área antes de abrir a próxima reduz risco e mostra valor cedo.
Caso ilustrativo: primeiro módulo SAP no Fabric em nove semanas
Cenário ilustrativo, montado a partir de situações comuns em projetos de integração de ERP. A empresa e os números são hipotéticos; os conectores e regras citados são os oficiais.
Contexto. Uma indústria de alimentos com três fábricas usa SAP S/4HANA on premises. O fechamento comercial dependia de extrações manuais em Excel e só ficava pronto no quinto dia útil do mês (D+5). A diretoria queria vendas e faturamento no Power BI, com atualização diária.
Escolha do caminho. Depois de validar com o parceiro SAP e com o jurídico, a empresa optou pelo conector SAP Table em pipelines do Fabric, lendo CDS views de vendas e faturamento com delta, pelo gateway on premises em uma VM dedicada.
Cronograma do primeiro módulo (vendas e faturamento).
| Semanas | Entrega |
|---|---|
| 1 e 2 | Validação contratual, usuário técnico, autorizações e gateway |
| 3 e 4 | Carga histórica de 3 anos por partições mensais na camada bronze |
| 5 e 6 | Camada prata com regras de estorno, status de documento e centros |
| 7 e 8 | Camada ouro e modelo semântico de vendas |
| 9 | Validação com o comercial e a controladoria e entrada em produção |
Resultado.
| Indicador | Antes | Depois |
|---|---|---|
| Tempo da carga diária | 3h40 (extração completa) | 18 minutos (incremental) |
| Fechamento comercial | D+5 | D+1 |
| Divergência entre comercial e controladoria | Discussão mensal | Número único, reconciliado com o SAP |
O que esse cenário ensina: o maior esforço ficou nas semanas 5 e 6, entendendo regras de negócio dentro das tabelas SAP. A extração em si foi a parte mais rápida. O segundo módulo (financeiro) reaproveitou gateway, padrão de camadas e validações, e ficou pronto em metade do tempo.
A beAnalytic já executou projetos de dados com SAP em grandes contas, como em um grupo de bioenergia com réplica dos dados SAP para o SAP Datasphere, e é dessa experiência que vêm as práticas deste guia.
Checklist antes de começar a integração SAP com Fabric
- Versão do SAP: ECC, S/4HANA on premises, S/4HANA Cloud, BW ou BW/4HANA.
- Banco de dados: HANA ou outro, e se o acesso direto é permitido.
- Caminho de extração: validado com a SAP e com o jurídico.
- Acessos: usuário técnico, autorizações e liberação de rede para o gateway.
- Volume: tamanho das principais tabelas e crescimento mensal.
- Frequência: diária, horária ou quase tempo real, por área.
- Prioridade de módulos: qual área entra primeiro.
- Dono do dado: quem valida o número em cada área.
Resumo para encaminhar à diretoria
- Problema: os dados do SAP precisam chegar ao Fabric com segurança, sem sobrecarregar o ERP e dentro do contrato.
- Opções: conectores nativos do Data Factory, espelhamento via SAP Datasphere, parceiros certificados ou arquivos.
- Custo ou risco: o caminho escolhido pode exigir licença SAP adicional (Datasphere ou parceiro); extração fora do contrato é risco jurídico.
- Recomendação: validar o caminho com a SAP, começar por um módulo e usar carga incremental desde o início.
- Próximo passo: avaliação de integração SAP com Fabric, cobrindo versão, acessos, volume e prioridade de módulos.
Perguntas frequentes sobre integração SAP e Fabric
Preciso de licença extra da SAP para extrair dados?
Depende do caminho e do seu contrato. O espelhamento via SAP Datasphere tem cobrança de Premium Outbound Integration da SAP, e o uso de ODP via RFC por terceiros é tratado na Nota SAP 3255746. Confirme com a SAP antes do projeto.
Funciona com SAP ECC e com S/4HANA?
Sim. O conector SAP Table atende ECC e S/4HANA, e o espelhamento via SAP Datasphere suporta S/4HANA, ECC, BW e BW/4HANA, segundo a Microsoft.
Dá para ter dados em tempo real?
Quase tempo real é possível com espelhamento ou CDC de parceiros. Para a maioria dos painéis de gestão, atualizações a cada poucas horas bastam e custam menos.
Quanto tempo leva o primeiro módulo?
Depende de acessos, volume e regras de negócio. O primeiro módulo é o mais longo, porque inclui gateway, acessos e o padrão de camadas que os próximos vão reaproveitar.
Preciso de gateway on premises?
Para os conectores SAP nativos do Data Factory, sim: todos rodam pelo gateway de dados on premises, com os drivers SAP instalados. O espelhamento via SAP Datasphere usa um armazenamento ADLS Gen2 intermediário.
Vai levar o SAP para o Fabric? A beAnalytic é consultoria de dados e implementa a integração de ERP de ponta a ponta, da extração ao painel. Peça uma avaliação de integração SAP com Fabric com a nossa consultoria de engenharia de dados, veja como migrar do Azure Data Factory para o Fabric ou escreva para [email protected].
Daniel Luz
CEO da beAnalytic. Na liderança da empresa há mais de 6 anos, minha missão é transformar a forma como as organizações enxergam e utilizam dados para tomar decisões estratégicas. Ajudo empresas a destravar insights valiosos, impulsionar eficiência operacional e gerar impacto financeiro real, com uma equipe especializada em Business Intelligence, Engenharia de Dados e Machine Learning.
