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

Cenário atual:

          Todos os nossos serviços até o momento eram expostos através de webService(SOAP / HTTP) com autenticação HttpBasic.

          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 chamado(ReadView,ReadRecord,etc).

          Quando era uma chamada Client x Server, a Lib  se encarregava de recuperar o RMSContext e entregar para o serviço, desta forma permitiu que os DataServers de produto fossem herdados do RMSDataServer, e as informações de contexto ficassem disponíveis nos serviços chamados, vamos ver mais à frente que isso vai contra há alguns fundamentos de SOA.

          Com a chegada do FrameHTML(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 no 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, veremos mais à frente que isso vai contra há alguns fundamentos SOA .

            O exposto acima reforça a necessidade da nossa solução ser 100% SOA(Arquitetura Orientada a Serviços), antes de continuarmos, vamos ver 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>.