Starting custom Sharepoint timer programatically

remote

When you need to start a timer job in SharePoint you can do it from Central Administration with a cool web interface.

There, you can see all timers Jobs in your farm and control their status and logs. But, sometimes we need to start a timer job from a Sharepoint front-end interface. I mean, a simple user wants to start a process that runs in background.

Yes, we have a timer job as a class, you can instantiate and call its RunNow method for starting the process. But, we need to do something else before that.

For security reasons, users can’t start timer jobs in front-end interface. In fact, you must write this Power Shell sentence in the application server or write in your feature activation method in feature receiver class.

PowerShell script

$snap = Get-PSSnapin | Where-Object { $_.Name -eq “Microsoft.SharePoint.Powershell” }
if ($snap -eq $null)
{
Add-PSSnapin “Microsoft.SharePoint.Powershell”
}
# get content web service
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
# turn off remote administration security
$contentService.RemoteAdministratorAccessDenied = $false
# update the web service
$contentService.Update()

C# code

// SET THE REMOTE ADMINISTATOR ACCESS DENIED FALSE
SPWebService.ContentService.RemoteAdministratorAccessDenied = false;
SPWebService.ContentService.Update();

Remeber that any timer job in Sharepoint is started by SP Timer and you need to restart that service in all farm servers when any change in your custom job are made.

Without modifing RemoteAdministrationAccessDenied to false when you try to start a job programatically a Access denied exception is thrown.

More information:

Custom SPJobDefinition and “Access denied” Error

Custom job and System.Security.SecurityException: Access Denied

Ejecución de una página ASP.NET

aspdotnet

Parte fundamental para entender como funciona ASP.NET y como puede afectar esto a tu forma de programar tus aplicaciones web. ASP.NET se planteó que la programación fuera “Event driven” que significa que cada página genera eventos. Entender cual es el orden de generación de los eventos es esencial para programar correctamente. Para verlo hablamos del ciclo de vida de la página.

Cuando llega una petición :

Construir el árbol de controles

Verás que las páginas en ASP.NET utilizan controles de servidor y esos controles están ordenados en forma de árbol tal y como ya pasa en las aplicaciones Winforms.

Evento Init

El primer evento que se ejecuta en una página es el Init. Tienes creados los controles pero estos aún no tienen los valores.

Cargar el estado y los datos recibidos

Aquí es donde se guardan los datos en los controles. En el caso que la petición sea un submit de un formulario previamente enviado también se guardaran estos valores nuevos.

Evento Load

El evento más comúnmente utilizado. Es donde tienes acceso a los valores en los controles. Aquí es importante no hacer inicializaciones sin antes comprobar que no se está realizando una petición Postback. Postback es la forma que tenemos para llamar las peticiones que envían información al servidor. Es decir, las llamadas creadas mediante una acción del usuario. No son Postback cuando la petición es directa mediante la barra de navegación del explorador o mediante un link simple (etiqueta a) de la página.

Evento acción del usuario / evento cambios en controles

Si se trata de una petición Postback quiere decir que el usuario ha realizado una acción, como por ejemplo el clic de un botón, esta acción es un evento que se debe tratar. También pueden ocurrir otros eventos que no tienen por que ser acciones de botones. Pueden ser eventos producidos por el cambio en una lista, el cambio en un texto. Este tipo de eventos también se tratan.

Evento LoadComplete

El evento anterior a procesar la página para su entrega al cliente.

Guardar el estado

Una de las características del ASP.NET es la utilización en cada página de una variable de estado denominada ViewState que permite recuperar el estado en que se ha enviado inicialmente la página. Fíjate que sin el ViewState no podrías saber que eventos de modificación se han producido.

Renderizar los controles

Otra característica de ASP.NET es la utilización de controles de servidor. Estos controles se caracterizan por empezar en “asp:”, tener un ID y un runat=”server”. Estos controles no pueden ser interpretados por ningún navegador ya que ellos solo interpretan Html. Por eso antes de enviar necesitas transformar los controles de servidor en Html.

Evento Unload

Ultimo evento en el ciclo. Se pueden liberar recursos ocupados en el proceso.

 

Para más información puedes comprar mi libro Guia Práctica de Asp.net

 

Más información:

Información general sobre el ciclo de vida de una página ASP.NET