Bij het implementeren van een orchestration die meerdere berichten uit moet sturen naar een ketenpartner, ben ik tegen een nogal vaag probleem aangelopen.
Voor het versturen van meerdere berichten maak ik gebruik van een Loop shape. Daarbinnen zit een Parallel shape met twee branches: één om de berichten te versturen, de andere implementeert een timeout. Als één van beide branches klaar is, wordt een exception gegooid en gevangen om de resultaten uit te lezen (zo wordt de andere branch ook gestopt). Dit wordt zo voor alle te versturen requests gedaan.
Een overzicht zie je in onderstaande plaat:
In de eerste iteratie verloopt alles goed, op punt A wordt gelogd dat parallelle executie is gestart, zowel B1 als B2 worden gelogd, de linkertak wordt volledig uitgevoerd waarna een exception wordt gegooid, die gevangen wordt in het handler met label Timeout. Daar wordt het tussentijdse resultaat bewaard, punt C wordt gelogd ("bericht 1 van 2 verwerkt") en de counter wordt opgehoogd.
In de tweede iteratie wordt op punt A netjes gelogd, maar B1 en B2 verschijnen niet in de log. Ook de overige inhoud van beide branches wordt niet uitgevoerd. Ook beide exception handlers worden niet uitgevoerd. Daarna wordt punt C wel gelogd ("bericht 2 van 2 verwerkt") en loopt de orchestration verder af.
Kan iemand hier verklaren hoe het komt dat bij de tweede iteratie de volledige Parallel shape wordt overgeslagen? Op de shape zitten zo goed als geen properties die zulk gedrag kunnen verklaren en je kunt er verder ook geen condities of iets dergelijks op zetten. Ook als ik de orchestration debugger gebruik, dan springt 'ie over de complete Parallel shape heen.
Het lijkt er sterk op dat het een bug is in BizTalk, maar ik heb er via google niets over kunnen vinden. Zoekresultaten op een query met een Parallel shape i.c.m. een Loop leveren hits op over synchronisatie van variabelen etc.
Misschien handig om nog te vermelden dat er helemaal niets stuk lijkt te gaan: geen suspended orchestration, geen meldingen in het Event Log, niets.
Voor het versturen van meerdere berichten maak ik gebruik van een Loop shape. Daarbinnen zit een Parallel shape met twee branches: één om de berichten te versturen, de andere implementeert een timeout. Als één van beide branches klaar is, wordt een exception gegooid en gevangen om de resultaten uit te lezen (zo wordt de andere branch ook gestopt). Dit wordt zo voor alle te versturen requests gedaan.
Een overzicht zie je in onderstaande plaat:
In de eerste iteratie verloopt alles goed, op punt A wordt gelogd dat parallelle executie is gestart, zowel B1 als B2 worden gelogd, de linkertak wordt volledig uitgevoerd waarna een exception wordt gegooid, die gevangen wordt in het handler met label Timeout. Daar wordt het tussentijdse resultaat bewaard, punt C wordt gelogd ("bericht 1 van 2 verwerkt") en de counter wordt opgehoogd.
In de tweede iteratie wordt op punt A netjes gelogd, maar B1 en B2 verschijnen niet in de log. Ook de overige inhoud van beide branches wordt niet uitgevoerd. Ook beide exception handlers worden niet uitgevoerd. Daarna wordt punt C wel gelogd ("bericht 2 van 2 verwerkt") en loopt de orchestration verder af.
Kan iemand hier verklaren hoe het komt dat bij de tweede iteratie de volledige Parallel shape wordt overgeslagen? Op de shape zitten zo goed als geen properties die zulk gedrag kunnen verklaren en je kunt er verder ook geen condities of iets dergelijks op zetten. Ook als ik de orchestration debugger gebruik, dan springt 'ie over de complete Parallel shape heen.
Het lijkt er sterk op dat het een bug is in BizTalk, maar ik heb er via google niets over kunnen vinden. Zoekresultaten op een query met een Parallel shape i.c.m. een Loop leveren hits op over synchronisatie van variabelen etc.
Misschien handig om nog te vermelden dat er helemaal niets stuk lijkt te gaan: geen suspended orchestration, geen meldingen in het Event Log, niets.
