Khanfar Blog

Creating Custom SharePoint Timer Job

2009-07-22T01:31:00.000-07:00

The first thing you need to do is create a class that inherits from the Microsoft.SharePoint.Administration.SPJobDefinition class. To implement this class, you need to create a few constructors and override the Execute() method, like so:

namespace SharePointApps.TaskLogger {
public class TaskLoggerJob : SPJobDefinition{

public TaskLoggerJob ()
: base(){
}
/* this constructor will be used to define the SP server where we want to install the job*/
public TaskLoggerJob (string jobName, SPService service, SPServer server,SPJobLockType targetType)
: base (jobName, service, server, targetType) {
}

/* this constructor will be used to assign the job for SP server*/

public TaskLoggerJob (string jobName, SPWebApplication webApplication)
: base (jobName, webApplication, null, SPJobLockType.ContentDatabase) {
this.Title = "Task Logger";
}

public override void Execute (Guid contentDbId) {
// get a reference to the current site collection's content database
SPWebApplication webApplication = this.Parent as SPWebApplication;
SPContentDatabase contentDb = webApplication.ContentDatabases[contentDbId];

// get a reference to the "Tasks" list in the RootWeb of the first site collection in the content database
SPList taskList = contentDb.Sites[0].RootWeb.Lists["Tasks"];

// create a new task, set the Title to the current day/time, and update the item
SPListItem newTask = taskList.Items.Add();
newTask["Title"] = DateTime.Now.ToString();
newTask.Update();
}
}
}

Aside from the requirement of inheriting from the SPJobDefinition class, the only other requirement is that the class override the Execute virtual method defined in the SPJobDefinition class. This is the method that Windows SharePoint Services calls when the job is executed. It receives a single parameter, the ID of the content database that is being processed by the job. With the custom timer job in this article, it returns the value of Guid.Empty because the target type of the job is not a content database. The Execute method in the warmup job issues a request for the home page of each site collection in the specified Web application, as shown in this example.

Unfortunately the only way to do this is through code, but it sure would be one heck of a candidate for a custom STSADM command. Anyway, since we don't have that today, I like to use the feature activated & deactivated events to install/uninstall my custom jobs.

To do this, you have to create another class that inherits from the Microsoft.SharePoint.SPFeatureReceiver class and implement the FeatureActivated & FeatureDeactivated event handlers like so:

namespace SharePointApps.TaskLogger {
class TaskLoggerJobInstaller : SPFeatureReceiver {
const string TASK_LOGGER_JOB_NAME = "TaskLogger";
public override void FeatureInstalled (SPFeatureReceiverProperties properties) {
}

public override void FeatureUninstalling (SPFeatureReceiverProperties properties) {
}

public override void FeatureActivated (SPFeatureReceiverProperties properties) {
SPSite site = properties.Feature.Parent as SPSite;

// make sure the job isn't already registered
foreach (SPJobDefinition job in site.WebApplication.JobDefinitions) {
if (job.Name == TASK_LOGGER_JOB_NAME)
job.Delete();
}

// install the job
TaskLoggerJob taskLoggerJob = new TaskLoggerJob(TASK_LOGGER_JOB_NAME, site.WebApplication);

SPMinuteSchedule schedule = new SPMinuteSchedule();
schedule.BeginSecond = 0;
schedule.EndSecond = 59;
schedule.Interval = 5;
taskLoggerJob.Schedule = schedule;

taskLoggerJob.Update();
}

public override void FeatureDeactivating (SPFeatureReceiverProperties properties) {
SPSite site = properties.Feature.Parent as SPSite;

// delete the job
foreach (SPJobDefinition job in site.WebApplication.JobDefinitions) {
if (job.Name == TASK_LOGGER_JOB_NAME)
job.Delete();
}
}
}
}
Now... to get it working, all you need to do is:

Deploy the strongly named assembly to the GAC.
Reset IIS (required for SharePoint to "see" the new timer job in the GAC).
Create a feature specifying the receiver class and assembly that contains the event receivers.
Install the feature.
Activate the feature.
This sample timer job assumes it's running within the context of a WSS v3 site that has a list created with the Tasks list template in the root web within the site collection (or, just create a Team Site at the root of your site collection).

Once you activate the feature, it should show up on the Timer Job Definitions page in Central Administration / Operations. It won't appear in the Timer Job Status page until it's executed at least one time. Wait for five minutes or so (the schedule this sample is using) to see if it's running. You should start to see items showing up in the Tasks list in the root site in your site collection.

Or, you can use this Windows SharePoint Solution Package (*.WSP) to deploy the prebuilt timer job used in this article (handles steps 1-4 above):

To deploy the WSP file, simply add it to the solution store using STSADM (using the following command) and then deploy it to the desired site:

stsadm –o addsolution –filename SharePointApps.TaskLoggerJob.ws

SharePoint Database Migration

2008-01-20T00:21:00.000-08:00

This post describes one of the main migration processes from SharePoint 2003 to SharePoint 2007;It called Database migration. This solutions is one of the most easiest solution, which is depend on moving whole content as it is to the new server.
To start the migration process, you should follow the following steps:

1. You must run the Prescan.exe tool on the WSS database to prepare the database to be added to the WSS 3.0 Web application

