Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto |
| Módulo |
|
Segmento Executor |
| ||
Projeto1 |
| IRM1 |
|
Requisito1 |
| Subtarefa1 |
|
Chamado2 |
| ||
País | ( ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) 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).
Objetivo
Disponibilizar uma API para inclusão de strings de tradução no AtuSX.
Definição da Regra de Negócio
REST
Para o correto desenvolvimento, utilização e configuração veja a documentação do REST antes de utilizar esta API: Doducmentação do REST no Protheus.
API - Put
Deverá ser desenvolvida uma API de integração com o AtuSX para permitir a inclusão de strings de tradução diretamente em sua base de dados.
O nome da rotina RESTFul deverá ser ATUSX.
A API deverá ser desenvolvida usando os fundamentos do RESTFul e deverá contemplar os seguintes metadados do AtuSX:
- Dicionário de perguntas – SX1
- Dicionário de tabelas – SX2
- Dicionário de campos – SX3
- Cadastro de tabelas genéricas – SX5
- Dicionário de Parâmetros – SX6
- Dicionário de Pastas e agrupamentos – SXA
- Dicionário de consultas padrões – SXB
- Dicionário de grupo de campos – SXG
- Help e help de campos
- Tabela de strings de tradução de programas – arquivos .CH
- Menus do sistema
As chamadas do REST deverão ser organizadas da seguinte forma
Método | URI | Metadado |
---|---|---|
PUT | /question | Dicionário de perguntas |
PUT | /table | Dicionário de tabelas |
PUT | /field | Dicionário de campos |
PUT | /genericTable | Tabelas genéricas |
PUT | /parameter | Dicionário de parâmetros |
PUT | /folder | Dicionário de pastas e agrupamentos |
PUT | /lookup | Dicionário de consultas padrão |
PUT | /fieldGroup | Dicionário de grupos de campos |
PUT | /help | Help de campo |
PUT | /programText | Strings de programas |
PUT | /menu | Menus do sistema |
Exemplo de como deverá ser composta uma URL: http://<servidor>:<porta>/rest/atusx/<URI>
Todos os métodos REST deverão receber um JSON no corpo da mensagem que deverá conter as seguintes informações:
- version: Versão do dicionário no AtuSX (parâmetro não obrigatório)
- project: Código do projeto no AtuSX (parâmetro não obrigatório)
- package: Código do pacote no AtuSX (parâmetro não obrigatório)
key: Array contendo os valores que representam a chave da tabela de destino no AtuSX.
Esta opção poderá conter os seguinte valores:
URI | Valores | Exemplo de preenchimento |
---|---|---|
/question | [Grupo de Perguntas, ID do filtro padrão, Ordem do Pergunte, País] | "key":["ABSENT","","01","BRA"] |
/table | [Alias da tabela, País] | "key":["SA1","BRA"] |
/field | [Nome do campo, País] | "key":["A1_NOME","BRA"] |
/genericTable | [Código da tabela, Chave da Tabela, País] | "key":["00","01","BRA"] |
/parameter | [Nome do parâmetro, País] | "key":["MV_1DUP","BRA"] |
/folder | [Alias da tabela, Ordem da Folder, Grupo da Folder] | "key":["SA1","1",""] |
/lookup | [Código da SXB, Tipo da consulta padrão, Sequencia, Coluna, País] | "key":["A2A","1","01","DB","BRA"] |
/fieldGroup | [Código do grupo, País] | "key":["001","BRA"] |
/help | [Descrição do help, País] | "key":[".A014NOPR.","BRA"] |
/programText | [ ID da tabela de cabeçalho do Help (ZB0), Código da String, País] | "key":[1,"STR0001","BRA"] |
/menu | [Código do menu] | "key":["0000008203"] |
Lista de possíveis países:
Código | Sigla | Descrição |
---|---|---|
1 | ALL | Todos |
2 | BRA | Brasil |
3 | ARG | Argentina |
4 | EUA | Estados Unidos |
5 | CHI | Chile |
6 | COL | Colômbia |
7 | VEN | Venezuela |
8 | MEX | México |
9 | POR | Porto Rico |
10 | PAR | Paraguai |
11 | URU | Uruguai |
12 | PER | Peru |
13 | COS | Costa Rica |
14 | DOM | Rep. Dominicana |
15 | EQU | Equador |
16 | PAN | Pana |
17 | BOL | Bolívia |
18 | SAL | El Salvador |
19 | PTG | Portugal |
20 | ANG | Angola |
21 | HAI | Haiti |
22 | TRI | Trinidad e Tobago |
23 | PAD | Padrão |
24 | AUS | Austrália |
25 | RUS | Russia |
property: Mnemônico que representa alguma coluna específica da tabela que será atualizada.
Os valores possíveis para esse parâmetro são:URI Valores /question description, definition1, definition2, definition3. definition4, definition5 /table description /field title, description, options /genericTable description /parameter description1, description2, description3 /folder description /lookup description /fieldGroup description /help text /programText text /menu text - idiom: Idioma no qual se deseja incluir o temo traduzido. A lista de possíveis valores para esse parâmetro são: pt-br (português do Brasil), pt (português de Portugal), en (ingles), es (espanhol), ru (russo).
- value: Valor traduzido
O JSON deverá ser montado seguindo o seguinte modelo:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
[ { "version" : "<AtuSX version -non obligatory->", "project" : "<AtuSX project -non obligatory->", "package" : "<AtuSX package -non obligatory->", "key" : [ <Index Keys separate by ","> ], "property" : "<Field to update>", "idiom" : "<pt-br, pt, en, es, ru>", "value" : "<Tranlated term>" }, ... ] |
Exemplo de JSON formatado com valores reais para alterações de registros de SX1:
URI: /atusx/question
Bloco de código | ||||
---|---|---|---|---|
| ||||
[ {"version":"","project":"","package":"","key":["ABSENT","","01","RUS"],"property":"description","idiom":"ru","value":"России тест"}, {"version":"","project":"","package":"","key":["ABSENT","","01","RUS"],"property":"definition1","idiom":"ru","value":"да"}, {"version":"","project":"","package":"","key":["ABSENT","","01","RUS"],"property":"definition2","idiom":"ru","value":"нет"} ] |
De modo geral o JSON enviado deverá ser um array onde cada linha será correspondente a um UPDATE na tabela do AtuSX. Cada item do array deverá ter todas as informações necessárias para a localização do registro que será atualizado e o valor a ser incluído.
Autenticação
A principio utilizaremos autenticação Basic.
Erros e Validações
A própria API deverá possuir tratamento para diversos erros nas requisições. Segue a lista dos principais erros tratados:
- Problema na estrutura do JSON.
- Não foi preenchida a tag Key.
- Não foi preenchida a tag Property.
- Não foi preenchida a tag Idiom.
- Não foi preenchida a tag Value.
- Não foi informado um idioma válido (o conteúdo deve ser: pt-br, pt, en, es ou ru).
- Conteúdo da tag Property é inválido.
- Tamanho do array passado na tag Key difere do tamanho da chave de índice correspondente.
- Registro não pode ser encontrado
Casso seja passado mais de um JSON pra ser processado de uma só vez, o erro deverá retornar qual posição do array apresentou erro. Porém, neste caso, todos os JSONs anteriores terão sido processados e o processo será abortado ao localizar um erro.
API - Get
Criação da API para poder recuperar os valores que precisam ser traduzidos baseados em um idioma de referência, ou seja, a API deverá receber o idioma para o qual se deseja traduzir e o idioma de referencia, o JSON resultante da busca retornará o texto do idioma de referência para ser enviado para tradução.
As validações dos Gets deverão ser as mesmas do Put (descritas no item Erros e Validações)
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>.
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|