Been a little remiss in posting for a while. Been busy! In any case, I’ve encountered some nuances about interacting with BizTalk that I’d like to share. I often talk about how BizTalk and InfoPath are perfect bedfellows in that they are both XML centric and are “designed to work together”. Well, that’s kind of true, but there’s a lot of headroom to grow into based on my personal experiences. I recently ran into a snag where I was using the techniques noted in this post http://blogs.msdn.com/timpash/archive/2006/01/13/Submit_XML_to_File_Share_Programmatically.aspx to push data to a UNC-Path file recieve location that BizTalk would grab and go with. The code worked fine when I was in-house, but would fail when I was on VPN, and wouldn’t work at all for my counterparts that were in other field offices. Turns out that when you invoke an XDocument.SaveAs(somestring) command it doesn’t actually let go of the file. I ran into issues where BizTalk wanted to grab it before I could get through my whole submit routine and shut down the form, and that would cause InfoPath to throw an error. Weird thing was that the file got to where it needed to be, and BizTalk was happy, but InfoPath was complaining (and so were end-users). So I got the idea (with some help) to push the file to a staging directory that BizTalk was not monitoring, and then use an ActiveXObject calling into the FileSystemObject to move the file to it’s final destination. Sounds smart, but everytime I tried it I’d get a permission denied error. The code I was running looks like this:
fso = new.ActiveXObject(“Scripting.FileSystemObject”);
So I was calling the function right after the XDocument.SaveAs line, and it would throw a permissions error. Could not figure it out, but then thought about the problem I was seeing with BizTalk and a light came on. In the script, I called two different submit operations and then called this line
to shut the form down. I found that when I called the MoveFiletoDropLocation function right after this line it worked like a champ. Bottom line, be careful with the XDocument.SaveAs call because that file is locked for editing and deletion until the form is closed.