Vinícius Rodrigues de Sousa: Desenvolvimento E Monitoramento de Uma Api de E-Commerce

UNIVERSIDADE ESTADUAL PAULISTA
“JÚLIO DE MESQUITA FILHO”

Instituto de Ciência e Tecnologia
Câmpus de Sorocaba
VINÍCIUS RODRIGUES DE SOUSA
DESENVOLVIMENTO E MONITORAMENTO DE UMA API
DE E-COMMERCE
Sorocaba
2021
VINÍCIUS RODRIGUES DE SOUSA
DESENVOLVIMENTO DE MONITORAMENTO DE UMA API DE E-
COMMERCE
Trabalho de Graduação apresentado ao

Instituto de Ciência e Tecnologia de Sorocaba,
Universidade Estadual Paulista “Júlio de
Mesquita Filho” – UNESP, como parte dos
requisitos para obtenção do grau de Bacharel
em Engenharia de Controle e Automação.
Orientador: Prof. Dr. Galdenoro Botura Júnior
Sorocaba
2021
AGRADECIMENTOS
Agradeço aos meus pais e irmã, por tornarem esse sonho de cursar uma universidade
pública possível e pela força que me deram ao longo dessa jornada, e a toda minha família, que
muito me incentivou ao longo do curso.
Agradeço ao Prof. Dr. Galdenoro Botura Júnior pela oportunidade de realizar este
projeto e por se mostrar disposto a me orientar para que fizesse o melhor trabalho possível.
Aos parceiros da República HM, que foram fundamentais no meu processo de
amadurecimento ao longo dos anos na universidade e cuja convivência fez com que estes
fossem os melhores anos da minha vida.
Aos meus amigos de Campinas, que continuaram presentes mesmo depois de cada um
ter ido para um lugar diferente.
Ao meu coordenador de estágio Razuk Jorge e toda a equipe do Middle Office do Itaú
Unibanco pela oportunidade e confiança no meu trabalho como estagiário de desenvolvimento.
Ao meu coordenador Robson Ribeiro, da área de Engenharia de Contas e Tarifas do
Itaú Unibanco, por confiar no meu trabalho e sempre exigir o meu melhor.
Por fim, a todos os funcionários, docentes e discentes da Unesp Sorocaba, que de
alguma maneira me ajudaram ao longo da minha formação.
RESUMO
O comércio eletrônico tem evoluído conforme o avanço dos serviços digitais, permitindo aos
microempreendedores expor seus produtos nas plataformas de venda de grandes varejistas
(marketplaces). Uma forma de dar autonomia aos pequenos lojistas na hora de realizar esta
exposição é fornecendo uma aplicação que permita a realização de operações de cadastro,
atualização, consulta e remoção de seus produtos na base de dados da empresa parceira.
Pensando nesse cenário e no crescente uso de APIs como forma de integração de plataformas,
bem como a necessidade de um monitoramento constante desse tipo de aplicação em tempo
real, foi proposto para este trabalho o desenvolvimento de uma API, na arquitetura REST, que
realizasse operações relacionadas aos produtos de um fornecedor, bem como um painel de
monitoramento da aplicação na nuvem, em tempo real. As regras de negócio do projeto foram
definidas, bem como o contrato da aplicação, desenvolvida a partir de uma arquitetura modular,
com o objetivo de contribuir para organização do código, aumentando sua performance. Para
as informações de produtos e fornecedores, foi criado um banco de dados relacional na
plataforma MySQL, enquanto que, para o armazenamento do token utilizado para autenticação
do fornecedor, foi criado um banco de dados não-relacional no Redis. Foi possível integrar a
aplicação aos bancos de dados e a plataforma de monitoramento Loggly, na nuvem, que
proporcionou a criação de gráficos de diferentes tipos a partir dos eventos de log enviados pela
aplicação para um acompanhamento em tempo real das requisições. Esta ferramenta se mostrou
eficiente para prover uma atuação mais rápida dos responsáveis pela manutenção da API em
casos de indisponibilidade sistêmica e erros no consumo da aplicação, possibilitando também
um contato mais rápido com o cliente nesses casos.
Palavras-chave: API, E-Commerce, REST, Monitoramento, Banco de Dados, Documentação,

Módulo, Eventos de log, Alerta.
ABSTRACT
E-commerce has evolved as digital services advance, allowing micro-entrepeneurs to display

their products on the sale platforms of marketplaces. One way to give small shopkeepers
autonomy at exposing their products is providing an application that allows registration,
updating, consultation and removal of these products from the partner company’s database.
With this set in mind and the increasing use of APIs as platforms integrators, as well as the
constant monitoring need of these type of applicatons in real time, this work’s proposal was
developing an API, using REST architecture, to perform operations related to providers’
products, and a real-time monitoring dashboard in cloud. The project’s business rules were set,
such as the application contract, developed through a modular architecture, increasing the code
quality and its performance. A relational database at MySQL platform was used to storage
products and suppliers informations, while Redis Server, a non-relational database platform,
was set to store supliers authentication data. As a result, it was possible to develop the
application, integrating it with the databases and the monitoring platform Loggly, in cloud,
which provided the cration of different types of graphs through log events sent by the
application for request’s real-time monitoring. This tool proved to be an efficient way to
increasing the responsible API team’s agility and timeliness in cases of systemic unavailability
and consumption’s error, also enabling a faster contact with the client in these scenarios.
Keywords: API, E-commerce, REST, Monitoring, Database, Documentation, Module, Log

Events, Alert.
LISTA DE FIGURAS
Figura 1 – Estrutura de um sistema segundo o padrão DDD. .................................................... 6

Figura 2 – Entidade Aluno e seus atributos. .............................................................................. 9
Figura 3 – Relacionamentos entre entidades no modelo relacional. .......................................... 9
Figura 4 – Modelo não-relacional chave-valor. ....................................................................... 11
Figura 5 – Janela de pesquisa do Loggly. ................................................................................ 12
Figura 6 – Comparação entre os modelos de monitoramento convencional e centralizado. ... 13
Figura 7 – Dashboard de monitoramento dos status code e requisições por servidores. ......... 14
Figura 8 – Expressão para criação de alerta de uso do espaço em disco. ................................ 16
Figura 9 – Monitoramento de informações dos técnicos. ........................................................ 16
Figura 10 – Contrato da rota de autenticação do fornecedor. .................................................. 20
Figura 11 – Desenho de solução proposto para o projeto. ....................................................... 21
Figura 12 – Modelo lógico de dados relacional utilizado para a aplicação. ............................ 23
Figura 13 – Modelo lógico não-relacional de dados. ............................................................... 24
Figura 14 – Diretório raiz do projeto. ...................................................................................... 24
Figura 15 - Implementação de gravação e consulta do Token. ................................................ 25
Figura 16 – Fluxo de autenticação. .......................................................................................... 26
Figura 17 – Fluxo de operações. .............................................................................................. 27
Figura 18 - Processo de build da aplicação realizado com sucesso. ........................................ 28
Figura 19 – Logs de inicialização da aplicação na tela de busca. ............................................ 28
Figura 20 – Logs de diferentes fontes divididos por nível de severidade. ............................... 29
Figura 21 – Configuração do painel de autenticações iniciadas. ............................................. 30
Figura 22 - Configuração do gráfico de status code retornado ao longo do tempo. ................ 31
Figura 23 - Configuração do monitoramento de cadastro de produtos. ................................... 31
Figura 24 - Configuração do alerta de erros na rota de cadastro de produtos. ........................ 32
Figura 25 – Cabeçalho da documentação gerada. .................................................................... 33
Figura 26 – Listagem dos endpoints relacionados às operações de produtos. ......................... 34
Figura 27 – Documentação dos parâmetros de entrada para o cadastro de produto. ............... 34
Figura 28 – Documentação dos parâmetros de saída do cadastro de produto. ........................ 35
Figura 29 – Validação do endpoint de autenticação. ............................................................... 36
Figura 30 – Token armazenado com sucesso no banco de dados Redis. ................................. 36
Figura 31 – Validação do endpoint de cadastro de produto..................................................... 37
Figura 32 – Produto criado com sucesso no banco de dados MySQL. ................................... 37
Figura 33 – Validação do endpoint de consulta de produto pelo seu código identificador. .... 38
Figura 34 – Validação do endpoint de atualização de produto. ............................................... 38
Figura 35 – Validação do endpoint de remoção de produto pelo seu código identificador. .... 39
Figura 36 – Produto removido da base MySQL com sucesso. ................................................ 39
Figura 37 – Painel de monitoramento do serviço de autenticação de fornecedores. ............... 40
Figura 38 – Eventos de log da aplicação por nível de severidade. .......................................... 41
Figura 39 – Painel de monitoramento das operações realizadas nas bases de dados. ............. 41
Figura 40 – Códigos de status retornados aos fornecedores ao longo do tempo. .................... 42
Figura 41 – Rotas acessadas pelos fornecedores ao longo do tempo. ..................................... 43
Figura 42 – Requisições de cadastro e atualização de produtos ao longo do tempo. .............. 43
Figura 43 – Requisições de consulta e exclusão de produtos ao longo do tempo. .................. 44
Figura 44 – Requisições de sucesso relacionadas aos produtos ao longo do tempo................ 45
Figura 45 – Alerta de erros no cadastro de produtos habilitado. ............................................. 46
Figura 46 – E-mail enviado após disparo do alerta.................................................................. 46
LISTA DE TABELAS
Tabela 1 – Categorias de códigos de status e suas descrições. .................................................. 4

Tabela 2 – Definição dos endpoints e suas finalidades............................................................ 19
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface

DDD Domain-Driven Design
DTO Data Transfer Object
HTML Hypertext Markup Language
JSON JavaScript Object Notation
POO Programação Orientada a Objetos
REST Representational State Transfer
SPL Search Processing Language
SQL Structured Query Language
TI Tecnologia da Informação
UNESP Universidade Estadual Paulista "Júlio de Mesquita Filho"
URI Universal Resource Identifier
URL Universal Resource Locator
XML Extensible Markup Language
SUMÁRIO
1. INTRODUÇÃO ......................................................................................................... 1
1.1. Justificativa ......................................................................................................... 1
1.2. Objetivos ............................................................................................................. 2
1.2.1. Objetivos Específicos................................................................................... 2
2. CONCEITUAÇÃO .................................................................................................... 3
2.1. E-Commerce ....................................................................................................... 3
2.2. Web Services ...................................................................................................... 3
2.2.1. Protocolo HTTP ........................................................................................... 3
2.3. API ...................................................................................................................... 4
2.3.1. Arquitetura REST ........................................................................................ 5
2.4. Domain-Driven-Design....................................................................................... 6
2.4.1. Isolamento do Domínio................................................................................ 6
2.5. Programação Orientada a Objetos ...................................................................... 7
2.6. Bancos de Dados ................................................................................................. 8
2.6.1. Bancos de Dados Relacionais ...................................................................... 8
2.6.2. Bancos de Dados Não-Relacionais ............................................................ 10
2.7. Monitoramento de Eventos ............................................................................... 11
2.7.1. Loggly ........................................................................................................ 12
3. LEVANTAMENTO BIBLIOGRÁFICO................................................................. 13
3.1. Benefícios da Utilização de uma Aplicação para Concentração e Análise em

