Archive

Archive for November, 2010

Custom Action to Trigger a SharePoint Timer Job

November 27, 2010 Leave a comment

In my last post I demonstrated how to create a SharePoint Custom Action to appear on a specific SharePoint List. When a user clicked the action it ran some of our custom code.

Today we will try to extend that example and run a SharePoint Timer Job on the click of our custom action.

I am making the following assumptions:

  • You have read my previous post and have created the custom action
  • You know how to create and deploy Custom Timer Job definitions

The Problem

SharePoint Timer Job instances are persisted in the configuration database. Typically the SharePoint Farm service account or other accounts that have been given permissions on this database explicitly are able to write to this database.

For this reason when you try to execute a SharePoint Timer Job from within a site collection it will generally fail even if you run it within a SPSecurity.RunWithElevatedPrivileges code block. Running with elevated priviledges results in the code being run in the context of the Application Pool account (referred to as the System Account by SharePoint). Unless you have deviated from the best practices guidelines this will result in the following error:

Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Access denied.

You could always get around this by explicitly giving the Application Pool account permissions on the Configuration Database or by setting the Farm account as also being the Application Pool account for your Web Application. However, both these approaches are not recommended and are a deviation from the best practices guidelines.

The Solution

In my previous blog post, we created a custom action and deployed it. We used our custom action to send the user to a custom aspx page (with code-behind) that was located in the layouts folder. In the code behind we ran the custom code we wanted to execute. In this way we were able to create a custom action that ran some custom code on the click of our custom action.

To use our custom action to trigger a SharePoint Timer Job we need to add the following code in the aspx code-behind page:

namespace MyProject.CustomJobDefinitions
{
    public class JobInitiator: SPJobDefinition
    {
        public JobInitiator()
            : base()
        {
        }
        public JobInitiator(string jobName, SPService service, SPServer server, SPJobLockType targetType)	 
	            : base(jobName, service, server, targetType)
        {
	 
        }
        public JobInitiator(string jobName, SPWebApplication webApplication)
            : base(jobName, webApplication, null, SPJobLockType.None)
        {
            this.Title = "JobInitiator";
        }
         public override void Execute(Guid targetInstanceId)
        {
            using (SPSite site = this.WebApplication.Sites["/"])
            {
                using (SPWeb web = site.RootWeb)
                {
                    if (web.Properties["InitiatorJobFlag"] != null)
                    {
                        // Reset the flag 
                        Helper.SetSiteProperty(site, "InitiatorJobFlag", null);
                        // This is the job we want to run that does some stuff. It could be any job we want to run
                        CustomJobToRun process = new CustomJobToRun("My Job", WebApplication);
                        process.Execute(targetInstanceId);
                    }
                }
            }
        } 
    }
}

And below is the very useful ‘SetSiteProperty’ helper method:

        public static void SetSiteProperty(SPSite site, string propertyName, string value)
        {
            bool unsafeUpdateValue = site.RootWeb.AllowUnsafeUpdates;
            site.RootWeb.AllowUnsafeUpdates = true;
            if (site.RootWeb.Properties.ContainsKey(propertyName))
            {
                site.RootWeb.Properties[propertyName] = value;
            }
            else
            {
                site.RootWeb.Properties.Add(propertyName, value);
            }

            site.RootWeb.Properties.Update();
            site.RootWeb.AllowUnsafeUpdates = unsafeUpdateValue;
        }

Now that we have created our Custom Timer Job Definition, we can create a feature (scoped at Farm or WebApplication) and in the FeatureReciever feature activated event we add the following code:

JobInitiator job = new JobInitiator("JobInitiator", webApp)
            {
                Schedule = new SPMinuteSchedule
                {
                    BeginSecond = 0,
                    EndSecond = 59,
                    Interval = 1
                }
            };
            job.Update(true);

The schedule above ensures that our Custom Timer Job will run every minute. So our timer job executes every single minute and checks a property on the RootWeb of our Site Collection. If this property is set then it runs the specified Job of our choice.

And then finally in the code-behind file of our aspx page we add the following code:

        protected override void OnLoad(EventArgs e)
        {
            base.OnLoad(e);
            Helper.SetSiteProperty(SPContext.Current.Site, "InitiatorJobFlag", "RunNow");
        }

So there we have it, by following this way we were able to create a Custom Action that, when clicked, triggers any SharePoint Timer Job we would like to run.

You might wonder why am I using a Job to execute another Job? Well there could be a scenario where you might want to run an OTB SharePoint Timer Job in which case this way would work.

In my specific scenario I had created a Job that was scheduled to run once every day. By using the above method I can easily trigger the execution of this Job on demand without interfering with its normal schedule.

SharePoint 2010: Custom action that executes custom code

November 21, 2010 18 comments

In 2007 it was possible to create a custom action and then link it to some code.

