My talk at the VBUG last week went off well. Thanks to the people who attended for making it a very enjoyable session (45 minutes of Q&A after the session must be some kind of record!!) and of course to VBUG for giving me the opportunity to speak. I look forward to the next time and im considering something in October, topic to be decided later. Anyway on to the subject of todays post.
MSMQT Tip: I found something about MSMQT that changed my understanding of queues or at least MSMQT in particular. The way i understand queues is that you can merrily post to them and the subscriber at the other end could be down and no one will care and when the subscriber comes up again, it picks up the messages. So accordingly we set up the MSMQT receive location and posted a message to it. Whadday know!!immediately Biztalk complained that it didnt have a subscriber. This baffled us for a while. So we created a send port which subscribed to the recieve port and dumped the message to the file. Of course this worked, but this is not the point of a queue! More experimentation followed. We stopped the queue leaving it enlisted. No proble and no error messages. As soon as it came back again the messages got dumped. Then we stopped the queue and unenlisted it.Strangely no problem at all. Once again as soon as it came back up the messages got dumped!! It appears that MSMQT wants to have seen at least one subscriber at some point of time in the beginning of the queues lifetime and then it doesnt mind if the subscriber is down. Isnt that odd?
The thing is , I will have an orchestration subscribing to the queue shortly but the queue is there so that i can also avail of the disconnected feature and then undeploy the subscriber for patches and bugfixes. But this also means that i cannot do a complete rebuild of all the ports etc because if i lose the dummy send ports or the orch receive locations then im stuffed. The messages will get lost. I will have to do a complete new mechanism for bug fixing which doesnt involve chopping out and rebuilding ports along with orchestrations. Im going to post this on the newsgroup and see what people say but in the meantime , keep this in mind when using MSMQT.
BizUnit tip: Now on to BizUnit and once again, i’ll keep you updated with what i find if its a bug or feature. It looks like we canot use the SOAPHttpRequestResponse step to post to an untyped webservice. We have an orch published as an ASMX and it takes an XmlDocument as input. No matter what InputTypeName we declared (in the BizUnit test case), BizUnit wouldnt hear of it . It kept complaining that it could create the necessary type. So we had to resort to NUnit instead and just loaded in an XmlDoc from file and sent the nodes across the wire. We’ll use BizUnit to test and validate the output file once we save the response locally.
Theres also one more thing about BizUnit which i think is dodgy. You cannot post a complete SOAP request to it (for a typed webservice). I cut and pasted the SOAP request from the ASMX helper page but it just wouldnt work. What you have to do is pick up a proxy object and then serialise it , copy the serialised XML and then send it to the SOAP end point. Thats really annoying as i was hoping to avoid generating webreferences and proxies. Moreover, if the ASMX page shows the structure of the SOAP message, why cant BizUnit pick that up? I can understand if we only remove the SOAP envelope and body and if BizUnit adds that dynamically, but the entire input message structure was kinda funny (compared to the ASMX page that is). Really weird, but i will discuss this on the GDN workspace and post my findings.