Linha de Produto: | RM. |
Segmento: | Framework Bh |
Módulo: | EAI |
| |
Esse documento tem como objetivo descrever as novas funcionalidades agregadas ao modelo atual de "mensagem única", procurando atender a definição de que “o vertical deve ser o dono da integração”.
Foram criados mecanismos que de acordo com o padrão de cada aplicativo, disponibilize seus “objetos de negócios” como BusinessContent.
Essas alterações não têm como objetivo substituir o modelo de mensageria única e sim agregar novas funcionalidades e recursos ao mesmo.
Para fins de adequação, para esse novo modelo adotaremos o nome de "MENSAGERIA TOTVS".
As equipes responsáveis pelos produtos Totvs deverão desenvolver serviços a serem expostos por webServices. As estruturas desses serviços (schemas ou contratos) devem ser expostos através do formato de xsd's .
Isso permitirá que os produtos possam enviar dados no formato de xml (BusinessContent) contendo informações já no formato nativo dos objetos de negócio (sem necessidade de transformação).
As estruturas de DataServers e Process serão expostos através das suas interfaces públicas IRMSDataServer e IRMSProcess. |
Exemplo: <transaction>RM/FinCFODataBR<transaction>
Mensageria Totvs: Nesse exemplo o nome do objeto de negócio foi enviado.
Exemplo: <transaction>CUSTOMERVENDOR<transaction>
Mensageria Única: Nesse exemplo o nome da mensagem única foi enviado
Em se tratando de mensagens nativas (não utilizando mensageria única), no atributo “transaction”, deve ser incluído obrigatoriamente o nome do ERP (RM/ ou Protheus/ ou DataSul/ ou /Logix) antes do nome do objeto de negócio.
No recebimento dessa mensagem, o EAI receptor verificará se o nome incluído emparelha com seu ERP. Caso positivo, trata-se de um receptor ERP. Caso negativo, trata-se de um receptor vertical.
Exemplo:
<MessageInformation version="12.1.9"> <UUID>578458748541574578548487</UUID> <Type>BusinessMessage</Type> <Transaction>Protheus/ObjetoDeNegocioProtheus</Transaction> <StandardVersion>1.0</StandardVersion> <SourceApplication>SourceApplication</SourceApplication> <CompanyId>CompanyId</CompanyId> <Product name="Any" version="Any"/> <GeneratedOn>2016-02-04T11:00:00</GeneratedOn> <DeliveryType>Assync/Sync</DeliveryType> </MessageInformation> |
---|
BusinessMessage> <BusinessEvent> <Entity>Protheus/ObjetoDeNegocioProtheus</Entity> <Event>upsert|delete</Event> <Identification> </Identification> </BusinessEvent> <BusinessContent> ... </BusinessContent> </BusinessMessage> |
---|
<ResponseMessage> <ReceivedMessage> <SentBy>client</SentBy> <UUID>94551485144878487457857454</UUID> <MessageContent><![CDATA[ <TOTVSMessage>...</TOTVSMessage> ]]> </MessageContent> </ReceivedMessage> <ProcessingInformation> <ProcessedOn>2001-12-31T12:00:03</ProcessedOn> <Status>OK</Status> <ListOfMessages> <Message type="WARNING" code="c1">msg1</Message> <Message type="ERROR" code="c2">msg2.</Message> </ListOfMessages> </ProcessingInformation> <ReturnContent> </ReturnContent> </ResponseMessage> |
---|
Foi criada uma nova tag chamada “XMLContent” filha de ReturnContent”. Nessa nova tag será enviado o xml contendo o resultado da informação após seu processamento pelo receptor. Através dessa informação, o EAI vertical saberá os valores exatos das chaves geradas. Possibilitando portanto a inclusão desses valores nas tabelas de De/Para.
<ResponseMessage> <ReceivedMessage> <SentBy>client</SentBy> <UUID>94551485144878487457857454</UUID> <MessageContent><![CDATA[ <TOTVSMessage>...</TOTVSMessage> ]]> </MessageContent> </ReceivedMessage> <ProcessingInformation> <ProcessedOn>2001-12-31T12:00:03</ProcessedOn> <Status>OK</Status> <ListOfMessages> <Message type="WARNING" code="c1">msg1</Message> <Message type="ERROR" code="c2">msg2.</Message> </ListOfMessages> </ProcessingInformation> <ReturnContent> <XMLContent> ... </XMLContent> </ReturnContent> </ResponseMessage> |
|
---|
Nas mensagens de Requests, ao enviar o o nome do Process da RM, será retornado na tag "xmlContent" a classe de parâmetros do processo contendo informações geradas após seu processamento. |
Exemplo: Atualmente no RM existem 4 objetos de negócios diferentes responsáveis pela inclusão dos dados bancários (banco, agencia, conta e conta caixa). No Protheus existe apenas um único objeto de negócio para inclusão dessas informações.
Sendo assim, deve ser criado pela equipe de segmentos do RM um único objeto de negócio capaz de receber todas as informações bancárias de uma única vez.
Esse novo objeto de negócio a ser criado pelo RM “orquestrará” as chamadas aos objetos de negócio nativos do segmento;
Exemplo de mensagem de entrada:
<TOTVSMessage> <MessageInformation version="1.001"> <UUID>bb9dd43c-9dcd-a056-c3c7-d78f038d2779</UUID> <Type>BusinessMessage</Type> <Transaction>WHOIS</Transaction> <StandardVersion>1.000</StandardVersion> <SourceApplication>PR11_BRA</SourceApplication> <CompanyId>18</CompanyId> <BranchId>D MG 01</BranchId> <Product name="PROTHEUS" version="11" /> <GeneratedOn>2015-09-22T19:46:09</GeneratedOn> <DeliveryType>Sync</DeliveryType> </MessageInformation> <BusinessMessage> <BusinessRequest> <Operation>WhoIs</Operation> </BusinessRequest> <BusinessContent> <RequestType BusinessObjectOnly="true" /> </BusinessContent> </BusinessMessage> </TOTVSMessage> |
---|
Caso o atributo "BusinessObjectOnly" esteja configurado com o valor "true" será retornado os nomes dos serviços (objetos de negócio). Caso seja marcado como "false", terá o mesmo comportamento da mensagem Whois 1.000, ou seja, retornará somente as mensagens mapeadas para o modelo de mensageria única |
Exemplo de mensagem de saída:
<ProcessingInformation> <ReturnContent> |
---|
Será retornada uma mensagem do tipo "ResponseMessage" contendo todos os nomes dos servers disponíveis na RM. Por questão de tamanho da mensagem, no exemplo abaixo será retornado somente alguns serviços, visto que, existem milhares de serviços disponíveis na arquitetura RM. |
Exemplo1: cadastro de cliente fornecedor (Mensagem de Event). Será utilizado o serviço "FinCFODataBR".
<TOTVSMessage> <MessageInformation version="1.000"> <UUID>bb9dd43c-9dcd-a056-c3c7-d78f038d433/</UUID> <Type>BusinessMessage</Type> <Transaction>GETSCHEMA</Transaction> <StandardVersion>1.000</StandardVersion> <SourceApplication>P12_INTX</SourceApplication> <CompanyId>T1</CompanyId> <BranchId>D MG 01</BranchId> <CompanySharingMode>E</CompanySharingMode> <BusinessUnitySharingMode>E</BusinessUnitySharingMode> <BranchSharingMode>E</BranchSharingMode> <Product name="PROTHEUS" version="12" /> <GeneratedOn>2015-10-30T14:18:11</GeneratedOn> <DeliveryType>Sync</DeliveryType> </MessageInformation> <BusinessMessage> <BusinessRequest> <Operation>GetSchema</Operation> </BusinessRequest> <BusinessContent> <Adapter>FinCFODataBR</Adapter> </BusinessContent> </BusinessMessage> </TOTVSMessage> |
---|
Será retornada uma mensagem do tipo "ResponseMessage" contendo o schema do serviço em questão.
<ProcessingInformation> <ProcessedOn>2016-03-23T17:43:55</ProcessedOn> <Status>OK</Status> </ProcessingInformation> <ReturnContent ><XSD> <Adapter>FinCFODataBR</Adapter> <Schema><FinCFOBR xmlns="http://tempuri.org/FinCFOBR.xsd"> <xs:schema id="FinCFOBR" targetNamespace="http://tempuri.org/FinCFOBR.xsd" xmlns:mstns="http://tempuri.org/FinCFOBR.xsd" xmlns="http://tempuri.org/FinCFOBR.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" attributeFormDefault="qualified" elementFormDefault="qualified"> <xs:element name="FinCFOBR" msdata:IsDataSet="true" msdata:UseCurrentLocale="true" msdata:EnforceConstraints="False"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="FCFO"> <xs:complexType> <xs:sequence> <xs:element name="CODCOLIGADA" msdata:Caption="Coligada" type="xs:short" /> <xs:element name="CODCFO" msdata:Caption="Cliente/Fornecedor"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="25" /> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="NOMEFANTASIA" msdata:Caption="Nome Fantasia"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100" /> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="NOME" msdata:Caption="Nome"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100" /> </xs:restriction> <xs:selector xpath=".//mstns:FCFOCOMPL" /> <xs:field xpath="mstns:CODCOLIGADA" /> <xs:field xpath="mstns:CODCFO" /> </xs:keyref> </xs:element> </xs:schema> </FinCFOBR> </Schema> </XSD> </ReturnContent> |
---|
Exemplo2: retorna o schema da classe de parâmetros do processo
<TOTVSMessage> |
---|
Mensagem de resposta:
<ProcessingInformation> |
---|
Ao chamar a mensagem "GetSchema" para processo qualquer, será retornado o objeto RMSParamsProc relacionado ao processo em questão de forma serializada. |
3) Direção das mensagens
a) Origem –> ERP / Destino -> Vertical
Detalhamento dos processos:
Retorno para o EAI(vertical) um xml contendo os dados atuais após a execução do objeto de negócio;
A partir de agora, os EAI’s não serão mais responsáveis em transformar mensagens e controlar informações de De/para. Esses serviços serão de responsabilidade dos diversos seguimentos.
Serviços genéricos poderão ser disponibilizados no EAI para facilitar o trabalho dos segmentos.
b) - Origem –> Vertical / Destino -> ERP e outro Vertical
Detalhamento dos processos:
Os dados das chaves do ERP serão extraídos da tag <XMLContext> localizada no “ResponseMessage”; |
Procedimentos quando o RM funcionar como ERP
Formula visual:
A propriedade "Id.Transformação", disponibilizada na atividade de fórmula visual, deve ser configurada conforme abaixo:
Deve ser incluída a palavra "RM" após a versão da mensagem. |
Procedimentos quando o RM funcionar como Vertical
RM recebendo os dados:
A atualização do De/Para e a transformação da mensagem será de responsabilidade dos verticais. |
RM enviando os dados: