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.