Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Âncora
_

Toc403759524

transaction
_

Toc403759524O que é um EAI?          EAI ou Enterprise Application Integration (Integração de aplicações corporativas) é um conceito que visa a integração entre sistemas corporativos diferentes, por meio da utilização de serviços disponibilizados. Um de seus objetivos é a troca de informações entre ERPs (Enterprise Resource Planning – Sistema de Gestão Empresarial), compreendendo como troca de informações o envio e recebimento de mensagens, o registro das mensagens trafegadas e o gerenciamento de filas de execução. Desta maneira, um EAI é uma arquitetura na qual diferentes aplicações conectam-se entre si, através de algum conector que permite a tradução dos dados de diferentes arquiteturas. Âncora_Toc403759525_Toc403759525Modelos de mensagens Síncronas e Assíncronas          As integrações via Mensageria propõem dois modelos de envio e recebimento de mensagens. O modelo Síncrono e o Assíncrono.
          No modelo de mensagens Síncronas a mensagem é enviada e o sistema que enviou aguarda o processamento da mensagem pelo receptor.
          Já no modelo Assíncrono a mensagem é enviada e o sistema que a enviou não aguarda o seu processamento. Posteriormente a mensagem será processada no receptor.
          O modelo de mensagem que será utilizado na integração deve ser avaliado com muito cuidado. Apesar do modelo síncrono parecer o mais adequado para uma integração, isto não é de todo verdade. Em um modelo síncrono deve ser levado em consideração o tempo de processamento: O processamento do sistema que envia, a velocidade do trânsito de dados da rede e o tempo de processamento e resposta do receptor. Isto pode acarretar um tempo de resposta ao usuário muito maior do que o normal, o que pode transformar a integração de solução ao problema. Já o modelo assíncrono, por não aguardar o retorno do processamento do receptor torna o processo mais rápido, porém, neste modelo de mensagem deve-se levar em consideração que o dado será gravado no sistema que envia a mensagem e que o processamento no receptor ocorrerá posteriormente. Desta maneira, em algumas situações os dados irão existir no sistema de envio, mas enquanto não forem processados no receptor eles não existirão lá.

transaction
Transação


          Uma transação, em qualquer sistema, consiste em uma sequência de ações que são consideradas “atômicas”, ou seja, indivisíveis no conceito de trabalho.

Toda transação deve seguir o conceito de ACID (Atomicity, Consistency, Isolation e Durability  - Atomicidade, Consistência, Isolamento e Durabilidade). Em termos gerais:

Atomicidade: A execução da transação é atômica. Ou seja, todas as ações são executadas ou nenhuma;

Consistência: Cada execução deve conservar a consistência do banco de dados;

Isolamento: Cada transação deve ser isolada dos efeitos de execução concorrentes de outras transações e;

Durabilidade: Toda transação que for finalizada de forma bem sucedida deve persistir os seus resultados no sistema.

Âncora
_transInProtheus
_transInProtheus
Transações no Protheus

 

Aviso
titleAtenção

As funções BeginTran() e EndTran() tem seu uso proibido no Protheus, e não devem ser utilizadas em nenhuma hipótese.


         No Protheus, o controle de transações é iniciado através do comando BEGIN TRANSACTION e finalizado através do comando END TRANSACTION.

Para garantir a atomicidade da transação, dentro de uma sequencia iniciada por BEGIN TRANSACTION, todos os dados são gravados ou nenhum. 

Exemplo:

Bloco de código
languagecpp
Function Grava01()

BEGIN TRANSACTION

	//Bloco de Gravação A

	Grava02()

END TRANSACTION

Return 

Function Grava02()

BEGIN TRANSACTION

	//Bloco de gravação B

END TRANSACTION 


Return 

No exemplo acima, caso exista um erro na rotina Grava02() ou até mesmo na Grava01(), nenhum dado será inserido no banco de dados do sistema.

Âncora
_DisarmTransaction
_DisarmTransaction
A Função DisarmTransaction

A função DisarmTransaction() pode ser utilizada para forçar o RollBack dos dados já inseridos e também evitar a gravação dos dados posteriores, protegidos desde a primeira chamada do comando BEGIN TRANSACTION. Esta função deixa o sistema no estado de TTSBREAK e, a partir deste ponto, todas as transações são desfeitas, até o primeiro nível de transação aberto.

No exemplo a seguir:

Bloco de código
languagec#
Function Grava01()

BEGIN TRANSACTION

	//BLOCO A

	Grava02()

	//BLOCO D

END TRANSACTION

Return 

Function Grava02()

BEGIN TRANSACTION

	//BLOCO B

	DisarmTransaction()

	Break

	//BLOCO C

END TRANSACTION

Return

