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

 

Especificação

Produto

 

TSS TOTVS Service SOA

 

Segmento Executor

 

Projeto1

 

IRM1

 

Requisito1

 

Subtarefa1

 

Chamado2

 

Release de Entrega Planejada

 

Réplica

 

País

(  X) Brasil  (  X) Argentina  (X  ) Mexico  (X  ) 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 um Definir o padrão para construção das funções que farão o de processamento das requisições recebidas pelo TSS.de Web Service. 


Os serviços oferecidos pelo TSS são disponibilizados apenas através de Web Services baseado no protocolo SOAP onde cada serviço é consumido através requisições feitas para métodos específicos dentro do TSS. Com o modelo proposto pelo TSS 3.0, os serviços do TSS deverão estar acessíveis tanto por web services quanto qualquer outra interface de integração com o TSS como requisições HTTP que será utilizada pela DLL de integração do TSS.  

(Obrigatório)

Definição da Regra de Negócio

Grande parte dos métodos de integração do TSS realizam o processamento das requisições no próprio corpo do método. Todos os métodos deverão estar desacoplados do processamento da requisição para que os métodos funcionem apenas como interface de integração. Como interface os métodos serão responsáveis apenas pela validações dos parâmetros da requisição e pela montagem do retorno do método enquanto o processamento das requisições será realizado através de chamadas para as funções de processamento.

Afim de facilitar a implementação será definido o seguinte padrão para as funções:

 

Nome das funções:

"TSPROC" + "Id Sequencial do processo" + "nome do Método" 

Os nomes das funções estarão definidos em uma lista de processos que será obtida através da função TSSGetficar , dessa forma as funções deverão ser criadas com o mesmo nome definido na lista de processos. 

Ex: TSPROC0001Remessa - Função para processamento de remessas do Web service NESBRA

As funções de processamento serão formadas por toda a parte de processamento segregada dos Web Services. Será estruturada da seguinte forma:

  • Validação:

A validação dos parâmetros das requisições serão definidas em uma função que será chamada pelo método ou poderá ser utilizada por qualquer outra interface que venha ser implementada para integração com o TSS. A nomenvlatura das funções deverá ser da seguinte forma:

Função:

TSSVal + código do processo +    nome do método

Parâmetro:

oJSON 

Exemplo:

TSSVal0002AdmEmpresas()

Processamento:

A função de processamento envolverá todo o código compreendido após a  validação da requisição. A função deverá retornar o resultado estruturado de acordo com o esperado pelo Web service. Da mesma forma que as funções de validações, a função de processamento receberá como parâmetro, um objeto deserializado com os parâmetros da requisição. Dessa forma a função estará pronta para receber tanto os parâmetros recebidos pelos método Web Service como as mensagens JSON envidas pela DLL. A nomenclatura será definida da seguinte forma:

 

TSSProc + código do processo + nome do método 

Exemplo:

TSSProc0002AdmEmpresas()Parâmetros


As funções receberão como parâmetro a mensagem JSON padrão definida para o TSS.(getJsonRequest() ).

A mensagem JSON recebida pela função já estará Deserializada e terá os mesmo parâmetros na mesma estrutura do recebida pelos Web Services, sendo necessario apenas subistituir as inicias " :: ou sef: " por:  "oJSON:receive" . 

Exemplo:

Acesso ao atributo  "TOKEN" através  do Web Service: "sef:TOKEN"

Acesso ao atributo TOKEN através do objeto JSON:  "oJSON:receive:token" .

 

  • retorno


    O retorno 

 oJSONRet:send + "retorno do método"

 

Ex:  Metodo Remessa:

Parâmetros : 

oJSON:receive:UserToken,

oJSON:receive:Id_Ent, 

oJSON:receive:Nfe:NOTAS[nX]:XML

 

Retorno:

oJSON:send:NfeOk:ID

 

Após o processamento as funções deverão criar a mensagem JSON de resposta através da função  getJSONResponse() e disponibiliza-lá na lista de resposta de requisições.

Para Implementação, verificar lista com a especificação das funções a serem implementadas. A lista será disponibilizada através da função TSSGetProcQueue()

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

 

Opcional

Fluxo do Processo

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>

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