Histórico da Página

Informações Gerais 

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Descrever os serviços necessários para que o monitor do TOTVS EAI  consiga realizar o diagnóstico dos serviços/integrações habilitadas entre os produtos integrados.

Definição da Regra de Negócio

Pré-requisitos

Os serviços de diagnósticos disponibilizados pelos produtos deverão atender os seguintes pré-requisitos:

• Plataforma com suporte a REST;
• Autenticação HTTP Basic;
• Suporte a tratamento de cross-domain, por conta das requisições de serviços em servidores de domínio diferente.

Definições gerais dos serviços

Os endpoints definidos neste documento seguem as definições presentes no documento Guia de implementação das APIs TOTVS. Em função disso, a API de diagnóstico terá uma versão diferente da API de monitoramento definida no documento ER_FRWJOI01-3_Serviços_para_monitoramento_de_EAI.

Todas as linhas de produto deverão disponibilizar os caminhos dos serviços do EAI de seus produtos, de forma que um ERP possa efetuar chamadas aos serviços dos demais ERPs.

Os parâmetros de paginação page e pageSize, quando não especificados, assumem o valor default de 1 e 10, respectivamente.

Serviços REST - Originados do Monitor EAI para o serviço REST dos aplicativos (produtos)

Âncora
/totvseai/monitor/v1/admin/companies/{appID}/{companyID}/{branchID}?page={page}&perPage={perPage} /totvseai/monitor/v1/admin/companies/{appID}/{companyID}/{branchID}?page={page}&perPage={perPage}

GET /totvseai/monitor/v2/admin/companies?externalAppID={externalAppID}&companyID={companyID}&branchID={branchId}&page={page}&pageSize={pageSize}

Este método lista os "de-para" de empresa e filial de um aplicativo interno (identificador do "de-para" igual a "CompanyInternalID").

O parâmetro externalAppID é opcional, e deve estar no formato "appID@productCode". Quando enviado, é buscado a informação do relacionamento somente para o aplicativo externo em questão. Caso contrário, é buscado todas as informações dos aplicativos disponíveis.

Pode-se também enviar os parâmetros de companyID (valor da empresa do aplicativo interno), para buscar o mapeamento somente de uma empresa/grupo daquele aplicativo; e branchID (valor da filial interna), para buscar somente daquela filial.

Atributos do JSON de retorno esperado:

• appID - Identificador do aplicativo interno (ex.PRODUCAO18@PROTHEUS).
• hasNext - indica se há mais itens além dos retornados na resposta.
• items- Array de objetos, onde cada objeto possui os seguintes atributos:
  • companyID - Empresa ou grupo de empresas (Protheus) do aplicativo interno.
  • branchID - Filial do aplicativo interno.
  • integratedProducts  - Array de objetos, sendo:
    • appID externalAppID - Identificador do aplicativo externo (Ex. PRODUCAO@RM)
    • companyID - Valor equivalente, no aplicativo externo, da empresa ou grupo de empresas (Protheus) associado.
    • branchID - Filial do aplicativo externo, equivalente a filial do aplicativo interno.

Fluxo do serviço

Neste exemplo, o Protheus será o aplicativo interno, e a comunicação é realizada apenas entre o monitor e o serviço REST do Protheus.

Legenda: (seta verde) requisição de origem; (seta vermelha) resposta da requisição.

Retorno em caso de falha

O método deve retornar, no corpo da resposta, os códigos de erro indicados abaixo, bem como o código HTTP 404 (Not found) no header quando:

• O aplicativo interno não possuir "de-para" de empresas cadastrado (código FE012);
• Não existir registros de "de-para" de empresa para o aplicativo externo informado (externalAppID) (código FE011);
• Não existir registros de "de-para" com o companyID ou branchID informados (FE009).

O formato do corpo da resposta deve estar conforme especificado no Guia de implementação das APIs TOTVS. Ou seja:

• code: recebe o código do erro.
• message: recebe o texto padrão do erro.
• detailedMessage: recebe texto complementar ao erro padrão, podendo ser um detalhe técnico ou maiores explicações sobre a causa do erro.

Exemplos de retorno

• Obtendo todos os "de-para" de empresa do aplicativo interno.

