Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
henrique_pinto
Active Contributor

Historicamente, os clientes em projeto de implementação das aplicações SAP, em particular do SAP ERP, tinham 3 maneiras mais comuns para atender às demandas analíticas e/ou de relatórios operacionais das áreas de negócios, a saber:

  • SQVI (SAP Quick Viewer): ainda existe, apesar de muito pouco usada hoje em dia. É uma transação user-specific para geração de relatórios simples, baseada no relacionamentos entre tabelas do SAP ERP. Pode ser útil para testes rápidos em desenvolvimento, mas também pode ser mas muito perigosa em produção, na mão de usuários mais "audaciosos". Por isso tipicamente é bloqueada na produção de 999 em 1000 clientes (sempre tem um MacGyver).
  • Relatórios ABAP: a maneira encontrada para limitar a liberdade dada pela SQVI mas ainda permitir a visão necessária para o negócio. O lado negativo claro é a dependência de desenvolvimento de código ABAP para qualquer nova demanda de relatório e, pior, qualquer simples modificação em relatórios existentes (a manutenção "eterna"), o que limita em muito a flexibilidade do negócio.
  • SAP BW: Além dos pontos negativos já descritos acima, os 2 modelos anteriores também tinham a desvantagem de serem executadas diretamente no ambiente transacional. Para relatórios mais simples, isso não gerava impacto, mas para relatórios mais pesados, especialmente em períodos de pico (por exemplo, em dia de fechamento), isso significava que executar um relatório desses poderia causar uma parada no sistema corporativo e impedir o resto da empresa de gerar faturas, criar pedidos, pagar contas, etc. momentaneamente. Basicamente, executar um relatório desses poderia parar todo o resto da empresa. Por isso, criou-se o mecanismo de extrair-se os dados do ambiente transacional para um outro ambiente dito analítico, tipicamente de madrugada, para que, durante o dia, pudessem ser gerados quaisquer relatórios necessários para o negócio sem impacto algum para o resto da empresa. No mundo de TI, esse ambiente analítico convencionou-se chamar de Data Warehouse (DW). No mundo SAP, em particular, o DW se chama SAP Business Warehouse (SAP BW). O BW era então a 3a maneira disponível para geração de relatórios operacionais e analíticos. Apesar da vantagem óbvia de não impactar o ambiente transacional em tempo de operação diurna (pois a carga ocorria de madrugada), o uso do BW para geração de relatórios trazia como ponto negativo, além do custo de infraestrutura adicional, o fato de que esses relatórios traziam sempre uma visão do passado (D-1), pois em um determinado dia, o ambiente analítico sempre estava carregado com os dados transacionais do dia anterior. Para alguns cenários de negócio, isso pode não gerar nenhum impacto, mas outros cenários podem demandar uma visão bem próxima do "tempo real". Por exemplo, para uma visão de estoques, não adianta saber quanto a empresa tinha no estoque semana passada ou ontem, precisamos saber quanto ela tem agora para saber se conseguimos honrar uma nova ordem de venda ou não sem precisar gerar uma nova ordem de produção.

O fato é que cada uma dessas três maneiras está longe de ser perfeita. É o chamado "se correr o bicho pega, se ficar o bicho come". Mesmo o BW, em teoria  a maneira mais elegante de resolver esse tipo de demanda e com melhor governança dos dados e objetos, é também a mais custosa para os clientes, pois envolve muitos custos de hardware e de consultoria, além de ser também a mais a demorada para novas entregas para as áreas usuárias. Por isso, esse tema sempre foi um ponto de muitas reclamações dos clientes para a SAP, e também alvo de busca de soluções alternativas de fornecedores externos por muitos clientes. O fato é que não existe mágica, e enquanto a arquitetura de soluções fosse baseada em bancos relacionais, cópias dos dados iriam continuar sendo necessárias e modelos multidimensionais (os chamados "cubos") tais quais os criados no BW iriam continuar tendo que ser criados, seja no BW, seja em quaisquer outros data warehouses.

Com o advento do SAP HANA, com sua capacidade de processamento paralelo massivo em memória, aquele velho problema de processar relatórios ao mesmo tempo em que o sistema transacional realizava as operações do dia-a-dia deixa de existir, pois o gargalo tecnológico que causava o problema era justamente a arquitetura baseada em bancos relacionais das aplicações de outrora (que por sua vez eram limitados pelo barramento de I/O dos discos). As aplicações baseadas no SAP HANA deixam de ter esse problema, e passam a ter a capacidade de processar cargas analíticas e transacionais no mesmo ambiente (OLAP e OLTP na mesma camada). Com isso, surge um novo paradigma de modelagem analítica não possível anteriormente, onde os modelos multidimensionais antes criados no DW externo podem passar a ser criados diretamente sobre o ambiente transacional, porém sem demandar uma transformação física do dado, sendo, portanto, modelos lógicos. No caso das aplicações SAP, esse conjunto de modelos lógicos para as mais diversas áreas de negócio, um Business Content nativo do HANA, chama-se HANA Live.