Tempo Real de Logs dos Servidores Web de uma Instituição de Ensino Superior ..... 13
3.2. Big Data: Analisando Dados com o Splunk Enterprise .................................... 15
4. METODOLOGIA .................................................................................................... 17
4.1. Requisitos de Sistema ....................................................................................... 17
4.2. Regras de Negócio ............................................................................................ 18

4.3. Definição dos Endpoints ................................................................................... 19
4.4. Proposta de Solução .......................................................................................... 21
4.5. Desenvolvimento .............................................................................................. 22
4.5.1. Criação do Modelo Relacional de Dados................................................... 22
4.5.2. Criação do Modelo Não-Relacional de Dados........................................... 23
4.5.3. Desenvolvimento da Aplicação ................................................................. 24
4.5.4. Desenvolvimento do Monitoramento ........................................................ 27
5. RESULTADOS E DISCUSSÃO ............................................................................. 33
5.1. Geração da Documentação ............................................................................... 33
5.2. Validação dos Endpoints................................................................................... 35
5.3. Monitoramento da Aplicação ............................................................................ 40
5.3.1. Painel de Visualização ............................................................................... 40
5.3.2. Alerta.......................................................................................................... 45
6. CONCLUSÕES ....................................................................................................... 47
6.1. Sugestões para Trabalhos Futuros .................................................................... 48
REFERÊNCIAS ........................................................................................................... 49
1
1. INTRODUÇÃO
1.1. Justificativa
Com o advento da era digital no final do século XX, as empresas de comércio varejistas
tem reformulado o conceito desta atividade econômica, investindo em plataformas eletrônicas
para a realização da compra e venda de bens e serviços. O comérco eletrônico, ou e-commerce,
como é chamado, tem evoluído cada vez mais, se tornando a maneira mais usual de
comercializar produtos ou serviços.
Assim, empresas já consolidadas no ramo do varejo que aderiram a essa transformação
passaram a comercializar produtos de diversos lojistas parceiros que não possuem estrutura
suficiente para a construção de sua própria plataforma digital.
Deste modo, os pequenos lojistas conseguem alcançar milhares de visualizações em
seus produtos, aumentando suas vendas, enquanto os grandes varejistas (os chamados
marketplaces), ampliam seu portfólio de produtos e recebem uma comissão das vendas e o
comprador final que possui mais variedade na hora de realizar suas compras.
Assim sendo, para garantir que este fluxo de informações entre os lojistas e o
marketplace ocorra de maneira estável e contínua, garantindo que o cliente final possua sempre
a informação de maneira rápida e confiável, são necessárias integrações digitais que
possibilitem aos lojistas o maior controle e liberdade possível ao expor seus produtos.
A API, (Application Programming Interface, ou, em português, Interface de
Programação de Aplicações), é uma tecnologia baseada em um conjunto de rotas e padrões de
progamação estabelecidos por uma aplicação, permitindo sua integração com diversos sistemas
e plataformas diferentes.
No cenário do e-commerce, as APIs tem sido adotadas como solução de integração
digital entre plataformas, possibilitando aos lojistas a requisição de informações relacionadas
a um determinado produto exposto e o cadastro de diversos produtos na plataforma do
marketplace de forma ágil e eficiente.
Uma vez que trata-se de uma aplicação que realiza a conexão de sua base de dados com
informações dispostas por terceiros constantemente, é necessário um acompanhamento
contínuo da aplicação para atuar em possíveis instabilidades o mais rápido possível.
Atualmente, em grande parte das empresas de tecnologia, este processo acontece de forma
mais reativa e menos proativa, em que os profissionais da TI são obrigados a analisar diversos
2
relatórios de eventos de log para poder atuar em instabilidades, demandando tempo e esforço.
Assim, o uso de ferramentas interativas baseadas em dashboards que coletam os registros de
log das aplicações automaticamente podem garantir um acompanhamento contínuo do estado
da aplicação, diminuindo o tempo e esforço necessário para identificar os possíveis erros nos
sistemas de TI.
Ao mesmo tempo, estas aplicações estão sempre passíveis de serem alteradas, sendo
necessário que sempre sejam documentadas e que essa documentação possa ser facilmente
acessada pela equipe que atue na sua manutenção.
1.2. Objetivos
O presente trabalho tem por objetivo o desenvolvimento do protótipo de uma API na

arquitetura REST voltada para o contexto de E-Commerce, que possibilite operações de
cadastro, consulta, atualização e remoção de produtos de um fornecedor em uma base de dados,
bem como o desenvolvimento de um painel de monitoramento da aplicação em tempo real na
nuvem, para tornar a atuação em erros sistêmicos ou de consumo da aplicação mais rápida.
1.2.1. Objetivos Específicos
 Desenvolvimento de uma aplicação em uma linguagem de alto nível (java)

utilizando o conceito de aplicação modular.
 Desenvolvimento de uma documentação dinâmica via código que auxilie no
entendimento do contrato da aplicação.
 Prover uma camada de segurança para a aplicação.
 Projetar o modelo de dados que melhor se encaixe às necessidades da aplicação.
3
2. CONCEITUAÇÃO
2.1. E-Commerce
O modelo de comércio em que as negociações são feitas em um ambiente eletrônico,

através da internet, é denominado comércio eletrônico, ou e-commerce, podendo ser realizado
de forma completa ou parcial, uma vez que esteja antendendo ao objetivo pré-estabelecido da
empresa (ALBERTIN, 2010).
Esta prática de comércio tem sido adotada pela maioria das empresas, seja para agilizar
as transações, para oferecer suporte ao cliente em tempo integral ou para oferecer serviços de
assistência técnica, por exemplo. Como fatores que impulsionam o crescimento desta
modalidade, destacam-se a competição entre empresas, oportunidade de redução de custos e o
alcance de novos clientes com maior facilidade (UEMA, 2020).
Com o decorrer dos anos, o comércio virtual se tornou uma ferramenta de extrema
importância para que as empresas conheçam a fundo as necessidades do clientes, deixando de
ser apenas um diferencial competitivo. Assim, o administrador de uma empresa precisa saber
gerir esta ferramenta e se atentar às constantes mudanças de tecnologias (DINIZ, 2020).
2.2. Web Services
Pode-se definir um Web Service como um sistema de software que possibilita a

interação entre aplicações e sistemas baseados em diferentes tecnologias, permitindo que estas
plataformas enviem e recebam dados de formatos diferentes. Uma vez que cada uma destas
peças possui sua própria linguagem, é necessário o uso de uma linguagem “universal”, como,
por exemplo, os formatos XML e JSON (MORO; DORNELLES, REBONATO, 2011).
Dessa forma, um Web Service tem como objetivo o encapsulamento de funcionalidades
disponíveis para serem acessadas através de protocolos. O protocolo mais utilizado para
comunicação entre clientes e servidores destes serviços é o HTTP. As tecnologias baseadas
nestes serviços tem sido cada vez mais utilizadas, devido ao crescente uso de APIs para a
integração entre plataformas. A partir do momento que uma API é consumida através do
protocolo HTTP, esta pode ser considerada um webservice. (OLIVEIRA, 2018).
2.2.1. Protocolo HTTP
O HTTP, principal protocolo existente na internet, é utilizado para distribuição de

objetos de hipermídia referenciados por uma URI, baseando-se na realização de requisições
4
por um cliente e no recebimento de respostas pelo servidor. Como trata-se de um meio de

comunicação, é fundamental que sejam determinadas regras para essa troca de informações
entre servidor e cliente (OLIVEIRA, 2018).
Dessa forma, uma requisição deve possuir um corpo (body), que contém informações
referentes aos dados da requisição, e um cabeçalho (header), que contém os meta-dados da
requisição, sendo estes informações como código de status (status code), formato do corpo da
requisição e parâmetros de autenticação (OLIVEIRA, 2018).
Com o corpo e o cabeçalho da requisição definidos de acordo com o que o serviço
espera, deve-se especificar o método da requisição, que define qual o tipo de ação que será
executada pelo servidor. Dentre os nove métodos existentes, há quatro que são os mais
utilizados, sendo estes o POST, GET, PUT e DELETE (MASSE, 2011).
O método POST é utilizado para criação de recursos novos no servidor. O método GET
é utilizado para requisitar um recurso do servidor, não existindo alteração ou criação de
informações novas. O método PUT é responsável pela atualização de recursos existentes e o
método DELETE é utilizado para exclusão de informações no servidor (MASSE, 2011).
Para toda resposta do protocolo HTTP, há um código de status envolvido, que serve
para identificar se a requisição foi feita com sucesso, se houve algum erro sistêmico, se o cliente
está tentando acessar uma rota inexistente, se o cliente não possui permissão para acessar uma
determinada rota, etc. Estes códigos são divididos por categorias, conforme mostra a Tabela 1
a seguir (MASSE 2011).
Tabela 1 – Categorias de códigos de status e suas descrições.

CATEGORIA DESCRIÇÃO
100 – 199: Informativa Comunica informações do protocolo.
200 – 299: Sucesso Requisição realizada com sucesso.
300 – 399: Redirecionamento O cliente deve realizar uma ação adicional.
400 – 499: Erro de Cliente Erro do cliente ao realizar a requisição.
500 – 599: Erro de Servidor Erro do servidor ao processar a requisição.
Fonte: Masse, 2011.
2.3. API
A API, do inglês Application Programming Interface, é uma interface, implementada

via código e que obedece um conjunto de padrões e rotinas, que é capaz de interligar diferentes
tipos de aplicações e sistemas. Desse modo, uma API permite que qualquer cliente que possua
5
conhecimento em relação a documentação da mesma possa consumi-la, tornando denecessária

a construção de uma aplicação que possua a mesma lógica. Dessa forma, uma API possui um
ou diversos endpoints, que fornecem um serviço para ser consumido por outras aplicações
clientes (OLIVEIRA, 2018).
2.3.1. Arquitetura REST
O REST, do inglês Representational State Transfer, é um modelo de arquitetura

