Criando Mocks de serviços REST com SoapUI

SoapUIO que podemos fazer quando precisamos de um serviço REST para concluir um desenvolvimento ou simular algum cenário de teste e o serviço em questão não está pronto ainda? Utilizamos mocks!
O SoapUI é uma ferramenta para testes de serviços SOAP e REST que nos permite também criar mocks para WebServices. Ou seja, com ele conseguimos simular um serviço REST executando como se fosse um serviço real.

A ideia deste post é mostrar como criar esses mocks de uma maneira simples utilizando o SoapUI.

O primeiro passo é criar um projeto de teste no SoapUI. Para isso clique em: “File > New REST Project” e defina um nome para o seu projeto.

Após isso, clique em “Project > New REST MockService”, será criado um elemento dentro do projeto do SoapUI.  No exemplo o nome dado para o elemento de mock foi “Produto”.

1

Figura 1 – Criando projeto de mock para REST

Depois de criado o elemento, é necessário configurar as propriedades do serviço que iremos simular. No exemplo vamos fazer um mock de um serviço que insere e consulta um produto. Para isso, definimos na aba “Custom Properties” as propriedades que devem ser informadas no request da requisição, no caso as propriedades serão nome e quantidade.

4Figura 2 – Definindo propriedades do serviço

O próximo passo é criar um mock para cada tipo de método que o serviço pode oferecer, no caso do exemplo, vamos criar um mock do método POST para a inserção de um produto e um mock do método GET para consultar o produto criado. Para isso, clique com o botão direito no elemento “Produto” e clique em “Add new mock action”.

5Figura 3 – Criando um elemento de mock

No pop-up aberto, selecione o método POST e coloque como o resource path: “/produto” e clique em “OK”.
Será criado um item que representa o mock.

6Figura 4 – Definindo resource path do mock

Para configurar o mock  que simulará a resposta quando este serviço for chamado, clique com o botão direito no elemento e depois na opção “New MockResponse”.

Crie o mock com o nome de “Sucesso”, pois nesse mock iremos definir como será o retorno do serviço em caso de sucesso.

7Figura 5 – Criando o mock para o response do serviço

Portanto, o próximo passo é definir a resposta do mock, ou seja, qual será o response code e qual o json de retorno quando o serviço for chamado. No caso de sucesso definimos que o retorno será status code igual a 200 e o json de resposta retornará o id do produto.

8Figura 6 – Configurando um retorno de sucesso

Para o mock que representará uma requisição com erro, definimos que o status code será igual a 400 e deverá retornar um json informando que um campo obrigatório não foi informado na requisição.

9Figura 7 – Configurando um retorno de erro

Feito! Criamos dois mocks para simular uma requisição com sucesso e outra com erro quando é chamado o serviço de inserção de um produto.
Agora faremos a mesma coisa para criar um mock para o serviço de consulta de produto.

Devemos criar um mock usando o método GET e o resource path será o mesmo usado anteriormente.
No mock de sucesso deve ser definido que o status code será igual a 200 e que deverá retornar um json com os dados do produto.

11Figura 8 – Definindo retorno do serviço de consulta

Pronto! Temos mais um mock criado! Qual o próximo passo? Executá-los!

Para isso clique com o botão direito no elemento “Produto” e clique na opção “Start Minimized”. O SoapUI executará os mock criados na porta 8080.

13Figura 9 – Executando os mocks

Para fazer um teste, chame os serviços usando o Postman, usando o URL definida nos mocks. O SoapUI retorná o que foi definido para cada situação conforme exemplo abaixo:

17Figura 10 – Requisição de sucesso e erro do mock inserção de produto
16Figura 11 – Requisição de sucesso do mock consulta produto

No caso do mock de inserção de produto, existe um mock para simular uma requisição de sucesso e outro para erro, quando chamamos o serviço, a cada requisição o SoapUI executa um dos mocks, ou seja, sempre é uma sequência, uma hora de sucesso e outra vez de erro.

Isso acontece porque no elemento produto foi definido na propriedade Dispatch como SEQUENCE. Outra opção que pode ser escolhida é a opção SCRIPT. Se definido essa propriedade o SoapUI irá executar o mock de sucesso ou erro conforme o script definido.

Para definir essa propriedade, basta clicar com o botão direito no mock do método POST na opção “Show MockAction Editor”. Será aberta a tela abaixo:

18Figura 12 – Definindo sequência de execução do mock

Feito!! Temos nossos mocks criados e executando com sucesso. Fácil, né? 😉