To use the Prescan.exe tool to scan the WSS database, follow these steps:
a. Copy the Prescan.exe tool on the WSS 3.0 server to a folder on the WSS server(Note The Prescan.exe tool is located on the WSS 3.0 server in the following folder: Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN)

b. Run the prescan.exe tool from the prompt and type the following commands: prescan.exe /c preupgradescanconfig.xml /all. At the end of the process you will receive a report if the upgrade process succeeds or not.

2. Detach the Desired Database form Database Server and move it to SharePoint 2007 Database Server.

3. Create Web application

4. Delete the Content Database of the Web applications that we have created .

5. Go to stsadm.exe tool (Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN) and use this command to attach the migrated Database to the web application that you created.

stsadm.exe -o addcontentdb
-url url
-databasename
[-databaseserver ]
[-databaseuser ]
[-databasepassword ]
[-sitewarning ]
[-sitemax ]

SIP ( Session Initial protocol )

2007-09-12T03:45:00.000-07:00

SIP Definition:
SIP stands for Session Initiation Protocol. It is an application-layer control protocol which has been developed and designed within the IETF. The protocol has been designed with easy implementation, good scalability, and flexibility in mind.
The protocol is used for creating, modifying, and terminating sessions with one or more participants. By sessions we understand a set of senders and receivers that communicate and the state kept in those senders and receivers during the communication. Examples of a session can include Internet telephone calls,
distribution of multimedia, multimedia conferences, distributed computer games, etc.
SIP is not the only protocol that the communicating devices will need. It is not meant to be a general purpose protocol. Purpose of SIP is just to make the communication possible, the communication itself must be achieved by another means (and possibly another protocol). Two protocols that are most often used
along with SIP are RTP and SDP. RTP protocol is used to carry the real-time multimedia data (including audio, video, and text), the protocol makes it possible to encode and split the data into packets and transport such packets over the Internet. Another important protocol is SDP, which is used to describe and encode
capabilities of session participants. Such a description is then used to negotiate the characteristics of the session so that all the devices can participate.
(it is also can be described as : a text-based protocol that used in the application layer , it is used to manage signaling and session between two end points ) .
The SIP entities are identified by URI ( Uniform Resource Identifier ) , and the form will be as following:

sip:username@domain

Suppose that you want to call peter at yahoo domain , so when you invite him the SIP URI will be as following

sip:peterUserName@yahoo.com

SIP Network Elements:

1- User Agents: are the endpoints that use SIP to find each other and to a negotiate session. This user can refer to the User Agent Server (UAS) or User Agents Clients (UAC). User Agent Server is the endpoint that receives requests and sends responses, where the User agent Client is the endpoint the send requests and receives responses.
so the user agent can be a UAS or UAC , when you are the caller , you send the invite request for the Callee who will receive the request and send a response , so you are a UAC and the Callee is UAS.

2- Proxy Server:
Proxy servers are very important entities in the SIP infrastructure , its is used to routing a session
invitations to according to user agent location and accounting , the session invitation will traverse a long set
of proxies until it find the proxy that actually know the location of the callee.

User Joe uses address sip:bob@b.com to call Bob. Joe's user agent doesn't know how to route the invitation itself but it is configured to send all outbound traffic to the company SIP proxy server proxy.a.com. The proxy server figures out that user sip:bob@b.com is in a different company so it will look up B's SIP proxy
server and send the invitation there. B's proxy server can be either preconfigured at proxy.a.com or the proxy will use DNS SRV records to find B's proxy server. The invitation reaches proxy.bo.com. The proxy knows that Bob is currently sitting in his office and is reachable through phone on his desk, which has IP
address 1.2.3.4, so the proxy will send the invitation there. But the question is how the proxy b.com know the location of the callee? The third entity in the SIP Infrastructure is (3- Registrar) . when sip:bob@b.com
is activate , his information that represent his address is sent to Registrar and stored in the location database , so the proxy b.com the information in the location database to determine the location of callee , these information represent the ipaddress of the calle , the port and the username. Before the callee onfo is stored
in the location database the SIP URI is map to : sip:username@CalleeIPaddress.com .

Import User Profiles form Database

2007-09-12T01:33:00.000-07:00

Before Describe the process of importing user profiles from BDC , everybody must consider this note

BDC cannot act as the primary source for user profile information. BDC can only work as a supplementary data source, in other words, you must have an import connection setup with say Active Directory or something else, before you can choose to supplement that information from BDC. BDC cannot be your master import connection.
Prerequisite : Configuring Single Sign On Service
Now you can start importing user profiles by following these steps :
1. In the SSP Admin page you’ll see a whole section devoted to the BDC. Click on ‘Import application definition’.

2. Use the browser button to locate our application definition file, or type in the path and filename yourself. Leave all the other options as they are for the time being, and click ‘Import’

Note : to Create BDC xml file , you can use Metaman tool
http://www.bdcmetaman.com/downloads/BDCMetaMan2.0.0.2.zip

3. In the SSP Admin page ,go to section users profiles and properties. Click on ‘Import New Connection’. Add a new connection for the new data sources (DBC)

4. After applying the steps above, the database info is added to user profile, and you have the option to create new properties that use BDC as main source for their values