You did this by first declaring your custom action in an elements.xml file (which you would then deploy as part of a feature):

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction
    Id="MyCustomAction"
    RegistrationType="List"
    GroupId="ActionsMenu"
    Location="Microsoft.SharePoint.StandardMenu"
    Sequence="1000"
    ControlAssembly="[Fully qualified assembly name]"
    ControlClass="MyNamespace.MyCustomAction">
  </CustomAction>
</Elements>

In the ControlAssembly and ControlClass attributes you specified your custom assembly and your custom class (a WebControl) that contained your custom code.

Then you created your custom WebControl:

public class MyCustomAction : WebControl 
{
    protected override void CreateChildControls() 
    {
        // Do some stuff
    }
}

Using this way we were able able to execute some custom code when someone clicked our custom action.

However, it seems that we cannot use this method in SharePoint 2010 although there are a few workarounds to achieve the same result. Below I will show you a way I used.

To start off with, I created an elements.xml file with the following declaration:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction Id="ContentTypeRibbonCustomization" RegistrationId="10005" RegistrationType="List" Location="CommandUI.Ribbon.ListView" Sequence="95" Title="Run Custom Code">
    <CommandUIExtension>
      <CommandUIDefinitions>
        <CommandUIDefinition Location="Ribbon.List.Settings.Controls._children">
          <Button Id="ContentTypeTest.Button" Image16by16="/_layouts/images/LSTPEND.gif" Image32by32="/_layouts/images/centraladmin_configurationwizards_farmconfiguration_32x32.png" Command="ContentTypeCommand" CommandType="General" Description="Runs some custom Code" TemplateAlias="o2" Sequence="95" LabelText="Perform My Action"/>
        </CommandUIDefinition>
      </CommandUIDefinitions>
      <CommandUIHandlers>
        <CommandUIHandler Command="ContentTypeCommand" CommandAction="/MyWeb/_layouts/CustomPages/MyCustomApplicationPage.aspx" />
      </CommandUIHandlers>
    </CommandUIExtension>
  </CustomAction>
</Elements>

This specifies that my Custom Action will appear on my custom list with TemplateType of 10005 (specified in the RegistrationId attribute) in the list view section.

I then used a Feature to depoy my Custom Action.

All my Custom Action does is to send the user to a custom page that is located in the Layouts folder:

/MyWeb/_layouts/CustomPages/MyCustomApplicationPage.aspx

I then created my custom aspx page. Below is the mark up for the page:

<%@ Assembly Name="MyCustomAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e246903334b3e97b" %>
<%@ Page Language="C#" AutoEventWireup="true" Inherits="MyCustomNamespace.MyCustomControl"
    Debug="true" %>

And finally, below is the code behind for the aspx page:

namespace MyCustomNamespace
{
    public class MyCustomControl: UserControl
    {    
        protected override void OnLoad(EventArgs e)
        {
            base.OnLoad(e);
            // run some custom code
            // then redirect the user back to the original page
        }
    }
}

Using this way I was able to link some custom code that would execute in response to someone clicking my custom action.

For everything you need to know about customising the SharePoin Ribbon please go here to Chris O’Brien’s blog post.

After spending a lot of time investigating how to customise the Ribbon to meet the requirements I had I can safely say this is by far the best and most comprehensive blog post I found on the net.

As I said earlier there are other ways you can use to achieve the same objective. You can easily link a custom action to execute some javascript function. I guess one option would be to link it to a javascript function that then invoked some server side code. I havent tried this myself so I cannot say for sure if this approach would work.

If you had a similar issue to the one I had above, I would be interested in hearing what approach you used to resolve it (if different to the approach I used).

How To: Enable Incomming emails on a Custom SharePoint List

November 11, 2010 Leave a comment

First of all if this list is hosted in a Meeting Workspace Web then this will not work. Please refer to this post for complete details.

Briefly, this is what you need to do:

  • Create your custom SharePoint list
  • Attach an Event handler of type ‘EmailReceived’ to your list (once you do this the ‘Incoming Email Settings’ option will appear in the List Settings section of the site)
  • Add some code to your event handler as per your requirements to process the email
  • Deploy your list the usual way and create an instance of it (could be done as part of the deployment or via the UI)

In the example below I am picking up the subject of the email, creating a new list item where I set the title field value to match the subject. This is a very simple example but you can do a whole lot of stuff in this event handler such as processing attachments e.t.c.

public override void EmailReceived(SPList list, SPEmailMessage emailMessage, String receiverData)
{
    SPListItem newItem = list.Items.Add();
    newItem["Title"] = emailMessage.Headers["subject"]
    newItem.Update();
}

For complete details on how to configure your environment to facilitate processing of incoming emails please click here or here. There is also a very useful technet video on the subject here.

Enable Incoming emails on a Custom SharePoint List

November 11, 2010 12 comments

We had a requirement recently whereby we needed to create a custom SharePoint list that would accept incoming emails. This post is going to be very long so bear with me …

