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 disponibilizados pelos produtos deverão atender os seguintes pré-requisitos:

• Plataforma com suporte a REST e autenticação ;
• 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

Todas as linhas de produto deverão definir uma URL base, a partir da qual os serviços REST do monitor de EAI serão disponibilizados. Todos os caminhos descritos neste documento serão relativos a esta URL base, conforme a especificação de requisitos 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á características diferentes da API de monitoramento definida no documento ER_FRWJOI01-3_Serviços_para_monitoramento_de_EAI. 

Os objetos de retorno dos métodos REST seguem o retorno especificado no requisito ER_FRWJOI01-3_Serviços_para_monitoramento_de_EAI. 

Todas as linhas de produto deverão disponibilizar no monitor os caminhos dos serviços do EAI de seus produtos.

Todos os parâmetros de query string page e perPage, quando não especificados, assumem o 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 aplicativos (produtos)

GET /totvseai/

diagnosis/v1/

companies

?page={page}&

pageSize={

page}

Este método lista as empresas cadastradas no aplicativo interno. Com essa lista, será possível verificar, nos aplicativos externos, se cada uma das empresas possui valor de de-para correspondente. Embora o nome do método sugira diferente, a lista retornada conterá empresa e filial/estabelecimento, nos caso onde se aplicar, já que para compor um identificador de de-para, as duas informações são utilizadas.

O método deve respeitar as definições de paginação e ordenação definidas pelo guia de implementação de APIs da TOTVS (Guia de implementação das APIs TOTVS#Cole%C3%A7%C3%B5es), assim como os retornos, em caso de falha, devem seguir as orientações do documento citado (Guia de implementação das APIs TOTVS#Mensagensdeerro).

Exemplos de retorno

• Exemplo padrão, supondo que seja o Protheus retornando informações.

{
	"hasNext" : false,
	"items" : [{
		"companyID" : "99",
		"branchID" : "01"
	},
	{
		"companyID" : "99",
		"branchID" : "02"
	}]
}

• Para o Logix, que não tem filial, o atributo "branchID" virá em branco.

{
	"hasNext" : true,
	"items" : [{
		"companyID" : "AA",
		"branchID" : ""
	},
	{
		"companyID" : "AB",
		"branchID" : ""
	},
	{
		"companyID" : "AC",
		"branchID" : ""
	}]
}

• Exemplo do RM retornando informações.

{
    "hasNext": true,
    "items": [
        {

Busca de empresas e filiais associadas (De-para de empresas)

Este método lista os de-para de empresas do aplicativo interno.

Caso o parâmetro targetAppID seja enviado, é buscado a informação do relacionamento somente para o aplicativo em questão. Caso contrário, é buscado todas as informações dos aplicativos disponiveis (no Protheus uma mesma instalação pode possuir mais de um aplicativo, pois cada Grupo de empresas Protheus comporta um aplicativo).

É possível buscar informações de um aplicativo externo a partir de um aplicativo interno (realizar a busca no Protheus somente das empresas associadas ao RM, por exemplo)

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

Retorno esperado:

• targetAppID - Identificador do aplicativo interno (ex.PRODUCAO18@PROTHEUS)
• product - Nome do Produto interno (ex. PROTHEUS)
• companies - Array de objetos, onde cada objeto possui os atributos:
  • company - Empresa ou grupo de empresas (Protheus) do produto buscado
  • branch - Filial do produto buscado
  • integratedProducts  - Array de objetos, sendo
  • targetAppID - Identificador do aplicativo externo (Ex. PRODUCAO)
  • product - Identificador do produto externo (Ex. RM)
  • company - Empresa ou grupo de empresas (Protheus) associado
  • branch - Filial associado ao produto externo.

Exemplo de retorno

{
  "messages": [],
  "length": 2,
  "data": [
    {
      "targetAppID": "PRODUCAO18",
      "product": "PROTHEUS",
      "companies": [
        {
          "company": "18",
          "branch": "D MG 01",
          "integratedProducts": [
            {
              "targetAppID": "AMBIENTE",
              "product": "RM",
              "companycompanyId": "011",
              "branchbranchId": "011"
            },
            {
              "targetAppIDcompanyId": "AMBX1",
              "productbranchId": "DATASUL2",
        },
      "company": "1",  {
              "branchcompanyId": "101",
            }
          ]"branchId": "3"
        },
        {
            "companycompanyId": "181",
            "branchbranchId": "D RJ 014",
          "integratedProducts": [},
            {
              "targetAppIDcompanyId": "AMBIENTE1",
              "productbranchId": "RM5",
        }
      "company": "01",
              "branch": "02"
            },
            {
              "targetAppID": "AMBX",
              "product": "DATASUL",
              "company": "1",
              "branch": "11"
            }
          ]
        }
      ]
    },
    {
      "targetAppID": "PRODUCAO19",
      "product": "PROTHEUS",
      "companies": [
        {
          "company": "19",
          "branch": "D MG 01",
          "integratedProducts": [
            {
              "targetAppID": "AMBIENTE",
              "product": "RM",
              "company": "02",
              "branch": "02"
            }
          ]
        }
      ]
    }
  ]
}

Exemplo de retorno

{
	"messages" : [],
	"length" : 1,
	"data" : {
		"targetAppID" : "PRODUCAO19",
		"product" : "PROTHEUS",
		"companies" : [{
				"company" : "19",
				"branch" : "D MG 01",
				"integratedProducts" : [{
						"targetAppID" : "AMBIENTE",
						"product" : "RM",
						"company" : "02",
						"branch" : "02"
					}
				]
			}
		]
	}
}

O método GET /totvseai/monitor/v1/apps/{targetAppID}/transactions?page={page}&perPage={perPage}  já criado para o monitor EAI será alterado, e um novo atributo será incluído no JSON:

• availableVersions - Indica as versões disponíveis para configuração da transação em questão. As diferentes versões disponíveis serão separadas por ";".

  Bloco de código
  language java title Exemplo de retorno de JSON
  { "messages" : [], "length" : 1, "data" : [{ "transactionID" : "order", "version" : "2.000", "supportedMode" : "both_enabled", "enabledMode" : "both_enabled", "allowAnonymous" : false, "includeOriginalMsg" : false "availableVersions" : "1.000;1.001" } ] }

]
}

