Handling messages without subscription in BizTalk 2010

1
votes

In BizTalk I am receiving a message of a known type which is a response of a message I send before. The current orchestration subscribes to the response via a correlation set. For a deployment I need to terminate some existing orchestrations, but new ones will be created which can be handled. Usually this can be fixed with a side-by-side deployment, however an update of a third party component requires me to terminate.

Is there some way I can route the routing failures which will occur after terminating to a different orchestration with the following constraints.\

  • I need the original message type to handle the message;
  • I am not interested in errors happening in the pipeline (which is also custom). Those should be suspended as usual.

I tried to play with filters on the receive shape, however it seems not to recognize the message as there is still a routing failure.

One alternative I thought of is to have no filter, but than I need to send some message if two orchestrations handles the same message, which should not occur in this solution.

The solution is only temporary, after one month all the old replies will be finished and the solution can be removed. So it should be easy to remove it without deployment (or downtime).

2
biztalkbiztalk-2010
Hold on a sec, what is it about the 3rd party component that is requiring you to redeploy? Maybe we can work around that. – Johns-305
@Johns-305 The dll's of the 3rd party are loaded in BizTalk and being used by some dll's of my solution which causes that those dll's needs to be imported. This import will crash if there are any instances existing in BizTalk. The 3dr party does not support side-by-side currently. – René
And they can't provide a different version? Just to be clear, they are BizTalk Assemblies, not plain, regular .Net Assemblies. – Johns-305
Correct, they can't provide a different version. Their package contains both BizTalk Assemblies as regular .NET Assemblies. But the last ones can be updated by replacing them in the GAC. Usually that is also possible with BizTalk Assemblies, but in this case the reworked a orchestration I call from my code. So it is better to have the dll's imported in the admin console next to updating them in the GAC. – René

2 Answers

1
votes

I see two possible options, and you would have to test each first.

  1. Enable Failed Message Routing and subscribe the failed responses to a Send Port
  2. Just let them suspend and use a WMI Script to save the messages. If you do this, you will also get the Context with all it's properties.

Either way, you'd then need a process to resubmit them.

0
votes

When dealing with a synchronous call, you generally get the response within a minute or so. Typically, setting up a maintenance window would be the better option. No incoming requests for a few minutes should allow you to clear up things and update your resources/artifacts.

If this is not an option, typically side-by-side deployment is specifically designed for this. But you are limited there as well.

Another option would just to let them suspend and handle them manually or - once suspended - save the body of the suspended messages and save them for further processing (either manually or some specific flow you can setup).