Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Especificação | |||||||||||||||||||
Produto | TOTVS | Módulo | EAI | ||||||||||||||||
Segmento Executor | Framework | ||||||||||||||||||
Projeto1 | FRAMEWORK SP - 005 | IRM1 |
| ||||||||||||||||
Requisito1 |
| Subtarefa1 |
| ||||||||||||||||
País | ( ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( X ) TODOS. | ||||||||||||||||||
Outros |
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
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.
Os serviços de diagnósticos disponibilizados pelos produtos deverão atender os seguintes pré-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á 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.
Índice minLevel 3
Âncora | ||||
---|---|---|---|---|
|
Recebe | externalAppID - string - query param |
companyID - string - query param | |
branchID - string - query param | |
page - int - query param | |
pageSize - int - query param | |
Retorna | Application/JSON |
Este método lista os de-para de empresa e filial de um aplicativo interno (identificador do de-para igual a "CompanyInternalID"). Caso o parâmetro externalAppID seja 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:
Dica | ||
---|---|---|
| ||
De acordo com o Guia de implementação das APIs TOTVS, este endpoint deve suportar ordenação, ou seja, permitir o parâmetro de query "order". Neste caso, os atributos que podem ser usados para organizar a lista de de-para retornada são companyID e branchID, situados no 1o nível, appID e productCode, situados no 2o nível (abaixo de integratedProducts). A ordenação pode combinar quaisquer atributos, por exemplo, "order=companyID,branchID,-appID" ou "order=branchID,appID,-productCode". |
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 aplicativo.
Legenda: (seta verde) requisição de origem; (seta vermelha) resposta da requisição.
O método deve retornar os códigos de erro indicados abaixo, bem como o código HTTP 404 (Not found) quando:
O formato do corpo da resposta deve estar conforme especificado no Guia de implementação das APIs TOTVS. Ou seja:
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "appID": "PRODUCAO18", "productCode": "PROTHEUS", "hasNext": false, "items": [{ "companyID": "18", "branchID": "D MG 01", "integratedProducts": [{ "appID": "AMBIENTE", "productCode": "RM", "companyID": "01", "branchID": "01" }, { "appID": "AMBX", "productCode": "DATASUL", "companyID": "1", "branchID": "10" }] }, { "companyID": "18", "branchID": "D RJ 01", "integratedProducts": [{ "appID": "AMBIENTE", "productCode": "RM", "companyID": "01", "branchID": "02" }, { "appID": "AMBX", "productCode": "DATASUL", "companyID": "1", "branchID": "11" }] }] } |
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "appID": "PRODUCAO18", "productCode": "PROTHEUS", "hasNext": true, "items": [{ "companyID": "18", "branchID": "D MG 01", "integratedProducts": [{ "appID": "AMBIENTE", "productCode": "RM", "companyID": "01", "branchID": "01" }] }, { "companyID": "18", "branchID": "D RJ 01", "integratedProducts": [{ "appID": "AMBIENTE", "productCode": "RM", "companyID": "01", "branchID": "02" }] }] } |
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "appID": "PRODUCAO18", "productCode": "PROTHEUS", "hasNext": true, "items": [{ "companyID": "18", "branchID": "D MG 01", "integratedProducts": [{ "appID": "AMBIENTE", "productCode": "RM", "companyID": "01", "branchID": "01" }, { "appID": "AMBX", "productCode": "DATASUL", "companyID": "1", "branchID": "10" }] }] } |
Âncora | ||||
---|---|---|---|---|
|
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.
Aviso | ||
---|---|---|
| ||
Este endpoint é anterior ao padrão para desenvolvimento de APIs da TOTVS. Por isso, ainda utiliza os parâmetros de paginação page e perPage. Da mesma forma, o retorno do endpoint é diferente do estabelecido pelo padrão de desenvolvimento de APIs. Verifique a especificação do endpoint para mais informações. |
Fluxo de envio para o App Interno:
Fluxo de envio para consulta direto no app externo:
Legenda: (seta verde) requisição de origem; (seta vermelha) resposta da requisição.
Âncora | ||||
---|---|---|---|---|
|
Recebe | targetAppID - string - Query param |
transactionID - string - query param | |
version - string - query param | |
supportedMode - string - query param | |
enabledMode - string - query param | |
Retorna | Application/JSON |
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 corpo do retorno, a mensagem deve informar que o parâmetro é obrigatório.
Os parâmetros version, supportedMode e enabledMode, opcionais, quando enviados farão a consistência de uma transação (adapter) cadastrada 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/{appID}/transactions?page={page}&perPage={perPage}.
Informações | ||
---|---|---|
| ||
O comitê de integrações, a partir de 2017, definiu que todos os EAIs devem permitir o recebimento de mensagens cujo o aplicativo de origem (sourceApplication) não esteja cadastrado no destino, bem como, nas mensagens de retorno, não será mais permitido incluir o conteúdo da mensagem original. Por conta disso, os atributos "allowAnonymous" e "includeOriginalMsg" terão sempre, por definição, os valores "true" e "false", não necessitando ser comparados entre os aplicativos. |
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 (baseado no formato definido no Guia de Implementação das APIs TOTVS):
Fluxo conceitual de envio para o aplicativo interno:
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á:
As transações com mais de uma versão/release tem a seguinte regra de compatibilidade.
Versão/release na origem | Versão/release no destino | Status |
---|---|---|
1.000 | 2.000 | Incompatíveis, pois pode haver mudança estrutural. |
2.000 | 1.000 | Incompatíveis, pois pode haver mudança estrutural. |
1.000 | 1.001 | Compatível. Os campos extras devem ser tratados na release maior. |
2.001 | 2.000 | Compatível. Os campos extras devem ser ignorados pelo destino. |
2.000 | 2.000 | Totalmente compatíveis. |
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.
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:
Modo no aplicativo A | Modo no aplicativo B | Envio de A para B | Envio de B para A | Código e Mensagens Adicionais |
---|---|---|---|---|
not_enabled | not_enabled | Não. Está desabilitada em A. | Não. Está desabilitada em B. | FE013 - Transação desabilitada em ambos os aplicativos. |
not_enabled | send_enabled | Não. Está desabilitada em A. | Não. Está desabilitada em A. | FE013 - Transação desabilitada no aplicativo (A). |
not_enabled | receive_enabled | Não. Está desabilitada em A. | Não. B não permite envio. | FE013 - Transação desabilitada no aplicativo (A). |
not_enabled | both_enabled | Não. Está desabilitada em A. | Não. Está desabilitada em A. | FE013 - Transação desabilitada no aplicativo (A). |
send_enabled | not_enabled | Não. Está desabilitada em B. | Não. Está desabilitada em B. | FE013 - Transação desabilitada no aplicativo (B). |
send_enabled | send_enabled | Não. B não permite recebimento. | Não. A não permite recebimento. | FE013 - Ambos os aplicativos apenas enviam. |
send_enabled | receive_enabled | SIM. | Não. B não permite envio. | FW005 - Envio possível apenas de (A) para (B). |
send_enabled | both_enabled | SIM. | Não. A não permite recebimento. | FW005 - Envio possível apenas de (A) para (B). |
receive_enabled | not_enabled | Não. A não permite envio. | Não. Está desabilitada em B. | FE013 - Transação desabilitada no aplicativo (B). |
receive_enabled | send_enabled | Não. A não permite envio. | SIM. | FW005 - Envio possível de (B) para (A). |
receive_enabled | receive_enabled | Não. A não permite envio. | Não. B não permite envio. | FE013 - Ambos os aplicativos apenas recebem. |
receive_enabled | both_enabled | Não. A não permite envio. | SIM. | FW005 - Envio possível apenas de (B) para (A). |
both_enabled | not_enabled | Não. Está desabilitada em B. | Não. Está desabilitada em B.. | FE013 - Transação desabilitada no aplicativo (B). |
both_enabled | send_enabled | Não. B não permite recebimento. | SIM. | FW005 - Envio possível apenas de (B) para (A). |
both_enabled | receive_enabled | SIM. | Não. B não permite envio. | FW005 - Envio possível apenas de (A) para (B). |
both_enabled | both_enabled | SIM. | SIM. | FI001 - Envio possível em ambos os sentidos. |
Exemplos de retorno da requisição para o aplicativo interno:
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "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.
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "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
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "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
Bloco de código | ||||
---|---|---|---|---|
| ||||
//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
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "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
Bloco de código | ||||
---|---|---|---|---|
| ||||
// 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 | ||||
---|---|---|---|---|
|
Recebe | targetAppID - string - Query param |
version - string - query param | |
Retorna | Application/JSON |
<<< Acrescentar método para enviar parâmetros adicionais ao ERP destino >>>
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.
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:
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/v2/admin/healthcheck/transactions/EAI?targetAppID={targetAppID}&transactionId={transactionID}&version={version}.
Fluxo de envio do método:
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "messages" : [], "length" : 1, "data" : [{ "transactionID" : "financing", "messages" : [{ "code" : "AE100" "text" : "É necessário configurar o parâmetro MV_MULNATP e MV_MULNATR na integração com o TOTVS Incorporações.", "additionalInformation": "Configure os parâmetros" } ] } ] } |
Âncora | ||||
---|---|---|---|---|
|
Recebe | AppID - string - path param - Obrigatório |
mappingValue - string - Query param - Obrigatório | |
mappingID - string - Query param - Obrigatório | |
Retorna | Application/JSON |
Este serviço verifica a integridade dos mapeamentos entre entidades do aplicativo origem e destino
Este produto busca, a partir de uma chave de internalID os valores do correspondente no outro aplicativo.
O JSon esperado por este método deve possuir os atributos a seguir:
Fluxo de envio para o aplicativo interno:
Fluxo de envio diretamente a um aplicativo externo:
Abaixo, exemplo de busca de de-para de empresas, com a requisição originada do aplicativo RM contra o Protheus
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "messages" : [], "length" : 1, "data" : { "destinationAppID" : "PROTHEUS18@PRODUCAO", "mappingValue":"18|D MG 01", "messages" : [{ "code" : "FI001" "text" : "Validado", "additionalInformation":"" } ] } } |
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "messages" : [], "length" : 1, "data" : { "destinationAppID" : "PROTHEUS18@PRODUCAO", "mappingValue":"", "messages" : [{ "code" : "FE011" "text" : "Não existe de-para associado.", "additionalInformation":"" } ] } } |
Âncora | ||||
---|---|---|---|---|
|
Recebe | targetAppID - string - path param |
companyID - string - path param | |
branchId - string - path param | |
Retorna | Application/JSON |
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 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:
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
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "messages" : [], "length" : 1, "data" : { "origintargetAppID" : "PRODUCAO18@PROTHEUS", "destinationtargetAppID" : "RM@RM", "originCompany" : "18", "originBranch" : "D MG 01", "messages" : [{ "code" : "FI001" "text" : "Validado", "additionalInformation":"" } ] } } |
Âncora | ||||
---|---|---|---|---|
|
Recebe | targetAppID - string - path param - Obrigatório |
Retorna | Application/JSON |
Este serviço inicializa validações específicas de produto.
O jSon de retorno esperado para este método contém os seguintes atributos:
Fluxo conceitual do processo:
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "messages" : [], "length" : 1, "data" : { "AppID" : "PRODUCAO18@PROTHEUS", "targetAppID" : "RM@RM", "messages" : [{ "code" : "FI001" "text" : "Validado", "additionalInformation":"" } ] } } |
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 | ||||
---|---|---|---|---|
|
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.
GET http://localhost:8080/eaiservice.apw
Fluxo do serviço:
Bloco de código | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
<?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><b>Serviço genérico de integração com o Microsiga Protheus via EAI</b></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 | ||||
---|---|---|---|---|
|
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:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
<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:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
<?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><?xml version="1.0" encoding="utf-8"?><TOTVSMessage><MessageInformation version="1.001"><UUID>66a7fdd0-ec4d-ac9a-0915-4a0c17a75cd4</UUID><Type>Response</Type><Transaction>WHOIS</Transaction><StandardVersion>1.000</StandardVersion><SourceApplication>PR12_BRA</SourceApplication><CompanyId>18</CompanyId><BranchId>D MG 01 </BranchId><Product name="PROTHEUS" version="12"></Product><GeneratedOn>2016-09-27T17:05:16Z</GeneratedOn><DeliveryType>Sync</DeliveryType></MessageInformation><ResponseMessage><ReceivedMessage><SentBy>TOTVSMONITOR</SentBy><UUID>dee8c4da-1e19-4b44-df97-249443638a9d</UUID><MessageContent><![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></BusinessContent></BusinessMessage></TOTVSMessage>]]></MessageContent></ReceivedMessage><ProcessingInformation><ProcessedOn>2016-09-27T17:05:16Z</ProcessedOn><Status>ok</Status></ProcessingInformation><ReturnContent><EnabledTransactions><Transaction><Name>WHOIS</Name><Version>1.001 </Version><Mode>both_enabled</Mode></Transaction><Transaction><Name>MYMESSAGE</Name><Version>1.000 </Version><Mode>send_enabled</Mode></Transaction><Transaction><Name>COSTCENTER</Name><Version>2.000 </Version><Mode>both_enabled</Mode></Transaction><Transaction><Name>FINANCIALNATURE</Name><Version>2.000 </Version><Mode>both_enabled</Mode></Transaction><Transaction><Name>ACCOUNTRECEIVABLEDOCUMENTDISCHARGE</Name><Version>2.001 </Version><Mode>both_enabled</Mode></Transaction><Transaction><Name>CUSTOMERVENDOR</Name><Version>2.002 </Version><Mode>both_enabled</Mode></Transaction><Transaction><Name>BANK</Name><Version>1.007 </Version><Mode>both_enabled</Mode></Transaction></EnabledTransactions></ReturnContent></ResponseMessage></TOTVSMessage></RECEIVEMESSAGERESULT> </RECEIVEMESSAGERESPONSE> </soap:Body> </soap:Envelope> |
Âncora | ||||
---|---|---|---|---|
|
Este serviço SOAP irá disparar, a partir de um XSD de mensagem padronizada previamente configurado no monitor, uma mensagem 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.
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.
Fluxo do serviço:
Exemplo de envio de simulation
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
<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> |
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}, verificando, para cada transação, se a mesma está correta na visão do EAI;
GET <URL_monitor_externo_REST>/totvseai/monitor/v1/admin/healthcheck/checktransactions/business?targetAppID=<app_interno>&version={version}&supportedMode={supportedMode}&enabledMode={enabledMode}&allowAnonymous={allowAnonymous}&includeOriginalMsg={includeOriginalMsg}, verificando, na camada de negócio, se as transações estão cadastradas de maneira correta.
Âncora | ||||
---|---|---|---|---|
|
Código reservados de Framework | Definição |
FE005 | Transação não está cadastrada no aplicativo consultado |
FE006 | (A transação recebida não está cadastrada neste destino para recebimento) |
FE007 | (A transação recebida não está cadastrada neste destino para envio) |
FE008 | Transação com versões incompatíveis |
FE009 | Empresa/grupo e filial não parametrizados para integração |
FE010 | Erro no envio da mensagem a outro sistema |
FE011 | Não existe de-para associado |
FE012 | Não há registros de de-para no aplicativo |
FE013 | Envio não é possível em ambos os sentidos |
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 | Envio possível em apenas um sentido. |
FW006 | Mensagem somente executada em uma filial |
FW007 | 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 |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|