SAP Gateway Zero-to-Hero — Pt. 6.3
SAP Gateway — Criando seu primeiro serviço baseado em RFC ou BOR
E aweeeee meu povo!!!!
Depois de aprendermos como criar serviços na unha, e baseados na DDIC. É hora de entendemos como funciona a criação do modelo do serviço baseado em Remote Function Call (RFC) ou Business Object Repository (BOR).
Essa capacidade de criarmos nossos serviços baseado em uma função ou BAPI é realmente muito interessante, e muito útil.
Criando o serviço
Clique no botão para criar um novo serviço:
Clique em Import > RFC/BOR Interface:
Será apresentado a seguinte tela de popup, onde:
Essa tela já não é tão estranha, temos que informar como nas outras o nome da entidade, e se desejamos que seja criado o Entity Set (coleção) para a nossa entidade.
As novidades estão em:
- Target System — Onde podemos informar se o objeto em questão seja ele RFC ou BOR está localmente ou em outro ambiente, e então podemos informar um endereço de destino;
- Data Source Attributes — No campo Type será nos apresentado as duas opções RFC ou BOR, logo abaixo você indica qual o nome da RFC ou BOR.
Para que possamos seguir com esse exemplo, irei criar uma função antes com um simples parâmetro de entrada e um outro parâmetro de saída:
Então agora irei informar essa função na tela de seleção, e então teremos algo assim:
Então você será direcionado a uma tela que requer a definição de quais campos serão necessário para utilização do nosso serviço. Mas mais do que isso reparem nos ícones que são utilizados para representar cada estrutura. Esses ícones são referentes:
- Import Parameter;
- Export Parameter;
- Changing Parameter;
- Tables Parameter;
- BAPI Return Parameter;
- Selection Option Parameter.
Atenção com a opção BAPI Return Parameter, este é um retorno baseado no tipo BAPIRET2. Sem dúvida é uma das opções mais úteis ao desenvolver um serviço utilizando o SAP Gateway, isso porque existe uma tratativa que sempre que você disparar uma excessão informando um erro, o gateway entende, e então já preenche essa estrutura, retornando para o cliente uma mensagem amigável informando sobre o problema que ocorreu com o código HTTP mais adequado. #NoDumps #NoInternalServerError #No500.
Na tela seguinte como nos exemplos anteriores, precisamos escolher uma chave para o nosso serviço.
Após finalizado você deve receber uma bela mensagem como abaixo:
Neste post vamos avançar um pouco mais, e vamos fazer o nosso serviço retornar algo um pouco mais interessante que um metadata. Como fizemos antes, gerar o serviço clicando na opção de gerar o serviço:
Depois de verificarmos que o nosso modelo está okay, vamos utilizar a nossa função para com um propósito a mais do que simplesmente tê-la como base para o nosso modelo, usando-a como rotina da nossa implementação.
Implementando o serviço
Agora no service implementation, clique com o botão secundário em GetEntity (Read), e então selecione Map to Data Source:
Será aberto um popup onde você deverá selecionar o destino, se é RFC ou BOR e seu respectivo nome:
Então você voltará para o service builder, mas desta vez com a opção de apenas mapear a função com a interface do seu serviço (modelo)
Utilizando o recurso de arrastar e soltar, é possível arrastar os nós da árvore que simboliza os parâmetros da função para os respectivos campos da interface do serviço.
Feito isso, é necessário regerar o serviço para que as classes MPC e DPC sejam rescritas pelo service builder. Abaixo um exemplo de como é o método que não está implementado, e após o mapeamento e regerar o serviço visto do ABAP Workbench:
Registrando o serviço
Registre o serviço na ICF:
Testando o serviço via postman:
Executando o serviço
No nosso bom e velho postman, vamos executar a implementação do nosso serviço.
Apenas relembrando a nossa função ela possuía um parâmetro de entrada e outro de saída. Um outro ponto é que implementamos um método GET. Sabendo disso o que precisamos fazer é configurar o postman para uma requisição GET e na URI informar um parâmetro de entrada.
Então temos o seguinte:
A grande novidade na imagem acima, é que depois do nome do serviço passamos a informar o nome do modelo e qual o seu respectivo input. Então o serviço já nos retornou a saída que neste caso é o valor MostExpensive.
É possível debugar isso?
Sim, para que isso seja possível você precisará inserir um ponto de parada externo no método que seja debugar, neste caso trata-se do FLIGHTSET_GET_ENTITY. Vejamos como isso funciona:
Um último pontinho…
Voltemos a nossa função e então implementemos um retorno para log de possíveis erros. Para isso faça como na imagem abaixo:
Voltando para a SEGW você perceberá que dando um duplo no MAPPING da implementação do nosso serviço, a nossa tabela de erros já estará referenciada, e note que o ícone dela é apresentado, isso pois apenas por ter declarado uma tabela com o tipo BAPIRET2 o SAP Gateway já entende que trata-se de uma tabela de retorno de logs.
Conclusão
Então pessoal já deu pra perceber que existe bastante coisa para ser aprendido e não foi ainda que realmente implementamos um serviço digno para ser levado à produção.
Então estarei sempre inserindo um novo elemento a cada post. Hoje vimos um pouco mais sobre como funciona a modelagem e implementação de um serviço baseado em uma função, e de forma bem rápida já passamos o nosso primeiro parâmetro via URI, mas iremos aprofundar muito mais que isso. #AguardeConfie.
E é isso ai, não deixe de conferir as referências abaixo, e se curtiu o post não deixe de participar comentando, compartilhando ou simplesmente segurando esse botão de aplausos para mostrar que é esse tipo de conteúdo que você deseja ter por aqui. Muito obrigado e até mais!