Â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/diagnosis/v1/mappings/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:

• hasNext - indica se há mais itens além dos retornados na resposta.
• items- Array de objetos, onde cada objeto possui os seguintes atributos:
  • appID - Identificador do aplicativo interno (ex.PRODUCAO18@PROTHEUS).
    
  • companyID - Empresa ou grupo de empresas (Protheus) do aplicativo interno.
  • branchID - Filial do aplicativo interno.
  • integratedProducts  - Array de objetos, sendo:
    • 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.

Image Added

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 FE010);
• Não existir registros de "de-para" de empresa para o aplicativo externo informado (externalAppID) (código FE009);
• Não existir registros de "de-para" com o companyID ou branchID informados (FE007).

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.

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

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

{
	"hasNext": true,
	"items": [{
		"appID": "PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D MG 01",
		"integratedProducts": [{
			"externalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "01"
		}]
	},
	{
		"appID": "PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D RJ 01",
		"integratedProducts": [{
			"externalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "02"
		}]
	}]
}

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

{
	"hasNext": true,
	"items": [{
		"appID": "PRODUCAO18@PROTHEUS",
		"companyID": "18",
		"branchID": "D MG 01",
		"integratedProducts": [{
			"extenalAppID": "AMBIENTE@RM",
			"companyID": "01",
			"branchID": "01"
		},
		{
			"externalAppID": "AMBX@DATASUL",
			"companyID": "1",
			"branchID": "10"
		}]
	}]
}

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

{
    "hasNext": false,
    "items": [
        {
            "appId": "RM@RM",
            "companyId": "2",
            "branchId": "2",
            "integratedProducts": [
                {
                    "externalAppId": "P12_17@PROTHEUS",
                    "companyId": "19",
                    "branchId": "D RJ 01"
                }
            ]
        },
        {
            "appId": "RM@RM",
            "companyId": "1",
            "branchId": "1",
            "integratedProducts": [
                {
                    "externalAppId": "P12_17@PROTHEUS",
                    "companyId": "20",
                    "branchId": "D MG 01"
                },
                {
                    "externalAppId": "P12_1718@PROTHEUS",
                    "companyId": "20",
                    "branchId": "D MG 01"
                },
                {
                    "externalAppId": "P12_1718@DATASUL",
                    "companyId": "33",
                    "branchId": "D MG 01"
                }
            ]
        },
        {
            "appId": "RM@RM",
            "companyId": "15",
            "branchId": "15",
            "integratedProducts": [
                {
                    "externalAppId": "P12_1718@DATASUL",
                    "companyId": "20",
                    "branchId": "D MG 01"
                }
            ]
        }
    ]
}

