Data de elaboração | 03/11/2021 |
Responsável pelo estudo | Rafael Passos dos Santos (Assessor) |
Equipe do estudo | Gustavo Felix Gomes (Assessor)
Rafael Passos dos Santos (Assessor)
André Honório de Andrade Silva (Tecnico)
Emanuel Rufino Alcantara de Lima (Analista)
Lucas de Souza e Sousa (Estagiario)
Euriane Nogueira (Product Owner) |
Alvo | Alpha |
Origem | Diminuir o acoplamento entre as apis de serviço e solicitação no Alpha |
Objetivo | Identificar as possíveis melhorias para diminuir o acoplamento entre as apis de serviço e solicitação do Alpha.
|
Documentação correlata | -/- |
Observações | O presente estudo pretende também levantar as Historias dos cards para a Sprint |
UX: Experiência do Usuário
User Experience: Experiência do Usuário
Após a refatoração do Alpha, espera-se que as apis trabalhem de forma autônoma, porém a api de solicitação depende de alguns dados da api de serviços para realizar alguns cálculos e listagens. Caso a api de serviços fique fora, a api de solicitação não consegue efetuar esses cálculos. Este estudo visa encontrar uma forma de minimizar esses impactos.
Após a refatoração, o alphaApi que era uma junção do alphasolicitacoesapi e do cartadeServicosApi foi desmembrado, porém algumas funcionalidades necessitam de integração entre essas duas apis. As funcionalidades são apresentadas abaixo:
Neste método é feita uma consulta a API de serviços para obter a forma de atendimento para então ser feito o cálculo do prazo final de atendimento.
Solução
Para este caso, é possível criar um campo que guarde a data final do prazo de atendimento. Este campo seria preenchido na criação da solicitação e só seria feita a busca na API de serviços uma vez. Com esta solução também haveria melhoria na performance, pois essa consulta é utilizada na listagem de solicitações do portal do servidor, então para cada solicitação uma busca na API é feita.
Neste método é feita uma consulta a API de serviços para obter a forma de atendimento para então ser feito o cálculo do prazo final de atendimento.
Solução
Para este caso, é possível criar um campo que guarde a data final do prazo de atendimento. Este campo seria preenchido na criação da solicitação e só seria feita a busca na API de serviços uma vez. Com esta solução também haveria melhoria na performance, pois essa consulta é utilizada na listagem de solicitações do portal do servidor, então para cada solicitação uma busca na API é feita.
Este método utiliza a rota "ObterServicoPorId" que traz os detalhes do serviço da solicitação. Esta busca é feita para calcular a situação do atendimento.
Solução
Com a solução anterior é possível eliminar esta busca, visto que a data final estaria gravada na api de solicitações
Neste método é feita uma consulta a API para obter quais são os serviços de RH
Solução
Para este caso, não foi encontrado solução, pois é necessário buscar todos os serviços que são de RH
Neste método é feita uma consulta a API para obter quais são os serviços do servidor de um determinado departamento.
Solução
Para este caso, não foi encontrado solução, pois é necessário buscar todos os serviços que são de departamento
Neste método é feita uma consulta a API para obter quais são os serviços do cidadão de um determinado departamento.
Solução
Para este caso, não foi encontrado solução, pois é necessário buscar todos os serviços que são de departamento
Neste método é feita uma consulta a API para trazer os detalhes do serviço de solicitações externas ao GCS. Esta consulta também serve para calcular o prazo de atendimento.
Solução
Para este caso, poderia não mostrar o prazo de atendimento ou gravar as solicitações de outros sistemas na base do alpha.
Título |
Pontos da História |
---|---|
(Debito Técnico) Gravar a informação da data final na solicitação de serviço |
5 pontos |
(Debito Técnico) Calcular a data final do prazo para a realização do serviço |
5 pontos |
TOTAL |
10 pontos |
As soluções apresentadas diminuem o acoplamento entre as apis e também visa deixar os portais do servidor e do cidadão online. No caso do alpha, as funcionalidades apresentadas dependem das informações dos serviços, por isso, não seria possível desacoplar.