SAP on HANA

No dia 10 de Janeiro de 2013 um termo apareceu nos trending topics mundial do Twitter: #SAPonHANA. Em se tratando de um tecnologia proprietária, usada por uma uma única empresa e para um público muito específico, isso é um fato que deve chamar a atenção. Foi nesse dia que a SAP anunciou que o seu famoso ERP está disponível para para o novo banco de dados in memory da SAP, o HANA.

Eu nunca escrevi nada sobre SAP on HANA aqui no ABAP101, até porque eu considerava não ser um assunto tão 101 assim, mas acho que está na hora de nossos leitores entrarem em contato com HANA e o entender o que isso mudará em suas vidas de ABAPers.

sap on hana

Quando estamos falando de HANA, a primeira coisa que o ABAPer precisa saber é que ele precisará aprender de SQL. Não estou dizendo que saber fazer um SELECT INTO TABLE é saber SQL. SQL é uma linguagem muito poderosa, mas que por conta da arquitetura do Netweaver preferimos apenas usar o SQL para recuperar os dados do banco de dados e fazer todas as operações na camada do servidor de aplicação.

Isso significa em termos de código, apenas fazer um SELECT simples e armazenar o resultado em uma tabela interna. Qualquer tipo de operação com os dados deveria ser feito no seu programa usando LOOP AT, READ TABLE e outras operações no programa. Qualquer operação do Open SQL é executada na camada de banco de dados e qualquer outro código ABAP é executado pelo servidor de aplicação.

Os dois principais motivos para isso são (1) independência de banco de dados e (2) performance.

Independência de Banco de Dados

No ABAP usamos uma linguagem para manipulação de dados chamada Open SQL. É um sub conjunto de comando do SQL padrão (SQL ANSI) com algumas coisas específicas para o mundo SAP, como por exemplo FOR ALL ENTRIES ou a cláusula IN quando usamos select options ou ranges. O Open SQL é o que podemos chamar de uma abstração do banco de dados, ou seja, é uma maneira da aplicação ficar independente das particularidades do banco de dados. Temos a mesma coisa em outros ambientes, como por exemplo o Hibernate no Java ou o ActiveRecord do Ruby on Rails.

Quando o runtime ABAP encontra uma instrução Open SQL ele traduz isso para o SQL específico do banco de dados instalado naquele ambiente. Cada gerenciador de banco de dados possui suas próprias particularidades em termos de acesso a dados. Praticamente todos os gerenciadores de banco de dados, Oracle, DB2, SQL Server etc. usam SQL como linguagem para acessar os dados, e cada fornecedor pode optar por fazer modificações no SQL padrão para atender a determinadas funcionalidades.

Para que os programas não fiquem específicos para o uso em um determinado banco de dados, o Open SQL faz essa tradução de maneira muito eficiente e transparente. Eu mesmo já trabalhei em muitos ambientes que usavam diversos gerenciadores de bando de dados, mas isso não quer dizer que eu me importe com isso. O que eu preciso saber é Open SQL e ponto final.

Essa independência do SQL do banco de dados trouxe muitas vantagens para a SAP, pois ela não precisa se preocupar em desenvolver e manter diversas versões do mesmo programa para manter a compatibilidade com o banco de dados. Isso permitiu que a SAP em 1992 tivesse uma arquitetura consistente onde as regras de negócio pudessem estar reunidas, permitindo que em 20 anos a SAP adquirisse um conhecimento de processo de negócio muito acima do que qualquer outro concorrente no mundo. Isso foi o que o Vishal Sikka chamou de “tempo-real em 1992″, unificando departamentos antes separados na empresa em uma única unidade de negócio.

Performance

A performance é o segundo motivo para mantermos o processamento na camada de aplicação.

O R/3 tem esse nome não porque foi a evolução do R/2 mas por conta da sua arquitetura em 3 camadas: Apresentação, Aplicação e Banco de Dados.

Na camada de apresentação temos toda a interação com os usuários, seja via SAPGui, browser ou mobile. Em termos práticos você pode pensar na camada de apresentação como sendo seu computador local. Ele atua apenas como um terminal-burro, nenhuma regra de negócio é executada nele, nenhuma validação de tela, nem mesmo verificação de campo obrigatório é feito nessa camada. Ela serve apenas para interagir com o usuário.

As outras duas camadas, Aplicação e Bando de Dados, podem ser vistas como o popular “servidor SAP”. Para nós usuários da infra-estrutura SAP, esses dois elementos podem ser interpretados como sendo uma grande caixa-preta, não nos interessando onde estão, qual sistema operacional, qual configuração de máquina ou quando banco de dados estamos usando. Apenas precisamos saber qual o nome do servidor, ID do sistema e número do sistema para configurar o SAPGui.

Mas não podemos ficar somente com a explicação da caixa-preta, precisamos ir um pouco mais além.

Em termos de infra-estrutura, temos o servidor de aplicação (camada de Aplicação) num servidor e gerenciador de banco de dados em outro servidor. Eles podem estar na mesma sala, em salas separadas, prédios separados ou até mesmo cidades diferentes. Podemos escalar a camada de aplicação em quantos servidores quizermos, conforme a necessidade de processamento. Como não temos nada armazenado no servidor de aplicação, exceto alguns buffers, a escalabilidade dessa camada é bem simples. Já na camada de banco dados isso não é possível. Não podemos simplesmente adicionar novos servidores para dar conta do trabalho como fazemos no caso dos servidores de aplicação, por isso devemos economizar processamento na camada de Bando de Dados.

Daí a necessidade de direcionar o processamento para a camada de aplicação. Por isso apenas recuperamos os dados necessários do bando de dados e fazemos todo trabalho de processamento dos mesmos no programa ABAP. Isso significa que se o time de Basis quiser escalar o sistema, adicionar um novo servidor, mesmo que temporariamente para reforçar a camada de aplicação, isso terá um impacto direto na performance do sistema.

Isso explica SQL não ser um ponto forte do ABAPer. O SQL como linguagem chega a ser quase que secundário no mundo ABAP.

O Que Muda com SAP HANA

Com o HANA, esse cenário mudou. Com o banco de dados da SAP trabalhando totalmente na memória do sistema, a camada de aplicação passa a ser o gargalo. A forma de se pensar muda drasticamente impactando diretamente a maneira de se programar em ABAP.

Antigamente as Store Procedures eram totalmente banidas, agora não somente estão permitidas, mas são incentivadas. Preparem-se para encontrar comandos como CALL STORED PROCEDURE.

Eu estou preparando um material bem completo sobre os impactos do HANA para os ABAPers 101, mas já adianto que é hora de tirar a poeira dos livros de SQL.

É bom estar preparado para isso. Dias bem emocionantes para os ABAPers estão por vir.

Referências

A Promise Delivered – SAP Business Suite Is Now Powered by HANA Autor: Vishal Sikka Link

Você pode gostar...