Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
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).
Definir a função EntidadeClear para a exclusão da entidade.
Atualmente grande parte dos métodos do TSS realizam o processamento das requisições no próprio corpo do método. A partir do novo modelo de processamento do TSS as requisições recebidas pelo TSS serão colocadas em filas para que assim possam ser processadas. Esse processamento será realizado através das rotinas de monitoramento de filas, que ao identificar a requisição encaminhará para as respectivas funções de processamento. Dessa forma faz se necessário que todos os processos possuam suas respectivas funções para o processamento das requisições. Diante desse cenário deverão ser implementadas funções para os seguintes métodos.
AdmEmpresas
getAdmEmpresasId
getAdmEmpresas
AdmClear
EntidadeClear
EntidadeAtiva
getPassEnt
RemessaNFe
monitorFaixa
monitorTempo
monitorSefaz
cancelaFaixa
RetornaFaixa
RetornaNotas
ConsultaChaveNFe
RetornaNfeStatus
Estatisticas
ConsultaDtChave
NfeIdClean
getDadosNfeId
NfeRemessaEvento
NfeRetornaEvento
NfeMonitorLoteEvento
NfeRetornaSeqEvento
NfeExportaEvento
NfeExportaEvento
Todas as regras de negócio e funcionamento dos processos deverão ser mantidos. Dessa foma as funções serão criadas com base nos próprios métodos. Devendo ser realizado apenas o desacoplamento do processamento dos métodos.
Após o processamento da requisição, as funções deverão montar a mensagem de retorno da requisição e disponibilizá-las nas filas de respostas de requisições. A distribuição deverá ser realizada através da função TSSDispacherRequest().
Parâmetros:
Dessa forma esses serviços ficam acoplados na interface de Web service e impedindo que o serviço possa ser consumido através de outros métodos de consumo. Para que os serviços oferecidos pelo TSS possam ser atendidos através de qualquer interface como as requisições HTTP que serão implementada na DLL, os serviços deverão ser disponibilizados através de funções. A nomeclatura das funções sera formada por:
"TSPROC" + "Sequencia do processo" + "nome do Método"
Ex: TSPROC0001Remessa - Função para processamento de remessas do Web service NESBRA
As funções receberão como parâmetro a mensagem JSON padrão definida para o TSS.(ver especificação da função: getJsonRequest() ). Para facilitar a implementação das funções, os parâmetros seguirão a mesma nomenclatura e estrutura recebida pelos métodos devendo apenas acrescentar os atributos de referencia para o objeto JSON. Dessa forma para criar as funções será necessário apenas copiar a estrutura dos métodos e realizar a dos parâmetros e do retorno:
oJSON:receive: + "parâmetro"
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()
retorno<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.
<Informações utilizadas na linha Protheus>.
<Informações utilizadas na linha Protheus>
<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. |
---|