Recently helping a clients customer setup error handling with BizTalk and SharePoint. It’s a familiar story except they wanted us to use SharePoint’s Enterprise Forms feature rather than have InfoPath installed on the client. Makes a lot of sense but not something I’ve done before.
The first step is to get your InfoPath form deployed to SharePoint as a content type. There’s some pretty helpful information on that floating around but start here.
You’ll end up with a Form library that has your InfoPath form setup as a content type, all good. The next step is to get the BizTalk WSS Adapter to publish documents to the library using your new form. Typically with oldskool InfoPath forms you’d have to tell the send port that InfoPath is involved and it would inject some processing instructions into the document before it hit SharePoint. As you want it to use your shiny new template this becomes a little tricky. The processing instructions look something like this.
solutionVersion="126.96.36.199" productVersion="188.8.131.52" PIVersion="184.108.40.206"
<?mso-application progid="InfoPath.Document" versionProgid="InfoPath.Document.3"?>
The string MyBiz-Project-ErrorReport is the name of the template that’s deployed to SharePoint. Everything else is plumbing and/or refers to the message type. To get the exact string simply create a form manually using the library, download it and open in a text editor.
We need to get this string in our message, there are a few ways to do this but fortunately the XmlTransmit pipeline has a property called XmlAsmProcessingInstructions that does just what we want.
Just throw that string in there and the Assemble pipeline component will inject the string into our message.
Whilst this is a little clunky it does work but it will complicate deployments and management of those binding files. Hopefully you’re using something like the XmlPreProcessor to do this. The main issue I have is those version numbers you can see, they’re from the InfoPath designer and will increment every time you save the form. However I did some testing and discovered you don’t need to provide them in the process instructions, the best I could do before I started getting errors was this guy:
Notice that you can exclude all the version attributes and the versionProgId from the last instruction. This should make it easier to manage the bindings as you only have to reference the form name and SharePoint site which you’d have to do anyway if using a traditional InfoPath form. Not sure what would happen if you had more than one version of the form deployed, hopefully it would use the latest and not fail.