baseado no protocolo HTTP, que especifica regras para a criação de implementações de
software. Desta forma, se uma API é criada com base na arquitetura REST, pode-se dizer que
ela é RESTful (FIELDING, 2000). Há 5 restrições obrigatórias relacionadas a esta arquitetura,
sendo estas:
1. Cliente e Servidor: Tem como base a premissa de que o consumidor de uma
aplicação REST não precisa conhecer implementações de banco de dados, cache,
etc. Dessa forma, cada componente evolui de forma independente, facilitando a
manutenção (FIELDING, 2000).
2. Stateless: Cada requisição do cliente ao servidor é única e independente de outras
requisições. Portanto, deve possuir todas as informações necessárias para que o
servidor a interprete com sucesso. Não existe armazenamento de informações dos
usuários por meio de sessões e cookies em aplicações REST (FIELDING, 2000).
3. Cache: A fim de acelerar as respostas do servidor e evitar processamento
desnecessário, em casos de aumento no número de requisições, o cache pode ser
utilizado para aumentar a performance da aplicação (FIELDING, 2000).
4. Interface Uniforme: É a principal característica da arquitetura REST. Define que
todo serviço REST deve utilizar o protocolo HTTP do mesmo modo, para que os
serviços sejam facilmente compreendidos (FIELDING, 2000). Dessa forma, um
recurso (uma informação que pode ser manipulada através de um serviço REST) é
identificado por uma URI (Uniform Resource Identifier) e representado através de
notações, como JSON, XML e HTML, dentre outras. Devem ser utilizados meta-
dados, através do header da requisição e da resposta, para um melhor entendimento
por parte do servidor e do cliente (SOUZA, 2018).
5. Sistema em Camadas: A divisão de uma aplicação por meio de camadas, para
separação de diferentes funcionalidades, garante organização e maior desempenho
(OLIVEIRA, 2018).
6
2.4. Domain-Driven-Design
O DDD, do inglês, Domain-Driven-Design, ou desenvolvimento orientado a domínio,

é um modelo de desenvolvimento de software baseado na ideia de que cada aplicação pertence
a um domínio, também conhecido como lógica ou regra de negócio. Essa concepção, se
implementada corretamente, garante facilidade na manutenção da aplicação e um código mais
performático (EVANS, 2003).
Dessa forma, o DDD pode ser considerado como uma união de metodologias utilizadas
para processos ágeis e boas práticas de desenvolvimento. Ao conhecer o domínio da aplicação,
ou seja, as regras de negócio, pode-se traduzir as necessidades do usuário em uma determinada
linguagem de progamação (EVANS, 2003). Para que a modelagem de um projeto utilizando o
DDD seja eficaz, deve-se seguir o princípio de isolamento do domínio.
2.4.1. Isolamento do Domínio
Uma vez que a premissa é o desenvolvimento orientado ao domínio, as informações

das regras de negócio devem ser isoladas através da implementação de uma arquitetura de
múltiplos módulos (ou camadas). Assim, no caso de sistemas corporativos, a divisão
geralmente é feita em quatro camadas, conforme mostra a Figura 1 a seguir (WERK, 2017).
Figura 1 – Estrutura de um sistema segundo o padrão DDD.
Fonte: Werk, 2017.

7
A camada de interface com o usuário apresenta as funcionalidades de aplicação para o

usuário, que, ao realizar uma operação, essas são repassadas para a camada da aplicação, que
controla quais regras do módulo do domínio serão realizadas. Estas regras são implementadas
pela camada de infraestrutura, que realizam a comunicação entre bases de dados e outros
serviços web, por exemplo (WERK, 2017).
Para a construção efetiva de um modelo baseado no domínio, deve-se utilizar padrões,
como a definição de Entidades (objetos definidos pela sua identidade no contexto do negócio),
Serviços (métodos que coordenam operações envolvendo objetos da camada de domínio) e
Repositórios (métodos de obtenção e criação de objetos da camada do domínio) (EVANS,
2003). A partir destes blocos de construção do projeto, pode-se desenvolver um modelo para o
domínio do sistema através de uma determinada linguagem de progamação, utilizando alguns
dos princípios da programação orientada a objetos (POO).
2.5. Programação Orientada a Objetos
A Programação Orientada a Objetos é um paradigma de progamação concebido por

Alan Kay baseado na ideia da aproximação do mundo virtual com o mundo real (RICARTE,
2001). Para isso, existem quatro conceitos fundamentais, sendo estes Objeto (elemento que
representa, no domínio da solução, uma entidade concreta ou abstrata), Classe (uma definição
dos comportamentos de um objeto), Atributo (uma propriedade de uma classe) e Método (uma
funcionalidade de uma classe).
Uma aplicação que utiliza o modelo de programção orientada a objetos deve se basear
em quatro pilares para o seu desenvolvimento, sendo estes:
1. Abstração: Representação de um objeto do mundo real dentro da aplicação,
atribuindo uma identidade, atributos e métodos.
2. Encapsulamento: Propriedades relacionadas ao acesso de determinadas classes e
objetos, atribuindo uma camada de segurança por meio de modificadores, sendo
estes privado, protegido e público.
3. Herança: Propriedade de uma classe de herdar atributos e métodos de outra classe,
promovendo reaproveitamento de código.
4. Polimorfismo: Capacidade de uma classe alterar o funcionamento de um método
herdado conforme suas necessidades (RICARTE, 2001).
8
2.6. Bancos de Dados
O banco de dados (BD) pode ser definido como uma coleção de dados relacionados
entre si, dispostos de maneira estruturada, que possibilita o seu acesso de forma eficiente e
precisa. Para a sua operação, são necessários Sistemas Gerenciadores de Bancos de Dados
(SGBD), softwares que surgiram no final da década de 1970.
Com o tempo, foram concebidos diferentes tipos de estruturas de dados para
armazenamento de informações e o SGBDs passaram a adotar diferentes modelos de
representação para desecrevê-las. Atualmente, são utilizados como modelos de base de dados
o modelo em rede, o modelo hierárquico, o modelo relacional e o modelo orientado a objetos
(TAKAI; ITALIANO; FERREIRA, 2005).
A fim de possibilitar consultas e atualizações aos bancos de dados, estes modelos
possuem funcionalidades e operações que os definem de acordo com sua estrutura. No modelo
relacional, são utilizados conceitos como entidades, relacionamentos e atributos. Uma entidade
seria a representação de um objeto do mundo real em um banco de dados, como, por exemplo,
um funcionário. Os atributos, ligados diretamente a entidade, são as propriedades que este
objeto possui, como, por exemplo, o nome e idade de um funcionário. Os relacionamentos são
associações entre as entidades, tais como o relacionamento entre um funcionário e um cliente,
por exemplo (ELMASRI; NAVATHE, 2018).
Os SGBDs podem ser categorizados não apenas a partir do modelo que utilizam, mas
também pelo número de servidores alocados para um banco de dados, por exemplo. Para um
banco de dados disponível em um único ambiente, este é dito centralizado, enquanto que um
banco de dados instanciado a partir de vários servidores é conhecido como distribuído (VICCI,
2014). Em relação aos modelos, os dois mais utilizados atualmente são o modelo relacional e
não-relacional, que serão detalhados nas seções seguintes.
2.6.1. Bancos de Dados Relacionais
O modelo de dados relacional pode ser definido como um conjunto de relações na forma
da tabelas, em que cada tabela, representando um objeto do mundo real, possui seus atributos
na forma de colunas e um registro deste objeto na forma de linhas. Cada atributo é definido a
partir de um tipo, podendo ser, por exemplo, uma cadeia de caracteres, um ponto flutuante ou
uma sequência de dígitos (SILBERSCHATZ; KORTH; SUDARSHAN, 2012). A Figura 2 a
seguir representa um objeto aluno e seus atributos, contendo cinco registros, em um modelo
relacional de dados.
9
Figura 2 – Entidade Aluno e seus atributos.
Fonte: Elmasri; Navathe, 2018.
A fim de evitar o armazenamento de dados repetidos, podem ser definidos

relacionamentos entre as entidades, simplificando a alteração dos registros. Para construir
relacionamentos entre as tabelas, deve-se seguir os princípios de cardinalidade. Uma
cardinalidade é o número de relações em que uma entidade pode ser associada.
Assim, a cardinalidade pode ser definida como (1:1), em que um registro de uma
entidade é relacionado apenas a um registro de outra entidade, (1:N), em que um registro de
uma entidade pode estar relacionado a N registros de outra entidade, porém, os N registros da
segunda entidade devem estar associados apenas a um registro da primeira, e (N:N), em que
diversos registros da primeira entidade podem estar relacionados a diversos registros da
segunda entidade (SILBERSCHATZ; KORTH; SUDARSHAN, 2012). A Figura 3 a seguir
ilustra, de forma intuitiva, os relacionamentos possíveis entre entidades no modelo relacional.
Figura 3 – Relacionamentos entre entidades no modelo relacional.
Fonte: Silberschatz; Korth; Sudarshan, 2012.

10
A fim de identificar uma entidade de forma única, um de seus atributos deve ser
escolhido como uma chave, podendo ser simples ou composta. Esta chave também é utilizada
para identificação dos relacionamentos entre entidades, em que uma entidade será dominante
e, a outra, dominada. Assim, ao excluir um registro da entidade dominante, todos os registros
da entidade dominada que são relacionados a este também serão excluídos. Um atributo
designado como chave primária não pode possuir o mesmo valor para mais de um registro
(SILBERSCHATZ; KORTH; SUDARSHAN, 2012).
2.6.2. Bancos de Dados Não-Relacionais
O modelo de banco de dados não-relacional surgiu com a proposta de armazenar

grandes volumes de dados de maneira distribuída, possibilitar o escalonamento horizonal de
dados e facilitar o acesso para manipulação dos dados. São representados por meio de uma
estrutura chamada de esquema, não havendo necessidade de uma definição prévia deste
(SCHREINER, 2016).
Em alguns casos, bancos de dados não-relacionais proporcionam maior desempenho
em relação aos bancos de dados relacionais, porém, não oferecem relacionamentos entre os
dados e não utilizam a linguagem SQL diretamente para operações de inserção, atualização,
consulta e exclusão do banco de dados. Há quatro tipos de modelos de dados não-relacionais,
sendo estes chave-valor, orientado a colunas, orientado a documentos e orientado a grafos
(VILELA, 2015).
O modelo chave-valor, dentre os modelos de dados não-relacionais, é considerado o
mais simples. Consiste em um agrupamento de dados por meio de uma chave, que é utilizada
para identificar unicamente um objeto, e um valor. Permite o armazenamento de uma grande
quantidade de dados e limita a consultas e alterações de um determinado valor apenas por meio
de sua chave. Desse modo, não é recomendado para casos em que sejam realizadas consultas
complexas (VILELA, 2015).
Uma das vantagens para o uso de um modelo chave-valor é a possibilidade de
indefinição da estrutura do dado, permitindo ao desenvolvedor efetuar as persistências de modo
mais arbitrário. Possui como principais métodos o put (inserção) e o get (consulta),
apresentando um alto ganho na velocidade e armazenamento de dados. Como desvantagem,
pode-se gerar uma quantidade de dados replicados muito alta (SCHREINER, 2016). A Figura
4 a seguir apresenta um banco de dados estruturado no modelo chave-valor.
11
Figura 4 – Modelo não-relacional chave-valor.
Fonte: Elaborado pelo autor.
2.7. Monitoramento de Eventos
Os sistemas computacionais, de várias escalas e padrões, geram, ao longo do seu ciclo

