Author Archive

Custom Content and Structure Report in Sharepoint 2007

Friday, May 29th, 2009

Sharepoint 2007 has a nice set of reports if you have the publishing features. You can see these reports using Site Actions>>View Reports. There are about 7 default reports in all. I needed to create a custom report for displaying "Expired documents" in our intranet publishing portal  and found it to be quite easy to add this new report.

Here are the steps I took to create the new reports.

  • Click on Site Actions >> View All Site Content
  • Click on "Content And Structure Reports" list to open up the list
  • Click on "New" >> New Item
  • In the Report title, enter "Expired Documents"
  • in The CAML Query type: <Where><Leq><FieldRef ID="{a990e64f-faa3-49c1-aafa-885fda79de62}"></FieldRef><Value Type="DateTime"><Today /></Value></Leq></Where> 
  • In the report description, type: All documents that have expired
  • Click "OK"
  • Go back to Site Actions>> View Reports >> Expired documents
  • You should now see a list of all the pages that have scheduled end date  less than today's date.

My Experience with MOSS 2007 on our intranet

Thursday, May 28th, 2009

We rolled out a company wide intranet solution on MOSS 2007 this week. We used the publishing portal template. Its been 3 days and our launch it has been surprisingly very smooth. Our IT ServiceDesk received very few calls and most were related to now sharepoint issues or user errors.

I was a bit worried about 700 + people hitting the web front end server in one day and causing the server to slow down. So far, the performance has been almost the same as when we were testing (about 20 people). I ran a quick analysis on the usage log and had over 500 distinct users on the first day after the launch. We rolled out 3 key features: My Sites, Search and the Intranet site using publishing portal template. The portal has been heavily customized in terms of look and feel ( master page). I wrote a silverlight web part that grabs images from mysites and rotates the images. Our current topology has 1 web server, 1 application server (index server) and 1 DB server. One of the important tip for you guys who are thinking about rolling out sharepoint is to thinking about disk capacity and storage in advance. My DB server has over 1TB of disk space but now i am worried that it may not be enough. With over 700 people, i have capped the space for MySites to 45 MB. Imagine, if everyone where to get upto 45MB in few months. I would be sitting with mysite gobbling up 350 GB of space in database. Throw in the backups and you know 1 TB is not much.

Luckily (Another Tip): I created a DB alias on my web server. The web server connects using this alias instead of the DB server machine name. So, if i am quickly approaching about 50 % of the disk space of DB server, i can work with the DBA and mirror the db server by adding another DB server with much more disk space ( possibly using SAN storage). Once the mirroring is in place, i can simply point the alias to the new db server.

For now, things are quiet but I think we will be rolling out the collaboration portals in near future…

Migrating Web Applications from Windows Sharepoint Services to a different MOSS 2007 server farm By Moving Content Databases

Sunday, January 11th, 2009
If you are planning to upgrade to MOSS 2007 from windows sharepoint services 3.0 you probably have to deal with migration of sites, application and most importantly also restructuring the logical architecture.
 
If the goal is to migrate content from WSS 3.0 to a brand new MOSS 2007  server farm then it gets more complicated based on your situation.You will have few choices like using stsadm tools, exporting sites or of course manually recreating sites. If you need to move an entire top level site collection from WSS 3.0 environment to MOSS 2007 new farm, I can show you an easier and painless way to accomplish the migration. This is particularly useful if the site collection in WSS 3.0 is huge ( few GB and has lot of subsites). I 
 
Here is the scenario
 
You have a WSS 3.0 environment which is actively being used.  Your company has now decided to use MOSS 2007.  Your Solution Architect  suggests that it is better to create a brand new MOSS 2007 farm instead of simply upgrading the WSS 3.0 server farm to deal with information architecture ,logical architecture issues  that was not properly implemented in WSS 3.0 farm.  You have been given the responsibility of migrating sites from WSS 3.0 to the new MOSS farm.
 