• Obtendo todos os "de-para" de empresa do aplicativo interno para a empresa "1" e filial "1" no RM.

{
    "hasNext": false,
    "items": [
        {
            "appId": "RM@RM",
            "companyId": "1",
            "branchId": "1",
            "integratedProducts": [
                {
                    "externalAppId": "P12_17@PROTHEUS",
                    "companyId": "20",
                    "branchId": "D MG 01"
                },
                {
                    "externalAppId": "P12_1718@PROTHEUS",
                    "companyId": "20",
                    "branchId": "D MG 01"
                },
                {
                    "externalAppId": "P12_1718@DATASUL",
                    "companyId": "33",
                    "branchId": "D MG 01"
                }
            ]
        }
    ]
}

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

{
    "hasNext": false,
    "items": [
        {
            "appId": "RM@RM",
            "companyId": "2",
            "branchId": "2",
            "integratedProducts": [
                {
                    "externalAppId": "P12_17@PROTHEUS",
                    "companyId": "19",
                    "branchId": "D RJ 01"
                }
            ]
        },
        {
            "appId": "RM@RM",
            "companyId": "1",
            "branchId": "1",
            "integratedProducts": [
                {
                    "externalAppId": "P12_17@PROTHEUS",
                    "companyId": "20",
                    "branchId": "D MG 01"
                }
            ]
        }
    ]
}

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 de erro, 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.
  • eaiInternalMessages - objeto contendo:
    
    • send: InternalID de envio.
    • received: InternalID de recebimento.

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

Image Added

Exemplo de utilização:

Diagnóstico dispara uma requisição de 'healthcheck' ao Protheus solicitando validação da integração com o RM, onde o mesmo irá disparar a mensagem WhoIs para o RM e retornar as informações previstas com sucesso.

{
	"originAppID" : "PRODUCAO18@PROTHEUS",
	"destinationAppID" : "RM@RM",
	"originCompany" : "18",
	"originBranch" : "D MG 01",
	"messages" : [],
	"eaiInternalMessages" : {
    	sent: "231465-32135432-146546465",
    	received: "231465-32135432-146546465" 
    }
}

Diagnóstico dispara uma requisição de 'healthcheck' ao RM solicitando validação da integração com o Protheus, onde o mesmo irá disparar a mensagem WhoIs para o Protheus e retornar as informações previstas com sucesso.

{
    "originAppID": "RM@RM",
    "destinationAppID": "P12_17@PROTHEUS",
    "originCompany": "1",
    "originBranch": "1",
    "messages": []
}

Diagnóstico dispara uma requisição de 'healthcheck' ao RM solicitando validação da integração com o Protheus, onde o mesmo irá disparar a mensagem WhoIs para o Protheus e retornar os erros encontrados.

