Quando uma mensagem é colocada na Message Box, e não existe nenhuma subscrição que a apanhe, são gerados tipicamente três (ou mais) erros no Event Log indicando a condição, como este:
The Messaging engine failed to process a message submitted by adapter:SOAP Source URL:/MyVD/MyWS.asmx. Details:Could not find a matching subscription for the message. This error occurs if the subscribed orchestration schedule or send port has not been started, or if some of the message properties necessary for subscription evaluation have not been promoted.
Este é possivelmente o erro mais frequente em desenvolvimento com BizTalk 2004, e geralmente é seguido da utilização do BtsSubscriptionViewer, incluido no SDK, para confirmar que subscrições existem realmente.
Quando se utiliza Direct Binding, no entanto, o que sucede não é bem isto. Como referi num post anterior, ao contrário do que a própria documentação pode deixar a entender, as mensagens enviadas com Direct Binding, apesar de parecerem invocações directas (síncronas) de orquestrações, passam pela Message Box. O que sucede então se uma orquestração publicar uma mensagem com Direct Binding e não existir nenhuma subscrição?
De forma semelhante ao primeiro cenário, vamos ter um erro no Event Log:
Microsoft.XLANGs.Core.PersistenceException: Exception occurred when persisting state to the database. —> Microsoft.BizTalk.XLANGs.BTXEngine.PersistenceItemException: A batch item failed persistence Item-ID 77c8fa0a-d202-42c6-9ed8-49e3abfdd9db OperationType MAIO_CommitBatch Status -1061151998 ErrorInfo The published message could not be routed because no subscribers were found.
Ao contrário do que sucede no caso mais comum, no entanto, este erro corresponde a uma excepção que é gerada aquando do Send, na orquestração que faz o envio com Direct Binding, e não pelo motor do BizTalk ao avaliar as subscrições. As subscrições parecem ser avaliadas síncronamente, e a mensagem não chega a ser guardada na Message Box.
E não acaba aqui: se a orquestração for transacional (tipicamente, Long Running), o mecanismo de Compensação vai ser desencadeado, para reverter as acções eventualmente já realizadas. Se isto não for o pretentido, basta colocar o Send dentro de um novo Scope transacional Long Running, e adicionar um Exception Handler. Agora ficamos sem erro no Event Log, e podemos tratar a situação como pretendermos.
Pode não parecer, mas o BizTalk tem muita piada. 🙂
jota
