Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.                                                             

  

(Obrigatório)

Informações Gerais

 

Chamado2

Especificação

Produto

TSS

 Módulo

TSS TOTVS Service SOA

 

Segmento Executor

 SERVIÇOS

Projeto1 

M_SER_TSS002

IRM1 

PCREQ-8272

Requisito1 

PCREQ-8273

Subtarefa1

 

 

Release de Entrega Planejada 

12.1.13

Réplica

 

País

(  X) Brasil  (   X ) Argentina  (  ) Mexico  (  ) Chile  (  X ) Paraguai  ( X   ) Equador

X ) USA  ( X   ) Colombia   (  ) Outro _____________.

Outros

<Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>.

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

(Obrigatório)

Objetivo

 Definir uma Definir a estrutura padrão para implementação a segregação dos métodos do TSS, para que possa ser utilizado tanto  pela DLL quanto pelo Web service do TSS.

(Obrigatório)

Web services dos TSS. A segregação dos métodos será necessária para que as funcionalidades do TSS estejam disponíveis tanto por chamadas via Web service quanto para as chamadas que serão realizadas pelo TSS OFFLINE, que será realizada através de comunicação via HTTP, com mensagens no formato JSON, (formato texto e completamente independente de linguagem). Dessa os serviços oferecidos pelo TSS estarão disponíveis para acesso através de qualquer interface de comunicação.  

Definição da Regra de Negócio

Para que os métodos do TSS funcionem apenas como uma interface de comunicação entre os ERPs e o TSS, os métodos deverão ser reestruturados, ficando livres de qualquer acoplamento de implementação de processamento e persistência de dados na camada do Web service.

Os métodos deverão conter a verificação do serviço do TSS que esta configurado, de acordo com o serviço, realizar o processamento correto da requisição e retornar como resposta a estrutura hoje existente.

Tanto a função de processamento quanto a função de validação, serão originadas a partir da segregação do método.

As entradas de requisições para processamento via TSS OFFLINE ou sem TSS OFFLINE, serão realizadas através dos mesmos métodos já existentes no TSS. De acordo com a configuração do appserver, as requisições seguirão o fluxo descrito abaixo.     

Caso a requisição seja recebida para processamento via TSS OFFLINE, o processo será direcionado para a função TSSAnalyseReq() que fará a verificação do serviço configurado e assim a função TSSBrokerReq() que fará o processamento, caso contrário, a requisição será enviada para a função responsável pelo processamento da requisição via Web service. Todos os métodos deverá ser definidos com a seguinte estrutura:Deverá ser retirado todo o processamento dos métodos. Os métodos deverão conter apenas as validações específicas dos métodos, a chamada para a função de processamento e a validação do retorno do processamento. O método deverá estar estruturado para funcionar tanto para requisições da DLL quanto para as requisições enviadas diretamente pelos Web Services do TSS. Caso a requisição seja recebida pela DLL, o processo será direcionado para a função DLLProcRequest(), caso contrário será enviada para a função TSSProcRequest(). A Decisão de qual função chamar, deverá ser definida na compilação através de uma diretiva de compilação.

 

WSMETHOD  XXXXXXXXX     WSRECEIVE  XXXXXX, XXXXXX, XXXXXXX       WSSEND XXXX            WSSERVICE XXXXXX

    local lRetorno cError := .T.
private oJSON := nil
private oJSONRet := nil

 

//VALIDAÇÕES ESPECÍFICAS DO MÉTODO. MANTER TODAS AS VALIDAÇÕES EXISTENTES.

fwJsonDeserialize( getWSJsonRequest() , @oJSON)if( type("oJSON") <> "U")
//Define o processo de acordo com a chamada: DLL ou Web Service
#IFDEF PROCDLL
fwJsonDeSerialize( DLLProcRequest( oJSON ), @oJSONRet)
#ELSE
fwJsonDeSerialize( TSSProcRequest( oJSON ), @oJSONRet)
#ENDIF
if( type("oJSONRet") == "U" .or. oJSONRet:result == "false" )
lRetorno := .F.
setSoapfault( STR0001, if( type("oJSONRet:error") <> "U", oJSONRet:error, getJSONError() )

""
    local lRetorno := .T.

if TSSAnalyseReq()

self:X := TSSBrokerReq( self, @cError )

else

if( lRetorno := TSValXXXXXXXXXX self, @cError) )

self:X := TSProcXXXXXXXXXX( self, @cError )

else

self:

NFeOk

:=

oJSONRet:send

nil

endif

else

endif

if !( lRetorno :=

.F.
setSoapfault( STR0001, getJSONError()

valType(self:ID_ENT) <> "U" ))

setSoapFault(WS_PROC, cError )

endif

delClassIntf()

return finishSped(lRetorno)

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

 

 

Onde TSSProcXXXXXXXXXX será o nome da função de processamento segregada do método via Web service. TSValXXXXXXXXXX  será o nome da função de validação da requisição segregada do método via Web service.

 

Opcional

Fluxo do Processo

1. Fluxo Principal:

1.1.

Valida parâmetros específicos do método

 Realiza a verificação do serviço configurado TSSAnalyseReq().

1.2.

Dados inválido[2.1]

Se o serviço é específico, a requisição será enviada para a função TSSBrokerReq(). 

1.3.

Monta mensagem JSON padrão de processamento do TSS

 Caso contrário executa função de validação e processamento do método;  

1.4.

Envia requisição para processamento 

Se retorno for nulo (nil), retorna Soap Fault com erro do processo.

1.5.

Verifica se houve falha no processamento.

 Caso contrário retorna resultado de acordo com estrutura esperada pelo Web service; 

1.6

. Falha na execução da requisição[2.1]

1.7. retorna resposta da requisição.

2. Fluxo Secundário

    2.1. Falha na validação

        2.1.1.  Retorna String Soap Fault.

Opcional

Dicionário de Dados

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

 Realiza limpeza do objetos instanciados; 

 

 

 


 

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas 

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.

[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.

[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante

[3] Categorias são obrigatórias para os programas FLEX.

[4] Obrigatório quando o projeto for FLEX

[5] Obrigatório quando o projeto for FLEX

[6] Obrigatório quando o projeto for FLEX

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.