{
    "originAppID": "",
    "destinationAppID": "P12_17@PROTHEUS",
    "originCompany": "1",
    "originBranch": "1",
    "messages": [
        {

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 na origem da requisição. Por exemplo, o monitor quer validar informações colhidas no RM e validar contra 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, informações de validações das rotas não serão verificadas.

Os parâmetros version, supportedMode, enabledMode, allowAnonymous, includeOriginalMsg e availableVersions, opcionais, quando enviados farão a consistência de uma transação (adapter) cadastrado em um aplicativo A contra um aplicativo B. Os valores permitidos para estes dados seguem os valores do retorno do método  GET /totvseai/monitor/v1/apps/{targetAppID}/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.

O envio destes parâmetros é opcional pois existem validações internas que independem do cadastro de outro sistema. 

JSON de retorno esperado:

• transactionID - Identificador da transação
• messages   - Array de objetos, contendo as mensagens pertinentes a transação:
  • code - codigo do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. São listados novos status para o serviço de monitoramento. Caso o código de erro seja omitido, somente o valor do atributo text é apresentado como um status de erro. Caso o atributo text também não seja enviado, um erro genérico será apresentado. Os códigos de erro podem ser encontrados aqui.
  • text  - Texto opcional, que pode ser acrescido as 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.

 {
	"messages" : [],
	"length" : 1,
	"data" : {
		"transactioID" : "order",
		"messages" : [{
				"code" : "FW006"
				"text" : "Filial de execução - 001"
			}
		]
	}
}

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 na origem da requisição. Por exemplo, o monitor quer validar informações colhidas no RM e validar contra 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, informações de validações das rotas não serão verificadas.

Os parâmetros version, supportedMode, enabledMode, allowAnonymous, includeOriginalMsg e availableVersions, opcionais, quando enviados farão a consistência de uma transação (adapter) cadastrado em um aplicativo A contra um aplicativo B. Os valores permitidos para estes dados seguem os valores do retorno do método  GET /totvseai/monitor/v1/apps/{targetAppID}/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.

O envio destes parâmetros é opcional pois existem validações internas que independem do cadastro de outro sistema. 

As áreas de negócio deverão ser responsáveis por permitir ou não validação de terceiros (customizações) em suas rotinas.

JSON de retorno esperado:

• transactionID - Identificador da transação
• messages   - Array de objetos, contendo as mensagens pertinentes a transação:
  • code - codigo do erro, para padronização das mensagens de erro identificadas. Estes erros seguem o padrão das mensagens de erro do EAI TOTVS. São listados novos status para o serviço de monitoramento. Caso o código de erro seja omitido, somente o valor do atributo text é apresentado como um status de erro. Caso o atributo text também não seja enviado, um erro genérico será apresentado.
  • text  - Texto opcional, que pode ser acrescido as 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.

Caberá a cada framework como identificar a melhor maneira possível de realizar as chamadas as validações de cada área de negócio envolvida na integração.

No Protheus os adapters serão chamados e os dados recebidos na requisição REST serão repassados para cada um dos adapters, que serão responsáveis por realizar as validações internas necessárias. Caso não haja tratamento para a CHECKINTEGRITY é assumido que não existe validação necessária para o adapter.

O retorno esperado segue o proposto pelo método /totvseai/monitor/v1/admin/healthcheck/checktransactions/EAI?targetAppID={targetAppID}&transactionId={transactionID}&version={version}&supportedMode={supportedMode}&enabledMode={enabledMode}&allowAnonymous={allowAnonymous}&includeOriginalMsg={includeOriginalMsg}&availableVersions={availableVersions}

{
	"messages" : [],
	"length" : 1,
	"data" : [{
			"transactioID" : "financing",
			"messages" : [{
					"code" : ""
					"text" : "É necessário configurar o parâmetro MV_MULNATP e MV_MULNATR na integração com o TOTVS Incorporações."
				}
			]
		}
	]
}

Este serviço verifica a integridade dos mapeamentos de empresa/filial entre o aplicativo origem e destino

Somente o parâmetro branchID é opcional.

O JSon esperado por este método deve possuir os atributos a seguir:

• origintargetAppID - targetAppID que se deseja verificar a integração.
• originCompany - Empresa ou grupo originais enviados
• originBranch - Filial enviada
• destinationCompany  - Empresa ou grupo do destino
• destinationBranch  - Filial do destino
• messages  - array de objetos, contendo:
  • code - Código do erro associado.
  • text - texto adicional a ser enviado.

 {
	"messages" : [],
	"length" : 1,
	"data" : {
		"originCompany" : "01",
		"originBranch" : "05"
		"destinationCompany" : "18"
		"destinationBranch" : "D MG 01"
		"messages" : [{
				"code" : "FI001"
				"text" : ""
			}
		]
	}
}

 {
	"messages" : [],
	"length" : 1,
	"data" : {
		"originCompany" : "01",
		"originBranch" : "01"
		"destinationCompany" : ""
		"destinationBranch" : ""
		"messages" : [{
				"code" : "FE009"
				"text" : ""
			}
		]
	}
}

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.

O parâmetro companyID recebe o valor da empresa/grupo de empresas.

o parâmetro branchID é opcional, e recebe o valor da filial buscada.

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

{
	"messages" : [],
	"length" : 1,
	"data" : {
		"origintargetAppID" : "PRODUCAO18@PROTHEUS",
		"destinationtargetAppID" : "RM@RM",
		"originCompany" : "18",
		"originBranch" : "D MG 01",
		"messages" : [{
				"code" : "F001"
				"text" : ""
			}
		]
	}
}

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 Única já existentes nos produtos. Eles tem como originador o Monitor Totvs EAI e tem como destino os serviços de EAI dos aplicativos cadastrados.

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.

GET http://localhost:8080/eaiservice.apw

<?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">
            "code": "EI002",
   <s:complexType>
         "message": "Erro",
            <s"detailedMessage":sequence>
 "Host não configurado na instalação do EAI."
        },
        {
 <s:element minOccurs="1" maxOccurs="1" name="INMSG" type="s:string" />
      "code": "EI003",
             </s:sequence>"message": "Erro",
            "detailedMessage": "Erro não  </s:complexType>
            </s:element>
            <s:element name="RECEIVEMESSAGERESPONSE">previsto: \r\nErro ao gerar WSDL do endereço \"http://10.80.129.107:8088/EAISERVICE.apw?WSDL\"!\r\nUUID: e15660ec-894d-478f-bdc1-9b2ad38a2d65\r\n"
        }
    ]
}

