Delete InfoPath Form from Script Code

A pattern I’ve seen appear multiple times with InfoPath solutions is around having two document libraries store the forms.  One typically serves as a drafting area, and the other serves as an approved or archived area.  This is typically done when security requirements dictate having two separate access lists for each library.  At some point during the life of the form it needs to move from one library to another.  The key here is move.  You don’t want to find it in both places.  It’s pretty simple to set up two data connections for submitting an InfoPath form, and have rules or code dictate which connection to use for submittal.  However, there’s no out-of-the-box functions for removing the InfoPath form from a library it was previously saved to.

One solution to this problem is to use the Scripting.FileSystemObject.  This class has a DeleteFile method and can use a UNC path to the file in a Sharepoint library/folder to delete the file.  However, the FileSystemObject class comes from an ActiveX component which is not marked as ’safe for scripting’.  Best practices for InfoPath development indicate you should avoid referencing these types of components.  InfoPath relies on Internet Explorer security settings as part of its security model.  By default all zones (Internet, Intranet, local) except for Trusted Sites do not allow execution of unsafe ActiveX components.

An alternate solution is to use the XMLHTTP class.  This class comes from a component which is marked as safe, and uses HTTP to perform the delete operation (which is typically faster than the file system approach with FileSystemObject).  Below is a snippet of JScript code which demonstrates how to use this within InfoPath:

try
{
    // Get full URL of the current form
    var docUrl = XDocument.URI;
   
    // Create an xmlhttp object.
    var xmlHttp = new ActiveXObject(”MSXML2.XMLHTTP”);

    // Delete the Working area document.
    xmlHttp.Open(”DELETE”, docUrl, false);
    xmlHttp.Send();
}
catch (ex)
{}

Another approach a co-worker recommended was around using Sharepoint Designer to construct a workflow.  I like this idea because typically these solutions are based on a consistent workflow.  However, there are some downsides to this approach - including having to learn Designer, having “code” and logic in multiple places, and security around execution of the workflow.  I’m going to try and explore this option some more and will post some results.

Merge Documents View Missing

I’m not sure what I was doing with an InfoPath 2003 solution I was working on today, but somehow the “Merge Documents” view in the form library I published it to on a Sharepoint 2007 server disappeared. 

 

I double-checked the “Enable form merging” option within the Form Options of InfoPath, and it was checked. 

In fact, when opening a new instance of the form, the Merge Forms option was available.  The view was just missing from Sharepoint.

To resolve the issue I simply unchecked the option, published the form, then rechecked the option and published the form again.  The view then magically appeared.