Com essa capacidade nativa das novas aplicações, muitos clientes questionam se ainda faz sentido manter o BW ativo numa arquitetura com aplicações baseadas em SAP HANA. Mesmo com o BW on HANA, que elimina a necessidade de algumas estruturas que eram necessárias no BW clássico e que permite uma modelagem simplificada e até mesmo lógica, com os Composite Providers, introduzidos no BW 7.31 e melhorados no BW 7.4, e com a Advanced DSO, que elimina a necessidade de cubos e PSAs e pode passar a ser a única camada de persistência no BW, de fato ele ainda demanda uma modelagem específica, replicação e transformação adicional dos dados transacionais. E esse é justamente o ponto. Existem cenários em que essas transformações e replicações fazem-se necessárias, e que portanto uma camada de persistência adicional não é indesejada mas sim um requerimento de modelagem. Nesses casos, a modelagem lógica não seria uma decisão inteligente pois poderia ser pior em termos de performance, já que fazer uma transformação muito pesada a todo momento em tempo de execução seria pior do que fazer somente uma vez e persistir o resultado. Outro caso de uso que pode fazer sentido replicar/persistir é quanto existem dados de múltiplas fontes de dados externas que se quer consolidar num único DW (e quanto a federação/virtualização de dados não fizer sentido). Um terceiro caso de uso são as aplicações de planejamento e consolidação (BIP/PAK, BPC, etc.).

Assim, existem sim casos em que o BW ainda fará sentido como paradigma de modelagem. Nesse sentido, a SAP evoluiu suas ferramentas de modelagem analítica de maneira a se combinarem de maneira transparente, de modo que os clientes consigam decidir em tempo de design a melhor modelagem que atenda à necessidade de negócio daquela demanda específica. Os clientes não mais precisarão ficar presos a um método único e ter que se limitar àquele método até o fim dos tempos (leia-se, até o próximo upgrade). Esse modelo híbrido de modelagem está disponível num novo conceito de Data Warehouse corporativo SAP, o chamado HANA EDW, apresentado abaixo.

Note que, apesar do nome, o conceito do HANA EDW pode coexistir, do ponto de vista de infraestrutura, com as aplicações transacionais, devido às capacidades em memória do SAP HANA. E na verdade, ele foi concebido para isso, para simplificar os landscapes das grandes corporações e eliminar as cópias de dados redundantes.

Agora, um exemplo mais prático do que esse novo paradigma de modelagem permite fazer. Digamos que a área de vendas queira um relatório que compare as quantidades das ordens em aberto desse período com a quantidade vendida no mesmo período ano passado. Até aí tudo bem, certo? Mas eles querem que o período corrente seja atualizado em tempo real! Seria algo bem complexo se não fosse trivial com o SAP HANA! Com um modelo combinando dados mestres do BW, dados históricos do BW e dados de vendas de uma Reuse View standard de SD do HANA Live, todos em uma mesma composite provider, é possível consumir tudo através de uma BEx Query mantendo as mesmas estruturas e hierarquias que já existem hoje. Ou, para quem não é muito fã do BEx, é só expor a Composite Provider como uma view do HANA (o que é feito com um clique de mouse, literalmente) e consumir através de alguma ferramenta que consuma SQL através de ODBC ou JDBC, como o SAP Lumira, por exemplo. Abaixo, um diagrama do que acabei de descrever:

E abaixo o resultado final, consumindo o relatório via BEx Query.

Com o SAP HANA, uma nova possibilidade de arquitetura se abre, porém essa possibilidade não é restritiva e sim colaborativa. Se você me perguntar hoje "Com qual modelo devo seguir - BW on HANA ou HANA Live?" eu diria "e por que você tem que escolher? Siga com os dois!". A melhor arquitetura para estar preparado para atender às mais diversas demandas do negócio é a arquitetura híbrida, e só o SAP HANA permite essa possibilidade, dando ao cliente a liberdade e a flexibilidade de escolher a melhor maneira de atender as necessidades do seu negócio sem se restringir ao modelo A ou B.

4 Comments
Labels in this area