de vida, mensagens relacionados ao seu estado em um determinado momento, conhecidas
como eventos de log. Estes registros podem ser armazenados em arquivos de texto, na memória
da máquina ou em bases de dados, e podem ser utilizados para reiniciar uma aplicação, validar
uma determinada função ou identificar comportamentos não esperados de um sistema
(CLEMENTE, 2008).
Desse modo, os registros de log são ferramentas fundamentais para detectar e resolver
problemas e incidentes em ambientes de tecnologia. A partir da análise das informações
providas pelos logs, pode-se descobrir falhas de autenticação de um usuário, exploração de
vulnerabilidades de um sistema e intermitências no funcionamento de serviços e programas de
uma máquina (MÜLLER, 2013).
Contudo, nos dias atuais, em grande parte das empresas de tecnologia os profissionais
encontram dificuldades para acessar os arquivos de log através de editores de texto e buscar
erros específicos em horários específicos para atuar em um incidente, tornando esse processo
demorado e cansativo (CLEMENTE, 2008). Com o advento da computação em nuvem, em que
os ambientes são escalados de forma dinâmica, manter o armazenamento de logs de forma
estática se torna menos eficaz ainda (CARMO, 2015).
A fim de auxiliar na coleta e agregação dos dados relacionados aos eventos de log,
podem ser utilizadas ferramentas que recebem esses eventos em tempo real, disponibilizando
módulos gráficos e customizáveis que permitem a visualização dessas informações de modo
interativo e intuitivo, bem como a criação de alertas, tornando o processo de atuação em
incidentes mais ágil e melhorando a experiência do cliente ao longo prazo. Também pode-se
integrar estas ferramentas com soluções de Big Data para análises de negócio mais complexas
(CARMO, 2015).
12
2.7.1. Loggly
O Loggly, ferramenta baseada em nuvem provida pela Solarwinds, é uma das opções
para monitoramento e gerenciado de logs em tempo real de modo centralizado. Não requer
instalação de nenhum programa e oferece integração com diversas plataformas, bem como
tutoriais para possibilitar o envio de logs das aplicações desejadas para a plataforma. Oferece
um período de 30 dias de gratuidade para emissão de até 10 GB por dia (PICKERING, 2020).
Para sua configuração, basta criar uma conta, especificar a origem dos logs e realizar
os procedimentos de configuração relacionados a tecnologia de envio de logs. No caso de
aplicações Java, deve-se importar o logback, dependência externa que realiza os registros de
logs, e criar um arquivo com a extensão XML para configuração da comunicação da aplicação
com a conta criada.
Assim, é possível realizar pesquisas de logs e criar gráficos de diversos tipos para
coletar os logs apenas utilizando a mensagem emitida pelos eventos, ou até mesmo realizar
operações lógicas entre essas mensagens para filtrar as informações. Também é possível
confeccionar alertas de e-mail baseados nos eventos da aplicação, escolhendo o intervalo de
varredura e a quantidade de ocorrências de eventos que deve disparar os alertas
(SOLARWINDS, 2021). A Figura 5 a seguir ilustra a janela de pesquisa de eventos do Loggly.
Figura 5 – Janela de pesquisa do Loggly.

13
3. LEVANTAMENTO BIBLIOGRÁFICO
Nesta seção, são apresentados trabalhos relacionados ao monitoramento dinâmico de

aplicações que serviram como motivação e base para o desenvolvimento do sistema de
monitoramento da aplicação, apresentando os ganhos de sua implantação.
3.1. Benefícios da Utilização de uma Aplicação para Concentração e Análise em Tempo

Real de Logs dos Servidores Web de uma Instituição de Ensino Superior
A fim de aprimorar a segurança da informação em uma Instituição de Ensino Superior,

este artigo teve como proposta a análise dos benefícios do uso de uma aplicação para análise
em tempo real, de modo centralizado, dos registros de log de um serviço web. Desse modo, foi
retratado o cenário anterior e posterior a implementação da ferramenta, executando testes para
validação de seu uso (ROCHA, 2018).
Para a coleta e análise dos logs, foram levantadas diversas ferramentas existentes no
mercado, como Elastic Stack, Splunk, Loggly, Apache Kafka, Logzilla, entre outras. Ao
analisar a viabilidade de cada ferramenta conforme os critérios estabelecidos pelo autor, que
incluem a existência de documentação extensa, suporte profissional ativo, alertas de
notificação, software aberto e comunidade ativa, foi escolhida a ferramenta Elastic Stack
(ROCHA, 2018).
Ao realizar a comparação entre o modo como o monitoramento de log é realizado no
cenário atual (chamado de modelo convencional) e o modo como a coleta dos logs é realizada
após a implementação do projeto (chamado de modelo centralizado), foi constatado um tempo
consideravelmente menor para a busca de um log específico ao utilizar o modelo
centralidazado, como mostra a Figura 6.
Figura 6 – Comparação entre os modelos de monitoramento convencional e centralizado.
Fonte: Rocha, 2018.

14
Ao explorar as funcionalidades disponibilizadas pela ferramentas, pode-se realizar o

uso de pesquisas de log de diversas maneiras, utilizando o formato JSON, utilizando expressões
regulares, operadores lógicos, entre outros. Foi possível criar interfaces de monitoramento
como o gráfico exibido na Figura 7, que permite monitorar os status code retornados em tempo
real das requisições dos servidores web, bem como os acessos por servidores (ROCHA, 2018).
Figura 7 – Dashboard de monitoramento dos status code e requisições por servidores.
Fonte: Rocha, 2018.
Foi concluído que a centralização dos logs através da ferramenta utilizada possibilitou
que o monitoramento fosse feito de modo mais ágil e assertivo, diminuindo a perda de dados e
aumentando a segurança da Infraestrutura. A coleta e análise de logs em tempo real para
atuação em falhas, tomadas de decisões e manutenção dos recursos de tecnologia (ROCHA,
2018).
15
3.2. Big Data: Analisando Dados com o Splunk Enterprise
Com a evolução das tecnologias, o número de dados gerados pelos sistemas de

computação tem aumentado de modo exponencial, trazendo um desafio de como armazenar e
utilizar esses grandes volumes de dados de modo eficiente. Este projeto tem como objetivo
utilizar a ferramenta Splunk para coleta e análise dos dados gerados pelo sistema de uma
empresa apresentada pelo nome fictício de Telex (IRACE, 2018).
Desse modo, o Splunk foi utilizado para otimizar o sistema de agendamento de
atendimentos desta empresa. O processo para esta otimização contou com as etapas de
aquisição dos dados, em que foi realizado um filtro para verificar quais dados não seriam
utilizados no futuro, integração dos dados, através dos índices do Splunk, e análise dos dados,
em que foram construídos painéis de monitoramentos baseados em gráficos, dashboards e
relatórios (IRACE, 2018).
Ao realizar uma análise da ferramenta escolhida, pode-se perceber que esta oferece uma
linguagem específica para tratativa dos dados, a SPL, do inglês, Search Processing Language,
ou, Linguagem de Processamento de Busca. Esta linguagem possibilita a manipulação dos
dados de diversos modos, uma vez que oferece comandos de comparação, ordenação, cálculo
de expressões e operações lógicas.
A Telex, estudo de caso do trabalho, é uma empresa de telecomunicações, com mais de
100 milhões de clientes pelo mundo. Entre seus produtos e serviços, encontram-se pacotes de
internet, telefonia fixa e canais de televisão fechados. Esses produtos podem ser especificados
de mais de uma maneira, e podem ser contratados isolados ou em conjunto. Foi realizada,
assim, a proposta de coletar e analisar os dados de log referentes às solicitações de clientes,
técnicos disponíveis para atendimento e horários de atendimento (IRACE, 2018).
Foi realizada uma etapa de entendimento da arquitetura dos servidores da empresa e
uma etapa de aquisição dos registros de logs enviados pelos servidores. Com os logs
armazenados no Splunk, foram criados dois alertas, sendo um de espaço em disco, que é
disparado quando a porcentagem de espaço em disco dos servidores se encontrar abaixo de
15%, e um que é disparado quando a porcentagem do uso de CPU se encontrar acima de 90%
(IRACE, 2018). A Figura 8 mostra a expressão, em linguagem SPL, utilizada para criação do
alerta de espaço em disco.
16
Figura 8 – Expressão para criação de alerta de uso do espaço em disco.
Fonte: Irace, 2018.
Foi possível criar painéis de monitoramento dos dados relacionados a infraestrutura do

sistema, como uso de CPU, memória e disco, bem como a quantidade de servidores ativos em
um dado momento, tornando a identificação de problemas sistêmicos mais rápida. Também foi
criado um dashboard para as informações dos técnicos que estão conectados ao sistema da
empresa (que traz informações relacionadas aos compromissos e tarefas diários), e que fizeram
ou não a limpeza do cache do sistema. Este painel pode ser visualizado na Figura 9.
Figura 9 – Monitoramento de informações dos técnicos.
Fonte: Irace, 2018.
Ao implementar um monitoramento centralizando, utilizando os painéis e alertas

disponibilizados pelo Splunk, foi possível auxiliar na tomada de decisão em relação aos dados
da Telex e diminuir em 80% a utilização do disco de seus servidores (IRACE, 2018). Dessa
forma, o Splunk se mostrou uma ferramenta útil para trativa de grandes volumes de dados em
tempo real.
17
4. METODOLOGIA
4.1. Requisitos de Sistema
Para definir os requisitos funcionais, relacionados às regras de negócio, da aplicação,

deve-se, primeiramente, pensar em um modelo arquitetural de base para o projeto. Pensando
em um cenário de marketplace de, em média, 5000 fornecedores, em que cada fornecedor pode
persistir, em média, 200 produtos na base de dados, tem-se, em média, 100000 registros de
volumetria relacionados aos produtos.
Uma vez que cada registro deve possuir, em média, 300 bytes de tamanho, considerando
o tamanho máximo do campo, tem-se, de volumetria total relacionada aos produtos, 10 MB.
Para estimar a quantidade de operações realizadas realizadas no banco de dados por segundo,
pode-se dividir a quantidade de fornecedores pelo total de segundos em um dia no horário
comercial, obtendo, em média, 0,2 operações por segundo.
Neste cenário, considerando a possibilidade de picos de memória, é viável o uso de um
banco de dados MySQL, uma vez que este disponibiliza recursos para integridade dos dados e
pode ser escalado de forma horizontal, dispondo mais servidores em vez de aumentar as
configurações de CPU e memória.
Para a memória interna da aplicação Java (JVM), dividida em memória heap (que
armazena os objetos criados pela aplicação) e memória perm (que armazena os dados estáticos
da aplicação), pode-se estimar o espaço mínimo e máximo da memória heap em 512 MB, uma
vez que se espera a criação de novos objetos a todo instante. Dessa forma, não há perda de
performance para escalar a memória para criação de novos objetos. A memória perm, por sua
vez, pode ser definida em um intervalo mínimo de 256 MB para criação dos objetos estáticos,
podendo escalar até 512 MB. Os parâmetros foram configurados na máquina virtual Java da
aplicação.
Para suprir a necessidade do armazenamento de chaves temporárias do fornecedor,
utilizou-se o Redis Server, uma vez que este possibilita o armazenamento de objetos chave-
valor, consultas rápidas, definição de tempo de expiração das chaves e possibilidade da
utilização da memória da aplicação (cache) para armazenamento dos dados. Deste modo,
espera-se uma resposta mais rápida do sistema na gravação e consulta das chaves temporárias.
18
4.2. Regras de Negócio
Para que seja possível a definição de um contrato para a aplicação, deve-se definir as
regras de negócio no contexto do sistema. Assim, pensando em um cenário de E-Commerce,
em que um fornecedor de produtos (cliente da aplicação) deve ser capaz de cadastrar, consultar,
atualizar e remover seus produtos de uma base de dados de uma empresa varejista, foram
definidas as regras a seguir.
1. Um fornecedor deve possuir seus dados pré-cadastrados em uma tabela, possuindo

