Configurando uma api REST no Apigee Edge

apigge

Apigee Edge é uma plataforma para desenvolvimento e gestão de proxies API. Os proxies são uma abstração da aplicação real, podendo ter um endereço totalmente diferente do real. Diversos controles podem ser aplicados, entre eles segurança, redirecionamento, cotas, análise entre outras coisas. Normalmente quem utiliza esta plataforma são desenvolvedores backend criando proxies para web services REST ou SOAP.

Neste post iremos utilizar o arquivo swagger para criar uma api.

Criação da Spec

1 – No menu Develop selecione Specs.

img1

2- No submenu Specs selecione + Spec >> Import file.

img3

3- Selecione o arquivo swagger(.yaml) para importar as configurações da api.

img4

Uma nova spec será criada com o nome do arquivo importado.

img5

Será necessário criar um proxy para a App que será criada posteriormente.

Criação do Proxy

4 – Selecione no menu DEVELOP >> API Proxies a opção + Proxy.

Neste momento criaremos um proxy com as configurações importadas na spec.

5 – Selecione a opção No target, pois o target será configurado posteriormente de forma manual.

img8

6 – Selecion Use OpenApi para associarmos o proxy ao arquivo swagger(.yaml) que foi importado.

img9

7 – Selecione o arquivo que importamos e pressione Select.

8 – Pressione Next.

O nome do proxy, base path e a descrição do proxy foram preenchidos automaticamente, caso seja necessário é possível alterar.

img11

9 – Pressione Next.

Na tela a seguir são exibidos todos os métodos(URL/resources) da app, caso não queira disponibilizar todos este é o momento para desmarca-lo.

img12

10 – Pressione Next.

No caso de nossa api, não está sendo utilizado oAuth ou outra configuração de segurança para autorização/autenticação.

11 – Selecione Pass through(none).

img13

12 – Pressione Next.

O virtual Host que utilizaremos será somente o host com http, caso estivéssemos utilizando segurança escolheríamos também secure para criar o host com https.

13 – Selecione somente default.

img14

14 – Pressione Next.

Agora definiremos o ambiente onde será feito o build/deploy da app, podendo ser prod e test.

15 – Selecione somente prod.

img15

16 – Selecione Buil and Deploy.

Podemos observar que o proxy foi gerado, foi carregado e realizado deploy em ambiente de prod.

img16

17 – As informações do proxy podem ser visualizadas selecionando o link Gestao-de-Consultas-Medicas.

img17

Criação de Produto

18 – No menu PUBLISH >> API Products selecione + API Product, para criar um novo produto que será associado a App posteriormente.

19 – Preencha as informações de produto conforme imagem a seguir.

img19

20 – Pressione save.

img20

Criando App

Agora precisaremos criar uma App para associar o proxy ao produto criado.

21 – No Menu PUBLISH >> Apps selecione a opção + App.

22 – Preencha os campos conforme imagem a seguir e associe a App ao produto recém criado.

img22

23 – Pressione save.

img23

Criando Target

24 – No menu DEVELOP >> API Proxies selecione o proxy criado anteriormente.

O proxy não possui Target Endpoints.

25 – Selecione a aba DEVELOP.

img25

26 – Selecione a opção “ +”(Add new target endpoint) para adicionarmos um novo target.
27 – Preencha os campos conforme imagem a seguir.

img26

Como target foi utilizada a URL de uma aplicação que tenho “depoyada” no Heroku com o seguinte HTTP Target http://gestao-consulta-medica-app.herokuapp.com/v1 .

img27

28 – Pressione Save.

img28

Repare no XML que o target foi criado com sucesso.

29 – No Navigator selecione Proxy Endpoints >> default >> PreFlow.

30 – Substitua o trecho de código <RouteRule name=”noroute”/> por:

<RouteRule name="gestao-de-consultas-medicas-target">
   <TargetEndpoint>gestao-de-consultas-medicas-target</TargetEndpoint>
 </RouteRule>

Atente para possíveis no nome do target espaços, pois isto pode dar erro.

31 – Pressione save.

img32

32 – Pressione Save novamente.

img34

33 – Selecione o checkbox Development e a opção prod.

img33

Será exibida uma mensagem solicitando a confirmação do undeploy.

34 – Pressione Undeploy.

Iniciando app em ambiente de prod

35 – No menu DEVELOP >> API Proxies selecione no checkbox a opção prod.

Aguarde até o final do deploy.

img36

A imagem a seguir exibe o deploy em prod com status “verde” e a URL da app http://carlinstr-eval-prod.apigee.net/gesto-de-consultas-medicas.img37

Testando a app em prod

Consumindo a app para consultas agendadas.

