Histórico da Página

(Obrigatório)

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

        Em consonância com o mercado e com a estratégia da TOTVS, estamos expondo nossos serviços para consumo externo em um padrão REST, inclusive os DataServers.

        O FrameHTML por ser tratar de uma aplicação baseada em javascript e HTML irá usufruir dessa infraestrutura criada.

        Diante disso surgem algumas definições e mudanças necessárias para que sejamos 100% SOA e consequentemente tenhamos nossos serviços prontos para serem consumidos por qualquer aplicativo.

Definição da Regra de Negócio

         Nossa arquitetura está preparada para ser 100% SOA, porém precisamos pensar como os nossos DataServers funcionam para então perceber as deficiências do mesmo e tratá-las.

Cenário atual:

Temos duas formas de chamadas de serviços no RM.Host, são elas:

1. Chamada Client (Winforms/WebForms)
   
   Neste caso, a Lib se encarrega de recuperar o RMSContext que está no contexto da aplicação cliente (WinForms/WebForms) e entregar para o serviço no server (RM.Host). Esta forma permitiu que os DataServers de produto fossem herdados do RMSDataServer e as informações de contexto ficassem disponíveis nos serviços (ReadView, ReadRecord,etc) executados.
   
   
   
2. Chamada WebService (SOAP/REST)

         Para expor nossos DataServers, foi criado um WebService genérico que recebe como parâmetro o nome do DataServer, o contexto (coligada, sistema, usuário, etc.) e demais parâmetros pertinentes ao serviço executado (ReadView, ReadRecord, etc.), com isso o DataServer do produto recebe o contexto que ele precisa para ser executado.

          Com a chegada do FrameHTML (100% HTML e Javascript), nossa arquitetura sofreu uma evolução para expor nossos serviços. Hoje temos uma camada que expõe os serviços em HTTP (REST/JSON ou XML) utilizando WebAPI 2.0, com isso qualquer aplicação, inclusive o FrameHTML, pode chamar nossos serviços, porém como vimos, nossos DataServers dependem de um contexto de excução (RMSContext). Contudo, o RMSContext traz consigo muitas informações que podem ou não ser uteis à execução do DataServer em questão.

          No primeiro momento para tornar o desenvolvimento produtivo, criamos um serviço RMSDataServerController que recebe o nome do DataServer como o parâmetro. Para entregar ao DataServer em questão o contexto da aplicação o FrameHTML tem um interceptor que resgata o contexto (está armazenado em uma variável chamada currentContext no escopo do AngularJS) e adiciona todas as propriedades do contexto no header da requisição. O RMSDataServerController resgata o contexto do header e entrega ao DataServer em questão.

            Como podemos notar o nosso serviço depende de informações de contexto que são trafegadas no header da requisição. Neste ponto precisamos entender alguns termos utilizados na arquitetura SOA que estão diretamente relacionamos às mudanças que teremos.

          Ao confrontarmos os conceitos SOA e as definições da TOTVS com o que está implementado hoje, vemos que precisamos das seguintes mudanças:

1. O serviço deve ser stateless, hoje nossos DataServers dependem do contexto.
2. O serviço deve ser auto documentávelautodocumentável, portanto esperar somente o que precisa para execução, o RMSContext têm muita informação que pode ser dispensável para determinadas rotinas.
3. Nenhuma informação deve ser enviada pelo header, pois dificulta a documentação e utilização.

        O Controller genérico RMSDataServerController criado na WebAPI juntamente com o intercepctor criado no FrameHTML permanecerá funcionando para manter compatibilidade. Porém é expressamente recomentado que as novas funcionalidades migradas para o FrameHTML nasçam respeitando todas as premissas apontadas acima.

         Veja o desenho simplificado da nossa nova estrutura.

      Outro ponto importante que devemos tratar é a segurança das informações armazenadas no clientcliente.

      Vamos nos ater a falar na aplicação web (Portal), hoje . Hoje grande parte das informações armazenadas no lado cliente como por exemplo o contexto da aplicação (RMSContext) está na session sessão do AspASP.Net NET e consequentemente protegidas. Já no FrameHTML, por se tratar de uma aplicação feita em HTML e javascript Javascript, não possui o conceito de sessionsessão, portanto deve-se observar quais informações estão sendo armazenadas no lado cliente , e criar mecanismos de proteção do lado server, para do servidor a fim de impedir que essas informações sejam alteradas. Veja o exemplo abaixo:

      O usuário (XXXU) loga e se autentica e acessa a funcionalidade de histórico salarial, considere . Considere que o DataServer de histórico salarial utilize o usuário do contexto para filtrar o retorno dos dados, ou a segurança da informação. Neste ponto temos a seguinte diferença entre o Portal e o FrameHTML:

       Portal:

                O RMSContext está na session sessão do asp.net que por sua vez protegida, portanto ASP.NET, protegida pelo servidor de aplicação. Portanto, podemos confiar na informação setada no atribuída ao RMSContext.

       FrameHTML:

                O RMSContext está no escopo do angular na aplicação, AngularJS, ou seja, no navegador e totalmente vulnerável à intervenção do usuário, portanto neste caso ele poderia alterar o usuário do RMSContext que acessar o histórico salarial de um usuário diferente do usuário logado.

        . Portanto, passível de alteração pelo usuário que se autenticar para acesso ao histórico salarial. Outro exemplo seria uma chamada de WebService, logando autenticando-se com um usuário e passando o outro usuário do no Contexto qualquer usuário que desejar.

Diante do exposto é expressamente recomendado que os serviços utilizem o usuário do

Principal (carteirinha), pois esse a Lib garante

. Já o usuário do RMSContext não é garantido pela Lib e o exemplo acima é apenas um de várias formas que temos de enviar um usuário logado diferente do usuário do contexto.