um código identificador único, sendo capaz de consultar e alterar seus dados através
deste identificador.
2. Um fornecedor deve possuir uma senha pré-cadastrada e pode alterar esta senha
para uma de sua escolha. Esta senha será utilizada para a realização de sua
autenticação.
3. Para conseguir realizar as operações que a aplicação lhe possibilita, um fornecedor
deve se autenticar, utilizando seu código identificador e sua senha no corpo da
requisição. Ao se autenticar, será gerado um token, que deverá ser enviado como
meta-dado nas requisições que este realizar.
4. Um fornecedor pode consultar os dados de todos os seus produtos, através do seu
código identificador, em uma única requisição.
5. Um fornecedor pode consultar as informações relacionadas aos tipos de pagamento,
transportadoras e centros de distribuições fornecidos pela empresa varejista. Assim,
ao cadastrar um produto novo, o fornecedor pode escolher, para cada produto, uma
forma de pagamento, uma transportadora e um centro de distribuição existente.
Caso ele não escolha uma transportadora, por exemplo, ao cadastrar o produto, será
atribuída a primeira transportadora encontrada na base de dados.
6. Um fornecedor pode cadastrar um produto novo através de uma requisição. Ao
realizar o cadastro, será gerado um código identificador único para o produto, que
possibilitará ao fornecedor consultar as informações deste produto, bem como
atualizá-lo e removê-lo da base de dados. Ao atualizar o produto, um novo código
identificador será gerado para ele.
19
4.3. Definição dos Endpoints
Com as regras de negócio definidas, pode-se estabelecer os endpoints necessários para

as requisições da API. Na Tabela 2 a seguir, são mostradas as rotas, métodos e finalidades de
cada tipo requisição:
Tabela 2 – Definição dos endpoints e suas finalidades.
Endpoint Método Finalidade

POST Geração de token do fornecedor.
/autenticacao
PUT Alteração de senha do fornecedor.
POST Cadastro de um produto novo.
GET Consulta de um produto pelo id ou de todos produtos.
/produtos
PUT Atualização de um produto.
DELETE Remoção de um produto.
PUT Atualização das informações do fornecedor.
/fornecedor
GET Consulta das informações do fornecedor.
/transportadoras GET Consulta de uma transportadora pelo id ou de todas as
transportadoras.
/formas_pagamento GET Consulta de uma forma de pagamento pelo id ou de
todas as formas de pagamento existentes.
/centros_distribuicao GET Consulta de um centro de distribuicao pelo id ou de
todos os centros de distribuição.
Assim, foi possível modelar, na notação RAML, os contratos para cada endpoint da api.
Para a requisição de geração de token do fornecedor, por exemplo, foi escrito o contrato
conforme mostra a Figura 10 a seguir:
20
Figura 10 – Contrato da rota de autenticação do fornecedor.
Desse modo, entende-se que, ao realizar uma requisição no endpoint /autenticacao,

escolhendo o método post, passando seu código identificador como parâmetro na URI
({idFornecedor}) e o mesmo código identificador e senha no corpo da requisição, caso estes
sejam válidos na base de dados, será retornado, no corpo da resposta, um token no formato
UUID e o status code 201 (recurso novo criado). Caso o código identificador e a senha não
correspondam, o token não será gerado, e será retornado o status code 401 (não-autorizado) e
uma mensagem de erro.
Com base nesse modelo e nas regras de negócio, foram criados os contratos para cada
endpoint necessário. Para o endpoint “/produtos”, por exemplo, foram criados os métodos de
cadastro (post), consulta (get), atualização (put) e exclusão (delete).
Uma vez que, em cada requisição, é verificado se o token enviado corresponde ao token
gerado pelo fornecedor (cujo código identificador é informado na URI da API), caso este não
seja válido, será retornado um status code 401 e uma mensagem de erro, pedindo para que o
fornecedor se autentique novamente.
21
Caso o fornecedor tente atualizar ou remover um produto que não pertence a ele, será
retornado um status code 403 (proibido), e uma mensagem de erro. Se, ao cadastrar um produto
novo, um fornecedor escolher uma transportadora, forma de pagamento ou centro de
distribuição que não existem na base de dados, será retornado um status code 404 (não
encontrado) e uma mensagem de erro. Caso o cliente faça uma requisição utilizando métodos
ou recursos que não são mapeadas pelo backend da aplicação, será retornado um status code
400. Para erros internos da aplicação ou banco de dados, é retornado um status code 500.
4.4. Proposta de Solução
Para contemplar os objetivos pré-estabelecidos para este projeto, bem como as regras
de negócio definidas, foi criado um desenho de solução conforme ilustra a Figura 11. Neste
fluxo, a aplicação é integrada a uma base de dados relacional (MySQL), uma base de dados
não-relacional (Redis) e à ferramenta de monitoramento na nuvem (Loggly), gerando uma
documentação com o uso da ferramenta Swagger.
Figura 11 – Desenho de solução proposto para o projeto.

22
Para o armazenamento das informações referentes aos produtos, fornecedores, centros

de distribuição, transportadoras e formas de pagamento, é utilizada a base de dados relacional,
uma vez que esta permite tipos de consulta mais customizados (não se limitando a consultas
referenciadas pela chave primária) e um relacionamento bem definido entre as entidades. Para
o armazenamento do token, é utilizada a base de dados não-relacional, uma vez que esta
variável é mais dinâmica, sendo criada cada vez que um fornecedor realizar uma sessão. Assim,
as consultas para verificação do token são realizadas mais rapidamente através de um esquema
chave-valor.
Desse modo, foi criada uma instância local da base de dados SQL, para geração das
entidades responsáveis pelo armazenamento das informações, e uma instância local da base de
dados no Redis.. A aplicação foi desenvolvida em linguagem Java, através do ambiente de
desenvolvimento Eclipse, utilizando a ferramenta Maven como gerenciador de dependências
externas. Foi utilizada a arquitetura DDD para a criação dos módulos da aplicação, sendo estes
o application, rest, domain e integration.
O módulo application foi criado tendo como responsabilidade a execução da aplicação
em um servidor embarcado e o armazenamento de configurações relacionadas às plataformas
externas (banco de dados e ferramenta de monitoramento). O módulo rest tem como função o
gerenciamento das requisições aos endpoints, bem como a geração de documentação. O
módulo domain tem como responsabilidade as aplicações das regras de negócio, enquanto que
o módulo integration é desginado para implementar as regras de negócio estabelecidas pelo
domain e realizar a integração com os bancos de dados.
Para a geração do painel de monitoramento, foi criada uma conta na ferramenta Loggly,
utilizando o recurso de incorporação dos logs emitidos pela aplicação e criação do dashboard
a partir destes logs. A documentação foi gerada via código com o auxílio da ferramenta
Swagger, tornando possível a parametrização das informações de sua interface através de
métodos importados externamente.
4.5. Desenvolvimento
4.5.1. Criação do Modelo Relacional de Dados
Após a criação da instância da base dados MySQL, o modelo lógico foi estruturado,
possuindo os relacionamentos e as chaves primárias conforme mostra a Figura 12 a seguir:
23
Figura 12 – Modelo lógico de dados relacional utilizado para a aplicação.
A partir do modelo lógico desenvolvido, foram criados os scripts, em linguagem SQL,

para a geração das respectivas entidades, sempre respeitando os relacionamentos estabelecidos
para cada entidade. Assim, obteve-se o modelo físico relacional de dados, sendo possível o
armazenamento e extração de informações nas entidades através da aplicação.
4.5.2. Criação do Modelo Não-Relacional de Dados
Tendo como base a premissa de que o token será armazenado e consultado a partir do
código identificador do fornecedor, foi desenvolvido o modelo lógico conforme mostra a
Figura 13 a seguir, em que o objeto, identificado como Fornecedor, possui como chave o código
identificador do fornecedor e como valor o token, na forma de uma String.
24
Figura 13 – Modelo lógico não-relacional de dados.
4.5.3. Desenvolvimento da Aplicação
Para o desenvolvimento da aplicação, foi utilizado o ambiente de desenvolvimento

Eclipse, trabalhando com a linguagem de progamação Java. Para automatizar a incorporação
de dependências externas ao projeto, utilizou-se a ferramenta Maven como gerenciador de
dependências. Ao criar o projeto novo no Eclipse, pode-se criar os módulos, relacionando-os
como sub-módulos do módulo principal na hierarquia do projeto.
Assim, no visualizador de pacotes da IDE ilustrado na Figura 14 a seguir, pode-se
observar o conteúdo do projeto principal, nomeado e-commerce, os módulos criados abaixo
dele, o arquivo de configuração pom.xml e outros arquivos de configuração do projeto:
Figura 14 – Diretório raiz do projeto.
Uma vez que cada módulo possui seu próprio arquivo de gerenciamento de
dependências externas (pom.xml), torna-se desnecessário importar uma biblioteca para o
projeto inteiro se esta não for utilizada em todos os módulos. Para fins de organização das
classes de cada módulo, são criados pacotes para agrupar classes de finalidades semelhantes.
Partindo do módulo integration, foi criado um pacote responsável por agrupar as classes
que representam as entidades no banco de dados. Assim, para cada entidade existente no
modelo físico, foi criada sua respectiva entidade na aplicação. Para realizar a associação das
25
entidades com o modelo físico, foram desenvolvidas as interfaces do tipo Repository, que, ao
herdar os métodos da super-classe CrudRepository (dependência externa fornecida pelo pacote
Spring Data), possibilita o gerenciamento das entidades no banco de dados.
Para realizar de fato as operações desejadas no banco de dados, utilizando as entidades
e os repositórios criados, são desenvolvidas as classes do tipo Persistence, responsáveis por
implementar os contratos estabelecidos nas classes de serviço, contidas no módulo domain.
No módulo de negócios (domain), são desenvolvidas as interfaces do tipo Adapter, que
possuem métodos relacionados às regras de negócio, e que são implementados pelas classes de
persistência. Assim, estas interfaces não possuem nenhuma implementação relacionada às
bases de dados, sendo isoladas do módulo de integração. As classes do tipo Service contém as
regras de negócio e realizam a chamada dos métodos das interfaces Adapter.
O módulo de entrega (rest), é responsável por mapear as requisições de cada endpoint,
realizar as validações básicas e a validação do token do fornecedor, para, assim, realizar a regra
de negócio especificada para o endpoint. Para a validação do token, é feita a comunicação com
a classe TokenRedisPersistence, que implementa os métodos de gravação e consulta do token.
A Figura 15 a seguir ilustra a implementação da classe RedisTemplate, alteração e consulta de
valores no banco de dados não-relacional através de uma chave:
Figura 15 - Implementação de gravação e consulta do Token.
Desse modo, pode-se resumir os serviços da aplicação em dois principais fluxo, sendo
estes o fluxo de autenticação e o fluxo de operações. O fluxo de autenticação é ilustrado na
Figura 16, em que, primeiramente, é realizada a consulta ao banco de dados relacional para
criação do token do Fornecedor no banco de dados não-relacional.
26
Figura 16 – Fluxo de autenticação.
O fluxo de operações, por sua vez, realizado nas requisições após o usuário já ter se
autenticado com sucesso, é mostrado na Figura 17, em que, primeiramente, é realizada a
consulta ao banco de dados não-relacional para verificação do token do fornecedor, e, em caso
de sucesso, a operação requisitada é realizada no banco de dados relacional.
27
Figura 17 – Fluxo de operações.
O último módulo para ser desenvolvido é o Application, em que foi criada a classe de
mesmo nome, responsável por inicializar a aplicação em um servidor embarcado. No diretório
de recursos, são realizadas as configurações de banco de dados e da conta da plataforma de
monitoramento, através de um modelo chave-valor.
Com todas as classes desenvolvidas e arquivos de configuração criados, pode-se
construir a aplicação, compactando todos os módulos através do módulo principal, e executar
efetivamente o projeto através de um servidor embarcado, tornando possível a realização das
requisições na API e o acesso à documentação criada via código.
4.5.4. Desenvolvimento do Monitoramento
A fim de visualizar os logs na ferramenta e construir a interface de monitoramento., foi