Initially, I was very optimisitic that all I needed to do was to setup incoming notifications via Central Administration and then turn on Incoming Email notifications on the list itself and it should all fall into place.

How wrong I was!

Setting up the Development Enviornment

The first thing you have to do is to setup your development enviornment so that you can send emails and your SharePoint list can recieve them. This turned out to be a massive task. I spent hours searching through blogs, forums and various sites to try and setup the infrastructure on my dev (Hyper-v VM based) enviornment but I just could not get it to work. Eventually I stubmled upon this post from Marc Charmois that explained in detail how to get the whole thing to work on your Dev enriornment:

Enabling Incoming-emails on the SharePoint List. The Problem:

Ok, so I created a custom SharePoint List went to List Settings and looked for the ‘In-coming email settings’ link under the ‘Communication’ settings and found it to be non-existent. Googling on this brought all sorts of theories, hearsay and rumours to light. Some thought that this option was only available on x,y or z type of lists then there were others that thought it was only available on a,b,c or d type of lists but one thing was for sure no one seemed to know for a fact what was actually going on. As I was looking at the object model I found a property on the SPList object called ‘CanReceieveEmail’. I thought maybe this was the answer i.e. all I needed to do was to get my list and set this property to true and it will all work. However you cannot set this property you can only get its value. I believe this property is used by the SharePoint UI to decide whether or not to show the ‘In-coming Email Settings’ link in the list settings area.

So it was time to fire up Reflector to find a way to set this property maybe through reflection?

Looking at the property via reflection I found:

public bool get_CanReceiveEmail()
{
    if (!SPEmailHandler.HasHandler(this.BaseTemplate) && !this.HasExternalEmailHandler)
    {
        return false;
    }
    return !SPMeeting.IsMeetingWorkspaceWeb(this.ParentWeb);
}

And ..

public static bool HasHandler(SPListTemplateType templateType)
{
    if ((((templateType != SPListTemplateType.Announcements) && (templateType !=    SPListTemplateType.Events)) && ((templateType != SPListTemplateType.DocumentLibrary)  && (templateType != SPListTemplateType.PictureLibrary))) && ((templateType !=  SPListTemplateType.XMLForm) && (templateType != SPListTemplateType.DiscussionBoard)))
    {
        return (templateType == SPListTemplateType.Posts);
    }
    return true;
}

And finally ….

internal bool HasExternalEmailHandler
{
    get
    {
        bool flag = false;
        foreach (SPEventReceiverDefinition definition in this.EventReceivers)
        {
            if (definition.Type == SPEventReceiverType.EmailReceived)
            {
                flag = true;
            }
        }
        return flag;
    }
}

From this we can determine the following:

If the list, regardless of its type, appears in a meeting workspace web it will not be able to recieve in-coming emails.

The list either needs to have the BaseTemplate of one of the following:

  • Announcements
  • Events
  • DocumentLibrary
  • PictureLibrary
  • XMLForm
  • DiscussionBoard
  • Posts

or it needs to have an event handler of type ‘EmailReceived’ attached to it.

An important point to note here is that it mentions the base template which should not be mistaken for the BaseType. What this means is that you could create a custom list that inherits from the BaseType Document Library but that does not mean that it will have incoming emails enabled. Your list will need to have the same BaseTemplate as the out of the box lists mentioned above which is not really ideal.

Enabling Incoming-emails on the SharePoint List. The Solution:

So the only route left for me to take was to go the Event Handler path. I attached the Event Handler (and the incomming email settings link started to appear in the list settings area) then sent an email to my list and debugged my code with a break point on my event handler. However it just never seemed to get hit and neither were my emails appearing in the list itself.

The mistake I was making was to attach the w3wp process but this is not the process that processes the incoming emails. I dont want to go into this in detail but the incoming emails are processed by a SharePoint job that runs every minute therefore the process I needed to attach was the OWSTimer process. Once I attached this process it started to hit my break point however the emails were still not appearing in the list.

One thing to note here is that whenever you make any code changes to this event handler, after you deploy the dll’s to GAC, you need to ensure you restart the SharePoint Timer Job Service because it holds a cached version of the dll’s.

Finally, the reason the emails were not appearing in the list was because this needs to be done via the Event Handler. For the lists that are from one of the Templates I mentioned above SharePoint understands how to process and add the email messages however for your own custom list it is down to the Developer to write the code to do this processing. The event handler though provides you an object of type SPEmailMessage which has all the data you require. Below is an example of how it can be used to add the email subject to a simple custom list with only a title field:

public override void EmailReceived(SPList list, SPEmailMessage emailMessage, String receiverData)
{
    SPListItem newItem = list.Items.Add();
    newItem["Title"] = emailMessage.Headers["subject"]
    newItem.Update();
}

You can easily extend it to deal with attachments as well but that is for another day!

P.S Illustrations to be added soon….