Com esse tipo de recurso não precisamos depender da implementação real do serviço para ganharmos agilidade em desenvolvimentos e testes que utilizam arquitetura baseada em serviços.

Referência

 https://www.soapui.org/rest-testing-mocking/rest-service-mocking.html

REST usa JSON e SOAP usa XML, certo?

SOAP (Simple Object Access Protocol) e REST (Representation State Transfer) são duas arquiteturas diferentes de web services. Entretanto, um erro comum é achar que a principal diferença entre elas é que SOAP utiliza XML (eXtensible Markup Language) e REST utiliza exclusivamente JSON (JavaScript Object Notation). Por esta razão, este artigo apresenta os conceitos básicos destas duas tecnologias, visando um maior esclarecimento das suas características e diferenças.

Em uma breve descrição, SOAP é uma tecnologia desenvolvida pela Microsoft para acessar web services unicamente por meio de mensagens de requisições e respostas feitas em XML, substituindo as tecnologias que utilizavam mensagens binárias. Além das mensagens, utiliza-se XML para criar o arquivo WSDL (Web Service Description Language), que é um contrato entre o provedor e o consumidor do serviço, como se fosse uma assinatura de método para o serviço web. Outra característica do SOAP é que é independente do protocolo de transporte, ou seja, pode ser enviado com a maioria dos protocolos, por exemplo HTTP, SMTP, TCP e JMS.

Já o REST é uma arquitetura criada para ser mais simples de se usar que o SOAP. Este pode ser usado em vários formatos de texto, como CSV (Comma-separated Values), RSS (Really Simple Syndication), JSON e YAML. Porém, só pode ser utilizado com o protocolo HTTP/HTTPS, por exemplo utilizando os métodos GET, POST, PUT e DELETE. Por este motivo, o REST comporta-se como se fosse um navegador que sabe como usar um protocolo e seus métodos padronizados, sendo que o aplicativo deve se adequar a isto. Neste caso, os padrões do protocolo não são violados, por exemplo criando métodos extras, aproveitando assim os métodos nativos e criando as ações com eles em seu tipo de mídia.

A seguir, temos uma comparação das duas tecnologias, com as principais vantagens de cada uma:

SOAP

  • Protocolo de transporte independente (REST utiliza somente HTTP)
  • Trabalha melhor com sistemas distribuídos, pois REST trabalha com comunicação ponto-a-ponto
  • O arquivo WSDL pode gerar um certo tipo de automação quando usado com determinadas ferramentas

REST

  • Melhor curva de aprendizado
  • Mensagens menores e mais eficientes como o formato JSON comparado com XML
  • Os dados podem ser colocados em cache, retornando sempre a mesma resposta para a mesma requisição
  • Mais rápido pois precisa de menos processamento que o SOAP

Portanto, vimos que cada arquitetura possui vantagens e desvantagens e é preciso analisar caso a caso antes de escolher qual utilizar. Porém, por ser mais simples e utilizar um protocolo que já é vastamente adotado pela comunidade, o REST geralmente é a arquitetura mais indicada para implementar um web service. Além do mais, com REST podemos trabalhar com diferentes formatos de texto enquanto SOAP é limitado exclusivamente ao formato XML.

Referências

Acessando web services com Pentaho DI

O pentaho data integration, ou kettle é uma ferramenta de ETL (Extract, transform, load) muito poderosa para extração, transformação/validação e carga de dados de uma fonte de origem para um destino.

A ferramenta já foi citada em outros posts aqui do blog, inclusive por mim. Os links encontram-se no final desse post.  

Dessa vez, vamos explorar um componente muito interessante chamado Web Services Lookup que, como o próprio nome indica, consulta informações de um web service, que deve seguir o padrão SOAP e, portanto, possuir um arquivo WSDL com a descrição dos serviços.

 

Descrição do cenário

Nesse post vamos criar uma transformação que consulta o web service de cálculo de prazo de entrega de encomendas dos correios. A descrição do serviço pode ser encontrado nesse link e o arquivo wsdl está disponível nesse link. A descrição e um teste online do serviço que vamos utilizar estão disponíveis nesse link.

 

Montando a transformação

1 – Vamos começar criando uma nova transformação. Clique no menu File > Novo > Transformação, ou aperte Ctrl + N.

Figura 1 - Nova transformação
Figura 1 – Nova transformação

 

2 – Inclua um componente Data Grid na área de trabalho da transformação. O componente está na pasta Input.

