KB000112

A new feature introduced in Service Pack 2a allows K2 Server to be configured to retry the deleting of temporary files in SPS. The feature was introduced in order to deal with occurences where SharePoint locks documents for a time, even if they are not open.

Temporary InfoPath files that K2.net creates in a SharePoint document library are not deleted when the user submits the form. This occurs even though the “Delete Temporary File” option is selected in the InfoPath process wizard or client event.

For this to occur, all of the following conditions have to be true:

1. The InfoPath temporary file is stored in SharePoint
2. The process’ InfoPath document does not use the K2.net task pane and therefore when submitting the form, the user gets a dialogue box showing that the form was submitted successfully
3. The user does not immediately close the dialogue box stating that the form was submitted successfully
4. The user account submitting the form is different from the one that the K2.net Server runs under

Because InfoPath keeps a ‘lock’ on the form while the dialog box is open, and since the K2.net Server is using a different account; K2.net Server is denied access to the temporary file preventing it from being deleted.

Workarounds

Three workarounds are known to resolve the issue. Be aware that the workarounds may impact on other areas of system operation, consider the implications before implementing a workaround.

Change the InfoPath process document so that it does not display any messages when submitting the form. This option has a disadvantage in that no error messages will be displayed and the user will be unaware if the submit operation was successful or not. This option is therefore not recommended. If, however this is the only solution that can work, do the following:

Workaround 1 

1. In the InfoPath form design mode, go to Tools>Submitting Forms>Submit Options
2. Uncheck the box Show message indicating success or failure
3. Click OK and then OK again
4. Publish or save the form

These settings will be overwritten every time the user runs the InfoPath process wizard or when the document settings in K2.net Studio are updated.

Workaround 2

Enable the K2.net task pane on the InfoPath form. The K2.net task pane has its own Submit button which does not display a dialogue message when the form is submitted and therefore it does not keep a lock on the file allowing K2.net server to delete the temporary file.

When the InfoPath form makes use of digital signatures to sign certain sections of the form, the K2.net task pane cannot be used and therefore this will always be a risk when using digital signatures. Furthermore, when a user signs the data on a form, InfoPath will always prompt the user to save the file to disc. Because of this prompt, the file will also be locked for the period that this prompt is open. This means that the user will have to answer both prompts within the time limit that was set as described above. Note that even if the user answers yes at the prompt it will save the instance, but if it is still within the time limit that was set up then the delete action fired by K2.net Server may still execute and delete the file instance in time.

Workaround 3

Change the number of times that K2.net server tries to delete the file as well as the amount of time that it waits between the consecutive retries. To do this, add the following entries to the k2server.config file which can be found at the following location [K2 Installation Folder]in:

<K2Server>
 <InfoPath>
  <TempFile>
   <NumberOfRetries>10</NumberOfRetries>
   <MillisecondsBetweenRetries>2000</MillisecondsBetweenRetries>
  </TempFile>
 </InfoPath>
</K2Server>

By default K2.net server will attempt 5 retries and waits 1000 milliseconds between each retry. The default settings can be changed to increase the number of retries and lengthen the period between the retries.

Changing these settings will cause the current K2.net Server thread to stop responding for the duration that is specified. If the number of retries is increased with a long interval between the retries, this may have a performance impact on the K2.net Server.