A shape de Suspend do BizTalk permite suspender a execução de uma orquestração. Esta shape recebe um único parâmetro, uma string que fica registada no HAT, não sendo gerado qualquer erro no Event Log.
Uma das utilizações desta shape prende-se com facto de poder ser usada em cenários de recuperação de erros: imagine-se uma orquestração complexa com diversos scopes transacionais/atómicos em que se escreve para a base de dados, e em que a recuperação de erros é feita com base na compensação. Se a escrita para uma base de dados XPTO falhar, num desses scopes transacionais, é grande a probabilidade de a compensação, que se inicia logo a seguir, também falhar.
Vou fazer outro post, mais detalhado, sobre abordagens possíveis para resolver isto, mas uma delas passa por fazer um Suspend caso a compensação falhar. Um administrador de sistema, alertado para o problema, poderá depois ir ao HAT e fazer “Resume” de todas as instâncias suspensas, sem qualquer perda de informação.
O problema é o seguinte: na documentação do produto, é referido que a única restrição do Suspend é que não pode ser usado em scopes transaccionais atómicos (e o mesmo se diz sobre a Actity de Suspend no Windows Workflow), mas isto não é a história toda: criei um scope transaccional atómico, e adicionei-lhe um bloco de compensação. Dentro deste, posso adicionar livremente a shape de Suspend. No entanto, se adicionar à compensação um scope transaccional Long Running, ou até um simples “group“, deixo de conseguir adicionar a Suspend Shape!
Isto resolve-se de forma simples criando uma 2ª orquestração, chamada por exemplo… “Suspender”, apenas com uma Suspend Shape, e recebendo por parâmetro a string a usar nessa shape. Depois, na orquestração original, dentro do scope LR/grupo, basta fazer Call a esta orquestração.
É deselegante, mas funciona na perfeição.
Já agora, no Windows Workflow (beta2) é muito mais linear: não se pode usar o Suspend nem dentro da transaction activity, nem sequer da sua compensation.
jota