http://carlinstr-eval-prod.apigee.net/gesto-de-consultas-medicas/consultas?status=agendada
img38

O projeto utilizado neste post pode ser baixado em https://github.com/carledwin/gestao-consulta-medica.

Há muito mais para falar sobre Apigge, aqui foi exposta apenas uma introdução rápida sobre o assunto. Escrevi este post para auxiliar os interessados nesta plataforma, mas que nunca a utilizaram e querem um overview.

Um grande abraço!

Anúncios

Integração Contínua com Heroku

continuous-integration

Nos dias de hoje muito se ouve falar sobre Integração continua, mas o que é isto?

Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler.

CI

No post de hoje iremos utilizar uma api rest como exemplo para criar o ambiente de integração contínua no Heroku, para isto iremos criar uma app e um pipeline onde a app será disponibilizada em PRODUÇÃO no ambiente do Heroku através do pipeline criado para que toda vez que fizermos um commit no Github no repositório … será iniciado o pipeline para o build e disponibilização da app atualizada de forma AUTOMATIZADA no ambiente de PRODUÇÃO.

Criando app e pipeline no Heroku

1- Selecione a opção New >> Create new app.

img1

2- Preencha App name com o nome da app.

3 – Pressione Add to pipeline.

img2

4 – Selecione + Create new pipeline, preencha Name the pipeline e selecione production em Choose a stage to add this app to.

img3

5 – Pressione Create app.

Ok, a app foi criada com o nome gestao-consulta-medica-app e o pipeline gcm-pipeline.

img4

Iremos conectar nossa app ao repositório no Github.

6 – Na aba Deploy, preencha o campo ao lado de Search com o nome do repositório e pressione Search. Abaixo será exibido o repositório buscado.

img5

7 – Pressione Connect para se conectar ao mesmo.

img6

Para que seja possível o deploy automatizado desta aplicação no Heroku, é fundamental seguir o passo abaixo.

8- Pressione a opção Enable Automatic Deploys.

img7

Na aba Settings iremos configurar o buildpack para definir o tipo de aplicação/linguagem.

9 – Pressione Add buildpack.

img8

10 – Selecione a opção java, automaticamente será preenchido o campo …URL com heroku/java.

img9

11 – Pressione Save changes.

img10

Na aba Overview é possível observar do lado direito Latest activiy com as últimas atividas na app.

img11

12 – Altere a aplicação via Eclipse ou diretamente no Github e efetue o “commit and push”.

img12

13 – Acompanhe a esteira do pipeline na aba de Overview.

O pipeline intercepta o commit, “starta” o build da app e efetua o deploy em ambiente de PRODUÇÃO.

img13

img14

Para ver a app em produção Pressione Open app. Seremos redirecionados para https://gestao-consulta-medica-app.herokuapp.com/ .

No caso desta aplicação foi necessário preencher uma URL específica por se tratar de uma api rest, como exibido abaixo.

http://gestao-consulta-medica-app.herokuapp.com/v1/consultas?status=agendada

img15

Esta é uma das maneiras de aplicar a prática de integração contínua em uma aplicação. Exitem diversas outras disponíveis no mercado.

Para baixar o projeto utilizado neste post acesse https://github.com/carledwin/gestao-consulta-medica.

Por hoje é isto, muito obrigado por acompanhar o post até o final.

Flyway

Quem nunca viu um desenvolvedor ou dba falando algo do tipo: “Fulano, você me mandou aqueles scripts?”, “Beltrano, os scripts que estavam na pasta de DEV foram executados em HOMOLOG?”, “Achei onde estava o erro, faltou rodar os scripts em PRODUÇÃO”. Acredito que muitos já passaram por este tipo de situação.

No post de hoje falarei um pouco sobre Flyway no intuito de apresentar uma alternativa para evitar que este tipo de problema ocorra quando a aplicação sofre alteração, scripts são criados em um ambiente e depois tudo isto é promovido para outro ambiente.

flyway

Flyway é uma ferramenta de migração  de banco de dados opensource. Auxilia na criação e alteração do banco de dados. Isto ocorre a partir de um script .sql. Tudo isto é controlado pelo Flyway através de uma tabela de controle de scripts criada no bando de dados.

Iremos utilizar o Flyway para automatizar a criação da tabela de pessoas e incluir alguns registros no banco de dados de nossa aplicação.

Para o exemplo iremos utilizar a api Rest pessoaApi. Configurei seguindo os passos abaixo:

1 – Configurar o Flyway na api alterando o arquivo application.properties.

config-application

2 – Criar as pastas db e migration.

pasta-db

3 – Criar o script SC1__script_create_table_pessoa.sql  na pasta migration para gerar a tabela pessoa.
insert-pessoa