{
	"appIDhasNext": "PRODUCAO18@PROTHEUS"false,
	"hasNextitems": false,[{
		"itemsappID": [{"PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D MG 01",
		"integratedProducts": [{
			"appIDexternalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "01"
		},
		{
			"appIDexternalAppID": "AMBX@DATASUL",
			"companyID": "1",
			"branchID": "10"
		}]
	},
	{
		"appID": "PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D RJ 01",
		"integratedProducts": [{
			"appIDexternalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "02"
		},
		{
			"appIDexternalAppID": "AMBX@DATASUL",
			"companyID": "1",
			"branchID": "11"
		}]
	}]
}

• Obtendo os "de-para" de empresa do aplicativo interno com o aplicativo externo RM.

{
	"appIDhasNext": "PRODUCAO18@PROTHEUS"true,
	"hasNextitems": true,[{
		"itemsappID": [{"PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D MG 01",
		"integratedProducts": [{
			"appIDexternalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "01"
		}]
	},
	{
		"appID": "PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D RJ 01",
		"integratedProducts": [{
			"appIDexternalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "02"
		}]
	}]
}

• Obtendo os de-para de empresa do aplicativo interno para a empresa "18" e filial "D MG 01".

{
	"appIDhasNext": "PRODUCAO18@PROTHEUS"true,
	"hasNextitems": true,[{
	
	"itemsappID": [{"PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D MG 01",
		"integratedProducts": [{
			"appIDextenalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "01"
		},
		{
			"appIDexternalAppID": "AMBX@DATASUL",
			"companyID": "1",
			"branchID": "10"
		}]
	}]
}

Âncora
/totvseai/monitor/v1/apps/{appID}/transactions?page={page}&perPage={perPage} /totvseai/monitor/v1/apps/{appID}/transactions?page={page}&perPage={perPage}

Transações habilitadas no aplicativo

O método GET /totvseai/monitor/v1/apps/{appID}/transactions?page={page}&perPage={perPage}, já criado para o monitor EAI, será utilizado. Para mais informações, consulte o método na especificação correspondente.

Fluxo de envio

Para consultas no aplicativo interno:

Em consultas diretas ao aplicativo externo:

Legenda: (seta verde) requisição de origem; (seta vermelha) resposta da requisição.

Âncora

/totvseai/monitor/v1/admin/healthcheck/checktransactions/EAI?appID={appid}&version={version}&suportedMode={suportedMode}&enableMode={enableMode}&allowAnonymous={allowAnonymous}&includeOriginalMsg={includeOriginalMsg}&avaiableVersions={avaiableVersions} /totvseai/monitor/v1/admin/healthcheck/checktransactions/EAI?appID={appid}&version={version}&suportedMode={suportedMode}&enableMode={enableMode}&allowAnonymous={allowAnonymous}&includeOriginalMsg={includeOriginalMsg}&avaiableVersions={avaiableVersions}

GET /totvseai/monitor/v2/admin/healthcheck/transactions/EAI?targetAppID={targetAppID}&transactionID={transactionID}&version={version}&supportedMode={supportedMode}&enabledMode={enabledMode}

Este serviço verifica a integridade da integração de acordo com as transações habilitadas em um aplicativo na camada do EAI (framework).

O parâmetro targetAppID informa o aplicativo destino para validação da transação. Deve usar o formato "appID@productCode". Como caso de uso, por exemplo, o monitor quer validar informações colhidas no RM contra as informações presentes no Protheus. Neste caso, o targetAppID seria o RM (RM@RM) e a requisição seria enviada ao Protheus. O intuito deste parâmetro é poder verificar a consistência das rotas. Caso ele não seja enviado, deve ser gerado um erro HTTP 400 (Bad request) no header e no corpo do retorno. No corpo do retorno, ainda, a mensagem deve informar que o parâmetro é obrigatório.

O parâmetro transactionID é opcional. Se omitido, serão consideradas todas as transações. Da mesma forma, o parâmetro version, quando omitido, permitirá validar todas as versões de uma transação.

Os parâmetros supportedMode e enabledMode são opcionais, e quando enviados, farão a consistência de uma transação cadastrada em um aplicativo A contra um aplicativo B, porém, sobrepondo os valores presentes na transação do aplicativo A. Isso permite antecipar problemas antes de efetivar uma alteração de configuração, por exemplo. Os valores permitidos para estes dados seguem os valores do retorno do método GET /totvseai/monitor/v1/apps/{appID}/transactions?page={page}&perPage={perPage}.

O retorno esperado para este método é um outro JSON, que retornará a compatibilidade ou não das transações enviadas x transações no aplicativo (baseado no formato definido no Guia de Implementação das APIs TOTVS). Seus atributos estão descritos abaixo:

• transactionID - Identificador da transação.
• messages - Array de objetos, contendo as mensagens pertinentes a validação da transação:
  • code - código do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. Também podem conter código de erro HTTP nos casos for aplicável.
  • message - Texto do erro padrão. Se não houver conteúdo no atributo "code", este atributo deve, obrigatoriamente, conter um valor.
  • detailedMessage - Texto opcional, que pode ser acrescido das mensagens recebidas. A string associada ao código de erro sempre é apresentada ao usuário. O contexto deste retorno é acrescentar informações adicionais ao erro apresentado.

Fluxo conceitual de envio para o aplicativo interno:

Verificações realizadas

O aplicativo interno, ao receber uma requisição neste endpoint,verificará se a transação consultada existe. Se existir, efetuará uma requisição para o endpoint GET /totvseai/monitor/v1/apps/{targetAppID}/transactions/{transactionID} no aplicativo indicado pelo parâmetro targetAppID, caso ele seja um aplicativo externo válido. No caso da transação informada não estar cadastrada no aplicativo interno, deve-se retornar mensagem com o código FE005, complementada com o nome do aplicativo interno.

Após receber o retorno do aplicativo, o aplicativo interno verificará:

• Se a transação existe no aplicativo consultado. Caso não exista, deve retornar o código FE005 (A transação não está cadastrada no aplicativo), complementada com o nome do aplicativo externo;
• Se, existindo transação, as versões da transação do aplicativo interno existem no aplicativo consultado (ver item verificação de versão/release, logo abaixo). Deve retornar o código FE008 (Transação com versões incompatíveis) em caso de erro. Em caso de compatibilidade parcial, deve retornar o código FW007 (Transação com releases diferentes).
• Se o modo habilitado da transação/versão é compatível com o modo habilitado do aplicativo consultado (ver item compatibilidade de modos, tabela logo abaixo), deve retornar o código informado na tabela de compatibilidade de modos (coluna Código e Mensagens Adicionais).

Verificação de versão/release

As transações com mais de uma versão/release tem a seguinte regra de compatibilidade.

Em resumo, versões (parte antes do ".") diferentes são incompatíveis. Versões iguais e releases (parte depois do ".") diferentes são potencialmente compatíveis, pois as diferenças deveriam ser tratadas pelos adapters de negócio.

O retorno deve considerar todas as possibilidades de interação entre versões, pontuando aquelas que são compatíveis e aquelas que não são. Considerando o seguinte cenário:

Transação CustomerVendor

Segue resultado da validação:

Compatibilidade de modos

Indica se é possível a troca de mensagens entre os aplicativos. A tabela abaixo demonstra as situações possíveis e o retorno que o endpoint deve prover.

Lembrando o significado de cada modo:

• not_enabled: a transação está desabilitada.
• send_enabled: a transação só permite envio.
• receive_enabled: a transação só permite recebimento.
• both_enabled: a transação permite tanto envio quanto recebimento.

Exemplos de retorno

Retorno da requisição para o aplicativo interno:

{
	"transactionID" : "order",
	"messages" : [{
		"code" : "FW006"
		"message" : "Mensagem somente executada em uma filial.",
		"detailedMessage": "Mensagem disponível somente na filial 001"
	}]
}

Retorno em caso de transação não cadastrada no aplicativo externo.

 {
	"transactionID" : "request",
	"messages" : [{
		"code" : "FE005"
		"message" : "Transação não está cadastrada no aplicativo.",
		"detailedMessage": "Aplicativo: RM@RM"
	}]
}

Retorno em caso de transação não cadastrada no aplicativo interno

{
	"transactionID" : "customervendor",
	"messages" : [{
		"code" : "FE005"
		"message" : "Transação não está cadastrada no aplicativo.",
		"detailedMessage": "Aplicativo: PRODUCAO18@PROTHEUS"
	}]
}

Retorno caso o parâmetro targetAppID seja omitido

//Na resposta, deve conter no header status o valor 400.
{
	"transactionID" : "user",
	"messages" : [{
		"code" : "400"
		"message" : "Bad request",
		"detailedMessage": "Parâmetro de query targetAppID é obrigatório."
	}]
}

Retorno caso a transação possua versões incompatíveis

{
	"transactionID" : "unitofmeasure",
	"messages" : [{
		"code" : "FE008"
		"message" : "Transação com versões incompatíveis.",
		"detailedMessage": "Versões na origem: 1.000, 1.002; versões no destino: 2.000"
	}]
}

Retorno caso a transação possua modos incompatíveis

// Neste exemplo, bank possui as versões 1.000 e 2.000 em ambos os aplicativos.
// A situação é a seguinte:
// Versão	Protheus		RM
// 1.000	send_enabled	send_enabled
// 2.000	receive_enabled	not_enabled
{
	"transactionID" : "bank",
	"messages" : [{
		"code" : "FE013"
		"message" : "Envio não é possível em ambos os sentidos",
		"detailedMessage": "Versão 1.000; Ambos os aplicativos apenas enviam."
	},{
		"code" : "FE013"
		"message" : "Envio não é possível em ambos os sentidos",
		"detailedMessage": "Versão 2.000; Transação desabilitada no aplicativo RM."
	}]
}

Âncora
Check_de_parametrização_business Check_de_parametrização_business

GET /totvseai/monitor/v2/admin/healthcheck/transactions/business?targetAppID={targetAppID}&transactionID={transactionID}&version={version}

Este serviço verifica a integridade da integração de acordo com as transações habilitadas em um aplicativo na camada de negócio (business).

O parâmetro targetAppID informa o aplicativo com o qual se deseja validar a integração. Deve usar o formato "appID@productCode". Por exemplo, o monitor quer validar informações colhidas no RM e validar estas informações no Protheus. Neste caso, o targetAppID seria RM. O intuito deste parâmetro é poder verificar a consistência das rotas. Caso ele não seja enviado, as informações de validações das rotas não serão verificadas.

O parâmetro transactionID é opcional. Quando não informado, serão consideradas para validação todas as transações registradas no aplicativo que receber a requisição.

O parâmetro version é opcional e válido somente em conjunto com o parâmetro transactionID. Quando não informado, serão consideradas todas as versões da transação solicitada.

O retorno esperado para este método segue o proposto pelo método /totvseai/monitor/v2/admin/healthcheck/transactions/EAI?targetAppID={targetAppID}&transactionId={transactionID}&version={version}. Os atributos são os seguintes:

• transactionID - Identificador da transação
• messages   - Array de objetos, contendo as mensagens pertinentes a transação:
  
  • code - código do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. Também podem conter código de erro HTTP nos casos for aplicável.
  • message - Texto do erro padrão. Se não houver conteúdo no atributo "code", este atributo deve, obrigatoriamente, conter um valor.
  • detailedMessage - Texto opcional, que pode ser acrescido das mensagens recebidas. A string associada ao código de erro sempre é apresentada ao usuário. O contexto deste retorno é acrescentar informações adicionais ao erro apresentado.

O trabalho de validação propriamente dito ficará a cargo das áreas de negócio. Caberá a cada framework definir a melhor maneira de realizar as chamadas para as validações de cada área de negócio envolvida na integração, bem como capturar o retorno das rotinas e retornar o conteúdo dentro do padrão esperado.

Fluxo do método

O ERP que receber requisições deste endpoint precisará efetuar uma segunda requisição para o aplicativo de destino. Essa requisição subsequente fornecerá parâmetros adicionais, referentes ao modo de integração entre os 2 ERPs envolvidos. Para mais informações, verifique a documentação do endpoint POST /totvseai/monitor/v2/admin/healthcheck/transactions/business.

Retorno em caso de falha

Algumas validações que serão efetuadas pelos frameworks, que dizem respeito aos parâmetros fornecidos:

• targetAppID não informado - Deve ser gerado um erro HTTP 400 (Bad request) no header e no corpo do retorno, onde também deve constar mensagem informando que o parâmetro é obrigatório.
• targetAppID não está cadastrado como aplicativo externo - Deve ser gerado um erro HTTP 404 (Not found).
• transactionID não está cadastrado para o aplicativo interno - Deve ser gerado um erro HTTP 404 (not found). No corpo do retorno da requisição, informar "Transação não existe para o aplicativo interno" no atributo "detailedMessage".
• transactionID não está cadastrado para o aplicativo externo - Deve ser gerado um erro HTTP 404 (not found). No corpo do retorno da requisição, informar "Transação não existe para o aplicativo externo" no atributo "detailedMessage".
• version não encontrada para o aplicativo interno - Deve ser gerado um erro HTTP 404 (not found). No atributo "detailedMessage" do corpo do retorno, informar "Versão não existe para a transação informada no aplicativo interno".
• version não encontrada para o aplicativo externo - Deve ser gerado um erro HTTP 404 (not found). No atributo "detailedMessage" do corpo do retorno, informar "Versão não existe para a transação informada no aplicativo externo".
• version informado sem o parâmetro transactionID - Deve ser gerado um erro HTTP 400 (bad request). No atributo "detailedMessage" do retorno, informar "Uso incorreto do parâmetro version. Deve ser usado em conjunto com o parâmetro transactionID".

Exemplo de retorno

• Retorno de uma requisição feita ao Protheus, validando uma integração com RM:

{
	"transactionID" : "financing",
	"messages" : [{
		"code" : "AE100"
		"message" : "É necessário configurar o parâmetro MV_MULNATP e MV_MULNATR na integração com o TOTVS Incorporações.",
		"detailedMessage": "Configure os parâmetros"
	}]
}

Âncora
post_trans_business post_trans_business

POST /totvseai/monitor/v2/admin/healthcheck/transactions/business&sourceAppID={sourceAppID}&transactionID={transactionID}&version={version}

Este endpoint será utilizado efetuar a validação de transações na camada de negócio, permitindo fornecer parâmetros adicionais, específicos da integração entre os dois ERPs envolvidos. Por exemplo: nas integrações entre Protheus e RM, há parametrizações de negócio que precisam estar ativadas. Essas parametrizações podem ser verificadas através desse endpoint.

Seu uso é complementar à chamada do endpoint GET /totvseai/monitor/v2/admin/healthcheck/transactions/business.

Descrição dos parâmetros enviados:

• sourceAppID - indica o aplicativo originador da requisição de validação. Este parâmetro é obrigatório, pois a partir dele o ERP determinará se os parâmetros adicionais serão considerados ou não. Deve usar o formato "appID@productCode".
• transactionID - indica a transação que será validada. Quando não informado, serão consideradas todas as transações.
• version - indica a versão da transação a validar (opcional). Se for omitido, todas as versões disponíveis para a transação serão verificadas. Seu uso requer a presença do parâmetro transactionID.

O JSON que deve ser enviado no corpo da requisição terá os seguintes atributos:

• parameter - conterá o nome do parâmetro;
• value - conterá o valor esperado, podendo ser um array ou um objeto.

A leitura e interpretação do JSON de parâmetros dependerá da implementação do endpoint no ERP. Será sua responsabilidade dar o tratamento correto ao conteúdo recebido.

Retorno em caso de falha

Abaixo seguem as situações de falha que o endpoint deve tratar, bem como o respectivo retorno. Sempre que possível, a resposta da requisição deve conter, no corpo, o JSON de retorno previsto pelo Guia de implementação das APIs TOTVS.

• Parâmetro sourceApp não informado - Retorna erro HTTP 400 (Bad request). No corpo da resposta deve constar a mensagem "Parâmetro sourceApp é obrigatório, mas não foi informado".
• Parâmetro sourceApp tem um valor inválido - Retorna erro HTTP 404 (Not found).
• Parâmetro transactionID tem um valor inválido - Retorna erro HTTP 404 (Not found).
• Parâmetro version foi informado sem o parâmetro transactionID - Retorna erro HTTP 400 (Bad request). No corpo da resposta deve constar a mensagem "Parâmetro version só é permitido em conjunto com o parâmetro transactionID".
• Parâmetro version tem um valor inválido - Retorna erro HTTP 404 (not found). No corpo da resposta deve constar a mensagem "Versão informada não foi encontrada para a transação".
  

Exemplo de JSON a ser enviado no corpo da requisição:

[{
	"parameter": "SharingMode",
	"value": "C"
},{
	"parameter": "MV_MULNATP",
	"value": "S"
}]

Exemplo de retorno

• Retorno gerado pelo Protheus, de uma chamada feita pelo RM.

{
	"transactionID" : "financing",
	"messages" : [{
		"code" : "AE100"
		"message" : "É necessário configurar o parâmetro MV_MULNATP e MV_MULNATR na integração com o TOTVS Incorporações.",
		"detailedMessage": "Configure os parâmetros"
	]}
}

Âncora
/totvseai/monitor/v1/admin/healthcheck/getcompanies/{appID}/{companyID}/{branchID} /totvseai/monitor/v1/admin/healthcheck/getcompanies/{appID}/{companyID}/{branchID}

GET /totvseai/monitor/v2/admin/healthcheck/mappings/{appID}?mappingValue={mappingValue}&mappingID={mappingID}

Este serviço verifica a integridade dos mapeamentos entre entidades do aplicativo origem e destino, buscando, a partir de uma chave de internalID, os valores correspondentes no outro aplicativo.

Parâmetros de entrada:

• appID - Código do aplicativo interno. Deve usar o formato "appID@productCode". Necessário informar, pois há ERPs que podem ter mais de um aplicativo configurado numa instalação (ex. Protheus);
• mappingValue - Valor do código interno (de-para) do aplicativo interno;
• mappingID - identificador do "de-para"; indica a entidade a qual se refere o mapeamento.

O JSon JSON esperado como retorno deste método deve possuir os atributos a seguir:

• externalAppID -  Código do aplicativo externo para o qual o valor de "de-para" foi registrado.
• mappingValue - Valor do código interno
• messages  - array de objetos, contendo
  
  • code - código do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. Também podem conter código de erro HTTP nos casos for aplicável.
  • message - Texto do erro padrão. Se não houver conteúdo no atributo "code", este atributo deve, obrigatoriamente, conter um valor.
  • detailedMessage - Texto opcional, que pode ser acrescido das mensagens recebidas. A string associada ao código de erro sempre é apresentada ao usuário. O contexto deste retorno é acrescentar informações adicionais ao erro apresentado.

Fluxo de envio para o aplicativo interno:

Fluxo de envio diretamente a um aplicativo externo:

Verificações realizadas

Deve ser gerado erro HTTP 400 (Bad request) caso um dos parâmetros esteja ausente. No corpo do retorno deve constar mensagem indicando qual(is) parâmetro(s) estão faltando.

Caso o valor informado no parâmetro appID não seja válido, deve ser gerado o erro HTTP 404 (not found). No corpo do retorno deve constar mensagem indicando que o aplicativo informado não existe.

Caso o valor informado no parâmetro mappingID não seja igual a "CompanyInternalID" ou "BranchInternalID", deve ser gerado erro HTTP 404 (Not found). No corpo do retorno deve constar a mensagem indicando que apenas os dois valores são permitidos no momento.

Exemplos de retorno

Abaixo, exemplo de busca de de-para de empresas, com a requisição originada do aplicativo RM contra o Protheus:

 {
	"externalAppID" : "PROTHEUS18@PRODUCAO",
	"mappingValue":"18|D MG 01",
	"messages" : [{
		"code" : "FI001"
		"message" : "Validado",
		"detailedMessage":""
	]}
}

Retorno no caso de "de-para" não encontrado no aplicativo:

{
	"externalAppID" : "PROTHEUS18@PRODUCAO",
	"mappingValue":"",
	"messages" : [{
		"code" : "FE011"
		"message" : "Não existe de-para associado.",
		"detailedMessage":""
	}]
}

Âncora
Check_ws Check_ws

GET /totvseai/monitor/v2/admin/healthcheck/wsintegration/{targetAppID}/{companyID}/{branchID}

Este serviço realiza o teste de envio de WhoIs a outro sistema partindo de um ERP (existe um método de verificação partindo do próprio monitor). O intuito deste serviço é testar se a comunicação entre os ERPs está funcionando de maneira satisfatória.

Este método é disparado visando validar a integração de um sistema A contra um sistema B. Neste cenário, o serviço REST é enviado ao sistema A, e o parâmetro targetAppID é enviado com o valor de B. O sistema A então irá validar se a integração com o sistema B está operante através de envio da mensagem WhoIS. O sistema A então devolve o status para o serviço do monitor.

O parâmetro targetAppID recebe o valor do aplicativo ao qual o destino deverá tentar conectar-se. Deve usar o formato "appID@productCode".

O parâmetro companyID recebe o valor da empresa/grupo de empresas do aplicativo A

O parâmetro branchID é opcional, e recebe o valor da filial buscada do aplicativo A

O JSON de retorno esperado para este método contém os seguintes atributos:

• • originAppID  - aplicativo que enviou a requisição ao outro sistema. Deve usar o formato "appID@productCode".
  • destinationAppID - aplicativo que se deseja verificar a integração. Deve usar o formato "appID@productCode".
  • originCompany - Empresa ou grupo originais enviados
  • originBranch - Filial enviada
  • messages - array de objetos, contendo:
    
    • code - código do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. Também podem conter código de erro HTTP nos casos for aplicável.
    • message - Texto do erro padrão. Se não houver conteúdo no atributo "code", este atributo deve, obrigatoriamente, conter um valor.
    • detailedMessage - Texto opcional, que pode ser acrescido das mensagens recebidas. A string associada ao código de erro sempre é apresentada ao usuário. O contexto deste retorno é acrescentar informações adicionais ao erro apresentado.

Fluxo de envio da requisição, onde Protheus é o aplicativo interno:

Exemplo de envio de requisição ao Protheus, onde o mesmo irá disparar a WhoIs para o RM

{
	"originAppID" : "PRODUCAO18@PROTHEUS",
	"destinationAppID" : "RM@RM",
	"originCompany" : "18",
	"originBranch" : "D MG 01",
	"messages" : [{
		"code" : "FI001"
		"message" : "Validado",
		"detailedMessage":""
	}]	
}

Âncora
settings settings

GET /totvseai/monitor/v1/admin/healthcheck/settings

Este serviço realiza validações específicas de produto, referentes a configurações necessárias para o correto funcionamento do EAI na instalação do aplicativo. Cada ERP que implementar este endpoint deveria realizar as verificações pertinentes. Por exemplo, no Protheus e Logix, pode-se verificar se a sessão WEBSERVICES foi informada no arquivo TotvsAppServer.ini. No Datasul, pode-se verificar se o arquivo eai2-config.properties está presente e contém todas as chaves de configuração básicas.

O JSON de retorno esperado para este método contém os seguintes atributos:

• • appID- Sistema que recebeu a requisição. Deve usar o formato "appID@productCode";
  • messages - array de objetos, contendo:
    
    • code - código do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. Também podem conter código de erro HTTP nos casos for aplicável.
    • message - Texto do erro padrão. Se não houver conteúdo no atributo "code", este atributo deve, obrigatoriamente, conter um valor.
    • detailedMessage - Texto opcional, que pode ser acrescido das mensagens recebidas. A string associada ao código de erro sempre é apresentada ao usuário. O contexto deste retorno é acrescentar informações adicionais ao erro apresentado.

Fluxo conceitual do processo:

Exemplo de retorno

• Retorno supondo o monitor instalado no Protheus:

{
	"appID" : "PRODUCAO18@PROTHEUS",
	"messages" : [{
		"code" : "FI001"
		"message" : "Validado",
		"detailedMessage":""
	}]	
}

• Retorno supondo o monitor instalado no Logix:

{
	"appID" : "EAI2@LOGIX",
	"messages" : [{
		"code" : "FE001"
		"message" : "Configuração inválida",
		"detailedMessage" : "Sessão WEBSERVICES não foi encontrada no arquivo TotvsAppServer.ini"
	}]
}

Serviços SOAP - Originados do Monitor EAI para o serviço de EAI do aplicativo

Os serviços SOAP a seguir visam reutilizar os serviços de EAI - Mensagem Padronizada já existentes nos produtos. Eles tem como originador o Monitor Totvs EAI e tem como destino os serviços de EAI dos aplicativos cadastrados.

Âncora
WsGetStatus WsGetStatus

Verificação de WSDL e autenticação

Serviço que verifica se o servidor do serviço do EAI está disponível.

O serviço irá gerar uma requisição de consulta ao WSDL do serviço do EAI cadastrado para o aplicativo.

A URL para obtenção do WSDL será obtida do retorno do serviço apps, no atributo wsdlUrl, e os dados para autenticação serão obtidos do arquivo monitor-url-list.json.

Fluxo do serviço:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generated 20160927 10:35:39 by ADVPL WSDL Server 1.110216 / Protheus 7.00.131227A-20160909 NG -->
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:s="http://www.w3.org/2001/XMLSchema" 
xmlns:s0="http://www.totvs.com/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" 
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
targetNamespace="http://www.totvs.com/" xmlns="http://schemas.xmlsoap.org/wsdl/">
    <types>
        <s:schema elementFormDefault="qualified" targetNamespace="http://www.totvs.com/">
            <s:element name="RECEIVEMESSAGE">
                <s:complexType>
                    <s:sequence>
                        <s:element minOccurs="1" maxOccurs="1" name="INMSG" type="s:string" />
                    </s:sequence>
                </s:complexType>
            </s:element>
            <s:element name="RECEIVEMESSAGERESPONSE">
                <s:complexType>
                    <s:sequence>
                        <s:element minOccurs="1" maxOccurs="1" name="RECEIVEMESSAGERESULT" type="s:string" />
                    </s:sequence>
                </s:complexType>
            </s:element>
        </s:schema>
    </types>
    <message name="RECEIVEMESSAGESOAPIN">
        <part name="parameters" element="s0:RECEIVEMESSAGE" />
    </message>
    <message name="RECEIVEMESSAGESOAPOUT">
        <part name="parameters" element="s0:RECEIVEMESSAGERESPONSE" />
    </message>
    <portType name="EAISERVICESOAP">
        <operation name="RECEIVEMESSAGE">
            <documentation>Metodo que recebe mensagens para processamento pelo Microsiga Protheus</documentation>
            <input message="s0:RECEIVEMESSAGESOAPIN" />
            <output message="s0:RECEIVEMESSAGESOAPOUT" />
        </operation>
    </portType>
    <binding name="EAISERVICESOAP" type="s0:EAISERVICESOAP">
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
        <operation name="RECEIVEMESSAGE">
            <soap:operation soapAction="http://www.totvs.com/RECEIVEMESSAGE" style="document" />
            <input>
                <soap:body use="literal" />
            </input>
            <output>
                <soap:body use="literal" />
            </output>
        </operation>
    </binding>
    <service name="EAISERVICE">
        <documentation>&lt;b&gt;Serviço genérico de integração com o Microsiga Protheus via EAI&lt;/b&gt;</documentation>
        <port name="EAISERVICESOAP" binding="s0:EAISERVICESOAP">
            <soap:address location="http://172.16.32.191:89/pr12_bra/eai/EAISERVICE.apw" />
        </port>
    </service>
</definitions>

Caso seja necessária autenticação no aplicativo destino, a mesma deverá ser enviada no header da requisição, via basic authentication. Para isto será necessário cadastrar o usuário de acesso ao EAI no monitor (o usuário de acesso nem sempre é o usuário logado no monitor).

Âncora
Autenticação e recebimento Autenticação e recebimento

Autenticação e recebimento

Serviço que visa verificar se o aplicativo destino está recebendo requisições normalmente.

Este serviço irá realizar o post da Mensagem Padronizada TOTVS WhoIs e irá aguardar o retorno da requisição.

A mensagem Padronizada TOTVS espera um código de empresa e filial para mapeamento de integrações. Este empresa e filial será capturada pelo método GET /totvseai/monitor/v1/admin/getcompanies. Para Datasul e Logix não existe a necessidade de envio  destes valores.

O SourceApplication e Product  enviados na mensagem serão padronizados como "TOTVSMONITOR". O atributo version da tag Product será enviado com a versão "1.000".

O retorno deste método definirá se o EAI está disponível para recebimento (serviço disponível no ar) e se houve sucesso na autenticação. A verificação será realizada pelo retorno do status da conexão HTTP e pelo retorno da mensagem do tipo ResponseMessage.

Fluxo do serviço:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tot="http://www.totvs.com/">
   <soapenv:Header/>
   <soapenv:Body>
      <tot:receiveMessage>
         <tot:inMsg><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<TOTVSMessage>
<MessageInformation version="1.000">
<UUID>dee8c4da-1e19-4b44-df97-249443638a9d</UUID>
<Type>BusinessMessage</Type>
<Transaction>WHOIS</Transaction>
<StandardVersion>1.000</StandardVersion>
<SourceApplication>TOTVSMONITOR</SourceApplication>
<CompanyId>18</CompanyId>
<BranchId>D MG 01</BranchId>
<Product name="TOTVSMONITOR" version="1.000"></Product>
<GeneratedOn>2015-11-26T10:55:23</GeneratedOn>
<DeliveryType>Sync</DeliveryType>
</MessageInformation>
<BusinessMessage>
<BusinessRequest>
<Operation>WhoIs</Operation>
</BusinessRequest>
<BusinessContent/>
</BusinessMessage>
</TOTVSMessage>]]></tot:inMsg>
      </tot:receiveMessage>
   </soapenv:Body>
</soapenv:Envelope>

O retorno esperado da Mensagem Padronizada WhoIs deverá ser semelhante ao seguinte:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <RECEIVEMESSAGERESPONSE xmlns="http://www.totvs.com/">
            <RECEIVEMESSAGERESULT>&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt;&lt;TOTVSMessage&gt;&lt;MessageInformation version=&quot;1.001&quot;&gt;&lt;UUID&gt;66a7fdd0-ec4d-ac9a-0915-4a0c17a75cd4&lt;/UUID&gt;&lt;Type&gt;Response&lt;/Type&gt;&lt;Transaction&gt;WHOIS&lt;/Transaction&gt;&lt;StandardVersion&gt;1.000&lt;/StandardVersion&gt;&lt;SourceApplication&gt;PR12_BRA&lt;/SourceApplication&gt;&lt;CompanyId&gt;18&lt;/CompanyId&gt;&lt;BranchId&gt;D MG 01 &lt;/BranchId&gt;&lt;Product name=&quot;PROTHEUS&quot; version=&quot;12&quot;&gt;&lt;/Product&gt;&lt;GeneratedOn&gt;2016-09-27T17:05:16Z&lt;/GeneratedOn&gt;&lt;DeliveryType&gt;Sync&lt;/DeliveryType&gt;&lt;/MessageInformation&gt;&lt;ResponseMessage&gt;&lt;ReceivedMessage&gt;&lt;SentBy&gt;TOTVSMONITOR&lt;/SentBy&gt;&lt;UUID&gt;dee8c4da-1e19-4b44-df97-249443638a9d&lt;/UUID&gt;&lt;MessageContent&gt;&lt;![CDATA[&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt;&lt;TOTVSMessage&gt;&lt;MessageInformation version=&quot;1.000&quot;&gt;&lt;UUID&gt;dee8c4da-1e19-4b44-df97-249443638a9d&lt;/UUID&gt;&lt;Type&gt;BusinessMessage&lt;/Type&gt;&lt;Transaction&gt;WHOIS&lt;/Transaction&gt;&lt;StandardVersion&gt;1.000&lt;/StandardVersion&gt;&lt;SourceApplication&gt;TOTVSMONITOR&lt;/SourceApplication&gt;&lt;CompanyId&gt;18&lt;/CompanyId&gt;&lt;BranchId&gt;D MG 01&lt;/BranchId&gt;&lt;Product name=&quot;TOTVSMONITOR&quot; version=&quot;1.000&quot;&gt;&lt;/Product&gt;&lt;GeneratedOn&gt;2015-11-26T10:55:23&lt;/GeneratedOn&gt;&lt;DeliveryType&gt;Sync&lt;/DeliveryType&gt;&lt;/MessageInformation&gt;&lt;BusinessMessage&gt;&lt;BusinessRequest&gt;&lt;Operation&gt;WhoIs&lt;/Operation&gt;&lt;/BusinessRequest&gt;&lt;BusinessContent&gt;&lt;/BusinessContent&gt;&lt;/BusinessMessage&gt;&lt;/TOTVSMessage&gt;]]&gt;&lt;/MessageContent&gt;&lt;/ReceivedMessage&gt;&lt;ProcessingInformation&gt;&lt;ProcessedOn&gt;2016-09-27T17:05:16Z&lt;/ProcessedOn&gt;&lt;Status&gt;ok&lt;/Status&gt;&lt;/ProcessingInformation&gt;&lt;ReturnContent&gt;&lt;EnabledTransactions&gt;&lt;Transaction&gt;&lt;Name&gt;WHOIS&lt;/Name&gt;&lt;Version&gt;1.001 &lt;/Version&gt;&lt;Mode&gt;both_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;Transaction&gt;&lt;Name&gt;MYMESSAGE&lt;/Name&gt;&lt;Version&gt;1.000 &lt;/Version&gt;&lt;Mode&gt;send_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;Transaction&gt;&lt;Name&gt;COSTCENTER&lt;/Name&gt;&lt;Version&gt;2.000 &lt;/Version&gt;&lt;Mode&gt;both_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;Transaction&gt;&lt;Name&gt;FINANCIALNATURE&lt;/Name&gt;&lt;Version&gt;2.000 &lt;/Version&gt;&lt;Mode&gt;both_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;Transaction&gt;&lt;Name&gt;ACCOUNTRECEIVABLEDOCUMENTDISCHARGE&lt;/Name&gt;&lt;Version&gt;2.001 &lt;/Version&gt;&lt;Mode&gt;both_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;Transaction&gt;&lt;Name&gt;CUSTOMERVENDOR&lt;/Name&gt;&lt;Version&gt;2.002 &lt;/Version&gt;&lt;Mode&gt;both_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;Transaction&gt;&lt;Name&gt;BANK&lt;/Name&gt;&lt;Version&gt;1.007 &lt;/Version&gt;&lt;Mode&gt;both_enabled&lt;/Mode&gt;&lt;/Transaction&gt;&lt;/EnabledTransactions&gt;&lt;/ReturnContent&gt;&lt;/ResponseMessage&gt;&lt;/TOTVSMessage&gt;</RECEIVEMESSAGERESULT>
        </RECEIVEMESSAGERESPONSE>
    </soap:Body>
</soap:Envelope>

Âncora
simulação simulação

Message Simulation

Este serviço disparar, a partir de um XSD de mensagem padronizada previamente configurado no monitor, uma mensagem SOAP para um produto destino.

Um novo evento de mensagem será criado aos já existentes (existentes hoje: upsert e delete ). O novo tipo, simulation, será utilizado para que os adapters não realizem a gravação dos dados e o disparo de algumas regras de negócio, quando não aplicáveis.

As áreas de negócio TOTVS serão as responsáveis por criar os métodos de simulação dentro dos adapters já existentes. Desta maneira, adapters que já existem terão, até serem adequados para este serviço, simulação não disponível (erro FW008)..

O monitor deverá ser capaz de prever os retornos de mensagem tanto no formato da Mensagem Padronizada quanto por SoapFault.

Erros de simulação gerados dentro do adapters deverão ser trafegados em formato da Mensagem Padronizada TOTVS.

Alguns códigos de erro podem ser utilizados para o retorno desta mensagem. Os códigos de erro podem ser encontrados aqui.

O monitor irá validar também o retorno da mensagem contra o XSD.

O monitor irá validar somente mensagens síncronas, já que a simulação requer um retorno imediato.

Fluxo do serviço:

Exemplo de envio de simulation

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tot="http://www.totvs.com/">
   <soapenv:Header/>
   <soapenv:Body>
      <tot:receiveMessage>
         <tot:inMsg><![CDATA[<?xml version="1.0" encoding="utf-8"?>
<TOTVSMessage>
	<MessageInformation version="2.000">
		<UUID>28b7fad2-7649-cc7d-c197-af60bcbdb85a</UUID>
		<Type>BusinessMessage</Type>
		<Transaction>FINANCIALNATURE</Transaction>
		<StandardVersion>1.000</StandardVersion>
		<SourceApplication>TOTVSMonitor</SourceApplication>
		<CompanyId>18</CompanyId>
		<BranchId>D MG 02 </BranchId>
		<Product name="TOTVSMonitor" version="12"/>
		<GeneratedOn>2016-11-18T20:27:44Z</GeneratedOn>
		<DeliveryType>sync</DeliveryType>
	</MessageInformation>
	<BusinessMessage>
		<BusinessEvent>
			<Entity>FinancialNature</Entity>
			<Event>simulation</Event>
			<Identification>
				<key name="InternalId">18|D MG 02 |VALE00001F</key>
			</Identification>
		</BusinessEvent>
		<BusinessContent>
			<CompanyId>18</CompanyId>
			<BranchId>D MG 02 </BranchId>
			<CompanyInternalId>18|D MG 02 </CompanyInternalId>
			<InternalId>18|D MG 02 |VALE00001F</InternalId>
			<Code>VALE00001F</Code>
			<Description>CREDITO                       </Description>
			<NatureType>Analytical</NatureType>
			<UseCategory>Receivable</UseCategory>
			<Blocked>0</Blocked>
		</BusinessContent>
	</BusinessMessage>
</TOTVSMessage>]]></tot:inMsg>
      </tot:receiveMessage>
   </soapenv:Body>
</soapenv:Envelope>

Tarefas de diagnóstico

O objetivo desta seção é demonstrar como cumprir tarefas de diagnóstico do EAI através dos serviços disponibilizados.  A tarefa é descrita como tópico principal, e os passos para cumpri-la são descritos como subtópicos.

Os seguintes "placeholders" são utilizados nas URLs abaixo:

<URL_monitor_local_REST>: Refere-se à URL base dos serviços REST de monitoramento na instalação do aplicativo interno.

<URL_monitor_externo_REST>: Refere-se à URL base dos serviços REST de monitoramento na instalação do aplicativo externo.

<URL_EAI_interno_SOAP>: Refere-se à URL base dos serviços EAI que são consumidos no aplicativo interno.

<URL_EAI_externo_SOAP>: Refere-se à URL base dos serviços EAI que são consumidos no aplicativo externo.

1. Conectar-se como um aplicativo no monitor
2. Verificar quais empresas/grupo de empresas e filiais estão associadas à aquele aplicativo
   1. GET <URL_monitor_local_REST>/totvseai/monitor/v2/admin/companies?externalAppID=<id_aplicativo_interno>&companyID={companyID}&branchID={branchId}&page={page}&pageSize={pageSize}, para identificar os aplicativos que fazem integração com o aplicativo interno.
3. Verificar a integridade dos de-para de empresas entre os aplicativos obtidos.
   1. GET <URL_monitor_externo_REST>/totvseai/monitor/v1/admin/healthcheck/mappings/<app_interno>?mappingValue=<empr_interna>|<filial_interna>&mappingID=CompanyInternalID
   2. realizar a chamada do método para cada empresa do aplicativo selecionado.
4. Verificar as transações habilitadas no aplicativo interno
   1. GET  <URL_monitor_local_REST>/totvseai/monitor/v1/apps/<app_interno>/transactions?page={page}&pageSize={pageSize} para buscar as informações dos aplicativos habilitados no aplicativo interno.
5. Verificar a integridade das transações frente ao aplicativo externo

   1. GET <URL_monitor_externo_REST>/totvseai/monitor/v2/admin/healthcheck/transactions/EAI?targetAppID=<App_interno>&version={version}&supportedMode={supportedMode}&enabledMode={enabledMode}, verificando, para cada transação, se a mesma está correta na visão do EAI;

   2. GET <URL_monitor_externo_REST>/totvseai/monitor/v1/admin/healthcheck/transactions/business?targetAppID=<app_interno>&version={version}&supportedMode={supportedMode}&enabledMode={enabledMode}, verificando, na camada de negócio, se as transações estão cadastradas de maneira correta.

6. Verificar a integridade da integração, observando o aplicativo como um todo
   1. GET <URL_monitor_externo_REST>/totvseai/monitor/v2/admin/healthcheck/settings, observando  o retorno do método.
7. Verificar se o serviço de integração está operando corretamente.
   1. GET <URL_EAI_interno_SOAP>, verificando se o serviço de EAI interno está acessível pelo monitor.
   2. GET <URL_EAI_externo_SOAP>, verificando se o serviço de EAI externo está acessível pelo monitor.
   3. GET <URL_EAI_interno_REST>/totvseai/monitor/v2/admin/healthcheck/wsintegration/<app_externo>/{companyID}/{branchID}, para verificar se o aplicativo interno consegue se comunicar com o aplicativo externo.
   4. GET <URL_EAI_externo_REST>/totvseai/monitor/v2/admin/healthcheck/wsintegration/<app_interno>/{companyID}/{branchID}, para verificar se o aplicativo externo consegue se comunicar com o aplicativo interno.
8. Verificar se é possível autenticar e receber uma mensagem do monitor.
   1. POST <URL_EAI_interno_SOAP>, verificando se o aplicativo interno consegue receber e retornar o post.
   2. POST <URL_EAI_externo_SOAP>, verificando se o aplicativo externo consegue receber e retornar o post.
9. Verificar a simulação da mensagem
   1. POST <URL_EAI_externo_SOAP>, verificando se a mensagem foi processada com sucesso.
10. Verificar se existem mensagens processadas em um aplicativo, mas pendentes de envio em outro aplicativo (normalmente por time-out).
    1. Buscar as mensagens com status de notDelivered e waitingConnection no aplicativo externo:
       1. GET <URL_EAI_externo_SOAP>/totvseai/monitor/v1/msgs/list?sourceApp={sourceApp}&status=notDelivered;waitingConnection
    2. A partir dos UUIDs retornados buscar, no aplicativo interno, as mensagens através:
       1. GET <URL_EAI_interno_SOAP>/ /totvseai/monitor/v1/msgs/{msgUUID}
    3. Apresentar, no monitor, as mensagens com status divergentes entre os sistemas.

Âncora
Codigos de erro Codigos de erro

 Códigos de erro padrão criados para o serviço de diagnóstico