| 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 | FRM_FRM002-85 - Getting issue details... STATUS |
Requisito1 | FRM_FRM002-127 - Getting issue details... STATUS | Subtarefa1 | FRM_FRM002-128 - Getting issue details... STATUS |
País | ( ) Brasil ( ) Argentina ( ) México ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colômbia ( 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á características diferentes da API de monitoramento definida no documento ER_FRWJOI01-3_Serviços_para_monitoramento_de_EAI.
Os parâmetros de paginação page e pageSize, quando não especificados, assumem o valor default de 1 e 10, respectivamente.
| Recebe | page | integer | query param | opcional |
| pageSize | integer | query param | opcional | |
| Retorna | application/JSON |
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).
{
"hasNext" : false,
"items" : [{
"companyID" : "99",
"branchID" : "01"
},
{
"companyID" : "99",
"branchID" : "02"
}]
}
{
"hasNext" : true,
"items" : [{
"companyID" : "AA",
"branchID" : ""
},
{
"companyID" : "AB",
"branchID" : ""
},
{
"companyID" : "AC",
"branchID" : ""
}]
}
{
"hasNext": true,
"items": [
{
"companyId": "1",
"branchId": "1"
},
{
"companyId": "1",
"branchId": "2"
},
{
"companyId": "1",
"branchId": "3"
},
{
"companyId": "1",
"branchId": "4"
},
{
"companyId": "1",
"branchId": "5"
}
]
}
| Recebe | externalAppID | string | query param | opcional |
| companyID | string | query param | opcional | |
| branchID | string | query param | opcional | |
| page | integer | query param | opcional | |
| pageSize | integer | query param | opcional | |
| 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").
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:
Ordenação
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 appID, companyID e branchID, situados no 1o nível; e externalAppID, situado no 2o nível (abaixo de integratedProducts).
A ordenação pode combinar quaisquer atributos, por exemplo, "order=companyID,branchID,-externalAppID" ou "order=appID,-branchID".
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.
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 formato do corpo da resposta deve estar conforme especificado no Guia de implementação das APIs TOTVS. Ou seja:
{
"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"
}]
}]
}
{
"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"
}]
}]
}
{
"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"
}]
}]
}
{
"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"
}
]
}
]
}
{
"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"
}
]
}
]
}
{
"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"
}
]
}
]
}
GET /totvseai/diagnosis/v1/healthcheck/wsintegration/{targetAppID}/{companyID}/{branchID}
| Recebe | targetAppID | string | path param | obrigatório |
| companyID | string | path param | obrigatório | |
| branchID | string | path param | opcional | |
| 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. 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:
Fluxo de envio da requisição, onde Protheus é o aplicativo interno:
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": [
{
"code": "EI002",
"message": "Erro",
"detailedMessage": "Host não configurado na instalação do EAI."
},
{
"code": "EI003",
"message": "Erro",
"detailedMessage": "Erro não 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"
}
]
}
| Retorna | Application/JSON |
Definição em andamento
Este endpoint ainda depende de definições que estão em andamento. Logo, sua implementação não é recomendada até que essas definições estejam concluídas.
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:
Fluxo conceitual do processo:
Exemplo de retorno
{
"appID" : "PRODUCAO18@PROTHEUS",
"messages" : [{
"code" : "FI001"
"message" : "Validado",
"detailedMessage":""
}]
}
{
"appID" : "EAI2@LOGIX",
"messages" : [{
"code" : "FE006"
"message" : "Configuração inválida",
"detailedMessage" : "Sessão WEBSERVICES não foi encontrada no arquivo TotvsAppServer.ini"
}
]}
{
"appID" : "RM@RM",
"messages" : [{
"code" : "FE006"
"message" : "Configuração inválida",
"detailedMessage" : "Job de processamento da fila não está configurado."
}]
}
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.
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><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).
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><?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>
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>
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.
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.
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.
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.
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.
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.
O fluxo abaixo descreve as tarefas da 2a etapa de validação de um aplicativo externo.
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.
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.
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.
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 não enviados pela release menor, devem receber valores padrão 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.
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
| Versões na origem | Versões no destino |
|---|---|
| 1.000, 1.001 | 1.000, 2.001 |
Segue resultado da validação:
| Versão origem | Versão destino | Retorno |
|---|---|---|
| 1.000 | 1.000 | FI001 (Totalmente compatíveis) |
| 1.000 | 2.001 | FE002 (Incompatíveis) |
| 1.001 | 1.000 | FW007 (Potencialmente compatíveis) |
| 1.001 | 2.001 | FE002 (Incompatíveis) |
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. | FE011 - Transação desabilitada em ambos os aplicativos. |
| not_enabled | send_enabled | Não. Está desabilitada em A. | Não. Está desabilitada em A. | FE011 - Transação desabilitada no aplicativo (A). |
| not_enabled | receive_enabled | Não. Está desabilitada em A. | Não. B não permite envio. | FE011 - Transação desabilitada no aplicativo (A). |
| not_enabled | both_enabled | Não. Está desabilitada em A. | Não. Está desabilitada em A. | FE011 - Transação desabilitada no aplicativo (A). |
| send_enabled | not_enabled | Não. Está desabilitada em B. | Não. Está desabilitada em B. | FE011 - Transação desabilitada no aplicativo (B). |
| send_enabled | send_enabled | Não. B não permite recebimento. | Não. A não permite recebimento. | FE011 - 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. | FE011 - 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. | FE011 - 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.. | FE011 - 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. |
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.
Abaio, diagrama de implementação do fluxo.
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.
Para implementação, considerar o diagrama abaixo.
| Código reservados de Framework | Definição |
|---|---|
| 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 |
| 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 | 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. |
|---|