Home - Szymon

8/21/2007

Validating your Share Point data in the presence of an event receiver

Assume the following scenario. I have a document library and I am uploading documents into the library by using the object model. I upload thousands of documents daily, and it is critical that the documents are not corrupted on their way into the library. To ensure data integrity, I set up a process whereby I compute a checksum of the byte stream and field values before sending it on to SharePoint and then compute the checksum on the SharePoint server again after uploading the file. If the two checksums match, the integrity of the data has been kept and we are ready to move on. But what if I have an event receiver set up on the library that modifies some field value after the file has been added to the library? This validation scheme is sure to fail. Ignoring validation in that particular case is not an option. How do we go about solving this issue and making sure that we can validate the data?

Posted at 10:17 PM by Szymon Rozga | Category: SharePoint | Permalink | Email this Post | Comments (1)

8/20/2007

Features and Solutions

One of the most useful features of WSS v3 is the model of deployment. This post gives a high-level view of both Features and Solutions to illustrate how useful they can be.

Features are the way in which WSS approaches packaging of new functionality. There are many ways in which one can extend WSS and MOSS. One option is to simply click through the Site Settings. For instance, if I wanted to create a new content type, I could do it by going into the Site Settings and then into the Content Types gallery and create new types using my mouse. A second approach would be to write a feature using XML and extend anything from Content Types to adding Custom Actions or defining new Fields or creating Receivers, etc. Receivers are particularly powerful because they allow us to write custom code that runs when a feature is activated. Consequently, I could place all my logic of creating new Fields and Content Types in C# code and have a receiver invoke this code. This is a powerful idea.

Moving up higher in the model of deployment, how do we deploy features? One way to do it is to create a directory in 12 hive\Templates\Features with the name of your feature, copy all relevant XML and code into it, and use STSADM.exe to install the features on the servers. This inefficiency is solved by using Solutions. These not only enable us to properly deploy features, but also allow us to deploy assemblies into the GAC and security policies under which the solutions will be run. One a solution is described by the developer and compiled into a WSP file, we use stsadm.exe to add the solution to the solution store and use the Central Administration to deploy the solution at a convenient time.

Understanding these parts of SharePoint is essential for junior developers (like myself). Once one begins to grasp how deployment is handled in Share Point, one can develop custom solutions with a clear vision of how one will take them from a development environment into a production environment.

Posted at 11:40 PM by Szymon Rozga | Category: SharePoint | Permalink | Email this Post | Comments (0)

8/16/2007

Seaching within a scope

I have been beginning to explore the Search Scopes capabilities of MOSS. This seems like a very powerful feature. Although I cannot speak on this feature intelligently yet, having taken a course specializing in search engines' design and implementation (CIS 430 with Prof. William Arms), I feel like I can express what I see as being useful and exciting about it.

At the most basic level, one of the ways in which we measure the "goodness" of a search engine is by the number of results returned and the number of those that are relevant. The number of results returned is not too relevant in our days of Google, but, it is important that a user finds the information he is looking for in the first page of results (It isn’t a life or death matter, but nobody likes to click on the next page of results).

For a user of a MOSS system with millions of documents, this can become quite difficult; especially if there can be some ambiguity in the search terms. If we could intelligently divide the body of documents into sets that would disambiguate a search, then we allow the user to find the information they are looking for faster.

Now, this is the kind of thing that Google has done with Google Images, Google News, etc. The important thing is that MOSS search gives the Administrator the power to do that kind of scoping without any coding. The scopes can have multiple rules, so you could even bring two disjoint sets of data into one scope.

The more you think about it, the more potential there is in this feature. Some issues I would like to investigate further are:

1. What are the performance implications of multiple scopes? How do they affect indexing? How many scopes can a system with heavy load and constant input of data healthily contain?

2. Is most of the potential use of this feature not actually practical? For instance (exaggeration coming but I hope it illustrates the point): I could search for JPEG images whose size is “medium” and come from the Images 2006 and Images 2003 lists on my SharePoint site, but would I ever want to?

Posted at 5:45 PM by Szymon Rozga | Category: SharePoint | Permalink | Email this Post | Comments (1)

8/15/2007

The power of Share Point

When I was in Cornell, I developed and maintained a Ruby on Rails web app for a team of technicians on campus. The app was a lot of custom Ruby code. We had to design and develop custom user and role management, work order management interface, reporting interface, and search functionality. It occurs to me, Share Point and SQL Server 2005 seems to be geared for this exact functionality.

I imagine the following solution: a top site collection as the main site with two child sites: The Work Order Management site and the Reporting Site. The top site collection would contain lists of all the different entities that existed in the database, such as, departments and customers. It would also include a Form Library to store the work orders themselves. The technicians could use InfoPath to submit work orders and possibly modify them. But, wouldn't it be cooler if the actual work orders could be items in a List on the server and users could add/modify items using InfoPath forms? (More importantly, is this even possible?).

With regards to reporting, SQL Server 2005 reporting should be enough. Share Point could be used as a dashboard to display these reports. (Edit: By using the Reporting Services Web Parts see: http://msdn2.microsoft.com/en-us/library/ms159772.aspx)

The breakdowns that are needed are by month, by department and by other categories. A few questions come to mind:

1. Is SQL Server 2005 overkill for smaller amounts of data? This app may get at most 10 new work orders per day.

2. If all this data is in a Share Point list, is there an easy way for the reporting services to leverage this fact or should the data to be reported on be replicated to a separate SQL database and then run the reports on?

User and role management could be simple. One could create Share Point groups representing the relevant groups of individuals in this application. The users would be added on the server and, afterwards, into Share Point. Customers could only see the work orders related to them. Would it be possible to provide reporting services for the customer about only the work associated with them? Would that be smart?

Search is also built into Share Point and would provide everything we need.

So overall, this sounds like it could be done in a short amount of time and a working prototype without reporting could be up and running within a few days, without any coding. Now that's power.

Posted at 11:50 AM by Szymon Rozga | Category: SharePoint | Permalink | Email this Post | Comments (0)

8/14/2007

Into Share Point I Go

I started this blog with the goal of exposing some of the experiences that a new grad with a strong computer science background encounters when switching from C, C++ and Ruby development into working with Share Point (disclosure: I have very little experience with this product).

I have currently been working on installing Share Point on a clean Windows 2003 Server install. It is a tour into Share Point's architecture and allowed me to take a peek under the hood of this huge piece of software. SharePoint uses a SQL Server 2005 database as its configuration repository. Since Share Point includes many built-in features, these tables are huge. Poking through them is quite revealing.

Another aspect that is of interest to me is the issues of under which users does this software run. The suite of Share Point services each requires a user to run as. To create a secure installation, one has to make sure that those services run as users with the minimum privileges that these services require. I will be working on figuring that out tomorrow.

Posted at 5:50 PM by Szymon Rozga | Category: SharePoint | Permalink | Email this Post | Comments (0)

RSS Feed

Szymon