SAP Gateway Zero-to-Hero — Pt. 6.2

SAP Gateway — Criando seu primeiro serviço baseado na DDIC

Erick Carvalho
Bar8
Published in
6 min readDec 1, 2017

--

E aweeee meu povo!!!!

No ultimo post entendemos sobre os processos básicos na criação de um serviço, partindo da criação do modelo, implementação com ativação. E para que isso fosse possível exploramos recursos do Service Builder (SEGW) juntamente com suas ferramentas.

Hoje vamos continuar na mesma linha, e faremos basicamente tudo que fizemos no último post, mas dessa vez iremos criar o nosso serviço baseado em uma estrutura da DDIC.

Criando o projeto

Então novamente, clique no botão para criar um novo serviço:

Após confirmar, clique em Data Model com o botão secundário, e então selecione a opção Import > DDIC Structure

Um popup será apresentado, como fizemos antes você deve sugerir um nome para a sua entidade, eu irei repetir o nome da entidade que fizemos no post passado. Em seguida você deverá escolher se essa entidade é:

  • Entity type — Podemos seguir o conceito básico de banco de dados onde uma entidade (entity) é um objeto que existe e é distinguível dos outros objetos. E por isso é necessário possuir chaves, para que se tenha a capacidade de ser única em algum aspecto. Uma entidade pode ser concreta, como uma pessoa ou um livro, ou pode ser abstrata, como um feriado ou um conceito.
  • Complex type — O maior diferencial quando utilizado um tipo complex é que eles consistem em uma coleção de propriedades sem uma chave exclusiva, elas só podem existir como propriedades de uma entidade que contém ou, fora de uma entidade, como um valor temporário. No entanto, os tipos complexos podem conter outros tipos complexos, ou seja, eles podem ter uma estrutura aninhada. Importante: Dentro de um tipo complexo, a cardinalidade é sempre 1:1.

Logo após escolher qual o tipo da sua entidade, você deverá informar qual estrutura da DDIC faz referencia para o seu serviço, no nosso caso utilizaremos a SFLIGHT. É aceitável como estrutura DDIC Estruturas, tabelas e visões.

Escolhido a estrutura, você pode optar para que seja criado a coleção da sua entidade ou não, assim como vimos no post anterior.

Então você será direcionado para um outro popup, onde você definirá quais os campos da estrutura citada anteriormente, fará parte do seu serviço. No nosso caso irei escolher todos os campos.

Após confirmar, você será direcionado a última tela para que você escolha qual será o campo chave ou quais serão os campos chaves do seu serviço.

Após finalizar você terá a confirmação se a criação e mapeamento ocorreu com sucesso.

Perceba que no post anterior, havíamos conseguido criar nosso serviço com todos os ícones verdes, entretanto utilizando o mapeamento para a DDIC, conseguimos mapear nosso modelo, entretanto com alertas.

Isso é justificável e explico o porquê. Abra as propriedades da entidade que acabamos de criar, como na imagem abaixo:

Perceba que utilizando esse tipo de mapeamento, muito do trabalho é adiantado. Até mesmo as traduções são feitas.

A criação de serviço é necessária para que seja possível expor informações para outras plataformas. Isso significa que precisamos trabalhar com tipos mais genéricos de dados, o cliente que está consumindo nosso serviço não sabe o que é um elemento de dados, e muito menos o que é S_CONN_ID ou S_CARR_ID.

Então para que um cliente possa consumir dados, precisamos trabalhar com tipos primitivos mais genéricos, e que ao menos sejam de conhecimento de outras linguagens. Então para isso temos:

Não vou investir tempo explicando cada um desses tipos, mas vou procurar utilizar diferentes tipos nos próximos posts para que seja possível entender o comportamento de cada um.

Portanto, quando pedimos para o service builder mapear a DDIC e criar o nosso serviço, ele pega o campo S_CARR_ID que é um char de 3 posições, baseado na lista acima, o que mais se aproxima disso é o Edm.String, e então informamos que terá o tamanho máximo de 3 caracteres.

Sabemos que isso irá funcionar, pois o tipo String nada mais é que um array de char, entretanto o SAP Gateway sempre irá nos alertar que houve uma adaptação, e será necessário atenção para que não exista perda de informação.

Implementação do serviço

Após o mapeamento, clique no botão para gerar o serviço, e então será criado as classes MPC e DPC, além da SRV e MDL igualzinho ao que ocorreu no post anterior.

Como já solicitamos que fosse criado a coleção da nossa entidade, neste caso bastaria um clique com o botão secundário em um dos métodos disponíveis, e então iniciar a nossa implementação.

Após serviço ativado, é hora de registrar.

Registrando o serviço

Desta vez, irei cortar caminho e utilizarei a opção de registrar o serviço pelo próprio service builder.

Após clique duplo em Service Maintenance, do lado direito clico em Register e agora será apresentado a seguinte tela:

No meu caso estou informando o system alias que previamente cadastrei na SPRO como local. Após confirmar será aberta a tela de registro do serviço como já fizemos no post anterior, e então é só confirmar, e teremos o seguinte:

Serviço ativado

Consumindo o serviço

Novamente no nosso querido postman, vamos consumir o nosso serviço para saber se está tudo certo, mas dessa vez queremos ver toda a especificação do nosso serviço, para isso logo após o nome do serviço vamos inserir $metadata, e o resultado é o seguinte:

Veja que legal, além de conseguirmos saber se o nosso serviço está ativo, agora também sabemos quais são as suas propriedades e que tipos de dados devemos passar quando formos consumir um serviço

Conclusão

Então de forma bastante simples aqui temos um modelo de serviço criado baseado em uma estrutura DDIC :).

--

--

Editor for

Agilista, Desenvolvedor e quando não está discutindo TDD está sendo repreendido por algum comentário infeliz