Âncora
settings settings

GET /totvseai/diagnosis/v1/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, ou ainda se há um servidor RPW corretamente configurado para processar a fila de mensagens assíncronas.

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:

Image Added

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" : "FE006"
		"message" : "Configuração inválida",
		"detailedMessage" : "Sessão WEBSERVICES não foi encontrada no arquivo TotvsAppServer.ini"
	}
]}

• Retorno supondo o monitor instalado no RM:

{
	"appID" : "RM@RM",
	"messages" : [{
		"code" : "FE006"
		"message" : "Configuração inválida",
		"detailedMessage" : "Job de processamento da fila não está configurado."
	}]
}

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:

Image Added

<?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: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<s:schema nameelementFormDefault="EAISERVICESOAPqualified" bindingtargetNamespace="s0:EAISERVICESOAPhttp://www.totvs.com/">
            <soap<s:addresselement location="http://172.16.32.191:89/pr12_bra/eai/EAISERVICE.apw" />
name="RECEIVEMESSAGE">
               </port> <s:complexType>
    </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).

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

A mensagem única 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.

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.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tot="http://www.totvs.com/">
   <soapenv:Header/>
   <soapenv:Body>
      <tot:receiveMessage>
                <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>
                        <tot:inMsg><![CDATA[
<?xml version<s:element minOccurs="1" maxOccurs="1.0" encodingname="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 Única 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>
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" />
            <RECEIVEMESSAGERESPONSE<output xmlnsmessage="https0://www.totvs.com/"RECEIVEMESSAGESOAPOUT" />
        </operation>
    <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>

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.

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

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

</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:

Image Added

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

Image Added

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 serão realizadas as tarefas de diagnóstico do EAI através dos serviços disponibilizados.  Nessa seção serão descritos também os comportamentos esperados pela interface de diagnóstico.

Iniciando o diagnóstico geral

O fluxo abaixo demonstra as tarefas que devem ser realizadas na interface de diagnóstico, para que os aplicativos externos registrados sejam exibidos. A partir da lista obtida, o usuário poderá escolher qual aplicativo externo deseja diagnosticar.

Image Added

A implementação das tarefas acima está detalhada pelo diagrama de sequência abaixo. O endpoint a ser consumido pela tela de Diagnóstico Geral pertence a API de configuração do EAI, que já segue o padrão da TOTVS.

Image Added

O fluxo seguinte mostra as etapas previstas para a validação de um aplicativo externo selecionado na lista. Os dados obtidos em cada uma das etapas de validação serão armazenados para posterior exibição, a medida que o usuário navega nas telas de diagnóstico.

Image Added

Validação de de-para de empresas

O fluxo a seguir detalha a 1a etapa do fluxo anterior. Os de-para de empresas tem um papel tão relevante para a integração, que merecem um processo próprio de verificação.

Image Added

A implementação das tarefas acima é descrita pelo diagrama de sequência a seguir. Do aplicativo interno serão obtidas as empresas cadastradas, que serão pesquisadas na tabela de de-para de empresas do aplicativo externo selecionado.

Image Added

Validação de de-para diversos

O fluxo abaixo descreve as tarefas da 2a etapa de validação de um aplicativo externo.

Image Added

A implementação das tarefas do fluxo é descrita pelo diagrama abaixo. Os endpoints utilizados para obtenção dos valores de de-para das demais entidades são os definidos pela API de monitoramento. A verificação dos de-paras ocorrerá efetivamente na interface de diagnóstico.

Image Added

Validação de transações

A 3a etapa de validação do aplicativo externo contempla as transações e rotas. As tarefas previstas estão descritas no fluxo a seguir.

Image Added

Os endpoints necessários a realização das tarefas acima estão referenciados no diagrama de sequência abaixo. Estão sendo utilizados os endpoints de configuração, que já se encontram no padrão de APIs da TOTVS.

Image Added

Processo de verificação das transações

• Validar se a transação de um aplicativo existe no outro aplicativo. Caso não exista, deve-se registrar o código FE005 (A transação não está cadastrada no aplicativo), complementada com o nome do aplicativo consultado que não possui a transação;
• Existindo transação, verificar se as versões da transação de um aplicativo existem no outro aplicativo (ver item verificação de versão/release, logo abaixo). Deve-se registrar o código FE002 (Transação com versões incompatíveis) em caso de incompatibilidade. Em caso de compatibilidade parcial, deve-se registrar o código FW007 (Transação com releases diferentes).
• Se o modo habilitado da transação/versão de um aplicativo é compatível com o modo habilitado do outro aplicativo (ver item compatibilidade de modos, tabela logo abaixo), deve-se registrar 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.

Validação de web service pelo ERP

As tarefas de validação do web service pelo ERP estão demonstradas no fluxo a seguir. O trabalho de validação será realizado pelo ERP (back-end), cabendo à interface de diagnóstico mostrar o resultado retornado pelo endpoint.

Image Added

Abaio, diagrama de implementação do fluxo.

Image Added

Validação de web service pelo Monitor

As tarefas de teste do web service pelo monitor estão indicadas abaixo. Será necessário que a interface de diagnóstico forneça meios para que o usuário indique o login e senha para autenticar no web service de recebimento do aplicativo externo.

Image Added

Para implementação, considerar o diagrama abaixo.

Image Added

Âncora
Codigos de erro Codigos de erro

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

diagnóstico

Código reservados de Framework	Definição

FE005A transação recebida não está cadastrada neste destino.FE006A transação recebida não está cadastrada neste destino para recebimento.FE007A transação recebida não está cadastrada neste destino para envio.FE008Transações com versões diferentes (incompatíveis)FE009

FE002	Incompatibilidade de versões da mensagem única.
FE005	Transação não está cadastrada no aplicativo consultado
FE006	Configuração inválida (usada para indicar problemas de configuração no diagnóstico).
FE007	Empresa/grupo e filial não parametrizados para integração

.FE010

FE008	Erro no envio da mensagem a outro sistema
FE009	Não existe valor de de-para associado
FE010	Não há registros de de-para no aplicativo
FE011	Envio não é possível em ambos os sentidos
FE012	De-para não está registrado no aplicativo.
FW001	Mensagem cadastrada como assíncrona, mas cadastrada como síncrona no destino

.

FW002	Mensagem cadastrada como síncrona, mas cadastrada como assíncrona no destino

.

FW003	Mensagem somente habilitada para eventos de upsert

.

FW004	Mensagem habilitada somente para eventos de delete

.

FW005

Mensagem com condição de envio e recebimento habilitada

Envio possível em apenas um sentido.
FW006	Mensagem somente executada em uma filial

.

FW007

Transações

Transação com releases diferentes

.

FW008	Esta versão de Mensagem Padronizada não possui serviço de Simulation disponível
FI001	Validado

.

com sucesso
FI002	Mensagem com validação de XSD

.