4 – Criar o script SC2__script_insert_pessoa.sql na pasta migration para inserir registros na tabela pessoa.

 insert2-pessoa

Ao “startar” a aplicação os scripts do Flyway são executados em ordem seguindo o prefixo completo SCx onde “SC prefixo” e “x numero que ordena a execução”, por padrão o prefixo é “V”. Uma observação muito inportante é que após o prefixo completo vem “__ duplo underline” seguido da descrição do script e a extensão “.sql”  Ex: SCx__descricao.sql.

Para este exemplo utilizei o H2 que é um banco de dados in-memory, podemos acessar o console do H2 para consultar a tabela pessoa em http://localhost:8080/h2-console . No meu caso não configurei senha então basta pressionar Connect.

console-h2

Abaixo pode ser observada tela inicial do H2 com as tabelas TB_PESSOA e schema_version .

query-browser

Executando um select na tabela de pessoa podemos observar que os registros do script foram inseridos na tabela.

select-pessoa

O select abaixo exibe a tabela de controle de execução de script com o script e status de execução, entre outras informações.

version-table

Com a api “startada” é possível consumir o serviço de pessoas e consultar todas as pessoas registradas na base de dados, conforme exibido abaixo.

get-pessoas

Exite muito mais para falar sobre Flyway, neste post foi feito apenas um resumo. Para saber mais sobre Flyway acesse https://flywaydb.org/.

O projeto completo pode ser acessado em https://github.com/carledwin/pessoaApi.

 

O que é TDD

tdd2

No post de hoje iremos falar sobre Test Driven Development(Desenvolvimento Dirigido a Testes), mais conhecido como TDD.

O objetivo principal é escrever testes antes de criar o código. Esta é uma prática muito popular entre os desenvolvedores de software e com certeza é um pré requisito da maior parte das vagas para desenvolvedores atualmente.

O TDD de maneira bem simples possui  três pilares:

  1. RED – Write a test that fails (Escreva um teste que falhe)
  2. GREEN – Make the code work/pass (Faça um código que funcione/passe no teste)
  3. REFACTOR – Eliminate redundancy (Elimine a redundância e “aplique as técnicas de clean code para melhorar o código”)

 

tdd

Falar de criar testes pode parecer uma coisa complexa, num primeiro momento, podemos nos perguntar “Mas o que irei testar?”.

No mundo da programação existem diversos cenários que podem ser testados de forma rápida e objetiva. Neste post iremos utilizar um exemplo bem trivial que é a validação de CPF.

Uma dica bem interessante para que está começando com testes é imaginar situações onde podemos encontrar falhas na entra ou saída de dados, comunicação com o webservice, apiRest, banco de dados, servidor, entre outras coisas.

Voltando ao nosso objeto de estudo, iremos realizar as seguintes  validações(testes) em nossa aplicação:

  1. CPF inválido
  2. CPF com número negativo
  3. CPF nulo
  4. CPF com números repetidos
  5. CPF válido com menos de 11 dígitos (CPFs com zeros a esquerda)
  6. CPF válido com 11 dígitos

Para a seguência de códigos a seguir utilizei JDK8 e jUnit5.

RED & GREEN

Implementei a classe de teste ValidadorCPFTest com o código abaixo para refletir as validações citadas acima, com testes RED e GREEN.

codigo_red

REFACTORY 1 

A classe de teste ValidadorCPFTestRefatorado foi implementada para refatorar a classeValidadorCPFTest, onde inclui javadoc e importei métodos estáticos para diminuir a redundância de código afim de deixar o código mais limpo.

codigo_red_refatorado

REFACTORY 2

A classe ValidadorCPFRefatoradoTest foi implementada para testar a classe ValidadorCPFRefatorado que é uma refatoração da classe ValidadorCPF.

A classe ValidadorCPFRefatorado ganhou validações que devolvem exceptions com mensagens específicas de erro, algumas constantes foram criadas para reduzir o hard-coded e serem utilizadas também em outras classes. Para lançar as exceptions foi criada a classe CPFInvalidoException.

teste_redRefatorado

Executando os testes no eclipse podemos observar o resultado na view jUnit.

jUnit

O ciclo do TDD é continuo e termina somente quando todo o código é desenvolvido, testado e refatorado.

No eclipse podemos utilizar também o Coverage para rodar todos os testes e analisar o percentual de cobertura de todo o projeto.

coverage

Esta é uma breve definição e aplicação do TDD na prática.

Alguns pontos do código foram omitidos neste post, mas o código digo fonte completo deste projeto pode ser baixado em https://github.com/carledwin/projectTDD.

Muito obrigado e até o próximo post.

 

COMO GERAR API REST COM editor.swagger.io À PARTIR DO ARQUIVO .yaml

