Since this exception can be catch in several scenarios the most commonly is when using dynamic ports.
To send something to a dynamic port the first thing before performing the send operation is to assign the Microsoft.XLANGs.BaseTypes.Address to the needed port.
and then assign the needed properties for connection (in this case, using the SOAP Adapter
MessageOut(SOAP.ClientConnectionTimeout )= miliseconds;
MessageOut(SOAP.UseProxy) = true;
MessageOut(SOAP.ProxyAddress ) = “proxyname”;
MessageOut(SOAP.ProxyUsername) = “proxyusername”;
MessageOut(SOAP.ProxyPassword ) = “proxypassword”;
MessageOut(SOAP.ProxyPort ) = proxyport;
In this scenario, the location where the orchestration will send the consumer message, is retrieved using Business Rules (BR) After performing some testing, everything went fine, but in some cases BizTalk raised a Microsoft.XLANGs.BaseTypes.PersistenceException exception. Digging in to the problem i discovered that in this case the persistence exception was raised when the executed BR returned Null as location value.
Well, i think this could be explained by the fact BizTalk always persists the state to the database in several cases, one of them when performing a send operation. As in this case the location is unknown, BizTalk will rise a persistence exception since the exception is raised while trying to doing it (before sending the message out) which makes real sense: why to persist nothing if i even could not send it?