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>Disponibilizar componente para inclusão das mensagens nas Filas e recuperação das respostas das mensagens.

(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

O componente de mensagens, deverá ser um componente utilizado apenas para torca de mensagens entre as aplicações, não poderá ter qualquer dependência de uso do TOP CONNECT e com regras de Negócio da aplicação. Será responsável apenas por implementar as interfaces de inclusão de mensagens na fila e das consultas das respostas das mensagens. As funcionalidades do componente serão definidas peas funções: PutProcInQueue() e GetProcResponse()

Função: PutProcInQueue()

Rotina responsável por inserir uma mensagem em uma Fila.

A rotina deverá obter uma referência para a Fila a ser utilizada para a inclusão da mensagem. A A referência deverá ser obtida através da função  QueueCreator(), que retornará um valor Booleano indicando se a criação do Objeto de referência para a fila foi criado com sucesso. Em caso de Sucesso a rotina poderá realizar a inclusão da mensagem na Fila através do método putMsg(). Caso contrário deverá retornar o erro ocorrido.

Parâmetros: 

cDocModel – Modelo do Documento. Utilizado para a definição da fila a ser Utilizada.

cJSONRequest – Mensagem a ser enviada para a Fila.

cMsgId – Referência para retorno do Id da Mensagem na Fila.

cError – Referência para informação de erros no Processamento.

Retorno:

lRet – Indica se a mensagem foi enviada com Sucesso para a Fila.

Função: GetProcResponse()

Rotina responsável por recuperar uma resposta de uma Lista

A rotina deverá obter uma referência para a Lista referente ao Modelo de documento A referência deverá ser obtida através da função  ListCreator(), que retornará um valor Booleano indicando se a criação do Objeto de referência para a Lista foi criado com sucesso. Em caso de Sucesso a rotina poderá recuperar a resposta da mensagem através do método getMsg(). Ao obter o retorno do método, a rotina deverá realizar algumas verificações essas verificações serão baseadas em atributos da classe utilizados para atribuição de retorno do método. A rotina deverá seguir os seguintes Critérios:

nRet = oObj: eNO_MSG: Condição que define a Inexistência de mensagens na Lista.

nRet = oObj:eNO_MSGID : Condição que define que não existe resposta para a Mensagem solicitada.  Em ambos os casos a rotina deverá gerar o seguinte retorno:

Status = “202”

Mensagem = “Mensagem Não localizada na Lista. ” + oObj:cName + “ Erro: ” + nRet

Parâmetros:

cMsgId – Id de referência para busca da resposta.

cDocModel – Modelo do Documento.

cMsgRet – Referencia para a resposta da Mensagem.

cHttpStatus – Referencia para Status Http da requisição

cError – Referência para informação de erros no Processamento.

Retorno:

lRet – Indica se a resposta foi recuperada

.

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