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 Função para recepção de requisições HTTP referente aos serviços do TSS.

(Obrigatório)

Definição da Regra de Negócio

Atualmente os serviços do TSS são consumidos apenas através de requisições WS SOAP. No TSS 3.0, os serviços poderão ser consumidos através de requisições estruturadas em formato JSON utilizando apenas o protocolo HTTP.  Todas as requisições serão realizadas através do método POST. Os serviços do TSS serão disponibilizados através de um único recurso WEB. A identificação do serviço solicitado será identificada através do atributo “action” definido na mensagem da requisição. O recurso para acesso aos serviços do TSS será definido pela função tssProcManager.

A função TSSProcManager será uma função definida em um fonte .prw que deverá ser definido com o mesmo nome da função(TSSProcManager).

Função: tssProcmanager

A função tssProcManager, será a função responsável pela recepção das mensagens enviadas pelas aplicações cliente do TSS através de requisições HTTP.

A mensagem recebida será em formato JSON. Ao deserializar a mensagem a função deverá identificar a ação a ser executada. A ação estará definida no atributo “action”. A rotina TSSProcMannager  deverá funcionar para requisições do tipo POST e do tipo GET. As requisições do tipo GET, serão atendidas por uma função única, que será a função getProcResponse(), responsável pela consulta da resposta das requisições. Para as requisições do tipo POST, serão executadas as funções de processamento de requisições WS.

Para a execução das requisições do tipo POST, a função deverá obter informações sobre o processo a ser executado. As informações serão obtidas através da função TSSGetProcQueue(), onde que receberá como parâmetro o código do processo que estará presente nas mensagens das requisições.

A função deverá estar preparada para executar a requisição de forma Síncrona ou Assíncrona. A decisão será feita através da função isQueue(). Que indicará se o servidor em execução está configurado para trabalhar com recurso de Fila. 

Caso o processamento deva ser realizado de forma Assíncrona, a rotina deverá processar a requisição através da função TSSProcRequest(), caso contrário a requisição deverá ser enviada para a fila de processamento através da função putProcInqueue().

As respostas HTTP deverão ser montadas através da função getJsonResponse().

Caso a requisição seja atendida em modo Síncrono e seja referente a um processo, deverá ser realizada a chamada para a execução do processamento ONDEMAND do TSS, que iniciará a execução do processamento da requisição. 

Função: GetJsonResponse()

A função getJsonResponse será a função responsável pela montagem das mensagens JSON de retorno.  Com base no resultado do processamento recebido como parâmetro, a função montará a reposta a ser enviada para a aplicação cliente do TSS.

A aplicação poderá ter como retorno 3 tipos de respostas, sendo:

Retorno do processo – Será o retorno em caso de sucesso no processamento da requisição.

Falha no Processamento – Qualquer situação de falha no processamento.

Ticket – comprovante de entrega de mensagem para a Fila.

Parâmetros:

cHttpStatus – Status http de retorno

uSend – Retorno do Processo

cError – erro de processamento

cTicket – Ticket recebido da Fila

Retorno:

cJsonResponse:

{"send":{ "status": '+ cHttpStatus + ',

          "msg":{"result":'+ cMsg + ',

                 "ticket":' + cTicket + '

                },

          "error": ' + cError + '

        }

}

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

Protótipo 01

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

Campo

<AAA_PERESP>

Tipo

<N>

Tamanho

<6>

Valor Inicial

<Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. 

Mandatório

Sim (  ) Não (  )

Descrição

<Referência Mínima para Cálculo>

Título

<Ref.Calc.>

Picture

<@E999.99>

Help de Campo

<Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação>

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

X1_ORDEM

01

X1_PERGUNT

Emissão De

X1_TIPO

D

X1_TAMANHO

8

X1_GSC

G

X1_VAR01

MV_PAR01

X1_DEF01

Comum

X1_CNT01

'01/01/08'

X1_HELP

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

Descrição

Configurações de Planejamento

Consulta Padrão

Tabela

“AMB”

Índice

“Código”

Campo

“Código”; ”Descrição”

Retorno

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Procedimento

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Módulo

Programa base

Nome Menu

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Registro padrão

Sim

Sim

Sim

Menu

Sim/Não

Sim/Não

Sim/Não

Release de Liberação

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