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). 

(Obrigatório)

Objetivo

        Definir um padrão para que nossos serviços atendam às premissas de serviços SOA e as premissas definidas pela TOTVS.

(Obrigatório)

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), desta 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.

 ).          Quando é uma chamada Client(WinForms e WebForms) x Server(Rm.Host), a Lib  se encarrega de recuperar o RMSContext que estava no contexto da aplicação cliente(WinForms/WebForms) e entregar para o serviço(RM.Host), desta forma permitiu que os DataServers de produto fossem herdados do RMSDataServer, e as informações de contexto ficassem disponíveis nos serviços executados.

          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 nossos serviços em HTTP (rest / json ou xml) utilizando WebAPI 2.0, com isso qualquer aplicação,inclusive o FrameHTML podem chamar nossos serviços.

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

          O exposto acima reforça a necessidade da nossa solução ser 100% SOA(Arquitetura Orientada a Serviços), antes de continuarmos, vamos entender alguns termos utilizamos na arquitetura SOA que estão diretamente relacionados às nossas mudanças.

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

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

         Nossa solução começou a construir um novo portal, porém como o FrameHTML é baseado em HTML e javascript não temos um conceito de 

Novo cenário:

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação: 

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.