Neste post irei mostrar como gerar uma API REST com Spring Boot à partir do arquivo.yaml utilizando o editor.swagger.io veremos que isto é bem simples.

Inicialmente irei colocar o swagger.yaml no editor.

swagger5

No menu Generate Server irei selecionar a opção spring e salvar como clienteAPI.zip.

clienteapi1

Irei ao diretório onde salvei o arquivo clienteAPI.zip e o descompactarei.

clienteapi3

Abrirei a pasta clienteAPI para acessar a pasta spring-server.

clienteapi4

Já na pasta spring-server podem ser observados os arquivos pom.xml,readme.md e a pasta src.

cliente5

Pronto, agora basta importar este projeto para a IDE de desenvolvimento(eclipse, IntelliJ, …) e finalizar o desenvolvimento de conteúdo de retorno do controller. É importante ressaltar que a parte mais pesada, no caso o desenvolvimento do projeto foi realizada pelo editor. Este projeto roda normalmente no servidor de aplicação(Tomcat,…).

Para baixar o projeto completo click aqui.

Até a próxima.

Como criar API Rest com Swagger – CRUD completo

Hoje irei falar sobre Swagger, um projeto que possui algumas ferramentas para auxiliar o desenvolvedor na criação de APIs Rest e sua documentação de maneira rápida e portável. Irei criar um arquivo .yaml que possui uma aparência semelhante a um arquivo de texto. É muito importante entender que toda a parte burocrática de mapeamento de URIs será declarada de forma simples neste arquivo, bem como a declaração de MODELs. Após a criação do arquivo será possível criar um projeto em diversas linguagens de programação tanto o Server quando o Client através do editor.swagger.io. No editor do swagger é possível criar o arquivo .yaml e um client da aplicação é carregado live load.

swagger-7

Caso exista algum erro de sintaxe ou identação a linha com erro fica marcada e uma breve explicação é exibida. Após desenvolver o arquivo .yaml basta gerar o projeto Maven através dos menus Genarate Server ou Generate Client ou para quem desejar gerar a partir do .pom do projeto maven também será possível, mas isto é assunto para um próximo post quem sabe.

swagger-11

swagger-12

Irei mostrar a criação de um arquivo swagger.yaml bem simples para uma API REST com um CRUD de Cliente.

  1. Definições básicas da aplicação

Nome da API, titulo, contato, licença, host, basePath da aplicação, schemes e tags.

swagger-1

swagger-8

Declaração da seção paths onde  de finimos as URIs da aplicação.

  1. Declaração da URI de CRIAÇÃO

Declaração da URI de criação do cliente, tag associada, tipo de consumo (neste caso json), tipo de produção/retorno(neste caso json), parâmetros da URI, schema (corpo da requisição) e tipos de respostas para esta requisição.

swagger-2

  1. Declaração da URI de CONSULTA

Declaração da URI de consulta do cliente, tag associada, tipo de produção/retorno(neste caso json), parâmetros da URI e tipos de respostas para esta requisição.

swagger-14

  1. Declaração da URI de ALTERAÇÃO

Declaração da URI de alteração do cliente, tag associada, tipo de consumo (neste caso json), tipo de produção/retorno(neste caso json), parâmetros da URI, schema (corpo da requisição) e tipos de respostas para esta requisição.

swagger-13

  1. Declaração da URI de REMOÇÃO

Declaração da URI de remoção do cliente, tag associada e tipos de respostas para esta requisição.

swagger-15

Abaixo pode ser observado o resultado da declaração de todas as operações desta API.

swagger-9

  1. Criação do Model CLIENTE

Declaração dos dados do cliente tipando cada dados de acordo com o seu tipo.

swagger-6

swagger-10

Conclusão

O Swagger permite documentar a API e testar a mesma enquanto o desenvolvedor cria o arquivo.  Espero que tenham gostado.

Este arquivo pode ser baixado em cliente.yaml.

Um grande abraço.

Configuração de ambiente para Angular 4 no Ubuntu 17.10

No post de hoje irei apresentar uma das formas de configurar o ambiente Ubuntu 17.10 para desenvolver em Angular 4. 

 

Primeiramente iremos instalar o NodeJS.

instalarNodejs

Vamos verifacar a versão do Nodejs.

verificarVersaoNode

Iremos instalar agora o NPM.

instalarNPM

Verificando agora a versão do NPM.

verificarVersaoNPM

Por fim vamos instalar e verificar a versão do Angular.

instalarAngularCLIverificarVersaoAngularCLI

Como podemos observar a instalação do Angular 4 no Ubuntu depende da instalação do NodeJS e do NPM, mas é uma instalação bem simples.

Espero que este post ajude aqueles que tem interesse em instalar o Angular 4 no Ubunto.

Um abraço!