This is tale about the BizTalk exception in the title and how solve it. A Google search reveals that many BizTalk developers have seen this error before. The general consensus is that this error occurs when two two-way ports subscribe to the same message.
Reproduce The Exception
Firstly directly bind a solicit response port in an orchestration to the message box. The S_R_EDIFACTPOBackupPort below is an example. Secondly directly bind another solicit response port in an orchestration to the message box, for example the S_R_SupplierPOprort. Emit the same message to both two-way ports.
Create filters on two physical solicit response ports that subscribe to the same message. My two physical ports are
Finally processing message through the orchestration creates a routing failure message for the first physical port. Additionally the orchestration suspends with a “Exception occurred when persisting state to the database.” error.
Diagnosis
I confess it took me many hours and false trails to work this one out. I wrote this blog because it might save someone else the same anguish. Furthermore I wanted to remember what I did because I have been in the same spot before.
The most compelling evidence is the subscriptions in the BizTalk group Hub. I see a subscription for the physical ports like this.
If you look closely at the second subscription you will see that it will also subscribe to the same messages as the first one. It makes sense that BizTalk server throws an error because how can the solicit response port handle two responses.
As an aside I wonder if in Azure if you set up the same thing what would happen…may you just can’t do it.
Solution
Now that we understand what is causing how error, how do we solve it. The solution is simple, add the BTS.Operation property to the filter on the second physical port to ensure the subscriptions are unique.
In the final analysis I have learnt that you must be careful to add the correct filters to all ports if you use direct binding to the message box.
