Thursday, June 11, 2009

State of Milyli

It's been a little while since I wrote about our little company Milyli. Since that was one of the original purposes of starting this blog, I figured I'd give a little update. Things are going well, but it's a lot of hard work.

As for myself, being mostly in charge of product development can be a little frustrating working almost alone. It's not that I'm the only person working to make the company and product a success, not by a long shot. But I am effectively the only developer working on the code. Granted, I get to develop the application whichever way I want. But for a not small piece of software, that's not as ideal as it might sound. I really miss being able to bounce ideas off of other developers that have a good sense of how the application works. The small increments of work are also not as satisfying when you realize that no work has been done on the rest of the application.

Besides the application, I did a bunch of project work early on and it looks like I'm about to get another load. I enjoy working on the consulting side. The projects are different and there's always a chance to learn a new trick of some sort. But it is frustrating to see so much of our already limited time not being spent on our product.

As for my two partners, they've been doing the bulk of the bill paying for the past number of months. They're each feeling the pain and glory in their own ways.

One of them is working with technology older than even that used at our last place of employment. The old code is plenty crufty and has more than its share of best practice failings. That and interacting with and managing the client seems to be wearing him a bit thin of late.

My other partner spends his time schizophrenically jumping between business development, market analysis, office manager, project manager and consultant. Basically filling in wherever needs filling. I am not envious at all of that role.

All I can do is thank them and keep my head down and keep making software of all sorts work better. What's important to remember is that the Dip is worth getting through. I'm pretty sure we haven't seen the bottom yet and if by some miracle we have, that will just be a pleasant little surprise.

There have been a number of high points as well. We get to make the environment the way we like it including eating lunch together everyday that we are in the office. We have started to see some preliminary design ideas for the look of our application. They look great and I can't wait to start implementing. We have signed on some work that should pay our bills for a while. We have other new, exciting projects coming in that look like they will fit great with our skills and experience. And we keep meeting new people to talk about their problems and solutions even when we aren't necessarily the best folks to tackle the resulting projects.

And that's where it all stands right now; things are going well, but it's a lot of hard work.

Wednesday, June 10, 2009

Create SharePoint Job Timer Definitions

So I realized recently that one of my MOSS applications did not have all of the timer jobs defined for it that it should have. You know, you go to Central Admin -> Operations -> Job Timer Definitions and they just aren't all there. Which ones should be there by default? Here's a good list. Just how do you go about getting some of those jobs in there? There's a bunch of tricks and supported approaches.

The publishing tasks (Scheduled Approval, Scheduled Page Review, etc.) can be created in one shot by creating a new web site collection using the publishing portal template under the existing application and deleting it. The timer definitions stay, the services start running and everyone is happy. Yaaaay!

Some of the definitions will be created if you set the appropriate properties using stsadm.
E.g., stsadm -o setproperty -pn job-immediate-alerts -pv "Every 5 minutes between 0 and 59" -url http://your-site.com
Once again the timer job shows up and most of the time your alerts start flowing. Hooray for our side!

But there are a bunch of definitions that there don't appear to be tools to create on their own. Sure you can back up the database, blow away the application, create a new application with the correct template and same name, restore the database, and fix the issues (there's always some). I didn't want to go through all that, though I'm not sure that what I figured out was less work. What I ended up doing was to write some crafty SQL. Well, maybe it was just plain old mundane and obvious SQL, but that's what I did. All the answers lie in the Objects table in your config database.

First find the id of your web application. This is going to be the parent id of the timer record you will insert. The following SQL worked pretty well for me.

SELECT * FROM Objects WHERE Properties LIKE '%SPWebApplication%'

Next, query the table and look for existing definitions of the jobs you are missing. If you don't already have an application that contains them, you can create one. The Name column of the records contains the stsadm property for each timer job. Here's a list of a few. And here's some SQL to help you out.

SELECT * FROM Objects WHERE o.Name LIKE 'job-%'

Find a record for the job you are interested in. You will need two pieces of information: the ClassId and the Properties contents. The classId tells the system which timer job to create and the Properties contain the frequency of the timer job and a couple of other easy to change settings.

Last, run a simple insert statement like the following...
INSERT Objects(Id, ClassId, ParentId, Name, Status, Properties)
VALUES (NEWID(), '[JobClassId]', '[ParentApplicationId]', '[JobPropertyName]', 0,'[PropertyContents]')

A quick refresh of the Timer Job Definitions page will show the new job ready to run. You may need to restart the Windows SharePoint Services Timer service before the new jobs are picked up though. Also, the Timer Job Status list will not show the new jobs until after the first time they are run. Be patient for those weekly tasks.

Again with the disclaimer: I saw in some posts that Microsoft doesn't take to kindly to messing around with the SharePoint databases. If you want continued support, tweak at your own risk. This should really only be used as a last resort in any case as there are usually other options. I just happened across someone asking this question and decided to figure out how to do it.


SharePoint Alerts Not Sending

There are all sorts of reasons why your alerts might not be working in SharePoint. There are a whole slew of causes as to why with the most common being a backup and restore to a new server, farm, environment, etc. Googling will provide you with a bunch of options for the common problems pretty quickly.

None of those really worked for me. I did eventually solve my problem though. One post pointed me at the EventBatches table in the content database. This table contains two pieces of information, the last event time and the last event id processed. It turned out that the id in the EventBatches table was FAR greater than the last id in the EventCache table. This was probably the result of some less than optimal backup and restore voodoo that had gone on previously. Regardless, I set the id in the EventBatches table equal to the last EventCache id and alerts started flowing freely from that point on.

I wasn't able to find anyone that just came flat out and said that, so there it is.

Disclaimer: I saw in some posts that Microsoft doesn't take to kindly to messing around with the SharePoint databases. If you want continued support, tweak at your own risk.