3 – Dê dois cliques no componente. Na janela que se abre, na aba Meta, defina as colunas “Cep Origem”, “Cep Destino” e “Cod Servico”, conforme Figura 2. Na aba Data, perceba que serão criadas 3 colunas exatamente com os nomes definidos na aba Meta. Na coluna “Cod Servico”, inclua o código “40010”, na coluna “Cep Origem” inclua o valor “68980000” e “Cep Destino”, inclua o valor “96255000”.

Figura 2 - Configurando data grid
Figura 2 – Configurando data grid

 

4 – Agora inclua o componente Web Services Lookup na transformação e conecte-o ao data grid, como na Figura 3.

Figura 3 - Conectando web services lookup com data grid
Figura 3 – Conectando web services lookup com data grid

 

5 – Dê dois cliques no componente Web Services Lookup. Na aba Web Service, vamos incluir as definições de acesso ao web service. Inclua a URL do WSDL no campo URL. Clique no botão Load. Perceba que os serviços disponíveis no WSDL foram carregados no campo “Operation“. Selecione a operação “CalcPrazo”. O restante das opções não precisa ser alterado.

Figura 4 - Configurando web services lookup
Figura 4 – Configurando web services lookup

 

6 – Ainda nos detalhes do componente web services lookup, perceba que existe uma aba “in“. Essa aba aparecerá sempre que a operação selecionada possuir parâmetros de entrada. No nosso caso, temos 3 parâmetros. Clique na aba “in” e configure na coluna “Name” o nome dos parâmetros que criamos no Data grid e na coluna “WS Name” inclua os nomes dos parâmetros, conforme Figura 5.

Figura 5 - Configurando parâmetros de entrada no componente web services lookup
Figura 5 – Configurando parâmetros de entrada no componente web services lookup

 

7 – Finalmente, perceba que existe também uma aba “CalcPrazoResult”. clique na aba e clique no botão “Obtém campos”. Aparecerá o elemento raiz da resposta do web service, conforme está descrito no WSDL.

Figura 6 - Configurando parâmetro de saída no componente web services lookup
Figura 6 – Configurando parâmetro de saída no componente web services lookup

 

8 – Com isso, já estamos lendo as informações do web service dos correios, mas perceba que a resposta é um elemento complexo, ou seja, receberemos um XML. Para extrair as informações que queremos, teremos que utilizar um outro elemento chamado “Get data from XML“, localizado na pasta “Input“.

 

9 – Inclua o componente “Get data from XML” e conecte-o ao componente “Web Services Lookup“.

Figura 7 - Incluíndo componente Get data from XML
Figura 7 – Incluíndo componente Get data from XML

 

10 – Dê dois cliques no “Get data from XML“. Na janela que se abre, marque a opção “XML source is defined in a field?” e no campo “Get XML source from a field“, selecione a variável “CalcPrazoResult”. Essa variável contém a resposta em XML retornada pelo web service, que configuramos na aba “CalcPrazoResult” do componente “Web Services Lookup“.

Figura 8 - Configurando o componente Get data from XML
Figura 8 – Configurando o componente Get data from XML

 

11 – Na aba “Content“, precisamos definir o XPath onde se encontram as informações que queremos extrair. Na página da documentação da operação, nesse link, existem alguns modelos de resposta da operação. Perceba que queremos recuperar os valores que estão dentro do XPath “/CalcPrazoResult/Servicos/cServico”, então vamos preencher isso no campo “Loop XPath“.

Figura 9 - Configurando XPath no Get data from XML
Figura 9 – Configurando XPath no Get data from XML

 

12 – Na aba “Fields” vamos definir os elementos que queremos ler do XML, conforme Figura 10.

Figura 10 - Configurando elementos no Get data from XML
Figura 10 – Configurando elementos no Get data from XML

 

13 – Agora basta incluir um componente de saída, para vermos o resultado. Incluí um componente Microsoft Excel Output.

Figura 11 - Incluindo componente de saída
Figura 11 – Incluindo componente de saída

 

14 – A transformação completa é exibida na Figura 12. Agora só rodar a transformação e conferir o resultado.

Figura 12 - Transformação completa
Figura 12 – Transformação completa

 

Observação: Para quem ficou curioso, o cep de origem utilizado no exemplo é do Oiapoque, no Amapá e o cep de destino de Chuí, no Rio Grande do Sul. O prazo de entrega é de 5 dias para SEDEX Varejo. Os códigos de serviço podem ser consultados na documentação dos correios, nesse link.

 

Links para consulta