Moving web application from WSS 3.0 to  a New MOSS 2007 Server Farm

  1. Create a new MOSS 2007 Server Farm Environment, Apply all the service packs and hot fixes etc, so that it matches the patch level of your WSS 3.0 farm 
  2. Check under the "Operations" section of the central administration to make sure that the version numbers of the MOSS farm and individual servers matches the version number of the WSS 3.0 farm
  3. Take a backup ( in SQL Server) of the content database of the web application you want to move ( Lets say the content database is called SalesDB and under this, you have a teamsite with many subsites. http://wssfarm/sales)
  4. Create an empty database in the SQL Server of the MOSS environment. The name of the database should be same as the name as in WSS 3.0 SQL Server ( In our example it should be called SalesDB
  5. Restore the back-up to the empty content database on the DB server of the MOSS farm using SQL tools or commands in query analyzer (Note: if your original database was in SQL Server 2000, you can restore it to SQL Server 2005. I think you need SP4 on the SQL Server 2000)
  6. Once the DB is restored, go to the central admin site of the MOSS 2007 Server.
  7. Create a web application . In the database name, enter the name of the database you just created and restored in the MOSS 2007 server
  8. Once the application is created, you should now have an exact copy of the WSS 3.0 Site collection to the MOSS 2007 Server.
  9. Impotant: You do not need to create a top site, it should already be created for you, just browse to the URL and you should now see that the entire site and subsites are moved over to the new server.
  10. You will notice that since the source was using team site template, the MOSS 2007 newly created site also uses the same template. If you need to use features like manage content and structure etc, all you need to do is, go to the "site collection features" and start enabling the collaboration features that you need.

Excel Services and OLAP will put you on the right track of flexible business intelligence solution

Friday, April 25th, 2008

I have been working with MOSS 2007 Excel Services a lot in the last few weeks and it has been quite exciting putting together a business intelligence solution for folks here in my company. I have a demo in next few days and I am actually looking forward to show the cool functionality in Excel 2007 and sharepoint.

Let me begin by asking you a few questions, this will determine if the post is of any use to you at all. 

Have you been working with customers whose requirements for reports are always changing?

Does a light bulb go off in your client's head  once they see your completed report and all of a sudden wants some more field to be displayed on the completed report

Does your client prefer to export the data from your report into an excel spreadsheet and then create their own report

Do your customer want to design their own reports but want an easy way to achieve that?

Do you have few folks in your company, who refuse to install excel on their computer because they love unix and "VI" editors and hate anything windows?

Most important, do you use sharepoint 2007 in your company? ( without MOSS 2007, you cannot use excel services 2007)

If you answered yes to most of the above question your organization can benefit greatly with the Excel 2007 and Excel Services. If you answered no to all of above you probably would not find this post interesting.

 

Developing a reusable SQL Data viewer WebPart for Sharepoint -Part 3

Saturday, December 8th, 2007

Customize the webpart properties for dynamic connection to SQL server and to enable paging in Grid view.

In Part 2 of the post, we looked at how to execute a SQL statement against a database and display the result in the web part as a gridview. Before going to Part 3 of developing a reusable SQL Data viewer web part for Sharepoint, please follow the steps in Part II. 

In Part III of the post, we will enhance this web part and add properties to the web part so that connection to SQL Server and the SQL statement can be configured after the webpart is added to the page. We will also throw in an eventhandler for the gridview to handle paging. If you have lots of records, we want them to show in pages. We will also look at how to configure the page size through properties.

Note: The example below shows how to save configuration data in properties in plain text.If you feel such a method is not suitable for your security needs, you should find a way to use encryption on the data being saved in the properties and a method to decrypt that when accessing from code. 

We will first create a webpart property called ServerName and also a method called ServerName

See Code Listing Below

public class DataViewer : WebPart

{

        private string servername;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("ServerName"), Category("Data Properties")]

        public string ServerName

        {

            get { return servername; }

            set { servername = value; }

        }

In the above code, we declared a private data member called servername and a get,set method called ServerName

We also created a webpart property called “ServerName” which will be displayed in a section called “Data Properties”

We will now create some more properties, see code listing below

 

    public class DataViewer : WebPart

    {

        private string servername;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("ServerName"), Category("Data Properties")]

        public string ServerName

        {

            get { return servername; }

            set { servername = value; }

        }

        private string dbname;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("DatabaseName"), Category("Data Properties")]

        public string DatabaseName

        {

            get { return dbname; }

            set { dbname = value; }

        }

        private string username;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("UserName"), Category("Data Properties")]

        public string UserName

        {

            get { return username; }

            set { username = value; }

        }

        private string password;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("Password"), Category("Data Properties")]

        public string Password

        {

            get { return password; }

            set { password = value; }

        }

        private string innerpassword;

        [Personalizable(), WebBrowsable(false),

        WebDisplayName("InnerPassword"), Category("Data Properties")]

        public string InnerPassword

        {

            get { return innerpassword; }

            set { innerpassword = value; }

        }

        private string sqlquery;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("SQLQuery"), Category("Data Properties")]

        public string SQLQuery

        {

            get { return sqlquery; }

            set { sqlquery = value; }

        }

        private int datarows;

        [Personalizable(), WebBrowsable(true),

        WebDisplayName("RowsPerPage"), Category("Data Properties")]

        public int DataRows

        {

            get { return datarows; }

            set { datarows = value; }

        }