No exemplo acima, a função Grava02 executou um DisarmTransaction após a sua gravação dos dados. Neste caso, os blocos “BLOCO A”, “BLOCO B”  e  “BLOCO D” não serão gravados no banco de dados, e o bloco  “BLOCO C” não será executado, pois, conforme veremos abaixo, após um DisarmTransaction só existem duas alternativas: Um Break, para que o fluxo seja desviado para depois do próximo comando END TRANSACTION ou a finalização da thread.

Caso uma transação seja iniciada com o sistema em TTSBREAK, o mesmo é abortado. 

Bloco de código
languagec#
Function Grava01()

BEGIN TRANSACTION

	//BLOCO A

	Grava02()


	BEGIN TRANSACTION
		
		//BLOCO D
	
	END TRANSACTION

END TRANSACTION

Return 

Function Grava02()

BEGIN TRANSACTION

	//BLOCO B

	DisarmTransaction()

	Break

	//BLOCO C

END TRANSACTION

Return

No exemplo acima, após sair da função Grava02() o sistema está em TTSBREAK,  e ao executar o comando BEGIN TRANSACTION o sistema será abortado por erro.

Aviso
titleAtenção!

Após o DisarmTransaction, o sistema entra em TTSBREAK, e somente é possível iniciar uma nova transação depois que o fluxo de processamento passar por todos os comandos END TRANSACTION. Caso uma nova transação seja iniciada como sistema em TTSBREAK, a aplicação é finalizada pelo erro “Controle de transações: tentativa de abertura de transação pela rotina ROTINA após DisarmTransaction dos dados.”, sendo rotina a função que tentou executar o comando BEGIN TRANSACTION. Este comportamento se faz necessário para garantir a atomicidade da transação.

Âncora
_HowToUse
_HowToUse
Controle de transações: como utilizar

A abertura de uma transação no Protheus deve ser realizada no momento de gravação dos dados, quando necessário.

A chamada da função DisarmTransaction() deve sempre ser seguida da finalização da thread  ou, quando necessário, de um BREAK, para que o fluxo da rotina seja direcionado para depois do END TRANSACTION . Esta função deve ser utilizada em casos específicos, não devendo ser utilizada de maneira indiscriminada no sistema, pois pode gerar erros de gravação ou interpretação errônea do fluxo do sistema.

Caso seja necessário é possível verificar, antes de abrir uma transação, se o sistema não está em TTSBREAK.

 

Nota
titleTTSBREAK

Em libs Protheus com versão acima da 08022017 é possível verificar se o sistema está em TTSBREAK  através da função FwInTTSBreak(). Esta função tem um retorno lógico, indicando se o sistema está ou não em TTSBREAK. Em um retorno positivo desta função um novo bloco de BEGIN TRANSACTION não pode ser chamado, pois o sistema ainda não executou todos os comandos de END TRANSACTIONS pendentes.

Em versões anteriores de lib. Protheus é necessário verificar a variável publica __TTSBreak (que indica se o sistema está em TTSBREAK) e se o sistema está em transação (através da função InTransact()).

 

Âncora
_KnowMore
_KnowMore
Para saber mais

BEGIN TRANSACTION

END TRANSACTION

Guia de boas Práticas - Transações

Âncora_Toc403759526_Toc403759526O EAI Protheus

          O EAI Protheus permite a troca de mensagens, no formato XML (eXtensible Markup Language), com qualquer produto ou software que disponibilize um WebService para esta finalidade. O EAI Protheus permite configurar quais as mensagens estarão disponíveis para uso (mensagem, no contexto do EAI, é o conjunto de dados e regras que são enviados entre os produtos, no formato XML), se as mensagens disponíveis podem ser recebidas e enviadas e uma outra série de combinações que permite decidir se as mensagens podem ou não ser processadas. Também é possível verificar os status das mensagens enviadas e recebidas e o conteúdo trafegado.
          IMPORTANTE: O EAI Protheus não é responsável por realizar o processamento das mensagens. Realizando um paralelo com o mundo real, o EAI Protheus seria o carteiro que envia e recebe mensagens entre duas entidades. O carteiro sabe para quem enviar uma mensagem, e de quem essa mensagem foi originada e também sabe o momento correto para este envio. Ele também é responsável por tentar entregar a mensagem novamente, quando a entrega anterior não foi possível. Desta maneira, erros no processamento da mensagem, problemas na regra de negócio envolvida na integração, problemas com consumo de memória normalmente são decorrentes da rotina envolvida no processamento da mensagem, e não do EAI Protheus.
          O EAI Protheus é composto basicamente por três camadas: Uma camada de Webservice, a camada do EAI e a rotina que executa o processamento da mensagem. Veremos mais abaixo que esta rotina é conhecida como Adapter EAI.

Status do documentoConcluído
Data18112014 
Versão1.0
Versão anterior1.0
Autores

Jandir Deodato De Souza Silva

Índice
Índice
outlinetrue
indent10px