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

 <Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>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

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

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

Tabelas Utilizadas

Atualmente os serviços do TSS são consumidos apenas através de requisições WS SOAP. No TSS 3.0, os serviços do TSS 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 na 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 consideradas 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()

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*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

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