All the properties are similar in declaration accept for a property called “InnerPassword”. You will notice that the WebBrowsable property for innerpassword is set to false.  This property will not be visible to users and it is created so that the password can be stored internally in this property.

Build the project by clicking on Build>>Build Dataviewer

Once you have successfully build the assembly, go to the sharepoint site where the dataviewer webpart was originally added and refresh the page.

Modify the dataviewer webpart properties and you will see a section called “Data Properties” as shown below

 

The “Data Properties” section havs 6 text boxes.

ú         Server Name = [name of the SQL Server]

ú         DatabaseName= Name of the Database

ú         UserName= SQL server login account

ú         Password = SQL Server Password

ú         SQLQuery= T-SQL Statement to query the database

ú         RowsPerPage = number of rows to be displayed in the gridview for a page

In the next section, we will now add code to capture the values entered in these properties and then execute it in the webpart.

We will modify the CreateChildMethods and instead of using static SQL Strings or connections, we will read the connection and sql statement from the properties.

The following codes have been added

if (password != "******")

{

     InnerPassword = password;

     password = "******";

}

string strConnection = "UID=" + username + ";PWD=" + innerpassword + ";Initial Catalog=" + dbname + ";Data Source=" + servername + ";";

                   

string sql = sqlquery;

objDB.StrConnection = strConnection;

DataTable dt = new DataTable();

dt = objDB.GetSQlResult(sql);

Let's examine the code above. If the password ( this is the password property) is not equal to “******” then we will assign the password to Innerpassword and set the password to “******”

The reason for doing this is, if someone entered a SQL Server password on the webpart, we do not want to show the password to the user again, instead we will show “******” to prevent other people from accessing the password of SQL server by looking at the properties.

In the next line, we are building the SQL server connection string by reading the properties of the web part.

In the sql string we get the value from the sqlquery property of the webpart.

We are now dynamically reading the SQL connection string and the query from the webpart properties, next step is just execute the GetResult method of our DBAccess object and bind the datatable returned to the gridview.

We will now add code to enable paging in the gridview. We also need to specify the page size. We will set the allowpaging property of gridview to true and also add an eventhandler to enable paging for gridview. The pagesize will be assigned from the “datarows” properties.

 

gv.AllowPaging = true;

gv.PageSize = datarows;

gv.PageIndexChanging += new GridViewPageEventHandler(this.gv_PageIndexChanging);

We will need to manually create the method for the event handler as below

protected void gv_PageIndexChanging(object sender, GridViewPageEventArgs e)

       

