Remove Versions in Wiki pages libraries using web service

Everybody using extensively Wiki libraries while relying on Versions to track changes has encountered at least once the issue of not being able to access the Versions History via the browser UI. Trying to access the Versions History via the ECB menu on an item fails and it is presented with the dreaded message instead stating “Server Out Of Memory”. Even worse, not actual error message being logged in the log files.

So the question from end-users was: “How can we actually remove versions if you can’t even tell how many are available?”.

Also, changing “Versioning Settings” via the Library settings, as you might be aware does not remove previous versions, but rather limits creation of new ones in the future to the configured limits. This practically adds up to the problem because it generates even more confusion for the users who expect to have stalled files removed automatically.

Such situation highlights once again the importance of having governance rules in place, even it is used as at least as guideline or recommendation for best-practices.

The issue becomes of extreme importance particularly when the library stores mission critical documentation for a large team (we talk about 100+ people actively consulting or updating this library) depends on it. Add to this extremely large wiki pages having images embedded of couple of megabytes – and problems are just around the corner.

I’ve been confronted with such a situation, not long ago and the issue we had to solve required a solution not only to enable access that function again, but also to enable end-users to recover from such situations by themselves.

Solution details

So as short reminder our requirements were as simple as:

  • Allow end-users to see how many versions are stored per each wiki page (Major and Minor)
  • Provide the possibility to remove unneeded versions on-demand for contributors even.
  • No-code solution was required (yeah, this gets challenging)

Of course, our first thought was to build a PowerShell script (despite the site being hosted on SharePoint 2007 at that time – meanwhile it runs on SharePoint 2010 – same solution works perfectly) and provide that to administrator, but we dismiss it quickly because end-users would not be able to execute it on-demand without support from Infrastructure team.

We fallback to building 2 Nintex workflows which would rely on a very powerful web service available in both SharePoint 2007 and SharePoint 2010 – the Versions.asmx web service (available of course <yourWebUrl>/_vti_bin/versions.asmx), namely using 2 main methods:

Both these methods are used in 2 different Nintex workflows as follows:

  1.  “Find All versions” – After execution to send out a Notification email to Initiator with the list of Version using a pre-defined pattern, as in “@2.5;0.1;0.2;0.3;0.4;0.5;0.6;0.7;0.8;0.9;0.10;0.11;0.12;0.13;0.14;0.15;0.16;0.17;0.18;0.19;0.20;0.21;0.22;0.23;0.24;0.25;0.26;0.27;0.28;0.29;0.30;0.31;0.32;0.33;1.0;1.1;1.2;2.0;2.1;2.2;2.3;2.4;” (Latest version on first position, followed by all minor/major versions available).
  2. “Remove Selected Versions” – takes as input part of the string above representing the actual versions and remove one by one each of them, in a loop.

“Find all versions” Workflow

"Find All Versions" Workflow

“Find All Versions” Workflow

The actual workflow is quite straightforward and it performs:

  • A “Query XML” activity which performs an XPath (//@version) stores the result it in a Collection (identified here by the workflow variable versions)

    Query XML activity

    Query XML activity

  • The actual notification activity simply sending email to Initiator with the content of the “versions” Variable.

“Remove selected versions” Workflow

This workflow is also pretty straightforward, though a little bit more challenging:

"Remove Selected Versions" Workflow

“Remove Selected Versions” Workflow

Conclusion

So by constructing 2 separate workflows we’ve provided the end-users the capability to remove un-necessary versions, beyond the settings in the library, which finally allowed them to gain back access to seeing the Versions comparison screen.

  • I’ve also shown precise usage of the 2 very important methods of the Versions.asmx workflow which also proved to be the only feasible way to access versions.
  • Any additional error processing has been removed in purpose to simplify the exposure of the main activities. In production environment we are actually collecting error messages and testing for them at the end of each activity, while storing either in the history log or by notifying the initiator of the error.
  • As a follow-up, it has been also decided to define a new Policy in the governance plan which enabled us to enforce the maximum number of versions (Minor – also known as Draft or Major  – or Published) stored in a list or library.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s