joão nuno félix abrunhosa de brito migração de uma aplicação … · 2019-03-01 · no...
TRANSCRIPT
Universidade do Minho Escola de Engenharia
João Nuno Félix Abrunhosa de Brito
Migração de uma aplicação desktop para a
cloud: geração automática de um web service
Dissertação de Mestrado
Mestrado Integrado em Engenharia e Gestão de Sistemas
de Informação
Trabalho realizado sob a orientação de:
Prof. Doutor José Luís Mota Pereira
Dr. José Miguel Pimenta Marques
Janeiro de 2018
Declaração para o RepositoriUM: Dissertação de Mestrado
Nome: João Nuno Félix Abrunhosa de Brito
N.º Cartão Cidadão: 14907573
Telemóvel: 913964866
Correio eletrónico: [email protected]
Curso: Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação
Ano de conclusão da dissertação: 2018
Título em PT: Migração de uma aplicação desktop para a cloud: geração automática de um web service
Título em EN: The migration of a desktop application to the cloud: automatic generation of a web service
Orientador: Prof. Dr. José Luís Mota Pereira
Coorientador: Dr. José Miguel Pimenta Marques
Declaro que concedo à Universidade do Minho e aos seus agentes uma licença não-exclusiva para
arquivar e tornar acessível, nomeadamente através do seu repositório institucional, nas condições abaixo
indicadas, a minha dissertação, em suporte digital.
Concordo que a minha dissertação seja colocada no repositório da Universidade do Minho com o
seguinte estatuto:
1. Disponibilização imediata do trabalho para acesso universal;
2. Disponibilização do trabalho para acesso exclusivo na Universidade do Minho durante o período de 1 ano,
2 anos ou 3 anos, sendo que após o tempo assinalado autorizo o acesso universal.
3. Disponibilização do trabalho de acordo com o Despacho RT-98/2010 c) (embargo______ anos)
Guimarães, _____ /_____ /_______
Assinatura: ___________________________________________________________________
iii
Agradecimentos
Gostaria primeiramente de agradecer aos meus orientadores todo o apoio que me deram durante o
decorrer deste grande projeto, e por me terem incentivado a fazer o meu melhor.
Queria agradecer também à minha família, que me apoiou emocionalmente, proporcionando o melhor
ambiente possível para conseguir atingir os meus objetivos.
Por fim, gostaria de agradecer aos meus amigos, pelo apoio e ânimo que me transmitiram.
Obrigado.
iv
v
Resumo
O mundo reconhece hoje, cada vez mais, a importância de aplicações híbridas que consigam conjugar
um ambiente desktop, com a Web e dispositivos móveis. Neste documento é descrita a criação de um
serviço Web que vem adicionar valor a um produto já existente, ao permitir disponibilizar as
funcionalidades desse produto através da Internet. Devido à complexidade e tamanho da aplicação em
questão, será necessária a geração automática da maior parte do código da interface possível, que será
feita através de uma ferramenta desenvolvida especificamente para o efeito, já que a criação e
manutenção manual do código da interface, seria muito dispendiosa.
Para que a aplicação desktop suporte a nova interface, a sua arquitetura terá de ser estudada e alterada
de modo a suportar uma componente extra que permita fazer a ligação da Web com a mesma,
respeitando as suas regras de negócio.
Foi também discutida a utilização de uma metodologia ágil adaptada ao desenvolvimento individual de
projetos. O documento encerra com uma discussão detalhada dos resultados alcançados, onde é
também descrita a utilização da metodologia de desenvolvimento e as diversas validações feitas ao
serviço Web.
Atualmente existem duas grandes abordagens para o desenvolvimento de serviços Web: uma baseada
em Simple Object Access Protocol (SOAP) e outra em Representational State Transfer (REST). Ambas
serão consideradas e avaliadas e a mais indicada será escolhida como abordagem de desenvolvimento
do serviço Web.
Palavras-chave: Serviços web, Web API, SOAP, REST, SOAP vs REST.
vi
vii
Abstract
Nowadays, hybrid applications that can manage the interactions between a desktop environment with
Web functionalities and mobile devices are steadily gaining more and more importance. The purpose of
this dissertation is to investigate, develop and implement an interface between the client’s desktop
application and the Web. Due to the desktop application complexity and size, there is a need to generate
as much code as possible automatically, thus saving a great amount of resources, instead of the manual
creation and maintenance of the interface’s code.
In order for the application to support the new interface, a study must be done to its original architecture
to evaluate the best way to re-model it, so that the connection between the Web and the desktop
application is done properly, and all the architecture’s business rules are respected.
The usage of an agile development methodology for solo developers was also discussed. The document
ends with a thorough discussion of the achieved results, where it is also described the usage of said
methodology and the validations made to the Web service.
Currently, two big approaches exist for developing Web services, specifically Simple Object Access
Protocol (SOAP) and Representational state transfer (REST). In this document, besides doing the state of
the art and planning the work throughout the dissertation, the advantages and disadvantages of each
architecture are discussed, considering the type of application and the its scope. This study lead to
conclusions as to which Web service is the best to used, developed and implemented during the following
work of the dissertation.
Keywords: Web services, Web API, SOAP, REST, SOAP vs REST.
viii
ix
Índice
Agradecimentos ................................................................................................................................. iii
Resumo ..............................................................................................................................................v
Abstract ............................................................................................................................................ vii
Lista de figuras .................................................................................................................................. xi
Lista de tabelas ................................................................................................................................. xii
Lista de Abreviaturas, Siglas e Acrónimos ......................................................................................... xiii
1. Introdução .................................................................................................................................. 1
1.1. Enquadramento .................................................................................................................. 1
1.2. Problema e motivação ........................................................................................................ 1
1.3. Objetivos e resultados esperados ........................................................................................ 2
1.4. Estrutura do documento ...................................................................................................... 3
2. Revisão de literatura ................................................................................................................... 5
2.1. Serviços Web SOAP ............................................................................................................ 7
2.2. Serviços Web REST ............................................................................................................. 8
2.3. REST versus SOAP ............................................................................................................ 10
3. Abordagem metodológica ......................................................................................................... 14
3.1. Scrum solo ....................................................................................................................... 14
4. Arquitetura do ERP da PrimaveraBSS ........................................................................................ 19
5. Web API ................................................................................................................................... 20
5.1. Arquitetura........................................................................................................................ 21
5.2. Funcionalidades ................................................................................................................ 22
5.3. Utilização da Web API ....................................................................................................... 33
5.4. Contratempos no desenvolvimento .................................................................................... 34
5.5. Documentação ................................................................................................................. 35
6. Gerador de código .................................................................................................................... 37
x
7. Aplicação de Scrum solo ........................................................................................................... 40
8. Discussão de resultados ........................................................................................................... 44
8.1. Utilização do Scrum solo ................................................................................................... 44
8.2. Validações do projeto ........................................................................................................ 44
9. Conclusões............................................................................................................................... 49
Referências bibliográficas ................................................................................................................. 51
Anexo 1 - Scope ............................................................................................................................... 53
Anexo 2 – Product backlog ............................................................................................................... 54
Anexo 3 – Spring backlog ................................................................................................................. 57
xi
Lista de figuras
Figura 1- Tempo de resposta REST e SOAP (Tihomirovs & Grabis, 2016) .......................................... 13
Figura 2- Fluxo do processo Scrum Solo. Adaptada de (Pagotto et al., 2016) ..................................... 15
Figura 3- Definição de requisitos (Adaptado de Pagotto, Fabri, Lerario & Gonçalves, 2016) ................ 15
Figura 4- Sprint (Adaptado de Pagotto, Fabri, Lerario, & Gonçalves, 2016) ........................................ 16
Figura 5- Gestão do projeto (Adaptado de Pagotto, Fabri, Lerario, & Gonçalves, 2016) ...................... 16
Figura 6- Deployment (Adaptado de Pagotto, Fabri, Lerario, & Gonçalves, 2016) ............................... 17
Figura 7-Arquitetura e organização da aplicação com a Web API ....................................................... 19
Figura 8- Exemplo de uma chamada ao ERP..................................................................................... 21
Figura 9 - Implementação da cache com o namespace "System.Runtime.Caching" ........................... 23
Figura 10- Exemplo da implementação de cache com “Strahweb.CacheOutput” ............................... 24
Figura 11- Exemplo da invalidação de cache ..................................................................................... 24
Figura 12- Inserção e extração de um objeto em cache ..................................................................... 25
Figura 13 - Fluxo do processo SAML ................................................................................................. 25
Figura 14- Fluxo do processo OAuth, OAuth2 e JWT .......................................................................... 26
Figura 15- Versão simplificada do código do override do método do AuthServerProvider ................... 28
Figura 16- Chamada da framework Oauth2.0 ................................................................................... 29
Figura 17- Teste ao serviço de geração de tokens com Postman ....................................................... 30
Figura 18- Utilização de um token para aceder a um recurso ............................................................ 30
Figura 19 - Diagrama de utilização de refresh tokens e access tokens ............................................... 31
Figura 20 - Diagrama de sequência da utilização da Web API ............................................................ 33
Figura 21- Página inicial da documentação ....................................................................................... 35
Figura 22- Exemplo da documentação de um método GET ............................................................... 36
Figura 23 - Exemplo da documentação de um método POST ............................................................ 36
Figura 24- Protótipo do UI do gerador de código ............................................................................... 37
Figura 25- Exemplo de um método gerado........................................................................................ 38
Figura 26- Diagrama de atividades da execução do gerador de código ............................................... 39
Figura 27- Calendário de sprints ....................................................................................................... 41
Figura 28 - Exemplo de um sprint backlog (página à direita) .............................................................. 42
Figura 29- UI da aplicação para autorização de documentos de venda .............................................. 45
Figura 30- UI do website para criação de documentos de compra ..................................................... 46
Figura 31- Interface de login no Outlook para verificação de vendas pendentes ................................. 46
xii
Figura 32- Interface de visualização de vendas pendentes ................................................................. 47
Figura 33- Exemplo de um Web test ................................................................................................. 48
Lista de tabelas
Tabela 1- Características de REST e SOAP (Adaptado de Muehlen, Nickerson, & Swenson (2005)) .... 11
Tabela 2- Comparação de SOAP vs REST (Adaptado de Wagh e Thool (2012)) .................................. 12
Tabela 3- Tabela de comparação de tokens opacos e JWT ................................................................ 26
xiii
Lista de Abreviaturas, Siglas e Acrónimos
• API - Application Programming Interface;
• DLL – Dynamic-link library;
• ERP - Enterprise Resource Planning;
• GPB - Google Protocol Buffers;
• HATEOAS - Hypermedia as the Engine of Application State;
• HTTP - Hypertext Transfer Protocol;
• IETF - Internet Engineering Task Force;
• JMS - Java Message Service;
• JSON - JavaScript Object Notation;
• JWT – JSON Web Token;
• PSP - Personal Software Process;
• REST - REpresentational State Transfer;
• RPC - Remote Procedure Call;
• SI - Sistemas de Informação;
• SMTP - Simple Mail Transfer Protocol;
• SOAP - Simple Object Access Protocol;
• TI - Tecnologias de Informação;
• UDDI - Universal Description Discovery and Integration;
• URI - Uniform Resource Identifier;
• URL - Uniform Resource Locator;
• WSDL - Web Services Description Language;
• XML- Extensible Markup Language.
1
1. Introdução
Este capítulo tem como objetivo fazer o enquadramento do projeto, explicar o problema e a sua
motivação, os objetivos e resultados esperados e, por fim, explicar o modo como o documento se
encontra estruturado.
1.1. Enquadramento
O mundo reconhece, hoje cada vez mais, a importância de aplicações híbridas que consigam conjugar
um ambiente desktop com partes de funcionalidades na Web e dispositivos móveis.
Originalmente, a Web era um conjunto de páginas estáticas, porém, está a sofrer uma transformação,
apresentando-se cada vez mais como um conjunto de serviços que interagem pela Internet (Paolucci,
Kawamura, Payne, & Sycara, 2002). Hoje em dia, esta transformação que estava a decorrer, passou a
uma realidade.
A utilização de serviços Web tem aumentado e, consequentemente, é importante que o tipo do serviço
Web seja corretamente escolhido na fase de design do projeto. As implementações mais comuns são
baseadas em SOAP (Simple Object Access Protocol) e REST (REpresentational State Transfer protocol)
(Tihomirovs & Grabis, 2016).
Este tema foi proposto pela PrimaveraBSS, sendo que, o desenvolvimento será feito nas instalações da
empresa, e serão disponibilizados recursos, para que o desenvolvimento da solução seja o mais agilizado
possível.
1.2. Problema e motivação
Os processos de negócio são o núcleo do mundo empresarial. Embora o número de serviços Web esteja
a crescer rapidamente, serviços Web básicos com funcionalidades limitadas não estão a satisfazer os
processos de negócio complexos. Para tal, é necessário um conjunto diversificado de participantes para
a composição de serviços Web que descrevam estes processos de negócio complexos. Para o
desenvolvimento de um serviço Web complexo, seria necessário codificar um cliente ou páginas da Web
para cada um dos processos, algo que iria requerer um grande acréscimo de trabalho e que teria pouca
flexibilidade (Ge & Wang, 2010).
2
No entanto, existem cada vez mais alternativas para o desenvolvimento de Web services, não baseadas
em codificação, que visam facilitar o processo complexo de desenvolver um serviço Web de grande
dimensão.
Foi então considerada a geração automática deste código, para minimizar de maneira significante a
carga de trabalho necessária.
No contexto específico do cliente, as principais motivações deste projeto foram:
• Dar aos seus clientes a possibilidade de aceder ao seu ERP (aplicação) através de qualquer
dispositivo móvel, sem ter de o fazer a partir de uma máquina fixa, previamente preparada.
• Permitir rapidamente criar interfaces com a Web automaticamente, de modo a que, mudanças
futuras na aplicação possam ser refletidas facilmente na interface;
• Manter-se a par com os seus concorrentes.
1.3. Objetivos e resultados esperados
Neste capítulo são descritos os objetivos e resultados esperados do trabalho que irá ser efetuado na
dissertação.
Os objetivos principais deste documento são:
• Garantir a existência de uma camada que permita fazer a ligação entre a Web e a aplicação
desktop (ERP da PrimaveraBSS), que esteja dotada de um conjunto de atributos que permitam
esta ligação:
o Ter um nível elevado de segurança (através da utilização de meios de autenticação e
autorização);
o Não ter estado (stateless), ou seja, cada pedido tem de conter, por si só, toda a
informação necessária para que o servidor consiga processar o pedido e fornecer uma
resposta;
o Não aceder a ficheiros físicos e registos do Windows (Windows registry);
o Ser capaz de responder a pedidos concorrentes com um elevado nível de desempenho;
• Disponibilizar uma ferramenta de geração de código, capaz de interpretar o código do ERP
existente, e gerar automaticamente o serviço que irá disponibilizar as funcionalidades do ERP
para a Web. Para este trabalho é necessário um estudo sobre a forma de gerar interfaces de
forma automática a partir de modelos já existentes (utilizando Winforms e c#);
3
• Implementar com sucesso a ligação entre a aplicação desktop e a Web, que terá um grande
impacto positivo no produto, adicionando flexibilidade e mobilidade na sua utilização e validar o
produto desenvolvido através da criação de aplicações diversas que façam uso do mesmo.
1.4. Estrutura do documento
A estrutura do presente documento é descrita nesta secção, de maneira sintetizada, oferecendo uma
maior compreensão dos pontos essenciais referidos após o capítulo de introdução.
No segundo capítulo, revisão de literatura, é feito um levantamento de informação relevante ao tema
abordado, indicando os métodos e recursos utilizados para cumprir esse objetivo.
No terceiro capítulo apresenta-se a abordagem metodológica que tem como objetivo descrever a
framework de desenvolvimento utilizada na parte prática do projeto.
O quarto capítulo contém a arquitetura do ERP da PrimaveraBSS, uma breve introdução à aplicação,
para contextualizar e ajudar a compreender onde o trabalho realizado se irá enquadrar.
No quinto capítulo está descrita a Web API criada. Este capítulo está dividido nos seguintes subcapítulos:
• Arquitetura – descrição da organização da solução e explicação de cada componente chave e
sua função;
• Funcionalidades – descrição das funcionalidades presentes na solução apresentada;
• Utilização da Web API – descrição de um caso de uso genérico, expondo as entidades e o seu
papel;
• Contratempos no desenvolvimento – descrição de alguns problemas encontrados no decorrer
do projeto;
• Documentação – descrição da documentação gerada de suporte à solução.
No sexto capítulo é descrita a solução desenvolvida para a geração de código, os seus componentes, e
o seu fluxo de funcionamento.
No sétimo capítulo é feita a descrição da utilização da framework escolhida para gerir o desenvolvimento
do projeto.
No oitavo capítulo é feita a discussão de resultados obtidos da utilização de Scrum solo, dos testes feitos
à solução, e das vantagens que trouxe à empresa.
4
Por último, no nono capítulo, são apontadas as conclusões acerca do trabalho efetuado e descrito neste
documento.
5
2. Revisão de literatura
Para que exista uma compreensão do tema foi necessária uma revisão de literatura, a partir da pesquisa
de palavras chave “Web API”, “Web services”, “REST”, “SOAP” e “REST vs SOAP”, na sua maior parte,
feita no motor de busca Google Scholar e no IEEE Explorer.
Foram utilizados dois ciclos principais para a seleção de documentos relevantes ao tema. No primeiro
foi feita uma leitura do resumo/abstract, e introdução do documento e, caso fosse relevante, seria então
guardado numa pasta devidamente identificada. No segundo ciclo, foi feita a leitura das conclusões e do
índice e, mais uma vez, os documentos foram separados para outra pasta. Finalmente, foram ainda
lidos, caso necessário, partes do documento (ou mesmo a totalidade do documento) para fazer esta
seleção.
Serviços Web foram reconhecidos como o novo padrão para computação distribuída e são considerados
por alguns, uma maneira poderosa e viável para atingir um estado de interoperabilidade universal (Zhao
& Cheng, 2005).
Na indústria de software é comum que as empresas tentem ganhar clientes através de plataformas e
tecnologias proprietárias. Serviços Web são um novo paradigma de programação que, pela primeira vez,
está a ser suportado por grandes software developers tais como a IBM, Sun e Microsoft, que
tradicionalmente competiriam com as suas próprias tecnologias (Tang & Cheng, 2005).
Serviços Web são aplicações independentes, publicadas na Web, de tal maneira que outras aplicações
da Web as possam procurar e usar. Isto permite componentes de software descobrir outros
componentes de software e realizar operações de negócio. Exemplos de serviços Web incluem serviços
de cartões de crédito que processam as transações para um determinado número de conta (Roy &
Ramanujan, 2001).
Serviços Web permitem a existência de atividades de e-commerce baseadas num padrão XML
(eXtensible Markup Language), tal como SOAP, UDDI (Universal Description Discovery and Integration)
e WSDL (Web Services Description Language). Alguns dos benefícios dos serviços Web para as atividades
de e-commerce incluem a redução do tempo de produção, a convergência de funcionalidades que
estariam, de outra maneira, separadas, e a possibilidade de facilmente disponibilizar uma aplicação de
negócio para os parceiros (Chiu, Cheung, Hung, Chiu, & Chung, 2005).
6
Um serviço Web consiste num serviço e descrição do mesmo onde o serviço é um módulo de software
fornecido por um prestador de serviços, disponível através da Web. A descrição do serviço contém
detalhes acerca da interface do serviço e implementações, incluindo tipos de dados, metadados,
informação acerca da categorização e a localização de onde o serviço está exposto (Tihomirovs & Grabis,
2016).
Segundo Gonçalves (2009), os serviços Web requerem várias tecnologias e protocolos para transportar
e transformar dados de um consumidor para um serviço numa maneira padrão. As mais aparentes são
as seguintes:
• Universal Description Discovery and Integration (UDDI) é um mecanismo de registo e
descoberta, semelhante às páginas amarelas, usado para armazenar e categorizar interfaces de
serviços Web.
• Web Services Description Language (WSDL) define interfaces com o serviço Web, dados e tipos
de mensagem, interações e protocolos.
• Simple Object Access Protocol (SOAP) é um protocolo de cifra de mensagens baseadas em XML,
definindo uma espécie de envelope para a comunicação de serviços Web.
• Mensagens são trocadas utilizando um protocolo de transporte. Embora Hypertext Transfer
Protocol (HTTP) seja o protocolo de transporte mais adotado, outros, tais como Simple Mail
Transfer Protocol (SMTP) ou Java Message Service (JMS) podem também ser usados.
• Extensible Markup Language (XML) é a fundação básica na qual os serviços Web estão
construídos e definidos.
As características de dispositivos móveis e plataformas desktop podem ser muito diversificadas. Devido
a este aspeto, a interface do utilizador com o serviço Web precisa ter flexibilidade e adaptabilidade para
suportar as interações do utilizador (He & Yen, 2007).
Nos próximos subcapítulos encontram-se os três temas principais que vão ser abordados na revisão de
literatura:
• Serviços Web SOAP;
• Serviços Web REST;
• SOAP versus REST.
7
2.1. Serviços Web SOAP
Enquanto que existam dois computadores, existe uma dificuldade em fazer a comunicação entre si.
Dezenas, possivelmente centenas, de estratégias emergiram, cada uma com as suas vantagens e
desvantagens. No final de contas, o resultado é a continuação da existência de dificuldades no acordo
entre computadores, para uma estratégia de comunicação universal. Consequentemente, existem
“Communication wars”, “CORBA vs. DCOM”, “DCOM vs. RMI”, “messaging vs. RPC”, etc... Para
responder a esta confusão de estratégias de comunicação foi criado o SOAP. Este protocolo não tem
como objetivo resolver todos os problemas de comunicação, apenas define um formato simples, baseado
em XML. Contudo, com este simples objetivo, e um poderoso mecanismo de extensibilidade, SOAP
consegue superar problemas de protocolo de comunicação, de sistemas operativos, ou de linguagem
de programação. Enquanto que o computador, sistema operativo, ou linguagem de programação
pudesse gerar e processar XML, pode fazer uso de SOAP (Seely & Sharkey, 2001).
Serviços Web baseados em SOAP são desenhados com um protocolo baseado em XML. O objetivo é
disponibilizar documentos legíveis à máquina com o intuito de passarem por qualquer tipo e vários
protocolos de conexão para criar um sistema distribuído descentralizado (Suda, 2003).
Devido à natureza heterogénea dos serviços Web, que é originada da definição de vários “XML-based
standards” para superar a sua dependência de plataforma e linguagem, os serviços Web tornaram-se
numa tecnologia emergente e promissora para o design e construção de aplicações complexas de
negócios, com origem em componentes únicos de software com base na Web (Dustdar & Schreiner,
2005).
SOAP é fundamentalmente um paradigma de troca unilateral de mensagens stateless (sem estado), mas
certas aplicações podem criar padrões de interação mais complexos (como, por exemplo:
request/response, request/multiple responses, etc.) combinando estas trocas de mensagens com
características providenciadas por certos protocolos e/ou informação específica de aplicações (Mitra &
Lafon, 2007).
SOAP é um protocolo independente de plataforma, de transporte e de sistema operativo, tudo devido a
ser construído utilizando sistemas de teste temporais tais como o protocolo HTTP e “text mark-up” em
XML. (Suda, 2003)
Segundo Ferris e Farrel (2003), existem vantagens e desvantagens relacionadas com a utilização dos
serviços Web.
8
• Vantagens:
o Os serviços Web tornam possível aos prestadores de serviços e fornecedores a venda
de serviços através da publicação da sua disponibilidade através da World Wide Web.
o A dissociação (“decoupling”) de interfaces de serviços de implementações e plataforma,
a possibilidade de executar “dynamic service binding” e um passo para
interoperabilidade de “cross-platform” e “cross-language”. Estes benefícios são
originados pela interface standard XML e acesso a descrições dadas pela WSDL.
o Os serviços Web podem servir de ponte para aplicações que estão a ser executadas em
plataformas diferentes, disponibilizar troca de informação de bases de dados e
permitem a distribuição de aplicações que foram desenhadas inicialmente para uso
interno. Serviços Web também encontraram um bom mercado quando são
desenvolvidos como utilidades ou como componentes de programas “pay-per-use”.
• Desvantagens:
o A framework dos serviços Web estão dependentes das agências que anunciam a sua
presença. Uma fraca implementação do mecanismo de descoberta pode resultar num
enorme retrocesso no alcance dos clientes e mercados.
o As especificações de interoperabilidade ainda não foram preparadas completamente. É
necessário que um organismo de interoperabilidade de serviços Web produza padrões
para a interoperabilidade relativamente rápido. Estes ainda se encontram em
desenvolvimento e precisam de ser completos e lançados para que outras camadas e
componentes possam ir construindo a sua framework em cima deles.
2.2. Serviços Web REST
Uma das diversas maneiras de criar um serviço Web é a abordagem REST. REST é uma abordagem
nova (comparativamente a SOAP), que se apoia no protocolo HTTP para transmitir dados, em diferentes
formatos, tais como XML, JSON, etc. (Serrano, Hernantes, & Gallardo, 2014). Esta abordagem tem
características de implementação que, se seguidas, irão resultar num serviço Web focado nos recursos
do sistema, incluindo como os estados desses mesmos recursos são manuseados e transferidos através
do protocolo HTTP, por uma panóplia de clientes (Rodriguez, 2008).
REST é de diversas formas uma abstração retrospetiva dos princípios que fazem a “World Wide Web”
escalável (Muehlen, Nickerson, & Swenson, 2005).
9
REST disponibiliza os seus serviços por meio de uma URL (Uniform Resource Location) inicial, a partir
da qual a navegação é guiada conforme a lógica de negócios proposta, dotando orientações dinâmicas
quanto à forma de construção e endereçamento dos requisitos, adotando um formato de comunicação
maximizado que atenda às necessidades de cada aplicação (Ribeiro & Francisco, 2016).
Segundo Fielding (2000), para que um serviço Web seja considerado REST são necessárias várias
condições (arquitetura cliente-servidor, “Stateless” (sem estado), “cache”, interface uniforme, sistema
de camadas, código “on-demand” (a pedido)):
• Arquitetura cliente-servidor: esta é a mais comum quando se trata de comunicação de dados
em rede hoje em dia, e a sua popularidade pode ser percecionada através do fenómeno que é
a expansão da World Wide Web. Uma definição de dicionário para cliente é um sistema ou
programa que faz pedidos a outros sistemas ou programas, chamados servidores para executar
certas tarefas; um servidor é um sistema ou programa que recebe um pedido por parte do
cliente e consequentemente desempenha uma tarefa para suportar o cliente nas suas tarefas.
(Hanson, 2000)
• “Stateless” (sem estado): é uma restrição à arquitetura cliente-servidor. Para que a
comunicação entre as duas partes seja “stateless”, é necessário que cada pedido do cliente ao
servidor contenha toda a informação necessária para que o servidor consiga entender e
processar o pedido, não tirando partido de qualquer tipo de contexto armazenado no servidor.
Desse modo o estado da sessão estará sempre guardado do lado do cliente (Fielding, 2000).
• Cache: é uma restrição de adoção facultativa, que tem como objetivo melhorar a eficiência da
comunicação em rede. Ao adicionar a cache a um serviço Web passa a existir a possibilidade
da reutilização de dados guardados na cache do cliente. Caso o cliente faça um pedido e os
dados já estejam armazenados em cache, não é perdido tempo com o reenvio dos mesmos
pelo servidor. Existe, porém, uma desvantagem na utilização da cache, a redução da
confiabilidade dos dados, já que os dados armazenados em cache, por vezes podem não
corresponder aos dados existentes do lado do servidor.
• Interface uniforme: é, de todas as condições, a que mais distingue a arquitetura REST de outras.
Através da aplicação do princípio da generalização de engenharia de software ao componente
da interface, a arquitetura do sistema é simplificada e a visibilidade das interações disponíveis
é melhorada. Este aspeto tem vantagens e desvantagens, dependendo do caso, estando
10
otimizado para casos genéricos, no entanto, em casos específicos, torna-se eficiente. Para atingir
uma interface uniforme são necessárias 4 condições:
o Identificação de recursos - cada recurso possui o seu único URI que serve como
identificador;
o Manipulação de recursos através de representações – As operações são feitas utilizando
HTTP, significando que, um pedido do tipo “GET” a um URI significa que se pretende
obter informação de um certo recurso;
o Mensagens que se descrevam a si próprias - Cada pedido de um cliente ou resposta de
um servidor é uma mensagem que se descreve a si própria, ou seja, contém toda a
informação necessária para completar a tarefa por si só;
o “Hypermedia as the Engine of Application State” (HATEOAS) – Um Website orientado
por hypermedia é capaz de fornecer informação dinâmica acerca da navegação das
interfaces do website, anexando hypermedia links nas respostas. Esta particularidade
contribui para o desacoplamento do cliente e servidor, permitindo o servidor evoluir
independentemente do cliente.
• Sistema em camadas: para obter melhorias operacionais, Fielding (2000) propôs a divisão do
sistema em camadas, possibilitando a existência de uma hierarquia, restringindo o acesso a
camadas não adjacentes. Este aspeto vem melhorar a segurança, organização e escalabilidade
do serviço Web.
• Código “on-demand” (a pedido): Segundo Moro, Dorneles & Rebonatto (2009), esta
característica opcional consiste em permitir que os clientes possam fazer o download e executar
código do lado do cliente. Desta maneira, a extensibilidade do produto é aumentada, ou seja,
algumas funcionalidades podem não ser implementadas à partida, já que o cliente as pode obter
mais tarde. Esta característica é opcional devido à desvantagem de reduzir a visibilidade do seu
conteúdo.
2.3. REST versus SOAP
As abordagens SOAP e REST lidam com interações de serviços de maneiras bastante diferentes. SOAP
é um protocol padrão para a construção e processamento de mensagens independente das capacidades
tecnológicas do recipiente e pode funcionar sobre uma vasta variedade de camadas de protocolos de
aplicações tais como RPC (Remote Procedure Call), HTTP (Hypertext Transfer Protocol) ou SMTP (Simple
11
Mail Transfer Protocol), enquanto que REST é um conjunto de princípios para o design de aplicações
Web (usando HTTP como protocolo de comunicação) (Potti, Ahuja, Umapathy, & Prodanoff, 2012).
Segundo Muehlen, Nickerson e Swenson (2005), as vantagens e desvantagens de abordagens baseadas
em REST ou SOAP podem ser sumarizadas na seguinte tabela:
Tabela 1- Características de REST e SOAP (Adaptado de Muehlen, Nickerson, & Swenson (2005))
REST SOAP
Características Operações são definidas nas
mensagens
Operações são definidas como
“WSDL ports”
Cada instância de processo tem um
endereçamento único
Cada operação tem um
endereçamento único
Cada objeto suporta as operações
(padrão) definidas
Múltiplas instâncias de
processos partilham a mesma
operação
Vantagens reclamadas
pelos autores
Instâncias de processos são criadas
explicitamente
Operações complexas podem
ser escondidas por detrás de
uma máscara
O cliente não necessita de informação
de routing para além do URI inicial
Wrapping de APIs existentes é
claro e direto
Possíveis desvantagens Número grande de objetos O cliente necessita de saber as
operações e as suas semânticas
previamente
Gerir o namespace do URI pode-se
tornar trabalhoso
O cliente precisa de portas
diferentes para diferentes tipos
de notificação
12
Outra tabela proposta por Wagh e Thool (2012) está a seguir representada. Tem como objetivo fazer a
comparação geral entre REST e SOAP.
Tabela 2- Comparação de SOAP vs REST (Adaptado de Wagh e Thool (2012))
SOAP REST
É uma tecnologia tradicional bem conhecida. É uma tecnologia nova, comparando a SOAP.
No contexto empresarial e B2B (Business to
Business), SOAP continua a ser bastante atrativo.
Embora SOAP talve seja o mais indicado na
maior parte dos casos, existem
implementações de sucesso em contextos
bancários de REST.
No caso de implementação, SOAP tem a vantagem
da existência de kits de desenvolvimento.
Mas os desenvolvedores de REST argumentam
que esses kits levam a uma inflexibilidade de
interface.
Mudar serviços frequentemente numa mudança de
código complicada no lado do cliente.
Mudar serviços não requer qualquer mudança
do lado do cliente (caso “code on demand”
esteja implementado).
SOAP tem uma carga mais pesada comparado com
REST.
REST é definitivamente leve na transferência de
dados.
SOAP não favorece uma infraestrutura wireless. REST favorece uma infraestrutura wireless
Serviços Web SOAP retornam sempre XML. Serviços Web REST são mais flexíveis no que
toca a devolução de dados (e.g. XML, JSON,
GPB).
Consome mais largura de banda. Consome menos largura de banda devido à sua
natureza leve.
Pedidos SOAP usam POST e necessitam um pedido
complexo XML para ser criado, o que leva a uma
difícil captura de respostas.
APIs RESTful podem ser consumidas usando
um simples pedido GET, servidores intermédios
de proxy podem facilmente colocar as suas
respostas em cache.
Concebido para lidar com ambientes de
computação distribuída.
Concebido para o modelo de comunicação
ponto-a-ponto.
Existe um pressuposto falso: SOAP é mais seguro.
SOAP utiliza WSS (Web Services Security). WSS foi
desenvolvido para suportar a independência de
transporte de SOAP, garantindo a segurança na
camada de transporte.
REST assume que o transporte será feito em
HTTPS e que os mecanismos de segurança que
estão embebidos no protocolo estarão
disponíveis.
Segundo Tihomirovs e Grabis (Tihomirovs & Grabis, 2016), REST é mais aconselhado se o projeto
necessitar de grande escalabilidade, compatibilidade e desempenho. A complexidade de
implementação, velocidade de execução, memória consumida e desempenho são melhores que o
protocolo SOAP. Conclui-se assim que, para um projeto de integração simples, de ponto a ponto
(arquitetura cliente-servidor), ou de boa disponibilidade em grande escala, REST é a escolha mais
13
adequada. No entanto, SOAP é uma escolha melhor, para casos de ambientes de computação
distribuida. Para além disso, vários projetos de integração de sistemas de negócio necessitam pedidos
de processamento de dados assíncronos, a vantagem de SOAP. Em conclusão, SOAP é mais adequado
para integrações de sistemas com grandes quantidades de informação, tal como projetos de integração
de sistemas de informação no ambiente bancário. Adicionalmente foram efetuados testes ao tempo de
resposta de ambos SOAP e REST nas quatro mais relevantes funcionalidades de um serviço Web,
apresentados na figura 1.
Figura 1- Tempo de resposta REST e SOAP (Tihomirovs & Grabis, 2016)
Em conclusão, após a investigação decorrida durante a revisão de literatura, e tendo em consideração
os requisitos do serviço Web a desenvolver, a abordagem REST aparenta ser a mais adequada devido
maioritariamente à facilidade de escalabilidade (um aspeto imensamente importante tendo em conta o
tamanho e complexidade da aplicação em questão), à maior rapidez de resposta (representado na figura
1), por ser mais recente e pela melhoria da experiência do utilizador, já que não tem de fazer alterações
caso exista uma mudança do código (algo inevitável no decorrer do ciclo de vida da aplicação).
14
3. Abordagem metodológica
Neste capítulo é feita a descrição da abordagem metodológica adotada para o desenvolvimento do
trabalho, tendo em conta a grande componente prática existente.
O cliente deste projeto é a PrimaveraBSS, uma empresa de desenvolvimento de software em que todas
as equipas de desenvolvimento de software fazem uso da framework ágil Scrum. À partida, faria sentido
a utilização da mesma no decorrer deste projeto, já que o trabalho será feito nas instalações da empresa.
No entanto, o Scrum foi desenhado para equipas de duas ou mais pessoas. Face a esta limitação e à
existência de uma necessidade, um grupo de quatro autores Brasileiros idealizaram uma framework
semelhante, o Scrum solo, a escolhida para desenvolver a parte prática do projeto.
3.1. Scrum solo
Em Portugal, 90% das empresas de desenvolvimento de software são caracterizadas como
microempresas (segundo o diretório de empresas do jornal de negócios, consultado em 20/03/2018).
No mercado Brasileiro, em 2012, cerca de 60% das empresas de software iniciavam as suas atividades
com apenas um developer (Pagotto, Fabrti, Lerario, & Gonçalves, 2016). Esta abordagem foi elaborada
com esta diferença em mente, sendo que existia uma necessidade para a organização/orientação do
desenvolvimento a solo. O Scrum Solo foi originado como uma personalização do processo Scrum
orientado para o desenvolvimento individual de software. (Nunes, 2016).
O Scrum solo é uma adaptação de Scrum e PSP (Personal Software Process) para desenvolvimento de
software a solo. Baseado na figura 2, é possível constatar algumas semelhanças entre Scrum e Scrum
solo (Pagotto, Fabrti, Lerario, & Gonçalves, 2016).
O objetivo de Scrum é fornecer um processo conveniente para o desenvolvimento de projetos,
apresentando uma abordagem empírica, que aplica ideias baseadas na teoria de controlo de processos
industriais para o desenvolvimento de software, introduzindo ideias adicionais como a flexibilidade,
adaptabilidade e produtividade (Soares, 2007).
Scrum foi desenvolvido para permitir developers normais organizarem-se, e formarem equipas de alto
rendimento (Sutherland, Viktorov, Blount, & Puntikov, 2007). Scrum assume que o processo de
desenvolvimento de sistemas é complicado e imprevisível, que apenas pode ser descrito como uma
progressão geral (Schwaber, 1997).
15
O fluxo de trabalho de Scrum solo começa pela criação de um product backlog, que contém todas as
tarefas necessárias para implementar as funcionalidades pretendidas pelo cliente. Deste grupo de
tarefas, são selecionadas algumas a ser desenvolvidas durante o sprint (num espaço de tempo de uma
semana). Este processo de sprints é iterativo até que a data de conclusão do projeto chegue, ou até que
todas as tarefas estejam concluídas. Durante os sprints, é necessária a existência de atividades de
gestão, que têm como propósito planear e acompanhar o desenvolvimento do projeto. Após a conclusão
das tarefas, é feita a entrega do projeto, que vai ser revisto por um grupo de avalização e, eventualmente,
será feita uma reunião de orientação com as pessoas que irão utilizar o produto desenvolvido (figura 2).
Figura 2- Fluxo do processo Scrum Solo. Adaptada de (Pagotto et al., 2016)
Esta abordagem metodológica é dotada de quatro atividades principais: definição de requisitos, sprint,
deployment e gestão. A definição de requisitos (figura 3) tem como objetivo definir o âmbito (scope) do
produto, o product backlog e, se possível, um protótipo de software. Estes objetivos serão atingidos com
a ajuda do input do cliente e orientador que irão auxiliar o developer a atingir a sua meta.
Figura 3- Definição de requisitos (Adaptado de Pagotto, Fabri, Lerario & Gonçalves, 2016)
16
Os sprints, representados na figura 4, são a atividade onde ocorre o desenvolvimento de um conjunto
de tarefas selecionadas no início do mesmo, provenientes do product backlog. Estas tarefas deverão ser
concluídas no espaço de uma semana, originando um sprint backlog, parte do produto, plano de
desenvolvimento, e uma ata.
Figura 4- Sprint (Adaptado de Pagotto, Fabri, Lerario, & Gonçalves, 2016)
Durante os sprints é preciso gerir o estado do projeto. A atividade de gestão do projeto (figura 5) tem
esse objetivo. Utilizando o product backlog, o developer, o orientador, e o cliente devem discutir o estado
do projeto. Dessa reflexão serão gerados a estrutura analítica do projeto (EAP), o cronograma, e a tabela
de custos do projeto.
Figura 5- Gestão do projeto (Adaptado de Pagotto, Fabri, Lerario, & Gonçalves, 2016)
17
Finalmente, como última tarefa, o deployment (figura 6) é a atividade em que o produto é disponibilizado
para uso do cliente. É também importante, após a entrega, a existência de uma reunião de orientação
para que os envolvidos percebam em maior detalhe o funcionamento do produto.
Figura 6- Deployment (Adaptado de Pagotto, Fabri, Lerario, & Gonçalves, 2016)
Existem diversos atores neste processo, nomeadamente o developer, que é o responsável pelo
desenvolvimento do produto e o seguimento da metodologia; o cliente (product owner), que será o
proprietário do produto final, pode ser constituído por um ou mais indivíduos que irão interagir com o
produto (exemplo: gestores, contabilistas, outros…); o orientador, que tem como responsabilidade ajudar
a guiar o developer durante todo o processo, para que os requisitos sejam bem cumpridos; e, finalmente,
o grupo de validação, constituído pelos utilizadores finais do produto, que têm como objetivo avaliar o
produto e dar feedback.
Os diversos artefactos gerados ao longo de todo o processo são os seguintes (Pagotto, Fabrti, Lerario, &
Gonçalves, 2016):
• Scope: serve para caracterizar o âmbito do processo e os aspetos inerentes ao mapeamento
dos problemas do product owner, descrevendo o âmbito do produto, o perfil do cliente e os
requisitos funcionais.
• Protótipo de software: consiste em imagens da interface do utilizador com o produto. É
aconselhada a utilização do formato “.png” e apontar o nome do item do product backlog que
representa a imagem.
18
• Product backlog: é uma lista de funcionalidades que devem ser implementadas no software.
Cada linha desta lista deve conter um código de funcionalidade, descrição, data de inserção e
data de seleção para o sprint backlog.
• Repositório do processo: serve para armazenar todos os documentos relativos a todo o processo
de desenvolvimento do produto na cloud. É importante que o developer organize bem as pastas
do repositório e siga um conjunto de regras para o efeito.
• Sprint backlog: é uma lista de todas as funcionalidades que devem ser implementadas num
determinado sprint. O sprint backlog deve também armazenar o código das funcionalidades.
• Produto ou parte em funcionamento: uma versão do produto que dê ao cliente a possibilidade
de obter um retorno pelo investimento previamente feito no momento que pediu o seu
desenvolvimento.
• Ata: serve para registar os momentos em que uma funcionalidade é implementada. Utilizada no
sprint e na entrega: no sprint, a funcionalidade é validada pelo orientador; na entrega é validada
pelo cliente.
• Plano de desenvolvimento: tem como objetivo juntar os artefactos usados na especificação das
funcionalidades. O Scrum solo sugere o uso de diagramas de casos de uso, sequência, classes
e entidade e relacionamento, existindo sempre a possibilidade de serem usados outros, caso
seja necessário para o caso.
• Estrutura analítica do projeto: uma estrutura hierárquica que subdivide o trabalho de um projeto
em componentes menores e mais facilmente legíveis.
• Cronograma: tem como objetivo organizar sequencialmente os pacotes de trabalho dentro de
um determinado espaço de tempo. Pode-se apontar o responsável pela execução de cada
atividade. É sugerido a utilização do cronograma no formato de diagrama de Gantt.
• Tabela de custos: tem como objetivo mapear o custo efetivo gerado durante a execução do
projeto para poder ser comparada com o orçamento realizado previamente.
Foi feita também uma pesquisa por “Scrum solo” através da plataforma Google académico, no entanto,
o estado de arte ainda se encontra pouco desenvolvido. Fonseca (2016) apenas descreve genericamente
o que é o Scrum solo como uma “metodologia para gestão dinâmica do projeto que permite também o
desenvolvimento de software de maneira ágil”. Similarmente, Kleim (2016) descreve que Scrum solo foi
desenvolvido com o âmbito de ajudar no que toca à organização do desenvolvimento de software por
indivíduos, baseando-se nas boas práticas descritas pelo PSP e Scrum.
19
4. Arquitetura do ERP da PrimaveraBSS
Neste capítulo é feita uma breve introdução à a arquitetura do ERP, para que haja uma contextualização
e para que seja mais fácil a compreensão das interações da Web API com a aplicação. Um dos diversos
produtos da PrimaveraBSS é o seu ERP. Esta aplicação tem como objetivo auxiliar a gestão de médias
e grandes empresas, disponibilizando vários módulos conforme as necessidades do cliente.
Na base do ERP está uma plataforma que tem motores para fazer o acesso aos dados. Este produto
está estruturado em 3 camadas principais. Este aspeto permite o tratamento de cada camada
independentemente das outras, promove a escalabilidade, e adiciona uma facilidade de manutenção de
código. Esta arquitetura distribuída possibilita também a substituição individual de componentes, sem
haver necessidade da reinstalação completa da aplicação.
Na figura 7, está representada a nova arquitetura proposta, composta pela camada de interface com o
utilizador (composta por um executável, EXE); a camada de serviços de dados (composta por serviços
de dados, DS); e a camada de serviços de negócios (composta originalmente por os serviços de
negócios, BS, e entidades de negócio, BE) que terá adicionalmente uma componente da Web API,
ligada à componente dos serviços de negócios (BS), permitindo o acesso a todos os serviços,
respeitando todas as regras de negócio impostas.
Figura 7-Arquitetura e organização da aplicação com a Web API
A aplicação é dotada de diversos módulos, tais como, vendas, contabilidade, inventários, tesouraria,
etc… Todo o código que representa estes módulos do lado da Web API serão gerados
automáticamente, no entanto, existe um módulo a destacar, a plataforma. Este módulo está
encarregue de, entre outros, abrir o motor da aplicação e fazer chamadas aos módulos. Por isto, a sua
implementação foi feita manualmente, já que o contexto Web e Desktop são tão diferentes.
User Interface
Business Services
Data Services
EXE
BS BE
DS
Base de dados
Web API
20
5. Web API
Neste capítulo é feita a descrição da Web API, destacado o porquê da escolha da abordagem REST face
a SOAP, da arquitetura da Web API desenvolvida, das suas funcionalidades, de alguns dos contratempos
e limitações que ocorreram e da documentação gerada.
Depois de toda a investigação feita em torno de REST e SOAP, foi concluído que a abordagem REST
seria a mais indicada para resolver o problema em questão. Esta conclusão foi maioritariamente
suportada pelas seguintes características:
• REST promove a escalabilidade – tendo em conta a complexidade e o tamanho do ERP da
PrimaveraBSS, a escalabilidade é um aspeto essencial a ter em consideração na escolha entre
REST e SOAP;
• REST tem uma velocidade de resposta melhor – tal como demonstrado na figura 1, existe uma
grande diferença no tempo de resposta entre SOAP e REST;
• Há maior facilidade na mudança do código do lado do cliente seguindo a abordagem REST – ao
contrário de SOAP, se um serviço Web do tipo REST não vier com todas as funcionalidades para
o cliente, a user experience não será tão prejudicada, já que, para obter novas funcionalidades,
o cliente terá apenas de fazer a aquisição da nova versão. Visto que a aplicação está em
constante desenvolvimento, faz sentido a adoção da abordagem REST.
O trabalho realizado tem como finalidade aceder à camada de serviços de negócios (Business Services)
do ERP, e fazer chamadas aos métodos do ERP de maneira segura, e com o maior nível de desempenho
possível. Para garantir a segurança, são utilizados tokens de acesso para validar o utilizador (descritos
posteriormente no capítulo “5.2.2 – Autenticação”) e é estritamente utilizado o protocolo HTTPS para
que os dados transmitidos, do cliente para o servidor e vice-versa, sejam transportados de uma maneira
segura. Para obter o melhor desempenho possível, foram executados testes de desempenho (descrito
posteriormente no capítulo “8.2 – Validações do projeto”) e foi implementado um sistema de cache
(descrito posteriormente no capítulo “5.2.1 – Cache”) que reduz de maneira significante o tempo de
resposta das respostas e pedidos.
21
5.1. Arquitetura
Esta Web API foi desenvolvida fazendo uso da ferramenta “Visual Studio 2017”. Foi criada uma solução
constituída pelo projeto principal, denominado “WebAPI”, juntamente com outros projetos do tipo “.NET
Framework Class Library” que tem como objetivo adicionar funcionalidade ao projeto principal, contendo
as classes geradas dos módulos do ERP e algumas classes adicionais auxiliares.
“WebAPI” é o projeto principal da solução, do tipo “ASP.NET Web Application – Web API”. Sendo o
projeto principal, tem como papel a desempenhar integrar todos os outros projetos, que estão
referenciados nesta solução.
Os restantes projetos consistem em módulos do ERP e, em certos casos, possuem projetos auxiliares.
A nomenclatura escolhida para identificar os módulos foi “Primavera.<módulo>.Services”. Esta
normalização permite distinguir facilmente os diferentes módulos do ERP dos outros projetos.
Embora tenham a mesma nomenclatura, o módulo “plataforma” distingue-se dos outros, sendo o único
que não foi gerado automaticamente devido à sua funcionalidade: gerir a autenticação dos utilizadores,
e abrir a plataforma. Algo que é feito de maneira distinta do ERP, requerendo, portanto, uma
implementação adaptada ao problema em questão.
Para fazer chamadas ao ERP, são utilizadas as classes geradas pelo gerador de código. Estas não
contêm o código dos métodos presentes no ERP, mas sim, uma chamada à camada dos serviços de
negócio do ERP. Tipicamente (como ilustrado na figura 8), no cabeçalho estão presentes a cache, a
verificação da autorização do pedido, a route e o tipo de chamada (GET ou POST). Já dentro do método,
é aberta uma ligação à plataforma do ERP é executado o método, e o resultado é enviado em formato
JSON para o cliente.
Figura 8- Exemplo de uma chamada ao ERP
22
5.2. Funcionalidades
Seguidamente são apresentadas as funcionalidades da Web API, cada uma dotada de uma breve
explicação, do processo da sua implementação e, se pertinente, uma explicação da sua utilização face
a outras opções existentes.
Segundo Fielding (2000), para que a implementação de um serviço Web seja considerada REST, são
necessários os seguintes requisitos:
• Arquitetura cliente-servidor;
• “Stateless” (sem estado);
• Cache;
• Interface uniforme;
• Sistema em camadas;
• Código “on-demand” (a pedido).
Embora alguns sejam opcionais, foi entendido que a sua inclusão na solução final seria benéfica para o
projeto, nomeadamente a cache para a melhoria do desempenho e escalabilidade, e o código “on-
demand” que visa a possibilidade de implementar versões futuras mais facilmente.
5.2.1. Cache
A cache pode ser utilizada de ambos os lados do cliente e do servidor. Ao adicionar a cache a um serviço
Web, passa a existir a possibilidade da reutilização de dados guardados na cache do cliente ou do
servidor.
Quando ocorre um pedido e o cliente já tem os dados armazenados em cache do seu lado, não é perdido
tempo com o reenvio dos mesmos pelo servidor. Foi também utilizada a cache para guardar o objeto
plataforma do lado do servidor, para mitigar o tempo de espera da sua abertura.
Existe, porém, uma desvantagem na utilização da cache, a redução da confiabilidade dos dados, já que
os dados armazenados em cache, por vezes podem não corresponder aos dados existentes do lado do
servidor, em casos da má implementação da cache.
Foi então feita uma exploração de diferentes implementações de cache, tendo-se ponderado três
maneiras diferentes de implementar esta funcionalidade para cliente e duas para servidor:
23
• Cliente:
o Projeto open source “CacheCow”;
o Namespace “System.Runtime.Caching”;
o Projeto open source “Strathweb.CacheOutput”.
• Servidor:
o Combinação de Redis e CacheManager;
o Namespace “System.Web.HttpRuntime.Cache”.
A primeira foi um projeto open source, denominado “CacheCow”. No entanto, está mencionado na
documentação do projeto a incompatibilidade com “attributed routing” (Exemplo:
[Route("TestFunc/{name}")]). Devido a esta incompatibilidade, esta solução foi descartada, já que
“attributed routing” é mais flexível que a contraparte, “convention routing”. Esta flexibilidade de
“attributed routing” provém do facto dos caminhos (“routes”) estarem definidos a par com os métodos
que as vão utilizar, enquanto que “convention routing” as centraliza num só ficheiro, dificultando a sua
geração automática e debugging.
Outra opção foi a implementação de raiz da cache (representado na figura 9), fazendo uso do namespace
“System.Runtime.Caching”. No entanto, esta implementação era demasiado simples para a
complexidade da solução desejada. É necessária a existência da gestão de confiabilidade de dados, para
evitar que os dados recebidos pelos utilizadores estejam sempre atualizados.
Figura 9 - Implementação da cache com o namespace "System.Runtime.Caching"
24
Finalmente, foi ponderado o projeto open source “Strahweb.CacheOutput”. A sua utilização é simples e
facilmente gerida na geração de código, sendo que, caso seja desejado guardar em cache o output de
um método, é apenas necessário adicionar uma linha no seu cabeçalho e, ao contrário da última opção,
permite a invalidação da cache sempre que uma alteração é feita a nível da classe (figuras 10 e 11).
Este projeto enquadrou-se nos requisitos e foi assim escolhido para a gestão da cache do lado do cliente.
Com o intuito de guardar o objeto da plataforma em cache para melhorar o desempenho do servidor,
foi inicialmente ponderado uma solução que fizesse uso do programa Redis (“open source (BSD
licensed), in-memory data structure store, used as a database, cache and message broker”) e do projeto
“Cache Manager”. Esta solução consiste na utilização do projeto Cache Manager para gerir a cache do
servidor e do programa Redis para guardar e disponibilizar pares chave-valor, em que a chave seria o
token do cliente e o valor seria um objeto serializado. No entanto a serialização do objeto pretendido
demonstrou-se impossível, devido à sua complexidade, tornando esta solução inviável.
Face à impossibilidade de serializar o objeto, foi procurada uma nova maneira de armazenar um objeto
em cache, do lado do servidor que não envolvesse este processo. O Namespace
“System.Web.HttpRuntime.Cache” foi então escolhido pois permite guardar em cache um objeto
associado a uma chave. Na figura 12 está representada a inserção do objeto em cache (linha 2), sendo
a chave de identificação o token do cliente, e sua obtenção (linhas 4-12), com um método que extrai o
token do pedido feito pelo cliente e devolve o objeto associado.
Figura 10- Exemplo da implementação de cache com “Strahweb.CacheOutput”
Figura 11- Exemplo da invalidação de cache
25
5.2.2. Autenticação
Para fazer a autenticação de um cliente, foram consideradas diversas maneiras de abordar este
problema, nomeadamente, OAuth, OAuth2, JWT (JSON Web Token) e SAML (Security Assertions Markup
Language).
As duas figuras seguintes (figuras 13 e 14) são representações do fluxo do processo de autenticação do
processo SAML e dos processos OAuth, Oauth2 e JWT, respetivamente. A grande diferença entre estes
dois fluxos é que, no processo SAML, existe apenas um prestador identidade centralizado, ao qual,
qualquer prestador de serviços conhecido pode aceder para verificar o cliente. Contudo, no fluxo do
processo de OAuth, OAuth2 e JWT, cada servidor de recursos precisa de ter o seu servidor de autorização
próprio, para fazer a verificação do cliente.
Figura 13 - Fluxo do processo SAML
Figura 12- Inserção e extração de um objeto em cache
26
Visto que a autenticação da Web API apenas será feita num local (plataforma do ERP), a abordagem
SAML não será a mais apropriada para o caso.
As frameworks OAuth, OAuth2, e os JWT não se devem comparar diretamente, sendo que as frameworks
podem fazer uso dos JWT ou dos seus próprios tokens opacos (conjunto de carateres aleatórios que não
têm significado para o seu titular). A diferença reside no facto dos JWT não serem opacos, pelo contrário,
contêm informação real, cifrada, resultando em tokens grandes, aproximadamente de 300 bytes ou
mais. Qualquer entidade que possua o token é capaz de o abrir, validá-lo e fazer uso das alegações
(“claims”) presentes para fazer decisões de autorização, caso tenha a chave para decifrá-lo.
Tabela 3- Tabela de comparação de tokens opacos e JWT
Usar JWT quando: Usar tokens opacos quando: Características comuns:
É desejada a existência de
múltiplas entidades capazes de
gerar e decifrar tokens. Por
exemplo: usar uma entidade para
gerar um token e depois usar
uma outra entidade para validar o
token. Com JWT, é possível que
tokens gerados possam ser
interpretados e validados por
terceiros.
Quem emite o token é quem o
valida.
Ambos têm a funcionalidade de
ter alegações personalizadas.
Não há necessidade nem
intuito do titular do token
examinar as alegações
contidas no token.
Ambos precisam ser segredos
bem protegidos.
Figura 14- Fluxo do processo OAuth, OAuth2 e JWT
27
Não é necessária ligação
assíncrona. Por exemplo: quando
o cliente faz o pedido, esse
pedido será guardado e
processado por outro sistema
(que não possui uma ligação
síncrona com o cliente)
posteriormente.
É desejado revocar tokens por
parte do cliente. JWT expiram
apenas na data de expiração,
definida durante a sua criação.
Ambos podem expirar após um
determinado tempo e ser
atualizados.
Ambos mecanismos de
autenticação proporcionam
uma experiência semelhante
para o utilizador.
No caso presente, não é necessária a inclusão de terceiros para a criação e/ou validação de tokens. A
entidade que emite os tokens é quem os valida, sendo que os JWT não fazem tanto sentido como os
tokens opacos presentes em OAuth e OAuth2.
OAuth é um protocolo de segurança, que permite quem o utiliza, facultar acesso dos seus recursos Web
(“Web resources”) a terceiros, sem partilhar as suas palavras-passe.
A primeira versão de OAuth foi publicada em Dezembro de 2007 e foi adotada rapidamente como o
padrão para suportar a delegação de acessos baseados em Web. Em Abril de 2010, foi publicado como
RFC 5849 pela IETF (Internet Engineering Task Force).
OAuth 2.0 é um protocolo completamente novo e não é compatível com as versões anteriores. No
entanto, reteve a maior parte da arquitetura e abordagem estabelecida pelas versões anteriores,
publicado pela IETF como RFC 6749 e atualizado posteriormente por RFC 8252.
As diferenças chave de OAuth e OAuth2.0 são:
• A adição de fluxos que suportam melhor aplicações não baseadas em browsers. Este era um
dos pontos mais criticados da arquitetura OAuth 1.0. A user experience era prejudicada uma
vez que aplicações desktop ou móveis tinham de direcionar o utilizador para um browser no seu
dispositivo, autenticar-se com um serviço de autenticação, copiar o token retornado pelo serviço
e introduzi-lo na aplicação ao qual estavam a tentar aceder. Com OAuth 2.0, existem maneiras
novas de uma aplicação obter autorização para os seus utilizadores.
• OAuth 2.0 não requer criptografia do lado do cliente. Com OAuth 2.0, o cliente apenas precisa
de fazer o pedido enviando o token por HTTPS, para aceder aos recursos desejados.
• Em OAuth 2.0 os tokens de acesso têm menos longevidade. Envés da existência de um token
de grande duração (tipicamente um ano ou mesmo de tempo ilimitado), o servidor pode emitir
tokens de menos longevidade e um “refresh token”. Este aspeto permite aos clientes obter
28
novos tokens de acesso quando necessário e manter o número de tokens limitado, melhorando
a escalabilidade.
• OAuth 2.0 faz a separação dos papeis do servidor responsável pela gestão dos pedidos de
geração de tokens e do servidor responsável pela gestão das autorizações to cliente.
Foi então adotada a framework OAuth 2.0, maioritariamente devido à necessidade da existência de
escalabilidade e pela melhoria da “user experience”.
A implementação foi feita em duas partes, a primeira (ilustrada na figura 15) consiste na customização
de um dos métodos do fornecedor de serviços de autenticação (“Authorization Server Provider”) para
que, quando um cliente faz um pedido de um token, apenas o é permitido caso as suas credenciais
sejam verificadas pela plataforma do ERP da PrimaveraBSS. O primeiro passo da customização foi a
extração da informação necessária do contexto e o seu armazenamento (“username”, “password”,
“company”, “instance”).
Figura 15- Versão simplificada do código do override do método do AuthServerProvider
29
Seguidamente foi criada uma instância do objeto que representa a sessão de um utilizador
(“UserSession”), que será posteriormente utilizado na plataforma do ERP para verificar se as credenciais
inseridas pelo cliente estão corretas (“platformFunctions.Open(user, password) e
platformFunctions.IsPlatformOpen()”). No caso de as credenciais serem válidas, o utilizador é então
validado e a framework irá gerar um token de acesso que será devolvido ao utilizador.
A segunda parte consiste em chamar a framework na inicialização da Web API (figura 16).
Esta chamada da framework permite configurar aspetos tais como o caminho ao qual aceder para obter
um token, a duração da validade de um token e permitir a utilização de HTTP inseguro (utilizado na fase
de construção e de testes da solução).
Para testar esta funcionalidade, foi feito uso da ferramenta “Postman”. Foi enviado um pedido ao
servidor com os dados de um utilizador fictício no corpo do pedido e o servidor devolveu um token de
acesso (figura 17) que o cliente poderá utilizar para aceder aos recursos do servidor, colocando o token
no cabeçalho de um pedido, como ilustrado na figura 18.
Figura 16- Chamada da framework Oauth2.0
30
Figura 17- Teste ao serviço de geração de tokens com Postman
Figura 18- Utilização de um token para aceder a um recurso
31
É também importante referir a existência de refresh tokens. Estes são tokens de longa duração, utilizados
para obter access tokens de curta duração (figura 19). Caso um atacante consiga obter um token de
acesso indevidamente, tem uma pequena janela de oportunidade para o utilizar, já que a sua longevidade
é pequena. No entanto, caso obtenha um refresh token, é possível a sua utilização até que seja
manualmente revocado.
Embora existam vantagens de criar uma solução com refresh tokens, o caso em questão não é ideal
pois não existe a possibilidade de revocar um token na eventualidade de um utilizador ser removido pelo
administrador do lado do ERP. Esse utilizador poderia usar o seu refresh token para obter acesso a
dados ao qual não deveria ter acesso.
A solução elaborada faz uso de tokens de curta duração, certificando que o utilizador possui as
credenciais corretas em curtas janelas de tempo. A sua duração é por defeito 20 minutos, mas pode ser
configurada por um administrador para suportar a sua realidade.
5.2.3. Outras funcionalidades
Para além das previamente mencionadas neste capítulo, Fielding (2000) propôs a utilização das
seguintes funcionalidades, para que um serviço Web seja considerado REST:
• Comunicação sem estado (“stateless”) - Esta restrição impede que o servidor mantenha o
estado de um cliente armazenado, mantendo-o do lado do cliente, que o envia juntamente com
Cliente
Auth Server
Resource Server
Refresh Token
Access Token
Access Token
Protected Resource
Figura 19 - Diagrama de utilização de refresh tokens e access tokens
32
cada pedido. Este aspeto tem como objetivo aumentar a escalabilidade de um serviço Web.
Cada pedido é tratado independentemente, o serviço Web não mantém registo das interações
prévias do cliente.
• Código “on-demand” (a pedido) – Quando chegar a altura de fazer a distribuição da Web API
para os clientes, estes poderão ter acesso à Web API da mesma maneira que têm acesso ao
ERP. Ou seja, sempre que for lançada uma nova versão da nova versão do ERP, a Web API irá
também anexada, possibilitando aos developers, implementar novas funcionalidades no futuro.
• Interface uniforme - Através da utilização de padrões de URI (“Uniform Resource Identifier”) é
feita a separação do cliente de uma estrutura específica de URI da aplicação. Utilizando o URL
“http://exemplo.com/ clientes /1234” como exemplo, é fácil identificar que um pedido feito irá
retornar o cliente cujo número identificador é “1234” e um pedido feito a
“http://exemplo.com/clientes” irá retornar uma lista de clientes. A adoção desta normalização
facilita a escalabilidade da Web API.
• Arquitetura cliente-servidor –De forma geral, um serviço prestado pelo servidor é uma abstração
para o cliente, na medida em que o cliente não necessita de se preocupar com nada para além
de entender a resposta do servidor. Adicionalmente, qualquer cliente apenas tem acesso de
comunicação ao servidor, e não a qualquer outro cliente.
33
5.3. Utilização da Web API
A utilização da Web API é descrita neste subcapítulo. Para auxiliar a compreensão do fluxo de atividades
entre as entidades diferentes presentes na utilização da Web API por um utilizador com credenciais
válidas, foi elaborada a seguinte diagrama de sequência (figura 20).
Para que um utilizador possa aceder a qualquer recurso do ERP, necessita de um token de acesso. Este
token é concedido pelo servidor de autenticação (Auth Server), caso as credenciais enviadas pelo
utilizador permitam abrir a plataforma do ERP. Neste caso, o token é guardado internamente no website
para ser anexado em todos os pedidos futuros.
Após a autenticação, o utilizador por fazer um pedido para ler um objeto do ERP, para tal, o website
anexa o token ao pedido, que é depois processado pela Web API que verifica a validade do token com o
servidor de autenticação e, caso seja válido, faz um pedido ao ERP para obter o objeto desejado, que é
então retornado ao utilizador.
Depois de obter o objeto desejado, o utilizador pode editá-lo e, tal como para o pedido de leitura do
objeto, é feito todo um processo idêntico em que o token é validado, o pedido é feito ao ERP e o utilizador
recebe uma resposta de sucesso.
Figura 20 - Diagrama de sequência da utilização da Web API
34
5.4. Contratempos no desenvolvimento
Nesta secção são evidenciados alguns dos problemas encontrados no decorrer do desenvolvimento da
Web API e a sua solução.
Um dos contratempos mais dispendiosos foi o processo de descoberta de quais das 320 DLL existentes
na solução do ERP eram necessárias para a Web API. Utilizando o protótipo inicial da Web API, foram
feitas inúmeras compilações e execuções para as identificar. Este processo, embora demoroso,
beneficiou a solução, reduzindo ao máximo o tempo de compilação. Após este processo, todas as DLL
essenciais encontravam-se associadas à solução.
Houve também um problema pontual de comunicação com um dos orientadores, que originou a procura
de uma solução para um problema inexistente. No entanto, o impacto deste contratempo foi mínimo
graças à grande disponibilidade de comunicação com o mesmo.
A Web API está diretamente dependente de DLLs do ERP, sendo que, o seu propósito é fazer chamadas
a métodos do ERP. Estando o ERP em constante evolução, ocorreram situações em que as mudanças
do ERP influenciaram negativamente a Web API, chegando, por vezes, ao ponto de impedir o seu
funcionamento completamente.
Um destes casos foi a atualização para DLLs assinadas, em que existia uma variável automaticamente
gerada em contexto desktop que não era gerada no contexto da Web API. Este problema foi resolvido
através da definição manual da variável no momento em que a Web API chama pela primeira vez a
plataforma do ERP.
Outro exemplo foi a mudança da versão da “.NET framework target” do ERP, que incapacitou a solução
da Web API de compilar até que todos os projetos fossem atualizados para a mesma versão e todas as
dependências fossem atualizadas para versões compatíveis.
Existiram também uma limitação por parte do hardware da máquina no qual o trabalho foi feito. A falta
de espaço de disco necessário para o desenvolvimento da solução levou à necessidade da incorporação
de um disco adicional na máquina que conseguisse suportar a grande quantidade de dados existentes.
35
5.5. Documentação
Uma boa documentação é sempre importante. Um dos fatores que mais motivou a procura de criar uma
boa documentação, foi a existência de entidades dependentes da Web API para fazer a interface Web
que vai ligar o utilizador ao ERP, através da Web API desenvolvida.
O trabalho realizado pode ser dividido em duas partes, a Web API e o gerador de código. Para a
documentação da Web API, foi utilizada a framework Swagger, capaz de gerar automaticamente a
documentação a partir dos métodos existentes em cada controlador da Web API (Figuras 21-23).
Esta framework permite que o consumidor da Web API possa facilmente visualizar os diferentes
controladores, métodos e atributos. No caso dos atributos é também exposto o seu tipo, e em caso de
ser um objeto personalizado do ERP, é apresentado um valor esperado, em formato JSON (Figura 23).
Figura 21- Página inicial da documentação
36
Figura 22- Exemplo da documentação de um método GET
Figura 23 - Exemplo da documentação de um método POST
Para a do gerador de código, todos os métodos criados foram comentados sem exceção, contendo
aspetos importantes tais como os atributos necessários, o tipo de retorno e uma breve descrição.
Adicionalmente, na maior parte dos casos foram também adicionados valores esperados e exemplos de
retornos para facilitar a compreensão do código, devido à complexidade do problema.
37
6. Gerador de código
O propósito da Web API é fazer a ligação entre o ERP e as aplicações Web. No entanto o ERP está em
constante desenvolvimento e, atualmente, já possui uma proporção considerável. Criar uma Web API
estática, que necessite constante manutenção para acompanhar o desenvolvimento da aplicação, seria
um grande dispêndio de recursos. A solução encontrada foi gerar automaticamente o máximo possível
de código da Web API. Desse modo, sempre que o ERP sofrer alterações, poderá simplesmente ser
gerada uma nova versão da Web API correspondente, com gastos de recursos mínimos.
Para a criação de tal programa, foi reutilizado um programa de testes do ERP (GitHub:
PrimaveraDarwin/darwing), que, dado uma DLL de um módulo, percorre todos os seus submódulos e
métodos correspondentes, e gera classes de teste. A existência deste programa agilizou o
desenvolvimento do gerador de código final, sendo que, a sua utilização permitiu o acesso cíclico aos
módulos, submódulos, e métodos do ERP.
O passo seguinte passou pela criação de exemplos específicos de métodos na solução da Web API, que
foram depois generalizados no gerador de código. Para cada linha de código, existe uma função
responsável por manusear os diferentes casos, e produzir um output funcional.
No entanto, com um ERP de tamanha complexidade, é muito difícil generalizar todos os casos existentes,
originando a necessidade da criação de filtros, que vêm auxiliar o processo de geração de código.
Quando um método é excluído através de um filtro, é deixado um comentário no seu lugar, indicando a
sua falta, facilitando a manutenção do código gerado.
Figura 24- Protótipo do UI do gerador de código
38
A interface do programa (ilustrada na figura 24) possui diversos campos seguidamente indicados:
• “Source” – caminho e nome da DLL do módulo a ser gerado;
• “Destination” – caminho para o qual as classes geradas serão armazenadas;
• “Enable Private Methods” – permitir a geração de métodos privados ou não;
• “Blacklisted Files” – lista de ficheiros a excluir;
• “Blacklisted Methods” – lista de métodos a excluir;
• “Generated Files Count” – contador da quantidade de ficheiros gerados durante a última
execução do programa;
• “Generated Methods Count” – contador da quantidade de métodos gerados durante a última
execução do programa;
É também importante mencionar que, para o funcionamento do programa, são apenas necessários os
campos de “Source” e “Destination” (assinalados com um asterisco). Os outros servem apenas para
filtrar os métodos e ficheiros gerados, e para os contar.
A figura 25 é a ilustração de um exemplo genérico de um método gerado. As partes essenciais para a
criação de um método são as seguintes:
• Linha 1: Cache. Em métodos do tipo GET, o resultado é guardado na cache do cliente, fazendo
uso do projeto open source “Strathweb.CacheOutput”;
• Linha 2: Autorização. Com esta linha é verificada se o token passado no cabeçalho do pedido é
válido. Em caso negativo, é devolvido uma mensagem de falta de permissões;
Figura 25- Exemplo de um método gerado
39
• Linha 3: Route. De modo a gerar código de maneira lógica, a route é sempre o nome do método,
seguido dos seus atributos. No caso de um dos atributos ser objeto será passado pelo corpo;
• Linha 7 e 10: declaração e abertura da variável plataforma. Esta variável é o que permite fazer
a ligação aos métodos do ERP;
• Linha 11: Chamada do método do ERP;
• Linha 12: Retorno do valor. Após a execução é retornado para o cliente o valor do método,
juntamente com um código de estado HTTP de sucesso.
O diagrama apresentado na figura 26 representa o funcionamento
de uma perspetiva de alto nível do gerador de código. Após a
verificação dos paths do módulo e destino, é feita a iteração pelos
submódulos e métodos do módulo inserido. Por cada submódulo
irá originar um ficheiro, com os métodos respetivos. Estes
ficheiros são escritos linha a linha, sendo que para cada linha
existe um método no gerador de código que permite diferenciar
os diferentes tipos de métodos presentes no submódulo e adptar
o código gerado conforme cada caso. Existem também contadores
que registam a quantidade de ficheiros e métodos gerados, para
depois ser facilmente visível para o utilizador.
Para aumentar o nível de automação da aplicação, foi também
implementada a funcionalidade desta aplicação poder ser ativada
através de bots, que irão substituir os ficheiros existentes pelos
ficheiros gerados. Embora exista esta possibilidade, é sempre
aconselhável que exista uma verificação humana dos ficheiros
gerados, já que o código do ERP pode conter mudanças
inesperadas que levem ao mal funcionamento da Web API.
Até à data de 2 de Fevereiro de 2018, foram gerados 5 módulos,
consistentes num total de 431 ficheiros, 7161 métodos, e cerca
de 170.000 linhas de código.
Figura 26- Diagrama de atividades da execução do gerador de código
40
7. Aplicação de Scrum solo
A metodologia Scrum solo consiste num processo iterativo e incremental, que une as boas práticas
definidas pelo Personal Software Process (PSP) e pelo Scrum, para promover o bom funcionamento do
desenvolvimento de um projeto. Esta metodologia foi aplicada apenas no âmbito do desenvolvimento de
software, não incluindo a escrita deste documento e toda a pesquisa necessária para tal.
Este projeto via possibilitar aos seus utilizadores, o acesso ao ERP, através de um Web service e,
eventualmente através de uma app ou um website dedicado, que consumam o serviço. No entanto, o
valor deste projeto reside também no facto da conversão do código do ERP (desenvolvido durante 25
anos, por múltiplas equipas, com cerca de 4.5 milhões de linhas de código atualmente) é feita
automaticamente, poupando uma enorme quantidade de recursos na sua criação e manutenção. Já
que o ERP está constantemente em desenvolvimento, o Web service teria obrigatoriamente de
acompanhar, adicionando um nível de complexidade na coordenação das equipas de desenvolvimento
do ERP e do Web service.
Scrum solo passa por um momento inicial de definição de requisitos, seguido de sprints onde o programa
é desenvolvido, seguido do deployment do programa para o cliente. Durante o processo de
desenvolvimento é necessário também existir atividades de gestão de projeto. Os dois capítulos
anteriores (Web API e Gerador de código) são o resultado deste longo processo.
Durante a definição de requisitos, foram feitas diversas reuniões com o cliente e orientador, de modo a
obter um entendimento dos requisitos necessários do produto. Este processo resultou num documento
denominado de scope (anexo 1), que contém a definição do âmbito do problema e do perfil do cliente;
e, um documento denominado product backlog (anexo 2), dotado de 32 atividades que, caso concluídas,
darão origem ao produto final, que irá ser entregue ao cliente.
A Web API tem a particularidade de não ter uma interface de utilizador tradicional. Em vez disso, a sua
interface é feita através de URL’s (ver [1]). Ou seja, o protótipo de software é constituído por este padrão
genérico para a interface, que será depois utilizado durante a geração de código.
“{Domínio}/api/{classe}/{método}/{parâmetros}” (1)
O repositório do processo está dividido em duas partes. Os artefactos gerados relativos à utilização do
Scrum solo foram arquivados numa pasta na cloud, utilizando os serviços da Google Drive. Já o código
41
desenvolvido, foi guardado na rede local da PrimaveraBSS, e foi gerido através da ferramenta TFS (Team
Foundation Server).
Foi definido que os sprints seriam constituídos por cinco dias úteis de desenvolvimento, no entanto, um
sprint não representa necessariamente uma semana, devido ao interrompimento do desenvolvimento
por razões externas, tais como a escrita de artigos científicos ou do presente documento.
O desenvolvimento do projeto começou a 18 de dezembro, no entanto já existiam protótipos funcionais
para a geração de código e da Web API. Esta facto economizou algum tempo inicial de pesquisa e
adicionou um nível de segurança ao projeto. Existe um total de 10 sprints desde o início do projeto até
à conclusão do mesmo (figura 27).
Entende-se que, segundo o trabalho Pagotto et al. (2016), após um sprint é suposto ser gerado um
plano de desenvolvimento. Neste caso, a Web API já respeita toda as regras de negócio impostas pelo
ERP. Este facto provém da utilização exclusiva da camada de negócio do ERP na Web API, ou seja, todas
as regras de negócio serão respeitadas, tal como no ERP, tornando-se dispensável a elaboração do
artefacto.
Outro artefacto importante para a organização do projeto são as atas, no entanto, no decorrer deste
projeto, não foram elaboradas devido ao clima de proximidade entre o developer e o orientador. Este
clima contribuiu para a existência de uma quantidade substancial de reuniões informais, permitindo que
o orientador estivesse sempre a par do desenvolvimento do projeto.
Figura 27- Calendário de sprints
42
Quanto ao produto, foram guardadas regularmente versões novas no TFS, permitindo o acesso ao código
a pessoas autorizadas, e ter acesso aos registos de todas as mudanças feitas. O sprint backlog (anexo
3) tem como objetivo identificar quais as tarefas do product backlog executadas num determinado sprint,
a sua data de começo e o tempo despendido na sua conclusão. Embora seja importante para o futuro
ter este artefacto bem documentado e legível para outras pessoas que não o developer, não há
necessidade da existência de ferramentas complexas para a sua gestão, uma simples folha de papel ou
um documento Word é suficiente. No caso representado na figura 28, é possível visualizar as tarefas do
sprint (assinaladas com uma seta) no topo da página e pequenas tarefas apontadas (assinaladas com
um hífen), tipicamente pequenos bugs a ser corrigidos.
A data de término do desenvolvimento do projeto coincide com a data de entrega deste documento. Este
facto impede a execução da atividade de deployment e a elaboração de testes automáticos que permitam
testar as funcionalidades da Web API.
Em projetos desta grandeza, existem riscos adicionados associados ao trabalho, não existentes em
projetos de desenvolvimento de software tradicionais. Os riscos identificados passam pela limitação de
acesso ao código original do ERP e a sua complexidade; entropia entre o ERP e Web service (a utilização
certos mecanismos para o uso de assemblies pelo ERP, causou bastantes problemas devido à
incompatibilidade desses mecanismos com a Web, resultando na necessidade da alteração do código
original do ERP, por exemplo); existiram também problemas em trabalhar com a versão do ERP que
estava em desenvolvimento, por vezes foram encontrados bugs, resultando em tempo despendido à
Figura 28 - Exemplo de um sprint backlog (página à direita)
43
procura da origem do problema; finalmente, a necessidade da mudança de máquina, também se
mostrou um contratempo, devido à dimensão do projeto e da configuração de diversos componentes de
suporte ao desenvolvimento.
A metodologia do Scrum solo, embora tenha uma tarefa de gestão de projeto, não responde bem a estes
casos de forte componente de integração. É proposto que seja criada uma tarefa de mitigação de risco,
equivalente a uma percentagem baixa do tempo despendido por sprint, que pode ser preenchida por
uma tarefa de desenvolvimento caso haja disponibilidade. Esta tarefa de mitigação poderá, por exemplo,
ser adicionada no final de todos os sprints, valendo 2-4h.
44
8. Discussão de resultados
Neste capítulo será feita a discussão de resultados acerca da utilização da metodologia Scrum solo, as
validações ao projeto (nomeadamente a descrição dos testes feitos à Web API e algumas das suas
aplicações desenvolvidas), e as vantagens que trouxe para o cliente.
8.1. Utilização do Scrum solo
A utilização do Scrum solo durante este projeto contribuiu para o seu sucesso, apesar dos contratempos
existentes e adaptações que foram necessárias. Devido à ausência de artigos científicos acerca desta
metodologia, e ao interesse para contribuir para esta área, foi submetido um artigo para a edição de
2018 da conferência CAPSI que se focava na descrição da aplicação do Scrum solo e algumas
adaptações necessárias para casos de alto nível de integração. Este paper, que estava em
desenvolvimento, foi aceite como póster. Foi também elaborado um artigo que apresenta uma
metodologia para converter código de uma aplicação para uma Web API, com base na experiência
descrita neste documento.
8.2. Validações do projeto
Com o intuito de fazer a validação do projeto, foi utilizado como parte do projeto vencedor da edição de
2018 do evento TecTalks e foram criadas 3 aplicações que consumem a Web API, com finalidades
diferentes:
• Aplicação para autorização de documentos de venda;
• Website para criação de documentos de compra;
• Integração com o Microsoft Outlook para visualizar pagamentos pendentes.
Estas aplicações foram apresentadas e demonstradas ao público, através de eventos/trailers produzidos
e organizados pela empresa para publicitar as novas funcionalidades.
A aplicação para autorização de documentos de venda (figura 29) permite ao utilizador fazer o login e
ligar-se ao ERP remotamente para visualizar e autorizar documentos de venda em casos em que o
montante é alto e necessita aprovação.
45
Figura 29- UI da aplicação para autorização de documentos de venda
O Website para a criação de documentos de compra possui uma página de login e uma página para a
criação dos documentos, que é o resultado da simplificação da janela do ERP que tem o mesmo
propósito. Esta simplificação e a utilização de ferramentas diferentes para a sua construção, resultaram
num aumento da fluidez da atividade e uma redução do tempo de espera, permitindo proporcionar uma
melhor experiência ao utilizador.
46
Figura 30- UI do website para criação de documentos de compra
Finalmente, foi feita uma integração com o Microsoft Outlook com o propósito de facilmente visualizar
os pagamentos pendentes de qualquer um dos fornecedores (figura 31). Este add-in permite ser apenas
ativado caso algumas palavras-chave sejam detetadas num email. Nos casos relevantes será adicionado
no topo do email uma barra que permite abrir uma interface onde o utilizador pode fazer a sua
autenticação e depois, pode verificar informações relevantes acerca dos pagamentos pendentes. Na
tabela onde a informação está a ser apresentada (figura 32), a morada possui um link que direciona o
utilizador para o Google Maps.
Figura 31- Interface de login no Outlook para verificação de vendas pendentes
47
Figura 32- Interface de visualização de vendas pendentes
Para promover uma aplicação melhor e uma melhor experiência de utilização, é importante fazer testes
à aplicação desenvolvida. A existência de testes é essencial para a manutenção e evolução das
aplicações. A Web API e o gerador de código não são exceções.
Os casos de uso do gerador de código são mais limitados, pelo que, foi possível fazer diversos testes
manualmente. Juntamente com a documentação, foram criados tutoriais que ajudam o utilizador passo
a passo em diferentes cenários. Caso as instruções sejam rigorosamente seguidas, existe uma baixa
probabilidade de um erro se suceder, e mesmo para esses casos, foram indicadas ações a tomar para
conseguir identificar e retificar o problema.
Para o caso da Web API, existem muitos mais casos de uso possíveis a testar, sendo que seria
praticamente impossível a sua execução manual. Face a esta impossibilidade, foi criada uma solução
para Web testing e load testing, disponível no Visual Studio.
Um Web test consiste numa sequência de atividades de um utilizador, por exemplo (tal como
representado na figura 33), fazer a autenticação e buscar um recurso do servidor. A vantagem destes
testes é a facilidade de utilização, configuração disponível, e o facto de estarem baseados em XML. Isto
permitirá no futuro adicionar ao gerador de código a funcionalidade de criar Web tests semi-
automaticamente (os dados concretos, tal como identificadores, terão de ser adicionados manualmente
conforme o caso).
48
Figura 33- Exemplo de um Web test
Os Web tests são importantes para a gestão individual de certos casos. No entanto é também importante
fazer testes de carga, para medir o desempenho da Web API. Esta solução permite criar cenários de
teste com diversas opções configuráveis tais como: nº de iterações (número de vezes que o Web test irá
ser executado por cada utilizador), utilização de “think times” (simulação do tempo que o utilizador leva
a fazer uma operação), utilizadores concorrentes (número de utilizadores a fazer o Web test), distribuição
dos testes (baseados pela ordem sequencial ou pelo ritmo de cada utilizador), tipo de ligação à internet,
e, finalmente browser.
Na figura 34, apresenta-se a lista de tempos de resposta de diversos pedidos à Web API, juntamente
com os tamanhos da resposta. O pedido do token, é o pedido mais demorado, sendo que é feita a
abertura da plataforma do ERP, que contém os seus motores, módulos, e submódulos. Após este podido
na fase do login, pode-se utilizar o token gerado para fazer outros pedidos, tais como listar os
documentos de compras existentes no ERP, ou listar os documentos de vendas pendentes. É também
importante mencionar o facto que todos os pedidos que podem ser guardados em cache (pedidos do
tipo GET), após o primeiro pedido, passam a ter tempo de resposta inferiores a 15 milissegundos.
Figura 34- Tempos de resposta a pedidos diversos da Web API
49
9. Conclusões
Este trabalho de dissertação tem como objetivo principal a criação de uma camada que permita fazer a
ligação entre a Web e a aplicação desktop (ERP da PrimaveraBSS). O ERP já possui a sua própria
arquitetura. De modo a conseguir adicionar uma nova componente a essa arquitetura, é necessário
compreender o trabalho que já está feito e só depois fazer uma proposta para a sua adaptação (capítulo
4).
Dentro dessa camada encontra-se um serviço Web (descrito no capítulo 5). Este tem como objetivo
receber pedidos de clientes com credenciais do ERP, e responder aos seus pedidos, fazendo uso da
camada de serviços de negócio do ERP, para assim respeitar as regras de negócio existentes na
aplicação desktop. Foi definido no início do projeto de desenvolvimento que este serviço deveria ter
algumas características, nomeadamente:
• Existência de um sistema de autenticação e autorização, baseado em tokens;
• Permitir que os pedidos não tenham estado (stateless), ou seja, cada pedido deverá conter toda
a informação necessária para que o servidor consiga desempenhar a sua função, sem precisar
de guardar dados acerca do utilizador;
• Não estar dependente de ficheiros físicos nem registos do Windows (Windows registry);
• Ser capaz de responder a pedidos concorrentes com um elevado nível de desempenho.
Até ao momento, foram registadas cerca de 4.6 milhões de linhas de código existentes na solução do
ERP. A sua dimensão e o facto de estar constantemente sujeito a mudanças, implica um custo altíssimo
no que toca ao desenvolvimento e à manutenção do serviço Web. Para responder a este problema, foi
criada uma ferramenta de suporte que tem como objetivo ler e interpretar o código do ERP
automaticamente e gerar a maior parte do serviço Web (descrita no capítulo 6). Esta ferramenta foi
elaborada de modo a existir a possibilidade de gerar o código completamente automaticamente através
de bots, que correm a aplicação e substituem os ficheiros do serviço Web, pelos ficheiros gerados com
a nova versão.
Com o propósito de organizar e gerir o desenvolvimento do serviço Web, foi adotada a abordagem
metodológica Scrum solo. Esta framework ágil foi escolhida sabendo que o desenvolvimento na
PrimaveraBSS é também feito com base numa framework ágil, o Scrum. No entanto, Scrum foi
desenvolvido para equipas de dois ou mais elementos em mente, algo que não se verifica no presente
contexto. Esta limitação levou à descoberta do Scrum solo, que de certo modo simplifica a metodologia
50
Scrum de maneira a que apenas um único developer consiga gerir o seu projeto. A descrição teórica
desta metodologia foi feita no 3º capítulo, e a sua utilização foi descrita nos 7º e 8º capítulos.
Finalmente, após o desenvolvimento do serviço Web, foi feita uma validação do trabalho desenvolvido
(descrita no capítulo 8). Neste caso foram feitos testes de carga e quatro aplicações que consomem o
serviço. A primeira aplicação fez parte do projeto vencedor da edição de 2018 do evento TecTalks, que
consiste num sistema de reconhecimento automático de documentos de faturas, que integra
diretamente a informação no ERP através do serviço Web. Foi também desenvolvido um website com a
framework Asp.Net Core, com o intuito de criar documentos de compra. Outro exemplo foi a criação de
uma aplicação mobile, fazendo uso de PowerApps e Microsoft Flow, que permite ao utilizador autorizar
documentos de venda. Por fim, foi desenvolvido um add-in para o Microsoft Outlook que permite
visualizar os pagamentos pendentes, sem sair do contexto do cliente de email.
51
Referências bibliográficas
Chiu, D. K., Cheung, S., Hung, P. C., Chiu, S. Y., & Chung, A. K. (2005). Developing e-Negotiation support
with a meta-modeling approach in a Web services environment.
Dustdar, S., & Schreiner, W. (2005). A survey on web services composition.
Ferris, C., & Farrel, J. (2003). What are web services? ACM.
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures.
Fonseca, J. W. (2016). A informatização na coleta de dados para controle de doenças epidemiológicas:
um estudo de caso com a Dengue.
Ge, Z., & Wang, X. (2010). A framework for automatic generation of composite web service user interface.
Kunming, China: IEEE.
Goncalves, A. (2009). "SOAP Web Services." Beginning Java™ EE 6 Platform with GlassFish™ 3: From
Novice to Professional.
Hanson, M. D. (2000). The Client/Server Architecture.
He, J., & Yen, I.-L. (2007). Adaptive User Interface Generation for Web Services. Hong Kong, China: IEEE.
Kleim, E. C. (2016). Um estudo do Scrum em um projeto com uma equipe pequena.
Mitra, N., & Lafon, Y. (2007). SOAP Version 1.2 Part 0: Primer.
Moro, T. D., Dorneles, C., & Rebonatto, M. (2009). Web services WS-* versus Web Services REST.
Muehlen, M. z., Nickerson, J. V., & Swenson, K. D. (2005). Developing web services choreography
standards—the case of REST vs. SOAP.
Nunes, L. M. (2016). Sistemas de gerenciamento de heurística de usabilidade.
Pagotto, T., Fabri, J. A., Lerario, A., & Gonçalves, J. A. (2016). Scrum solo: Software process for individual
development. Las Palmas, Spain: IEEE.
Pagotto, T., Fabrti, J. A., Lerario, A., & Gonçalves, J. A. (2016). Scrum solo: Software process for
individual development. Las Palmas, Spain: IEEE.
Paolucci, M., Kawamura, T., Payne, T. R., & Sycara, K. (2002). Semantic matching of web services
capabilities.
52
Potti, P. K., Ahuja, S., Umapathy, K., & Prodanoff, Z. (2012). Comparing Performance of Web Service .
Ribeiro, M. F., & Francisco, R. E. (2016). Web Services REST - conceitos, análise e implementação.
Rodriguez, A. (2008). Restful web services: The basics.
Roy, J., & Ramanujan, A. (2001). Understanding Web Services.
Schwaber, K. (1997). SCRUM Development Process.
Seely, S., & Sharkey, K. (2001). SOAP: Cross Platform Web Service Development Using XML. Prentice
Hall PTR.
Serrano, N., Hernantes, J., & Gallardo, G. (2014). Service-Oriented Architecture and Legacy Systems .
Soares, M. d. (2007). Metodologias ágeis extreme programming e scrum para o desenvolvimento de
software.
Suda, B. (2003). SOAP Web Services.
Sutherland, J., Viktorov, A., Blount, J., & Puntikov, N. (2007). Distributed Scrum: Agile Project
Management with Outsourced Development.
Tang, Q. C., & Cheng, H. K. (2005). Optimal location and pricing of Web services intermediary.
Tihomirovs, J., & Grabis, J. (2016). Comparison of SOAP and REST based Web services using software
evaluation metrics.
Wagh, K., & Thool, R. (2012). A Comparative Study of SOAP Vs REST Web Services Provisioning
Techniques for mobile Host.
Zhao, J. L., & Cheng, H. K. (2005). Web services and process management: a union of convenience or
a new area of research?
53
Anexo 1 - Scope
Âmbito do problema: O cliente pretende dar aos seus clientes a possibilidade de aceder ao seu ERP
(aplicação) através de qualquer dispositivo móvel, sem ter de o fazer a partir de uma máquina fixa,
previamente preparada, com uma grande quantidade de dados armazenada e permitir rapidamente criar
interfaces com a web automaticamente, de modo a que mudanças futuras na aplicação possam ser
refletidas facilmente na interface. É proposto a criação de um serviço Web que preencha esta camada
de ligação do ERP com a Web e a criação de um programa de geração de código que suporte a geração
automática de código para o serviço Web.
Perfil do cliente: O cliente é a PrimaveraBSS, uma empresa no ramo de desenvolvimento de soluções
de gestão para empresas. Alguns dos seus produtos são: Omnia, Jasmin, TLIM, PSSST!, entre outros.
54
Anexo 2 – Product backlog
ID Descrição da tarefa Data de inserção
Tempo de desenvolvimento (em
horas) Retrabalhado?
Orçamentado Realizado
WAPI-01 Desenvolver controller de teste - implementação básica para ambientação
19-Dec 16 4 Sim
WAPI-02 Desenvolver ligação ao ERP - criar um projeto que abra, verifique o estado e feche a ligação
21-Dec 8 3 Não
WAPI-03
Preparar arquitetura - definir a organização dos documentos na arquitetura da solução da Web API, importar um exemplo de controller e o projeto de ligação ao ERP, e adicionar referências
19-Dec 2 5 Sim
WAPI-04 Atualizar controller de teste - adicionar funcionalidade de se ligar ao ERP e testá-la
22-Dec 1 2 Não
WAPI-05 Utilizar controllers de assemblies externas - Permitir que o projeto principal da Web API reconheça os controllers externos
05-Jan 2 7 Não
WAPI-06 Implementar segurança - Oauth 2.0 para gerar tokens e SSL para forçar que os pedidos sejam HTTPS
17-Jan 16 11 Sim
WAPI-07 Testar a geração de tokens - usar Postman para fazer múltiplos pedidos para testar a funcionalidade
30-Jan 8 21 Sim
WAPI-08 Implementar cache - implementar a cache e certificar que reduz o tempo de resposta a partir do segundo pedido
22-Jan 24 24 Sim
WAPI-09 Implementar módulo de vendas - class library com classes e métodos do módulo
02-Jan 16 3 Não
WAPI-10 Testar módulo de vendas - selecionar e usar alguns métodos para teste 19-Feb 4 3 Não
55
WAPI-11 Implementar módulo base - class library com classes e métodos do módulo
02-Feb 12 2 Não
WAPI-12 Testar módulo base - selecionar e usar alguns métodos para teste 19-Feb 4 5 Sim
CGEN-01 Explorar o programa pré-feito - programa já feito que lê as DLL dos módulos e itera pelos sub-módulos e métodos
18-Dec 8 8 Sim
CGEN-02 Adaptar programa - para gerar um módulo, ler os nomes dos sub-módulos e métodos e criar ficheiros com esses nomes
19-Dec 4 2 Não
CGEN-03 Adicionar referências - método que gera referencias no inicio de cada classe
22-Dec 1 7 Sim
CGEN-04 Adicionar leitor de namespace - a partir do nome do outputpath, ler o namespace para usar na classe gerada
22-Dec 1 1 Não
CGEN-05 Adicionar RoutePrefix - identifica a classe baseado no nome do módulo e sub-módulo
22-Dec 2 5 Não
CGEN-06 Adicionar call handler - método para manipular string da call do método do ERP
22-Dec 8 1 Não
CGEN-07 Adicionar route - método que escreve a linha da route referente a um método do ERP conforme
20-Dec 1 10 Sim
CGEN-08 Adicionar GET/POST, Cache e OAuth - linhas no cabeçalho de cada método que definem se o método é GET ou POST, a cache e o Oauth
22-Jan 1 3 Não
CGEN-09 Adicionar gestão de plataforma - linhas que abrem e fecham a ligação à plataforma do ERP
22-Jan 1 2 Não
CGEN-10 Adicionar chamada do método do controller - linha de chamada do método do controller
15-Feb 8 14 Sim
CGEN-11 Adicionar chamada do método ERP - linha que chama o método do ERP 26-Dec 8 7 Sim
CGEN-12 Adicionar linha de retorno - linha que faz o retorno dos dados retornados pelo método para o cliente
27-Dec 4 7 Sim
56
CGEN-13 Adicionar gestão de refs - atualizar o código para estar preparado para gerir métodos com parâmetros do tipo “ref”
08-Jan 8 9 Sim
CGEN-14 Adicionar blacklists - alterar código e UI para suportar blacklists para ficheiros e métodos
23-Jan 4 1 Não
CGEN-15 Adicionar gestão de erros - sempre que houver uma restrição com métodos, deixar um comentário com o nome do método e a razão do problema
26-Dec 4 2 Não
CGEN-16 Adicionar funcionalidades extra - contadores de ficheiros e métodos para serem usados como métricas e permitir chamar o programa através da linha de comandos
29-Jan 1 6 Não
CGEN-17 Gerar módulos - Usar o programa para gerar módulos diversos 02-Jan 8 5 Sim
AUX-01 Criar cliente de testes - Criar um cliente em consola que simule a ligação à Web API para efeitos de teste
14-Fev 8 15 Sim
AUX-02 Testar cliente de testes - Testar o cliente para testar a WebAPI 19-Fev 24 4 Sim
UX-03 Usar cliente de testes - usar o cliente para testar a WebAPI 03-Apr 24 12 Sim
57
Anexo 3 – Spring backlog
Date Task code Time
S1 18-Dec CGEN-01 6
19-Dec WAPI-03 3
CGEN-02 2
WAPI-01 2
20-Dec CGEN-07 5
21-Dec WAPI-01 2
WAPI-02 3
CGEN-01 2
22-Dec CGEN-03 1
CGEN-04 1
CGEN-05 1
CGEN-06 1
CGEN-07 1
WAPI-04 2
S2 26-Dec CGEN-11 5
CGEN-15 2
27-Dec CGEN-11 1
CGEN-12 4
CGEN-07 2
02-Jan CGEN-17 2
WAPI-09 3
CGEN-11 1
WAPI-03 2
03-Jan CGEN-03 6
04-Jan NT
S3 05-Jan WAPI-05 7
08-Jan CGEN-13 4
10-Jan NT
16-Jan NT
17-Jan WAPI-06 7
S4 22-Jan WAPI-08 2
CGEN-08 3
CGEN-09 2
23-Jan WAPI-08 1
CGEN-13 3
CGEN-12 3
24-Jan NT
29-Jan CGEN-16 6
CGEN-14 1
30-Jan WAPI-07 7
S5 01-Feb WAPI-07 7
02-Feb CGEN-17 3
WAPI-11 2
CGEN-07 2
05-Feb NT
06-Feb NT
07-Feb NT
S6 08-Feb NT
09-Feb NT
12-Feb WAPI-06 2
14-Feb AUX-01 5
15-Feb CGEN-10 7
S7 16-Feb AUX-01 4
19-Feb AUX-02 2
WAPI-12 2
WAPI-10 3
20-Feb AUX-01 4
21-Feb NT
22-Feb AUX-02 2
S8 23-Feb NT
26-Feb NT
27-Feb WAPI-12 3
28-Feb CGEN-10 1
WAPI-08 6
01-Mar WAPI-07 4
AUX-01 3
S9 02-Mar CGEN-10 4
WAPI-07 3
05-Mar WAPI-08 7
06-Mar WAPI-08 7
08-Mar WAPI-08 1
15-Mar NT
S10 16-Mar CGEN-10 2
WAPI-06 2
03-Apr CGEN-13 2
AUX-03 5
10-Apr AUX-03 7
*NT- No task.