Suspending SLAM'ing while list backup runs

May 4, 2009 at 7:50 AM
Hello all,

I have SLAM'ed a list that gets mirrored by a console application every night to another list. The source list contains active tickets from our helpdesk - the target list is the ticket archive. The target list is also SLAM'ed. We have experienced lots of errors in the Windows event log while the console application is running. Is it possible to suspend SLAM'ing for a set timeframe, then restart it and beginn a list synchronization job using e.g. Windows scheduled jobs or the Sharepoint timer service?

Thanks in advance

Best regards

May 4, 2009 at 2:56 PM
Hi Silmarin,

The errors you are encountering in your console app are likely because the console app can't find the SLAM config.  SLAM works just fine with console apps, as long as you point to the correct SLAM config.  Create an AWS.SLAM.ConfigurationManager.Config key in the app.config and point it to you SLAM config.

Why are you copying your tickets to another list?  If you are slamming your main list, you already have a back up of all the data in your SQL database.  I suspect I'm missing something...



May 4, 2009 at 3:08 PM
Hi Allan,

thanks for your reply. I thought along that line as well.

Well ... the list source contained almost 20.000 items a couple of weeks ago and our users began to report performance issues when creating new tickets and some of our sharepoint designer workflows started to get weird. After reviewing our options to add columns to the index no noticeable performance gains were reached. So we decided to offload items form that list into an archive. Along the line we remove all workflow related info from the tickets (as they are closed anyway). Performance is now a lot better with the ticket list.

SLAM - in this scenario - is used to grab a couple of fields an copy it to a SQL table to provide a lean and clean basis for reporting. Since especially ticket timestamps (created date, first solved date, closed date etc.) are used, SLAM does a wonderful job and our reporting performance is great. Before we queried the AllUserData table directly (yeah we know we shoudn't :) ) and performance was terrible due to all the versions our queries had to run through.

Thanks again & best regards

May 4, 2009 at 3:20 PM
Happy to help!  The issue with list performance on really big lists is actually a limitation of the SharePoint UI, not the underlying list itself.  The SharePoint product group published a really informative white paper on the subject if you are interested:

In any case, I would suggest you SLAM all fields in your ticket and use that not only for reporting but managing your archive as well (since you can then build an interface to search against the archive if you want).  You would need to create a custom type profile, however, to override the default delete behavior since SLAM will automatically delete records from your slammed table when they are deleted from the list. 

If you find SLAM useful, by the way, please take a moment to review our project.

Thanks and happy slamming!

May 5, 2009 at 4:54 AM
Actually, SLAM'ing all list fields to a SQL table was my first plan as well. However one of the requirements from the support team was to keep all the versions of the tickets so they are able to see what was done and in which timeframe (service level agreement stuff). So SLAM couldn't help here ... or at least I don't know how to SLAM versions :) .

Aside from that - a great feature would be to be able to select which event receiver are "active" for a given list. Exactly what you mentioned. Like a checkbox list with "Enable insert event receiver" ,  "Enable update event receiver" , etc.

Of course I have already reviewed your great project. ... I think it was the previous version though :) .

Best regards

May 5, 2009 at 10:55 PM
While we have dealt with versioning ourselves with a custom Profile, our solution is rather specific to what some of our applications and is not a general solution to storing all item versions in SLAM.  SLAM was developed with the intent of leaving archiving up to SharePoint since it already does it.  To address the issue of suppressing delete, as Allan suggested you can create a profile and override delete OR you can use a tool like the SharePoint Inspector and just remove the delete event from the list since it sounds like it is only a particular case.  When designing SLAM it does not seem likely that a situation would arise where we would want to synch new items and updates but not deletes without a peculiar need and therefore a Profile.  Creating a Profile for suppressing deletes would be fairly simple by creating a project with say an implemention of AWS.SLAM.Events.IItemDeleter called DummyDeleter that does nothing in its Delete method (and empty constructor), and an implemention of AWS.SLAM.StructureMap.ITypeProfile called NoDeleteTypeProfile where CreateProfile does something like "registry.CreateProfile(name).For<IItemDeleter>().UseConcreteType<DummyDeleter>();".  Put the resulting dll into your GAC, add the TypeProfiles section (as described: ) with an entry for the NoDeleteTypeProfile.  The list that needs overridden then would have an extra attribute, TypeProfile="NoDelete" or whatever you want to call it. 

Creating a general profile for versioning would require a bit more effort, but the primary change would just be the tracking of the VersionId in each table and associations would be defined as ListItemID, VerisonId to ListItemID to establish version to item associations.  It would require implementing all layers though, from Creater/Updater/Deleter through DataServices.

Hope that helps,