necessário construir a aplicação (build) e executá-la (deploy). Assim, ao executar o arquivo de
configuração do módulo principal, a aplicação foi construída com sucesso, em alguns
segundos, conforme a Figura 18 a seguir:
28
Figura 18 - Processo de build da aplicação realizado com sucesso.
Para inicializar a aplicação no servidor local, foi preciso executar a classe principal do
módulo Application como uma aplicação Java. A partir deste momento, pode-se confirmar a
comunicação entre a API e o Loggly, visualizando todos os logs referentes a aplicação na tela
Search, conforme mostra a Figura 19 a seguir:
Figura 19 – Logs de inicialização da aplicação na tela de busca.
Através da tela de busca, pode-se obter os eventos de log referentes às requisições da

API, pesquisando pela mensagem contida no log, nível do log (error, info ou debug), nome da
classe ou método. Para criação do painel de visualização, utilizou-se a tela Charts, em que é
possível criar diferentes quadros a partir dos eventos de log.
29
Para filtrar os logs nesta tela, utiliza-se uma barra de busca semelhante a da tela de
pesquisa, podendo pesquisar pelo tipo de log e pela mensagem contida neste. É possível criar
gráficos de linha, coluna, área, pizza, ponto, tabelas e valores numéricos, possibilitando um
leque de diferentes tipos de visualização para os eventos. Também pode-se criar queries,
utilizando operadores lógicos (AND, OR, NOT), para relacionar mais de um tipo de log em
uma mesma pesquisa.
Outra funcionalidade importante é a criação de mais de um grupo de evento no mesmo
quadro, para visualização de diferentes eventos no mesmo gráfico, para fins de comparações
rápidas. Ao mesmo tempo, pode-se dividir um mesmo grupo de evento em alguns padrões pré-
estabelecidos pela ferramenta. Além disso, é possível customizar o intervalo de tempo de cada
gráfico, para verificar os logs emitidos ao longo de períodos específicos.
A Figura 20 a seguir mostra um gráfico sem nenhum tipo de filtro (buscando por todos
os logs possíveis que são enviados para a ferramenta de todas as fontes pré-configuradas),
contendo um grupo dividido por nível de severidade, sendo estes informação (INFO), aviso
(WARN) e erro (ERROR):
Figura 20 – Logs de diferentes fontes divididos por nível de severidade.
Desse modo, foram desenvolvidos os gráficos para composição do painel de

monitoramento da aplicação, tendo em mente a utilidade de cada gráfico para um
acompanhamento efetivo das requisições. A fim de validar as autenticações dos fornecedores,
foram desenvolvidos três quadros, na forma de números, que representam a quantidade de
30
requisições de autenticação realizadas, a quantidade de requisições em que o token foi gerado

e a quantidade de autenticações com falha. A Figura 21 ilustra a configuração para o painel
das requisições de autenticações iniciadas.
Figura 21 – Configuração do painel de autenticações iniciadas.
Para o monitoramento de forma geral da aplicação, foi desenvolvido um painel

escolhendo o tipo “Bar”, e utilizando o filtro log.type, a fim de possibilitar a visualização, em
um único gráfico de pizza, da quantidade de logs emitidos de três severidades diferentes, sendo
estas info (informativo), warn (aviso) e error (erro).
A fim de monitorar constantemente as persistências aos bancos de dados, foram criados
dois gráficos em formato de área, sendo um responsável pelo MySQL e outro responsável pelo
Redis Server, utilizando a mensagem de log emitida ao fim de cada operação. Para o
acompanhamento dos códigos de status retornados pelas requisições ao longo do tempo, foi
criado um gráfico, no formato de área, contendo uma variável correspondente a cada código
possível de ser retornado pela aplicação. A Figura 22 ilustra o filtro realizado por mensagem
para o gráfico de status code ao longo do tempo.
31
Figura 22 - Configuração do gráfico de status code retornado ao longo do tempo.
Para ter uma visão das requisições realizadas aos endpoints de maior relevância, foi
criado um gráfico, na forma de coluna, para cada endpoint da rota de produtos, contendo uma
variável de requisições de sucesso e uma variável de requisições com erro. Nesse caso, foi
utilizada a expressão lógica AND para filtrar os logs emitidos pelo respectivo método
responsável pelo mapeamento do endpoint e a mensagem de sucesso ou erro, como mostra a
Figura 23.
Figura 23 - Configuração do monitoramento de cadastro de produtos.

32
Além dos quadros de monitoramento, é disponibilizada a função de criação de alarmes

para envio de e-mail baseado em emissões de logs em um determinado período de tempo. A
partir dessa funcionalidade, foi criado um alerta responsável por verificar, de um em um
minuto, a quantidade de eventos de erro na rota de cadastro de produtos na última hora e
disparar um e-mail caso o número ultrapasse cinco eventos, como mostra a Figura 24:
Figura 24 - Configuração do alerta de erros na rota de cadastro de produtos.

33
5. RESULTADOS E DISCUSSÃO
5.1. Geração da Documentação
Ao executar a aplicação, é criada a página HTML de documentação da aplicação a partir

dos parâmetros descritivos habilitados pelo código. Assim, ao acessar a rota
“localhost:8080/swagger-ui.html#/”, é carregada a tela mostrada na Figura 25 a seguir:
Figura 25 – Cabeçalho da documentação gerada.
Nota-se que os parâmetros iniciais foram carregados com sucesso, permitindo a

visualização do título, descrição e urls para contato com o desenvolvedor da aplicação. Ao
navegar pela página, pode-se encontrar todos os Controllers na API, e, ao expandir o
controlador Produtos, são encontrados todos os seus endpoints, divididos por método,
disponbilizados ao cliente, conforme a Figura 26 a seguir.
34
Figura 26 – Listagem dos endpoints relacionados às operações de produtos.
Ao expandir o endpoint POST, temos acesso aos parâmetros de entrada necessários da

requisição, como o código identificador que deve ser passado na url e um exemplo do objeto
JSON que deve ser enviado no corpo da requisição, bem como a descrição de seus atributos
(na seção Model), como pode ser observado na Figura 27:
Figura 27 – Documentação dos parâmetros de entrada para o cadastro de produto.

35
Abaixo dos parâmetros de entrada, pode-se visualizar um exemplo de objeto de resposta

do cadastro de produtos, a descrição de cada campo e os possíveis status de resposta, como
mostra a Figura 28 abaixo:
Figura 28 – Documentação dos parâmetros de saída do cadastro de produto.
Assim, pode-se disponibilizar, tanto para os consumidores da aplicação quanto para os

desenvolvedores que podem atuar nela, uma documentação simples e de fácil visualização, que
informa os métodos disponíveis em cada rota e os parâmetros de saída e de entrada. Esse tipo
de documentação padronizada pode sanar dúvidas rapidamente e economizar tempo na busca
pelo entendimento do contrato da aplicação.
5.2. Validação dos Endpoints
Com a aplicação executada, pode-se realizar requisições, através da ferramenta

Postman, para verificar o comportamento da API em cada endpoint. Assim, foi criado no banco
de dados um fornecedor, identificado pelo código 15368 e pela senha “chaveDoFornecedor1”.
36
Ao realizar a autenticação através da rota “/login/{idFornecedor}”, utilizando o método

POST e enviando no corpo da requisição um JSON contendo as informações do código do
fornecedor e senha, obteve-se como resposta um JSON com o token a ser utilizado para o
fornecedor e o status code 201, como mostra a Figura 29.
Figura 29 – Validação do endpoint de autenticação.
Para confirmar a criação do token no banco de dados, acessou-se o Redis Client e,

através da query ‘HGETALL Fornecedor’, que busca por todos os objetos armazenados no
banco identificados pela chave ‘Fornecedor’, obteve-se o resultado como mostra a Figura 30,
confirmando o armazenamento do token gerado para o fornecedor 15368.
Figura 30 – Token armazenado com sucesso no banco de dados Redis.
Com o token gerado, pode-se realizar a requisição de cadastro de um produto novo para
este fornecedor. Assim, ao realizar uma requisição na rota “/produtos/{idFornecedor}”,
utilizando o método POST, enviando o token como valor do campo “Authorization” no
cabeçalho e, no corpo da requisição, o JSON contendo as informações do produto novo
corretamente preenchidas, obteve-se o seguinte resultado, mostrado na Figura 31.
37
Figura 31 – Validação do endpoint de cadastro de produto.
Nota-se que a requisição foi realizada com sucesso, uma vez que obteve-se o JSON
referente ao produto retornado, bem como status code 201, indicando a criação de um recurso
novo. Ao consultar o banco de dados, foi verificado a criação de um produto novo para este
fornecedor, como mostra a Figura 32.
Figura 32 – Produto criado com sucesso no banco de dados MySQL.

38
Ao consultar o produto criado através do seu código identificador (128), passando o

token no header da requisição, foi retornado o status code 200, bem como as informações do
produto, como exibe a Figura 33.
Figura 33 – Validação do endpoint de consulta de produto pelo seu código identificador.
Para verificar a rota de atualização de produtos, foi modicado o nome do produto

