Histórico da Página

...

1. Pré-requisitos
   1. O modelo de implementação da API T-Reports foi criado seguindo o documento "Guia de implementação de API" disponível no link abaixo:
      http://tdn.totvs.com/pages/viewpage.action?pageId=274849083
   2. Plataforma com suporte REST e autenticação Basic.
   3. Suporte a a tratamento cross-domain, por conta das requisições de serviços em servidores de domínio diferente.
      
      
2. Definições gerais
   1. Os retornos dos serviços REST devem estar encapsulados dentro de um objeto JSON com a seguinte especificação:
      

      Mensagens de erro

      Para todas as mensagens que representam um erro (códigos HTTP 4xx e 5xx) deve-se retornar obrigatoriamente os campos a seguir:

      {     code: "Código identificador do erro",     message: "Literal no idioma da requisição descrevendo o erro para o cliente",     detailedMessage: "Mensagem técnica e mais detalhada do erro" }

      
      Mensagens de sucesso

      Mensagens de sucesso (código http 2xx devem) devem retornar diretamente a entidade que representa o objeto resultado da operação do endpoint. Ex:
      

      GET http://totvs.com.br/api/trep/v1/dataproviders/1 {   code: "0001",   description: "provedor de DB" ... }

3. Descrição dos serviços
   

   Os serviços REST descritos a seguir estão divididos em:

   • Serviço de leitura de parâmetros gerais;
   • Serviço de teste de conexão;
   • Serviço de teste de sentença sql;
   • Serviço de leitura de schema de tabelas fisicas;
   • Serviço de leitura de schema de sentença sql;
   • Serviço de retorno de dados;

   Na descrição de cada serviço podemos encontrar os seguintes elementos:

   • Definição da URL do serviço;
   • Parâmetros de request (entrada) e  response (saída);
   • Descrição do serviço com detalhes relativos ao seu funcionamento;
     
     
     
   1. Serviço de leitura de parâmetros gerais;
      

      GET /api/trep/v1/dbdataproviders/parameters      

      Recebe	Não recebe parâmetros
      Retorna	Application/JSON

      Esse método é utilizado para obter os parâmetros do provedor de integrado do tipo "banco de dados". A necessidade e definição desses parâmetros é de livre pelo responsabilidade do dono do provedor a ser implementado. Os parametros retornados nesse provedor parâmetros retornados por esse serviço aparecerão na grid de parâmetros localizada no "cadastro de provedores de dados" do front-end eend do T-Reports. No JSON de retorno, deve constar as seguintes informações:

      • hostAppID: Código do aplicativo interno (host application);
      • databaseType: O tipo de banco de dados em uso pelo produto (ORACLE, SQLSERVER, PROGRESS, DB2, MYSQL, etc.);
      • productName: Nome do produto instalado (DATASUL, PROTHEUS, RM, LOGIX, etc.);
      • productVersion: Versão do produto instalado;
      • userCode: código do usuário logado. Corresponde ao identificador único gerado pelo produto, por exemplo, “jose.silva”, “santos001”, etc.;
      • userName: nome do usuário logado, por exemplo, “José da Silva”, “Luiz dos Santos”, etc.;
      • userEmail: e-mail do usuário logado. Por exemplo: “jose.silva@totvs.com.br”, “santos-luiz@mycomp.com”, etc.;
      • userDialect: dialeto do usuário logado, utilizado para fins de tradução da interface do usuário (i18n). Por exemplo, “pt-BR”, “es-ES”, “en-US”, etc.;
      • userCanMonitor: indica se o usuário logado pode acessar o monitor de EAI (serviços e interface) ou não. Pode ser “true” ou “false”.

      Importante: Em relação ao acesso, este será o único serviço que um usuário não autorizado poderá acessar e obter retorno. Os demais serviços retornarão código HTTP 403 (Forbidden) caso não tenham permissão (userCanMonitor = “false”).

      Exemplo de JSON de retorno
      • name: Nome do parâmetro;
      • description: Descrição do parâmetro;
      • value: Valor do parâmetro;
      • isPassword: Define se o valor do parâmetro será gravado e mostrado de forma criptografada. Pode ser “true” ou “false”