Histórico da Página
Versões comparadas
Chave
- Esta linha foi adicionada.
- Esta linha foi removida.
- A formatação mudou.
Âncora | ||
---|---|---|
|
|
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á.
|
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 | ||||
---|---|---|---|---|
|
Aviso | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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 | ||||
---|---|---|---|---|
|
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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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 | ||||
---|---|---|---|---|
|
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 | ||
---|---|---|
| ||
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 | ||||
---|---|---|---|---|
|
Guia de boas Práticas - Transações
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 documento | Concluído |
---|---|
Data | 18112014 |
Versão | 1.0 |
Versão anterior | 1.0 |
Autores |
Índice | ||||||
|