cadastrado anteriormente e realizado uma requisição, que obteve como retorno o produto
atualizado, com um novo código identificador, e o status code, como exibido na Figura 34.
Figura 34 – Validação do endpoint de atualização de produto.

39
Para validar a rota de exclusão de produtos, foi passado o código identificador do

produto 130, atualizado, anteriormente, na url da requisição. Obteve-se como retorno uma
mensagem, indicando sucesso na remoção do produto, e o status code 200, de acordo com a
Figura 35.
Figura 35 – Validação do endpoint de remoção de produto pelo seu código identificador.
Ao verificar, na base dados de produtos, se existe algum registro de produto com o

código identificador 130, não foi retornado nenhum resultado, conforme mostra a Figura 36.
Figura 36 – Produto removido da base MySQL com sucesso.
Assim, pode-se validar as rotas referentes aos produtos e a autenticação do fornecedor.

Foram realizadas diversas requisições, para validação dos outros endpoints de consulta, e para
geração de erros de permissão (403), autenticação (401), registros não encontrados (404), a fim
de gerar eventos de log para análise dos gráficos desenvolvidos para o monitoramento da
aplicação.
40
5.3. Monitoramento da Aplicação
5.3.1. Painel de Visualização
A fim de realizar um acompanhamento eficiente da aplicação, foram criados diversos

quadros de diversos tipos. Ao realizar várias requisições na API ao longo de um período de
tempo de três horas, pode-se obter os resultados demonstrados nessa seção.
Para monitorar de forma prática as requisições de autenticação, foram criados quadros
na forma de números, indicando a quantidade total de vezes em que o endpoint foi acessado, a
quantidade de vezes em que o token foi retornado com sucesso e as falhas de autenticação,
como mostra a Figura 37 abaixo:
Figura 37 – Painel de monitoramento do serviço de autenticação de fornecedores.
Uma vez que é utilizado o mesmo intervalo de tempo para os três quadros, pode-se
notar que o acompanhamento é efetivo, com o número de chamadas iniciadas igual ao número
de chamadas finalizadas com erro ou sucesso. Desse modo, ao clicar no quadro de
autenticações com erro, a janela de busca é aberta, carregando os objetos retornados de todas
as requisições sem sucesso.
Com o código identificador do fornecedor exibido nas mensagens de erro retornadas, é
possível uma rápida atuação do analista para entrar em contato com o fornecedor que não
consegue se autenticar, ou mesmo identificar se a rota está tentando ser acessada por alguém
que não tem permissão alguma.
Para possibilitar o acompanhamento dos logs de uma forma mais genérica, é utilizado
o gráfico no formato de pizza mostrado na Figura 38 a seguir, que filtra todos os eventos de
41
log recebidos pela aplicação por nível de severidade. Através desse gráfico, pode-se ter uma
ideia geral sobre o estado da aplicação em uma rápida visualização.
Figura 38 – Eventos de log da aplicação por nível de severidade.
A fim de acompanhar métricas relacionadas a infraestrutura dos bancos de dados, foram

criados gráficos de área que disponibilizam uma visão dos eventos relacionados ao MySQL e
Redis Server ao longo do tempo. A Figura 39 exibe o gráfico de operações nos bancos de dados
ao longo do tempo.
Figura 39 – Painel de monitoramento das operações realizadas nas bases de dados.

42
Desse modo, pode-se identificar períodos de pico no uso dos bancos de dados para que
sejam disponibilizados mais servidores rapidamente. Pode-se perceber, no gráfico relacionado
ao Redis Server, dois períodos de indisponibilidade (entre 13:45 e 14:00 e entre 15:30 e 15:50),
períodos no qual o servidor foi desligado para analisar o comportamento do gráfico.
Para monitorar as requisições com base no status code retornado, foi desenvolvido o
painel apresentado na Figura 40, que filtra todas as respostas de todos endpoints pelo código
de status retornado. Através dele, pode-se ter uma visão da proporção de chamadas com sucesso
em relação ao total de requisições realizadas.
Também pode-se ter uma ideia da proporção de erros causados por chamadas realizadas
erroneamente (códigos de status 400, 401, 403 e 404) e erros internos do sistema (código de
status 500), possibilitando um melhor direcionamento para atuação nesses casos. Nota-se que
os períodos de indisponibilidade no Redis Server também foram refletidos neste gráfico, nos
períodos em que houve grande quantidade de erros de status 500.
Figura 40 – Códigos de status retornados aos fornecedores ao longo do tempo.
Com a finalidade de ter um acompanhamento na mudança da necessidade dos clientes

consumidores da API, é criado um gráfico que informa a quantidade de requisições por
endpoint ao longo do tempo, mostrado na Figura 41 a seguir. Pode-se notar, através dessa visão,
que a ferramenta não se limita ao monitoramento de software e hardware, podendo ser utilizada
para tomadas de decisões de negócio em relação a utilização de diferentes tipos de consulta.
43
Figura 41 – Rotas acessadas pelos fornecedores ao longo do tempo.
Para monitorar as rotas mais utilizadas pelos consumidores da aplicação, pode-se filtrar
os logs de determinado endpoint por tipo de severidade. Assim, é possível acompanhar serviços
de negócio mais críticos de maneira especial. A Figura 42 a seguir mostra o monitoramento do
serviços de cadastro e atualização de produtos ao longo do tempo.
Figura 42 – Requisições de cadastro e atualização de produtos ao longo do tempo.

44
Nota-se que, no período entre 16:15 e 16:30, em que houve um alto índice de
requisições com erro de cadastro e atualização de produtos, também apresentou um alto índice
de erros 401, 403 e 404, como pode ser visto no acompanhamento de requisições por código
de status. A Figura 43 mostra o acompanhamento das rotas de consultas e exclusões de produtos
ao longo do tempo.
Figura 43 – Requisições de consulta e exclusão de produtos ao longo do tempo.
Pode-se observar que a rota de consultas de produtos apresenta menor quantidade de

erros, uma vez que a requisição é mais simples, envolvendo apenas a passagem do código do
fornecedor e do produto.
Ao identificar erros nestes fluxos, pode-se abrir a tela de busca (clicando no gráfico) e
descobrir rapidamente, através do corpo da mensagem de log, qual fornecedor está tendo erro
ao cadastrar um produto novo e o motivo, possibilitando uma tempestividade maior na atuação
em erros destes serviços.
Pode-se também obter outro tipo de visão, voltada para contexto de negócio, em que se
monitora as quatro operações relacionadas aos produtos ao longo do tempo. Deste modo, pode-
45
se perceber rapidamente casos em que exclusões de produtos começam a superar muito os

cadastros de produtos novos, por exemplo, possibilitando um contato com os fornecedores de
imediato para descobrir o porquê de estarem excluindo vários produtos em um intervalo
pequeno de tempo. A Figura 44 a seguir mostra o gráfico responsável por esse monitoramento:
Figura 44 – Requisições de sucesso relacionadas aos produtos ao longo do tempo.
5.3.2. Alerta
Com a intenção de reforçar o monitoramento de serviços mais críticos e garantir que a

equipe de desenvolvimento seja notificada mesmo em períodos em que não haja tempo para
visualizar os painéis constantemente, são criados alertas de erro.
Desse modo, pode-se configurar a ferramenta para vasculhar os eventos de log uma vez
a cada cinco minutos e disparar um alerta caso, nos cinco minutos antecedentes à varredura,
tenham ocorrido mais de cinco erros na rota de cadastro de produtos. A Figura 45 a seguir
mostra este alerta configurado e habilitado para envio de e-mail ao dono da conta.
46
Figura 45 – Alerta de erros no cadastro de produtos habilitado.
Ao realizar algumas requisições com erro na rota de cadastro de produtos, foi recebido
o e-mail conforme mostra a Figura 46, confirmando a importância dessa funcionalidade, que,
aliada aos painéis de visualização, possibilitam uma reação mais rápida nos casos de erros
destes serviços.
Aém do disparo de e-mail, os alertas podem ser enviados a algum endpoint estabelecido
na hora de sua configuração, para abertura de incidentes ou para canais de comunicação
existentes nos ambientes de tecnologia, tais como o Microsoft Teams.
Figura 46 – E-mail enviado após disparo do alerta.

47
6. CONCLUSÕES
Neste trabalho, foi possível, por meio de uma ideia de negócio e suas necessidades,
propor um desenho de solução de software e implementá-lo com sucesso, realizando a
integração entre diferentes tecnologias, sendo algumas destas em ambiente local e uma em
nuvem.
O modelo de desenvolvimento modular mostrou-se adequado para ser utilizado em
APIs, uma vez que facilita a implementação de regras no módulo de negócios, independente
dos outros módulos, e divide as responsabilidades para cada camada da aplicação, tornando-a
mais leve e facilitando sua manutenção. Foi possível aplicar os conceitos de programação
orientada a objetos, tais como encapsulamento e herança, neste modelo de desenvolvimento, e
entender sua importância na manutenção de software.
Pode-se implementar, em uma mesma aplicação, duas tecnologias de bancos de dados
diferentes, mostrando como essas podem se complementar. O MySQL Server mostrou-se uma
escolha adequada para as informações de produtos e fornecedores, dada a necessidade de
relacionamentos entre entidades, precisão de dados e consultas mais customizadas. O Redis
Server pode ser utilizado com sucesso para armazenamento do token, proporcionando
dinamismo em uma consulta que é realizada em todas as requisições providas pela API.
A documentação gerada através do código se mostrou uma ferramenta útil para um
rápido entendimento do contrato da aplicação, facilitando a manutenção do código. No entanto,
para uma explicação mais detalhada das funcionalidades de negócio da aplicação e suas
integrações com outras plataformas, deve-se utilizar outras ferramentas.
A construção do painel de monitoramento da aplicação foi realizada com sucesso,
mostrando como o Loggly possibilita um acompanhamento efetivo e dinâmico, em tempo real,
do estado da aplicação e das tecnologias integradas a esta. Esta ferramenta proporciona uma
atuação mais rápida e tempestiva da equipe de desenvolvimento em casos de instabilidade do
sistema e de erros dos consumidores da aplicação. A ferramenta também pode ser utilizada pela
equipe de negócios, para monitorar a utilização de cada serviço da API pelos clientes, mantendo
um contato mais próximo com estes.
No geral, este trabalho serviu como uma oportunidade para aplicação dos
conhecimentos do aluno na área de computação aprendidos ao longo do curso, bem como
outras disciplinas relacionadas a lógica. Também mostrou-se como uma chance para buscar
conhecimentos de recursos modernos que são utilizadas no mercado de tecnologia da
informação.
48
6.1. Sugestões para Trabalhos Futuros
Uma possibilidade para continuação deste trabalho é a geração de uma imagem da

