Use of unconstructed message

Question

I am using BizTalk 2004

I have an orchestration that has exception block that sends out the actual log file it is creating before it hit an exception.

here is the design: My log file message may contain several record instances, say: (I added "-" in the nodes so you can see the sample)

<-log> <-record> <-node1 /> <-node2 /> <-/record> <-record> <-node1 /> <-node2 /> <-/record> <-/log>

I have an overall scope in Long Running Transaction with an exception block that catches System.Exception Inside the scope is the overall processing of my request message containing several records. The log file is initially constructed with just the header (log), then the log file is updated in a loop for the records, wherein it gets the records from the request which is processed individually to a single xml. It will loop through each individual xml, then adds the record in the log file.

this constructed log file is being sent out successfully after the loop processing. Now I want to send the log file constructed when an exception is hit. As I said, the log file is being updated and constructed in the loop. but when I tried sending the log file inside the exception block, I hit the "Use of Unconstructed Message" thing, so I tried saving the log file in an xmldocument then construct the message inside the exception block with the xmldocument, but I then have the "Use of unconstructed Message" thing for the xmlDocument itself

If you can show me how I can successfully send the log file inside the exception block in a long running transaction scope will be greatly appreciated.

Thanks in advanced!

Answer 1

If I understand your description correctly the problem is that you are creating a message in the scope, which you then wish to use in the exception handler of the very same scope. As far as the compiler is concerns, there cannot be any guarantees that the message would be constructed before an exception is thrown, in which case the exception handler may execute with the message being unconstructed. This will happen if you have a failure in the scope before, or at, the message construct shape.

To solve this you must construct the message initially before the scope whose exception handler uses the message. you can then go and re-construct the shape inside the scope, but this would guarentee that, when hitting the exception handler, a message will exist, one way or another.