‘Crash Recovery’ é um recurso muito interessante, disponível no servidor Magic xpi.
Ele nos permite parametrizar ações do Magic xpi Server, em resposta a eventos inesperados durante a execução dos fluxos de integrações.
Por exemplo, considere o exemplo abaixo:
Este projeto exemplo possui dois fluxos, sendo um Auto Start. Num determinado ponto da execução, outro fluxo será chamado (sob certa condição). Este segundo fluxo possui um componente de usuário que está propositalmente compilado com erros (bugs).
Por conta disso, sempre que este componente for executado ocorrerá um AV/GPF, e a thread de execução destes fluxos será eliminada abruptamente. Quando isso ocorre, o restante dos passos do fluxo em execução é ignorado simplesmente, e a lógica de integração provavelmente ficará inacabada.
O que queremos agora é uma forma de detectar isso, e tomar alguma medida corretiva.
A parte quanto a detectar a anomalia, é toda por conta do Magic xpi. Já a questão da medida corretiva, depende do designer do projeto.
Existem algumas configurações quanto a isso, e a mais importante delas é o Recovery Policy do fluxo. Ou seja: política de recuperação do fluxo.
Existem diferente opções para esta política, e no nosso projeto exemplo, vamos escolher Save Point para o fluxo inicial (Run).
‘Save Point’ significa instruir o Magic xpi Server a reiniciar a execução do fluxo a partir do último estado conhecido. Isso só se aplica nas situações em que o fluxo não chega ao seu final natural, segundo a lógica desenhada. Escolher a política ‘Save Point’ exige algumas outras configurações adicionais:
1) É preciso selecionar os componentes desejados no fluxo, e marca-los com pontos de salvamento (Save Points):
O último Save Point executado sobrescreve os anteriores. Um ícone representando um disquete é exibido, para mostrar que aquele componente é um Save Point do fluxo. Os Save Points são gerados sempre antes de executar o referido componente onde foram definidos.
2) Além das anomalias que interrompem as threads de execução dos fluxos, podem existir também aquelas que interrompem a execução do processo do próprio Magic xpi Server, como por exemplo, falta de energia. Nestes casos, se queremos que a política de recuperação entre em ação também na próxima vez que o Magic xpi Server reiniciar a sua execução, necessitamos ir até as configurações do servidor do projeto e ajustá-las para que as informações de recuperação não sejam removidas durante a inicialização do projeto.
Neste nosso projeto exemplo, criamos um Save Point logo antes de chamar o fluxo que irá causar o desastre, e também configuramos para reter as informações de recuperação, entre reinicializações do Magic xpi Server.
Muito bem. O que ocorre quando executamos este projeto é o seguinte:
O fluxo Auto Start inicia-se automaticamente e em determinado ponto, é feita a chamada ao fluxo defeituoso (Crash). Antes disso, informações de restauração do contexto de execução do fluxo são recolhidas e salvas numa pasta do projeto, chamada ‘Recovery’:
É o famoso Save Point.
Em seguida, o componente com problemas é executado. Neste momento ocorre um AV/GPF e execução do fluxo é interrompida. No Magic xpi Monitor vemos a mensagem:
A main thread was terminated abnormally. Recovery has been executed.
Observe (olhando de baixo para cima) então que entra em ação a política de recuperação, que neste caso, restaura o contexto de execução a partir do último Save Point existente e reinicia o fluxo a partir dali.
Obviamente, sempre que este fluxo de exemplo executa novamente, ele passa pelo mesmo ponto problemático e gera novo crash. Por isso, a repetição das etapas de recuperação.
Mas podemos claramente verificar o sistema de ‘crash recovery’ do Magic xpi Server em ação.
Esta é mais uma dica de como desenhar integrações robustas, de alta disponibilidade, com o Magic xpi.