aplicação, possibilitando a criação de uma máquina virtual e, consequentemente, a
virtualização das rotas da API, simulando um comportamento mais próximo da realidade em
relação ao seu uso. Para isso, seria necessário implementar mais uma camada de autenticação,
por meio da criação de credenciais únicas para a aplicação.
Com a criação de um servidor na nuvem para a aplicação e os bancos de dados, seria
possível realizar o monitoramento de métricas mais específicas em relação a infraestrutura do
sistema, tais como consumo de CPU e memória ao longo do tempo.
49
REFERÊNCIAS
ALBERTIN, A. L. Comércio Eletrônico: Modelo, aspectos e contribuições de sua

aplicação. 6. ed. São Paulo: Atlas, 2010.
CARMO, H. V. do. O que você está fazendo com seus logs? Imaster. Disponível em:
<https://imasters.com.br/aws/o-que-voce-esta-fazendo-com-seus-logs>. Acesso em: 30 mar.
2021.
CLEMENTE, R. G. Uma Arquitetura para Processamento de Eventos de Log em Tempo

Real. Pontíficia Universidade Católica do Rio de Janeiro (PUC-RJ), 2008. Disponível em: <
https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=12571@1>.
Acesso em: 30 mar. 2021.
DINIZ, L. L. O Comércio Eletrônico como Ferramenta Estratégica de Vendas para

Empresas. São Paulo: Unisalesiano, 2011. Disponível em: <
http://www.unisalesiano.edu.br/simposio2011/publicado/artigo0093.pdf> Acesso em: 19 jun.
2020.
ELMASRI, R.; NAVATHE S. B. Sistemas de banco de dados. Person Education do Brasil,

7ª edição. 2018.
EVANS, E. Domain Driven Design. [S.l.]: Alta Books, 2016.
FIELDING, R. T. Architectural styles and the design of network-based software

architectures. Tese (Doutorado) — University of California, Irvine, 2000.
IRACE, M. B. M. Big Data: Analisando Dados com o Splunk Enterprise. Universidade

Federal do Rio de Janeiro (UFRJ), 2018. Disponível em: <
http://monografias.poli.ufrj.br/monografias/monopoli10024511.pdf >. Acesso em: 30 mar.
2021.
MASSE, M. REST API Design Rulebook: Designing Consistent RESTful Web Service
Interfaces. [S.l.]: "O’Reilly Media, Inc.", 2011.
MORO, T. D.; DORNELES, C.; REBONATTO, M. T. Web services WS-* versus Web
Services REST. Instituto de Ciências Exatas e Geociências, Universidade de Passo Fundo
(UPF), 2011. Disponível em: <https://seer.ufrgs.br/reic/article/view/22140/12928>. Acesso
em: 28 mar. 2021.
50
MÜLLER, E. J. Argos: Solução Centralizada para Loggin de Aplicações. Universidade

Federal de Santa Maria (UFSM), 2013. Disponível em:
<https://repositorio.ufsm.br/handle/1/156>. Acesso em: 30 mar. 2021.
OLIVEIRA A. G. G. de. Construção de Aplicações Distribuídas Utilizando-se de APIs

REST. Universidade do Estado do Rio Grande do Norte (UERN), 2018. Disponível em:
<https://di.uern.br/tccs2019/html/ltr/PDF/014006456.pdf>. Acesso em: 28 mar. 2021.
PICKERING, A. Centralised logging with Loggly and Bunyan. Disponível em:

<https://levelup.gitconnected.com/centralised-logging-with-loggly-and-bunyan-
63c24f4d5617>. Acesso em: 30 mar. 2021.
RICARTE, I. L. M. Programação Orientada a Objetos: Uma Abordagem com Java.

Faculdade de Engenharia Elétrica e de Computação. Universidade Estadual de Campinas
(UNICAMP), 2001. Disponível em:
<https://www.dca.fee.unicamp.br/courses/PooJava/Aulas/poojava.pdf>. Acesso em: 28 mar.
2021.
ROCHA, F. da. Benefícios da Utilização de uma Aplicação para Concentração e Análise

em Tempo Real de Logs dos Servidores Web de uma Instituição de Ensino Superior.
Universidade do Sul de Santa Catarina (UNISUL), 2018. Disponível em:
<https://riuni.unisul.br/handle/12345/4959>. Acesso em: 30 mar. 2021.
SCHREINER, G. A. SQLTOKEYNOSQL: Uma Camada para Mapeamento de Esquemas

Relacionais e de Operações SQL para Bancos de Dados NOSQL para Bancos de Dados
Baseados em Chaves de Acesso. Florianópolis, SC, 2016. Universidade Federal de Santa
Catarina (UFSC), 2016. Disponível em:
<https://repositorio.ufsc.br/xmlui/handle/123456789/167987>. Acesso em: 29 mar. 2021.
SILBERSCHATZ, A.; KORTH; H. F.; SUDARSHAN; S. Sistema de banco de dados. 6º

edição. Rio de Janeiro, RJ. Elsevier. 2012.
SOLARWINDS. Loggly Getting Starter Guide. Disponível em:

<https://documentation.solarwinds.com/en/Success_Center/loggly/Content/loggly_Getting_St
arted_Guide.htm> Acesso em: 30 mar. 2021.
SOUZA, J. A. N. de. Uma API REST para Consumo de Dados Georreferenciados

Utilizando ArangoDB. Faculdade de Ciências Exatas e Naturais, Universidade do Estado do
51
Rio Grande do Norte (UERN), 2018. Disponível em:

<http://di.uern.br/tccs2019/html/ltr/PDF/014003929.pdf>. Acesso em: 28 mar. 2021.
TAKAI, O. K., ITALIANO, I. C., FERREIRA, J. E. Introdução ao Banco de Dados. São

Paulo: USP, 2005. Disponível em: <https://www.ime.usp.br/~jef/apostila.pdf> Acesso em: 29
mar. 2021.
UEMA, E.; LAZZARI, C. P. de. O. O Crescimento do E-Commerce no Brasil: Estudo de

Caso do “Submarino”. Revista Científica da Faculdade das Américas, São Paulo, 2008.
Disponível em: <https://agmkt.files.wordpress.com/2010/03/estudo-de-casos-e-
commerce.pdf> Acesso em: 19 jun. 2020.
VICCI, C. Banco de dados. 1º Edição. São Paulo, SP. Person Education do Brasil. 2014.
VILELA, F. de A. Um Método de Integração de Dados Armazenados em Bancos de Dados

Relacionais e NOSQL. Instituto de Informática. Universidade Federal de Goiás (UFG), 2015.
Disponível em: <https://repositorio.bc.ufg.br/tede/handle/tede/5862>. Acesso em: 29 mar.
2021.
WERK, L. S. de. Desenvolvimento de plataforma online de doações baseada em uma

arquitetura DDD, Event Sourcing e CQRS. Centro Tecnológico. Universidade Federal de
Santa Catarina (UFSC), 2017. Disponível em:
<https://repositorio.ufsc.br/handle/123456789/197639>. Acesso em: 28 mar. 2021.

Vinícius Rodrigues de Sousa: Desenvolvimento E Monitoramento de Uma Api de E-Commerce

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Vinícius Rodrigues de Sousa: Desenvolvimento E Monitoramento de Uma Api de E-Commerce

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTADUAL PAULISTA

“JÚLIO DE MESQUITA FILHO”

VINÍCIUS RODRIGUES DE SOUSA

DESENVOLVIMENTO E MONITORAMENTO DE UMA API

DESENVOLVIMENTO DE MONITORAMENTO DE UMA API DE E-

Trabalho de Graduação apresentado ao

Orientador: Prof. Dr. Galdenoro Botura Júnior

Palavras-chave: API, E-Commerce, REST, Monitoramento, Banco de Dados, Documentação,

E-commerce has evolved as digital services advance, allowing micro-entrepeneurs to display

Keywords: API, E-commerce, REST, Monitoring, Database, Documentation, Module, Log

Figura 1 – Estrutura de um sistema segundo o padrão DDD. .................................................... 6

Tabela 1 – Categorias de códigos de status e suas descrições. .................................................. 4

API Application Programming Interface

1.1. Justificativa ......................................................................................................... 1

1.2. Objetivos ............................................................................................................. 2

1.2.1. Objetivos Específicos................................................................................... 2

2.1. E-Commerce ....................................................................................................... 3

2.2. Web Services ...................................................................................................... 3

2.2.1. Protocolo HTTP ........................................................................................... 3

2.3. API ...................................................................................................................... 4

2.3.1. Arquitetura REST ........................................................................................ 5

2.4.1. Isolamento do Domínio................................................................................ 6

2.5. Programação Orientada a Objetos ...................................................................... 7

2.6. Bancos de Dados ................................................................................................. 8

2.6.1. Bancos de Dados Relacionais ...................................................................... 8

2.6.2. Bancos de Dados Não-Relacionais ............................................................ 10

2.7. Monitoramento de Eventos ............................................................................... 11

2.7.1. Loggly ........................................................................................................ 12

3.1. Benefícios da Utilização de uma Aplicação para Concentração e Análise em

3.2. Big Data: Analisando Dados com o Splunk Enterprise .................................... 15

4.1. Requisitos de Sistema ....................................................................................... 17

4.2. Regras de Negócio ............................................................................................ 18

4.4. Proposta de Solução .......................................................................................... 21

4.5. Desenvolvimento .............................................................................................. 22

4.5.1. Criação do Modelo Relacional de Dados................................................... 22

4.5.2. Criação do Modelo Não-Relacional de Dados........................................... 23

4.5.3. Desenvolvimento da Aplicação ................................................................. 24

4.5.4. Desenvolvimento do Monitoramento ........................................................ 27

5. RESULTADOS E DISCUSSÃO ............................................................................. 33

5.1. Geração da Documentação ............................................................................... 33

5.2. Validação dos Endpoints................................................................................... 35

5.3. Monitoramento da Aplicação ............................................................................ 40

5.3.1. Painel de Visualização ............................................................................... 40

6.1. Sugestões para Trabalhos Futuros .................................................................... 48

O presente trabalho tem por objetivo o desenvolvimento do protótipo de uma API na

1.2.1. Objetivos Específicos

 Desenvolvimento de uma aplicação em uma linguagem de alto nível (java)

O modelo de comércio em que as negociações são feitas em um ambiente eletrônico,

2.2. Web Services

Pode-se definir um Web Service como um sistema de software que possibilita a

2.2.1. Protocolo HTTP

O HTTP, principal protocolo existente na internet, é utilizado para distribuição de

por um cliente e no recebimento de respostas pelo servidor. Como trata-se de um meio de

Tabela 1 – Categorias de códigos de status e suas descrições.

A API, do inglês Application Programming Interface, é uma interface, implementada

conhecimento em relação a documentação da mesma possa consumi-la, tornando denecessária

2.3.1. Arquitetura REST

O REST, do inglês Representational State Transfer, é um modelo de arquitetura

O DDD, do inglês, Domain-Driven-Design, ou desenvolvimento orientado a domínio,

2.4.1. Isolamento do Domínio

Uma vez que a premissa é o desenvolvimento orientado ao domínio, as informações

Figura 1 – Estrutura de um sistema segundo o padrão DDD.

Fonte: Werk, 2017.