{

      gv.PageIndex = e.NewPageIndex;

      string strConnection = "UID=" + username + ";PWD=" + innerpassword + ";Initial Catalog=" + dbname + ";Data Source=" +    servername + ";";

     

      DbAccess objdb = new DbAccess();

      objdb.StrConnection = strConnection;

      DataTable dt = objdb.GetSQlResult(sqlquery);

      gv.DataSource = dt;

      gv.DataBind();

}

Note: The gridview should not be instantiated inside the CreateChildControls Method anymore because the gv_PageIndexChanging will not be able to access the object, we will therefore instantiate the gridview as a member of the class.

  public class DataViewer : WebPart

    {

        GridView gv = new GridView();

Build the project. Go to the sharepoint page where the webpart has been added previously. Refresh the page.When the webpart reloads you may see an error message. This is expected because the database connections and SQL query has not been set.

 

 

You will now need to edit the dataview webpart properties to make the error go away and execute your SQL Statement.

Change the Title to : Employees

Expand the Dataproperties section and enter your connection information


 

 

Once the properties have been entered, click “Apply” and then click “OK”. You will now see that the web part displays the result of your sql query.

Important: The RowsPerPage must have a number greater than 0.

When the page loads, the page should similar to this, base on your data and your SQL Statement


  

 

You can now add more dataviewer webparts on the page and connect it to different SQL Servers or run different SQL Statements.  Example below

 

You can now build a report dashboard based on this dataviewer webpart and re-using it multiple times on the same page by simply configuring the connection and query properties.

Developing a reusable SQL Data viewer WebPart for Sharepoint – Part II

Sunday, December 2nd, 2007

Create the Data Access library and display query results in GridView

This is the Part II of the 3 Parts on how to create a reusable SQL Data VIewer Web Part. If you missed Part I, here is the link. Part I

In the part I of the post, we looked at how to create a simple webpart and deploy it to the bin directory. The webpart simply displayed a static text. We will now look at changing the webpart code and overriding some base class method so that instead of a static text, it will display data from SQL server database in a grid view.

In the part I of the post, we started a project called dataviewer, we will now continue with the same project.

Add a new class to the project and call it DBAccess

In the using section add the namespace

using System.Data.SqlClient;

The DBAccess.cs should look like this

 

 

We are now going to add some methods to the class DBAccess

Add a private data member called strConnection of string type. This will hold the connection information to the sql server database from where the query result will be fetched.

Create a get, set method for this data member so that we can set the connection string property through the assessors. Code snippet is shown below

public class DbAccess

    {

        private string strConnection;

        public DbAccess()

        {

        }

        public string StrConnection

        {

            get { return strConnection; }

            set { strConnection = value; }

        }

  }

We need to create a method called GetSQLResult which returns a data table and takes a SQL statement as a parameter

public DataTable GetSQlResult(string sql)

        {

            DataTable dt = new DataTable();

            try

            {

                SqlConnection cnn = new SqlConnection(strConnection);

                SqlDataAdapter da = new SqlDataAdapter(sql, cnn);

                da.Fill(dt);

                return dt;

            }

            catch (Exception ex)

            {

                return dt;

            }

        }

Build the project again. If the build fails, make sure all the namespaces are included. The namespaces required for this class are

using System;

using System.Collections.Generic;

using System.Text;

using System.Data.SqlClient;

using System.Data;

After adding references, build the project again, make sure there are no errors.

You have successfully created the data access library.

Next step is to, use this DAL ( data access library) on the web part  and display the data in a grid view.

Open the dataviewer.cs code file, we will now look at the method to display the output on a webpart. The method that displayed the output is shown below

protected override void RenderContents(HtmlTextWriter output)

{

      output.Write("Data Viewer Test");

}

This is a base class method and we chose to override it in our class. The output is a HtmlTextWriter which gets displayed in the webpart UI.

We can also choose to override another base class method which will produce the same result, the method is called createchildcontrols.

See code listing below

protected override void CreateChildControls()

{

           base.CreateChildControls();

}

If we are going to create controls like gridview, labels,textboxes etc and display it in webpart, it is much better to override the createchildcontrols method because it is easier to manage the order in which the user controls will be displayed in the webpart. We will therefore choose to override the createchildcontrols instead of  rendercontents method

The next step is to create a gridview control and then bind the gridview to a datatable. We will then add the gridview to the controls collection so that the gridview will be displayed in the webpart with the result of the sql statement.

See code listing below

 

In the above listing, I have commented the RenderContents method because I want to use the CreateChildControls method to display the gridview in the webpart.

The strConnection string has the connection information to the sql server.

UID: name of the sql server account,

PWD: password for the user, I

nitial Catalog: Database to which you want to connect and finally

Data Source: The name of the server in which the SQL Server is running.

If you have multiple SQL Servers running on this machine, you have to specify the instance name as well Example: testserverSQLEngine1

Build the project, Build>>Build Data Viewer

If there are any build errors. Make sure that you have followed the code listings and included the namespaces correctly.

Go back to the sharepoint site on which you had added the DataViewer webpart in Part I of the blog. Simply refresh the page and you will now see that the web part loads with a gridview and a result of the SQL Statement.

See Screenshot below:

 

You have now successfully created a webpart that takes a SQL Statement, database connection string and executes the SQL statement and displays the result in the web part.

In part I, we set the assembly version to 1.0.0.0 and this makes it easy to test our changes by simply refreshing or reloading the page that contains the webpart. If we had not set the assembly to a fixed version, everytime we build our dataviewer project, it would create a new revision number and you would be required to edit the web.config and register the control as safe.

The problem with the above webpart is that the SQL statement and the connection information to the server are stored in the assembly.

In part III of the “Developing a reusable SQL Data viewer WebPart for Sharepoint”, we will look at how to store the SQL statement and connection string in the webpart properties, so that it can be configured easily. We will also look at how to set paging properties of the gridview.

  

Developing a reusable SQL Data viewer Web Part for Sharepoint

Friday, November 30th, 2007

Part I:   Create a basic web part in Visual Studio 2005 and deploying it to sharepoint

A few weeks back I came across a blog post that talked about a Data Viewer Web Part that can be purchased from Lightning Tools. I decided that it would be good exercise to actually develop a web part similar to the one that is offered by Lightning tools.  I have not developed sharepoint web parts in the past so it would give me some experience with sharepoint web part development and deployment. I would like to share the source code and the steps required to build a re-usable data web part that will work with SQL Server. I am posting the entire steps, code snippets and screen shots in 3 separate parts.

Before I started coding the Web Part, I had few clearly defined goals in mind

The Web Part should work on sharepoint

  1. The data source, connection and the query for the web part must be configurable through webpart properties and should not be hard coded.
  2. The user account and password for the database should be configurable from webpart properties. Once the password is entered, it must be hidden with password character.
  3. User must have the ability to enter a T-SQL command in one of the web part property and the query result should be displayed in a grid view.
  4. The grid view must have paging and user should be able to control how many records to show in each page by setting a webpart property.

Things you need before starting this project

Visual Studio 2005

  1. Experience with C# or similar programming language
  2. Sharepoint (WSS or MOSS). This project should be developed on a visual studio 2005 which is installed on the server hosting the sharepoint environment.

Building a Web Part Project in Visual Studio 2005

Start your visual studio 2005 and click:   File>> New >> Project

Click on visual C# >> Windows and select "Web Control Library"

In the Name field   enter: DataViewer and then click "OK" See Screenshot below

Visual Studio Project

 

In the solution explorer on the right, rename the file webCustomControl1.cs ( Right Click + Rename)  to DataViewer.cs

On the Dataviewer.cs delete the following lines just below the DataViewer namespace

[DefaultProperty("Text")]

[ToolboxData("<{0}:WebCustomControl1 runat=server></{0}:WebCustomControl1>")]

  

Examine the line below

public class DataViewer : WebControl

The above line says that the DataViewer class is inheriting ( : ) from WebControl class

Since this is going to be a WebPart, we need to instead inherit from the webpart class.

Change the code to following

public class DataViewer : System.Web.UI.WebControls.WebParts.WebPart

 

In the above code, we inherited the WebPart class but typed the namespace and the entire parent class name, we can change this to  a shortened version by simply putting a reference to the parent class in the using section, type the following in the using section

 

using System.Web.UI.WebControls.WebParts;

Change the inheritance code to

public class DataViewer : WebPart

Delete the text property code. In the output.write, change it to output.Write("Data Viewer Test");

 

The final code listing should look like this

code listing 1

 

 

 

Build the project. Build>>DataViewer. This should compile without any errors.

 

On the solution Explorer, expand properties, click on assemblyinfo.cs and open the file

 

Locate the line : [assembly: AssemblyVersion("1.0.*")]

Change this to

[assembly: AssemblyVersion("1.0.0.0")]

 

The purpose of this change is to make sure that the assembly version will be the same even if we compile multiple times. For now, we just want to make sure it stays the same version, so that we will have easier time to deploy and debug the webpart.

 

Click on Project>> Dataviewer Properties

Click on the "Build" on the left side

Under "output" section locate "output path" and then click on "browse" button

In the "select output path" dialog box, select the path of a sharepoint web application and then choose the bin folder.

Example: If you have as sharepoint application under C:inetpubwwwroot   then you should choose C:inetpubwwwrootin as the output path.

If you deploy the Webpart assembly to the bin folder, you can easily debug your code and do not need to provide a strong name to the assembly with a public key token.

For now, we will just deploy to the bin folder and not worry about signing the assembly with a public key token. (Note: if a bin folder does not exist, you can simply create a folder called "bin")

Build the project again, this time the dll will be output to the bin folder. There will be two new files in the bin folder called dataviewer.dll and dataviewer.pdb

The next step is to register this assembly as safe in the web.config of the sharepoint application.

Go to one folder above the bin folder and open the web.config file in notepad or visual studio 2005

 

Under the safecontrols section enter the following line

<SafeControl Assembly="DataViewer" Namespace="DataViewer" TypeName="*" Safe="true" />

The assembly name is DataViewer, the Namespace is also called DataViewer, in the typename we have a "*" which means all the classes in this assembly. Safe= true is telling the sharepoint that this webpart is safe.

Save the web.config file and close it.

Go to the sharepoint web application where you want to now add the web part

Click on Site Acttions>> Site Settings

Under "Gallery" section, click on "Web Parts"

In the webpart gallery page, click on "New" you should now see a webpart called dataviewer.dataviewer with a filename dataviewer.webpart

 

Select this webpart and click the button "Populate Gallery". This webpart is now added to the webpart gallery.

 

Click on edit icon to edit the propererties of this webpart.

 

For the group type: Data

For the Quick Add Groups type: Data

Click "OK"

web part gallery

If you got this far, the web part has been successfully deployed and added to the web part gallery. You are now ready to use this webpart in any site within the site collection.

 

Go to a site within the sharepoint site collection

Click on Site Actions>> Edit Page

On any of the web part zone, click on "Add a web part"

Scroll down to the section called "data" and select the dataviewer webpart and click "Add"

Add web part to page

 

 

The Dataviewer Webpart should now be on the page with the title "DataViewer" and the text "DataViewer Test" as shown below

web part on page

This concludes part 1 of the reusable SQL data viewer Web Part. In part 2, we will start coding a data access class. This library will have a method to execute a SQL statement and return a data table. In Part 2, we will also look at adding gridview control to our webpart.

 

 

Is Moss 2007 a platform or a solution?

Saturday, October 20th, 2007

 I think MOSS is both a platform and a solution. I am going to broadly categorize some of the capabilities of MOSS 2007 into two buckets and then explain my rationale for why a specific capability is in a particular bucket

 

Solution

  •  Web Content Management/portals
  • Enterprise Search

Platform

  •  Business Intelligence using Excel Services
  •  Business Process using InfoPath Forms

Solution:  If you are planning to implement a new corporate intranet with portal capability, you will use the publishing template along with MySites. The out of box capability can get you far enough that you will probably focus only on specific items like branding, configuring the site structure, security, content and some minor customization. The OOB capability of sharepoint can meet most of your needs for a corporate search engine. You may be able to get this up and running in a relatively short time by configuring the search, scopes and content sources. I think that sharepoint is a solution for WCM and Enterprise search because it addresses most of the business need with the out of box functionality. The WCM and search investment in sharepoint can be realized fairly quickly by just configuring the out of box features. You have a quicker time to deploy an intranet site or a search engine and your focus is mostly on content.  

 

Platform: If you are planning to implement a business intelligence solution or form based application you will use BDC, excel services and InfoPath form services. These are however pieces of the pie. Excel services and report center templates by itself cannot provide you business intelligence. It provides the framework and the presentation layer for your underlying data.Even before you get to using sharepoint for business intelligence, You will need to start out by understanding the data structure in a LOB applications, figure out a way to get to the data by either designing an OLAP solution or consume web services or directly connecting the data source through providers. You will then need to publish connection strings to secure connection library and then start developing the reports using excel 2007. You can develop your excel reports to sharepoint and then present the report in a dashboard. When you get this far, most of pieces are together and you are now addressing the business intelligence requirement.  For business intelligence, we use the sharepoint infrastructure for the purpose of application security layer (control access, permission), presentation layer (dash board, navigation, content, excel services web part) and report design tool (Excel 2007). 

 

If you are planning to implement a web based expense entry with reports, you will need to use InfoPath form services, work flows etc. Infopath will provide you the design tool to start developing the forms but most of the time applications are much more than a form. You will need workflows, notifications and reports on data entered into the forms. In some cases, you may need to integrate the expenses into a project management system or other applications. Here again, Infopath form services is one piece of the pie. In the above two context, sharepoint is a platform for business intelligence and form based applications. You choose the infrastructure and the framework provided by sharepoint to ultimately achieve your business needs.

 

 I can see that sharepoint BDC and excel services are a good solution for building dashboards and reporting portals. Using excel as a reporting design tool seems to be a very smart move since most of the business users are familiar with excel and it also empowers the end users to build their own reports based on data connections quite easily. How many times have you built reports that have changed 10 times because the requirements kept changing? Well, with excel services, developers can now focus on the OLAP, data connections and all the useful things whereas the report power users can focus on creating reports that suits their needs. I am not sure I can say the same thing about InfoPath Form Services. While, InfoPath makes it easy to design forms and quickly deploy it, is it a good platform for applications? Is InfoPath a good option to actually develop complex applications based on the fact that it has an easy designer and can be deployed into sharepoint.  Are we constrained by the functionality of the form designer? As a developer, I still need to play around with InfoPath a lot more before I can make an assessment, but for now, I am more comfortable developing business applications using visual studio and .net. I welcome any experience or ideas from readers who have used InfoPath forms services extensively.

 

How to restrict public access to sharepoint list views using filters

Tuesday, October 16th, 2007

In sharepoint you can either create a personal or a public view on a document libraries, lists etc. You may come across situations where you need only a few individuals to see a particular view.

Lets take an example

 Your have a custom list containing software contract information like customer, license type, product, contract date,contract currency, contract amount etc. You are required to allow everyone in the sales department to see this list however the contract amount should be visible only to few management executives. You may create 2 public views, one that has the contract amount and the other that does not. The next step would be to provide read-access to the list to all the people in the sales department.

In sharepoint, if you give read access to a list or library, the person will also have read access to all public views. which means, by default everyone is able to see both the views, one with the contract amount and the one without. Not being able to control access on views seems to be a design flaw/gap in sharepoint. I hope Microsoft will address this in the next release or a service pack. Until that time, here is a workaround that may work in some of the cases

On the list where you want to restrict access to views to a few individual:

  • Create a column called "Restricted users".
  • Column Type = Person or Group
  • Allow Multiple Selections =Yes
  • Allow Selection of = People Only
  • Choose From = All Users (This is the list of Users from your Active Directory(
  • Show Field= Name ( Choose this from the drop down)

Lets say John Smith and Jane Smith are 2 executives who need to see the list views with the contract amount

Open up the list in data sheet view.  [List Name]>>Actions>> Edit In Datasheet

Scroll to the column called "Restricted Users"

Under the column, in the first cell type John Smith;Jane Smith  ( These 2 names should be in AD exactly as spelled, if not find the correct spelling)

Copy this cell to the rest of the cells under the "restricted users" column and save.

Create a view for this contract list, call it "Contract-Restricted"  or an appropriate name. This view should be created as a public view.

In the filter section where it says "show the items when"

  • Choose "Restricted Users" from the dropdown list
  • Condition =Is equal to
  • In the text box type [Me]

When sales people login to the site and selects the list, they will see both the views but when they choose the "Contract-Restricted" view, they will not see any results because of the filter.

The filter essentially looks at the current user logged in sharepoint, if it is John Smith or Jane Smith, the filter condition is met and it returns the result in the "contract-restricted" view otherwise the view will not return any result.

 

 

Restore a production sharepoint web farm to a new web farm

Tuesday, October 2nd, 2007

 If you have a production WSS 3.0 sharepoint environment and need to copy the production data into a test environment web farm (different web farm), it can be done using SQL backups and restore.

I am more comfortable using this method than using stsadm tool. This could also be helpful when your production system crashes and you need to quickly get a backup sharepoint farm up and running with the latest production data.

Note: Make sure that you have a database maintenance plan, that backs up your production content databases nightly.

 Production sharepoint farm steps
 
  In SQL Server Enterprise Manager, back up all Windows SharePoint Services 3.0 databases.
 
 
 Target farm steps ( if you are setting up a brand new WSS 3.0 farm)
 
1.  Install Windows SharePoint Services 3.0 on the target farm computer. Do not create a web application.
 
2.  In SQL Server Enterprise Manager, restore to the target farm computer, all Windows SharePoint Services 3.0 databases except the configuration database and the central administrator content database. Use the Restore Databases menu option.
 
3.  In the Windows SharePoint Services 3.0 central administrator console, create a web application for the portal site. If you have more web applications in the source farm, create the corresponding web applications in the target farm.
 
4.  In the Windows SharePoint Services 3.0 central administrator console, detach the content database from the newly created web application by doing the following:

5.  From the Application Management page click the Content Databases link under the SharePoint Web Application Management section.
 
6.  Change the web application from the drop down list.
 
7.  Select the content database.
 
8.  Select Offline for Database Status and check the remove content database
 
9.  Click OK.
  
10.  Attach the restored site Content database for the newly created web application.

11. On the Application Management page click Content Databases under SharePoint Web Application Management.
 
12.  Change the web application from the drop down list
 
13.  Click Add a content database.
 
14.  Enter the SQL Server name and the name of the restored database.
 
15.  Click OK.
  
16.  Start the search crawl from the Search Setting page.
 
17.  Click OK on the pop up dialog to resume the crawl.

You have now created a brand new web farm that is a copy of the production web farm.

Target farm steps (if WSS 3.0 farm is already Installed  and has web applications)
 

1. Make sure that you have same number of web application on this target server as the production server. You will need to use this web application for the restore of the production web application.
 
2.  Go to  Windows SharePoint Services 3.0 central administrator console, select the web application from the web application list.

3.  Select the content database.
 
4.  Select Offline for Database Status and check the remove content database
 
5.  Click OK.

6. Go to the SQL Server and delete the content database

7. Create an empty database on the SQL server and name it the same as the content database that you want to restore from the production web farm

8. Restore the backup taken from the production on this empty database.

9. Go back to Central Administration site
10 On the Application Management page click Content Databases under SharePoint Web Application Management.
11.  Change the web application from the drop down list
12.  Click Add a content database.
13.  Enter the SQL Server name and the name of the restored database.
14.  Click OK.
15.  Start the search crawl from the Search Setting page.
16.  Click OK on the pop up dialog to resume the crawl.

You should now have a copy of the production web farm in a test environment.