SAP Netweaver Gateway – Do que se trata essa parada?

HANA, SAPUI5, Gateway, Lumira, HANA, River, Fiori, Cloud, HANA, HANA, HANA, etc, etc, etc… Tanta coisa nova, não é mesmo? Quem trabalha com SAP já deve estar careca de saber que de tempos em tempos aparece uma nova avalanche de nomes e siglas e conceitos e slides e guias e livros e… um bando de desenvolvedores perdidos sentindo-se ultrapassados.

Recentemente eu tive um pouco de contato com uma das ferramentas dessa nova onda de produtos. Fucei um pouco no SAP Netweaver Gateway e vim contar um pouco pra vocês do que se trata essa parada, para que você não fique cambaleando perdido no escritório.

Apesar do Gateway parecer uma coisa extremamente recente, ele já deu as caras no mundo SAP há pelo menos uns 2/3 anos. Sabe como é, leva tempo para as coisas ficarem um pouco mais robustas e terem uma utilização maior em clientes. Particularmente enxergo uma grande utilização do Gateway no futuro, já que o negócio é beeeem firmeza.

Mas antes eu preciso preparar você, caro leitor, para entender os motivos que levaram a SAP a criar essa ferramenta. Por conta disso, antes de explicar a ferramenta, vamos falar um pouco sobre interfaces com usuário.

User Interfaces

Todo mundo aqui já olhou para alguma tela do SAP e pensou “nossa, que lixo“. O maior mérito das telas da SAP Gui atuais é a velocidade, tanto de desenvolvimento quanto de uso. Mas ela são feias de dar dor, parecem extremamente ultrapassadas. O ABAP puro dispõe do Webdynpro e BSPs para tentar gerar alguma coisa menos bizarra, mas ambas as tecnologias não são muito populares. O que mais se cria é aquela boa e velha tela 9000 e com aquele ALVzão gigantesco cheio de botões e ícones que não explicam nada da ação daqueles botões (eu já vi um Refresh com o ícone de um cara empurrando caixas).

A questão é que a experiência do usuário com outras tecnologias tem mudado bastante. Não é mais uma questão de comodidade acessar um sistema empresarial por um celular ou tablet, é uma necessidade. O design de aplicativos em geral tende a interfaces extremamente simples, mas com uma inteligência robusta e complexa por trás.

Pense em como você fazia antigamente para comprar um ingresso de cinema: você precisava arranjar um jornal com os horários e dias, ir até o cinema, enfrentar uma fila enorme, descobrir na hora se existe ou não sessão para o filme que você quer ver… Hoje, com um celular você consegue fazer tudo: desde a avaliação da disponibilidade até a compra efetiva. E nem precisa imprimir o ingresso, apresentando o ticket na tela do celular você entra no cinema. Talvez não tenha aí na sua cidade, mas aqui em SP eu uso muito esse esquema.

Aos poucos, essas facilidades existentes em algumas áreas começam a criar um sentimento de dúvida: será que em outros ramos (sem ser o cinema), é possível criar sistemas que simplifiquem processos complexos? Esse tipo de dúvida ronda o mundo corporativo e de softwares empresariais diariamente.

Bem, sei que falar de apps corporativos para celulares, tablets e web é chover no molhado, mas muito pouco disso ainda é realidade no mundo SAP. Primeiro que o ABAPer médio mal fica sabendo dessas tecnologias de UI modernas, ele mal vê um Webdynpro na vida fora do GRC (me conta 10 telas de Webdynpro que você conhecer sem ser do GRC, valendooooo). Segundo que o caso mais levantado é sempre a aprovação de XYZ pelo celular. Perdi a conta de quantas vezes ouvi falar da empresa X ou Y que tem toda uma plataforma de mobilidade que serve para fazer aprovações e mais nada. Essa falta de inovação pode ser uma particularidade do mercado brasileiro, mas em parte acredito estar atrelada a licenças malucas e complexidade de explicar esse monte de siglas e variações para as empresas (dificultando, portanto, a venda).

Enfim, esse mundo é um caos, todos já sabem, inclusive a própria SAP. Engana-se você se pensa que a gigante alemã não sabe dos problemas de usabilidade de seus produtos. É muito fácil achar informação na web sobre SAP e UX, com sites dedicados ao tema e até cursos para explicar as novas possibilidades. Como dizia minha mãe: “quando você está indo, eles já estão voltando”.

Pensando na nossa carreira como ABAPers, precisamos entender qual parte dessas novas coisas relacionadas a UI e experiência do usuário podem ter um impacto em nossas vidas de debuggadores. Particularmente, acredito que o SAP Netweaver Gateway é um dos produtos que têm mais chances de ver a luz do dia nas suas mãos digitadoras de código. Calma que eu explico.

“Me consuma”, diz o OData

Depois de toda essa coisa louca que eu falei de Interfaces, pense no esforço necessário para adaptar todas as telas e códigos do ERP (standards e customizadas) para tecnologias de UI modernas. Parece um trabalho insano, não é? Provavelmente, quando o trabalho estivesse concluído (se é que seja possível terminá-lo), as novas telas já estariam defasadas, dada a quantidade monstruosa de tempo necessário para fazer tal adaptação.

