SAP Gateway – Por que conhecer?

De tempos para cá tenho acompanhado um grupo de ABAP no Skype (aliás, parece haver uma centena deles) e por consequência estou acompanhando vagas que postam por lá. Vire e mexe surge uma vaga ou outra pedindo horrores em termos de quantidade de qualificações técnicas. Todavia há algum tempo tenho notado uma crescente procura por profissionais que conheçam SAP Gateway. Como estou num projeto que envolve muito disso também, resolvi dar meus 30 centavos aqui.

Um pouco de história

Lembro-me do meu primeiro SAP Inside Track por volta de 2010. Foi a primeira vez que ouvi falar no SAP Gateway. Na época, nunca tinha ouvido falar em HANA (afinal, ele era mega embrionário na época), UI5 nem existia e a febre do momento era mobilidade. Na época muita gente estava sonhando ficar trilionária construindo apps.

E por que o Gateway se encaixava nisso? Pois com ele um desenvolvedor ABAP pode criar de maneira “simples” um serviço que possa ser consumido por um mundo externo, por exemplo um iPhone.

E é aí que mora uma das principais diferenças entre o este e o PI (cuja confusão é mais frequente do que deveria). Sistemas de que consomem dados de serviços criados via Gateway são tipicamente clientes, pertencentes a camada de apresentação do modelo em três camadas.

Gateway, RESTFull e oData

Mais importante ainda, os serviços criados via SAP Gateway são consumidos usando HTTP, que é um protocolo de internet e não proprietário como as RFCs. Se você conhece serviços RESTfull, saiba que o SAP Gateway te permite criar serviços deste tipo.

Contudo, não é qualquer tipo de serviço RESTFull. O SAP Gateway segue o padrão de indústria criado pela Microsoft chamado oData. Isso facilita ainda mais a construção e adoção de tais serviços. O HANA tem esta capacidade nativamente, já o NetWeaver precisa de alguns componentes instalados para ter tal capacidade. o Gateway é um add-on de ABAP!

E por que só agora preciso disso?

Segundo a página de FAQ na SCN, em 2013 já eram 8000 instâncias com Gateway mundialmente falando, logo a onde bem dizer não está começando agora.

O motivo principal para a crescente demanda em Gateway tem tudo a ver com o crescimento da demanda em Fiori. Isso pois todas as aplicações Fiori (criadas usando o famoso SAPUI5) consomem dados do SAP criados via SAP Gateway.

Logo, para criar uma aplicação Fiori, suas telas serão feitas em UI5, enquanto o seu código ABAP que faz algum select, em algum lugar, de alguma forma, está encapsulado num projeto criado pela transação SEGW. Isso é ABAP também.

E é difícil?

Particularmente, não acho o aprendizado do SAP Gateway complicado. Um dos principais desafios é você arrumar uma forma inteligente de não esbarrar nas suas limitações. Algo que acho muito interessante é o pensamento que se deve ter para modelar o seu projeto no Gateway. O raciocínio é diferente se comparado em termos de modelagem de banco.

Mas como diria São Fransico: “Comece fazendo o que é necessário, depois o que é possível, e de repente você estará fazendo o impossível.“. Independente quão fácil ou difícil é aprender Gateway, um ABAP que se preze hoje deveria estar preocupado em aprender.

E para quem já está estudando UI5, este é um dos melhores complementos que você poderá ter. Aprendendo o SAP Gateway a classe oDataModel vai ficar muito mais fácil de entender e se trabalhar. Curiosamente é esta classe que é usada em todas as aplicações standard Fiori.

O que fazer agora?

Há (mais) um post muito bom do ABAPZombie sobre o Gateway, recomendo a leitura. No mais, não perca mais tempo, comece a estudar isso. Comece indo na SCN e lendo o máximo que puder.