Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Especificação | |||
Produto | TSS | Módulo | TSS |
Segmento Executor | SERVIÇOS | ||
Projeto1 | M_SER_TSS002 | IRM1 | PCREQ-8287 |
Requisito1 | PCREQ-8288 | Subtarefa1 |
|
Release de Entrega planejada | 12.1.13 | ||
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. |
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
Definir Função para recepção de requisições HTTP referente aos serviços do TSS.
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 pela função TSSProcManagertssProcManager.
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
Âncora | ||||
---|---|---|---|---|
|
A função TSSProcManagertssProcManager, 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 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.
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.
cHttpStatus – Status http de retorno
uSend – Retorno do Processo
cError – erro de processamento
cTicket – Ticket recebido da Fila
cJsonResponse:
{"send":{ "status": '+ cHttpStatus + ',
"msg":{"result":'+ cMsg + ',
"ticket":' + cTicket + '
},
"error": ' + cError + '
}
}
<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
<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>.
Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/
Índice
Chave
01
<FI9_FILIAL+FI9_IDDARF+FI9_STATUS>
<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF>
03
<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO>
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> |
<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
<Informações utilizadas na linha Protheus>
Consulta: AMB
Descrição
Configurações de Planejamento
Tipo
Consulta Padrão
Tabela
“AMB”
Índice
“Código”
Campo
Retorno
AMB->AMB_CODIGO
<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
(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
Visualiza Menu
Sim/Não
Sim/Não
Sim/Não
Release de Liberação
Programas
Programa |
|
|
|
Descrição | (Max 40 posições) | (Max 40 posições) | (Max 40 posições) |
Nome Externo |
|
|
|
Nome Menu/Programa | (Max 32 posições) | (Max 32 posições) | (Max 32 posições) |
Nome Verbalizado[1] | (Max 254 posições) | (Max 254 posições) | (Max 254 posições) |
Procedimento |
|
|
|
Template | (Verificar lista de opções no man01211) | (Verificar lista de opções no man01211) | (Verificar lista de opções no man01211) |
Tipo[2] | Consulta/Manutenção/ Relatório/Tarefas | Consulta/Manutenção/ Relatório/Tarefas | Consulta/Manutenção/ Relatório/Tarefas |
Interface | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Categoria[3] |
|
|
|
Executa via RPC | Sim/Não | Sim/Não | Sim/Não |
Registro padrão | Sim | Sim | Sim |
Outro Produto | Não | Não | Não |
Visualiza Menu | Sim/Não | Sim/Não | Sim/Não |
Query on-line | Sim/Não | Sim/Não | Sim/Não |
Log Exec. | Sim/Não | Sim/Não | Sim/Não |
Rotina (EMS) |
|
|
|
Sub-Rotina (EMS) |
|
|
|
Localização dentro da Sub Rotina (EMS) |
|
|
|
Compact[4] | Sim/Não | Sim/Não | Sim/Não |
Home[5] | Sim/Não | Sim/Não | Sim/Não |
Posição do Portlet[6] | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right |
Informar os papeis com os quais o programa deve ser vinculado |
|
|
|
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>.
Código Papel | (máx 3 posições) |
Descrição em Português* |
|
Descrição em Inglês* |
|
[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
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|