Não seria mais fácil, então, prover algum meio de aplicações externas acessarem os dados do ERP de uma forma consistente e gerenciável, desenvolvendo a UI em outras tecnologias? Dessa forma a SAP quebra as amarras das telas do seu sistema: o cliente pode consumir dados do ERP a partir de qualquer tipo de aplicação que ele quiser (e sonhar), criando uma UI específica para seus propósitos. É exatamente para tratar esse tipo de cenário que foi criado o SAP Netweaver Gateway.

Através do Gateway, desenvolvedores ABAP podem modelar um serviço ODATA(Open Data Protocol) para ser consumindo por alguma fonte externa. Essa fonte externa pode ser absolutamente qualquer sistema ou tecnologia que consiga consumir um serviço OData, seja ele um aplicativo web, um aplicativo mobile, um aplicativo desktop, uma máquina de café… Você cria esses serviços por uma transação específica, a SEGW:

Para entender o funcionamento completo do Gateway, é preciso estudar um pouco mais do protocolo ODATA e da arquitetura REST, mas isso sai do escopo deste singelo post. O importante é você saber que existe uma ferramenta da SAP que permite que um sistema externo Consulte, Atualize, Crie ou Apague dados do ERP, executando código ABAP.  Nesse cenário, o ABAPer terá a função de desenvolvedor backend, tratando os dados e criando lógicas consistentes para que o aplicativo externo possa consumir a informação já trabalhada. Se você odeia desenhar telas e não entende nada de desenvolvimento frontend, essa parada de desenvolvedor backend pode ser um caminho para o seu futuro.

Muitas siglas? Muitos nomes novos? Muita animação e confusão? Vamos ser mais práticos.

Quero fazer uma tela muito louca para buscar dados de um material e preciso de algo do lado ABAP que retorne os dados de alguma forma, para que a minha aplicação web possa exibi-los em um quadrado que dá piruetas. Supondo que eu tenha criado um serviço OData com o Gateway, a app web vai lá e acessa o serviço OData por uma URL (a partir de um nó da SICF gerado pelo Gateway):

Que dispara um método de uma Classe do lado ABAP (também gerada pelo Gateway). Nesse método, você vai lá e faz seus SELECTs, BAPIs e marretadas para retornar os dados do Material. Isso então é formatado em um XML e retornado para o sistema web que chamou o serviço:

Daí para frente, a aplicação que consumiu o serviço faz o que ela quiser.

Não precisa ser só uma busca: pode ser uma ação de deletar, criar, alterar… Esse monte de informações e tags que você está vendo aí em cima é um XML que segue um padrão hierárquico definido por você na hora de criar o serviço OData (prefere outros formatos, tipo o JSON? Também dá!). Aí no meio desse print tem as informações dos materiais e também das ordens de vendas ligadas ao material (caça o milho aê! 🙂 ).

No Gateway, através da transação SEGW, você modela o serviço OData, definido a estrutura do serviço (dados de entrada/saída, associações, etc, etc) e ele cria para você as classes, entradas na SICF e todos os paranauês que são necessários para que alguém possa consumir o serviço. Tem ainda um monte de logs e variações e opções e usos e telas e tudo que você esperaria de algo da SAP.

Esse negócio é um mundo à parte. A explicação cobre um cenário muito básico, só para que você entenda do que se trata. Tem tanta coisa que precisa de um livro para explorar todas as possibillidades (tipo esse aqui).

Mas ué, não é tipo o PI isso aí?

Esse conceito básico do Gateway é alvo de muita confusão com outro produto da SAP: o PI, middleware para gerenciamento de interfaces.

Todas as features do Gateway focam em prover os dados do ERP de forma que possam ser consumidos e/ou manipulados por aplicação externas que envolvam ações do usuário. Já o PI tem uma abragência muito maior, atuando como um ponto único para integrações de qualquer natureza entre o SAP e sistemas externos. Apesar de parecerem similares, o posicionamento de cada ferramenta é bem diferente dentro do ecossistema.

“E por que você acha que isso vai dar jogo?”

O SAP Netweaver Gateway é novo (criado em meados de 2011), portanto a aderência ainda não é ampla. Porém, veja só que bacana, a partir da versão 7.4 o Gateway vem embutido por padrão no pacotão do ABAPão. Não precisa de licença, ajoelhar no milho, benção do CIO, nada disso. É só ir lá, usar e fim.

Mesmo se você não estiver na 7.4, você ainda pode instalar o Gateway de forma separada, através de um add-on. Este link contém a disponibilidade por versões.

Ora, se a SAP criou a plataforma para prover dados para serem consumidos externamente, o que a impede de criar seus próprios aplicativos para exibir essas informações? Ela já criou pequeno mancebo, é um tal de SAP Fiori (que pretendo explicar num post futuro). Esses caras não dão ponto sem nó, é ou não é?

Termino assim esta singela explicação do Gateway. Espero que você tenha conseguido absorver pelo menos a idéia de existir uma coisa mágica que provê dados do ERP para serem consumidos, envolvendo programação ABAP. Agora volta lá para debuggar que daqui uns 3 ou 4 anos você usa isso (eu nunca disse que ia pegar rápido 😉 ).

Abraços a todos que já consumiram coisas bem piores que um serviço OData.