Important: this should be carried out on a non-production server first and then refined before deploying to live!
I just created a timer scheduled job in SharePoint with the help of Some Code Off The Internet (TM) plus a few hard-earned lessons all of my own.
The important thing to realise about a timer job is that it's just another SharePoint feature plus dll with some feature overriding code in it. Nothing more, nothing less. When I download a project with all the components and setup stuff, I tend to just work with the actual .cs files in a class library, make the dll and then do it manually. That means I know what's going on.
The code I downloaded was here
(thank you Alexander Brütt)
But what I did rather than open the whole package as a Visual Studio item was to open the whole thing and drop all the build instruction files because I was deploying to another machine anyway. The three files you really need are
Job.cs
JobInstaller.cs
Feature.xml (which you will put somewhere separate in the FEATURES folder in the Twelve Hive anyway)
The rest is just detail. But don't forget the strong key. It saves time since that's the key in your feature.xml file. Also there are some items in the folder with dollar signs on them. They're for you to change the name. I called the Job class CustomSharePointJob and the Installer class CustomSharePointJobInstaller. Yes I was looking for an easy life there :)
Build the thing as a dll (forgetting the manifest xml and all that packaging stuff) and if there are build errors, chances are you need to conjure up a couple of GUIDs to identify the dll as the code has $guid somewhere, I think. It should eventually build ok.
OK, then GAC register your dll and make sure the info in the feature.xml file matches up. The Feature Receiver line should be the same as your components. Stick it into the Twelve Hive. Now fire up the command line, change dir to your twelve hive BIN folder and enter the following piece of sublime poetry:
stsadm -o installfeature -filename CustomSharePointJob\Feature.xml
And then
Hopefully it should give you the thumbs up. But just to make sure, open up SharePoint Central Admin and navigate to Operations - Timer Job Definitions. Your timer job should be there and its schedule should be Minutes.
OK, we want to deactivate it for a moment and do some work on it. So in stsadm
The wonderful thing about this code is that it has event receivers for the feature deactivating, and the event triggers a delete. So you don't have to worry about taking the job off the list in sharepoint central admin, it's all taken care of.
Now in Visual Studio, have a look at the Job.cs folder. I put in instructions to send me an email when the job fired - just to make sure it worked ok. In order to do that I had to instantiate an SPSite object and SPWeb object which I did as per usual using a site url. But there is one important difference to note. The code here specifies a job lock type of SPJobLockType.ContentDatabase. This means that the job is designed to fire against every content database on that server. I was wondering why I was getting nine emails! Go into your Job.cs file and change that to SPJobLockType.Job and you are sorted, it will only fire the once.
Also, what else do I need to do. Well I don't want the damn thing running every 2 minutes, once a day is enough. I scoured the internet looking for something telling me how to set up a daily schedule and eventually found a solution which I've amended slightly to run at 6am. If, for testing purposes, you want to change that hour, just move up the BeginHour and EndHour properties:
SPDailySchedule schedule = new SPDailySchedule();
schedule.BeginHour = 6;
schedule.BeginMinute = 15;
schedule.BeginSecond = 0;
schedule.EndSecond = 15;
schedule.EndMinute = 15;
schedule.EndHour = 6;
myCustomSharePointJob.Schedule = schedule;
myCustomSharePointJob.Update();
I put in some code to do the thing I wanted to do on the site I wanted to do it on - this goes in the Execute method - recompiled the dll and GAC registered it once more. Ready to do battle - but wait -
Now this next step is very important
Save yourselves a good few hours of pain and do this now. Just when you've finished running gacutil from the command line, enter the following line:
net stop sptimerv3
(it will be sptimerv4 for you sharepoint 2010 heads)
And then straight afterwards type
net start sptimerv3
This stops and restarts the OWSTIMER.EXE process for sharepoint. (This is why not to do this on live.) The reason this has to be done is otherwise, the process will cache your old dll FOREVER. It doesn't matter if you re-register it seven times, doesn't matter if you delete the damn thing or restart the job or whatever - it will just keep caching it.
This has to be done every time the dll is recompiled!
Then - and only then - reactivate the feature by going into stsadm and entering the activatefeature command as described above. Then hopefully all should be well.
I would like to recommend the following links which are very helpful:
No comments:
Post a Comment