As we have found out in part 1, SharePoint can manipulate data using the user profile management objects and can accept data from external sources. Using these two features apart we have two limited tools with limited usage, but using them together gives us a powerful, flexible and efficient method of storing and using data from any internal or external resource.

It’s time to see this solution to our problems in action.

Code example of getting/setting the profile property from a C# application

The concept is the same for any source of information (web services, web applications, etc.):
Get the user’s profile->Get the required profile property->Get/Set profile property value

Code example: (note that to access profile properties, this code must run with elevated privileges)

string value;
try
{
 SPSecurity.RunWithElevatedPrivileges(delegate()
 {
  
     // Change the site address for different deployment environments
     // Note: WIN2003STD is a place holder for your environment, usually your server name
     SPSite site = new SPSite("http://WIN2003STD/");
     SPWeb web = site.OpenWeb();

     // Get the profile manager object for the site
     UserProfileManager profileManager = new UserProfileManager(ServerContext.GetContext(site));

     // Use the username from the User Information Item to get the full profile of an user
     UserProfile user_profile = profileManager.GetUserProfile(System.Web.HttpContext.Current.User.Identity.Name);

     // Get the required profile property value from the profile
     value = user_profile["MyProperty"].Value.ToString();

  
 });
}
catch (Exception e)
{
 return "Error getting user info: " + e.Message.ToString();
}

user_profile["MyProperty"].Value gets or sets the profile property value.

This is a very convenient way of using profile properties to store required information for each user. Properties can be set as read-only or not to appear in the user’s profile, which gives you even more control.

System.Web.HttpContext.Current.User.Identity.Name returns the username (the login username) and it is used in the code example above to get the profile of the currently logged-in user.

Tools You Never Knew You Had… (and what to do with them now that you’ve wised up!)

With this simple solution to getting/setting a user’s profile property value, endless opportunities are now at hand. This small code snippet helps developers control, validate and use values stored for each user, without corrupting the database or resorting to other more complex and error-prone solutions.
For those not needing to use an external application to get information from the users, a custom SharePoint web application can be developed and deployed on SharePoint. This way all the controls offered by ASP .NET or custom controls can be used to perform required operations on the data before it’s stored.

External applications running on the server can access this information the same way, so a bridge between SharePoint and applications like web sites, game servers, messaging apps, etc. can be easily created.

SharePoint Complications, As Usual

Watch out that the profile property might be set as read-only in SharePoint. Even if it’s the case however, the above code should still be able to access the profile because it’s running with elevated privileges. So if there is a situation in which the user is allowed to see the data but only modify it by using a service (like a web application or web service), this is a good way of doing it.

Another gotcha is that the code above can only be used on the SharePoint server machine. This is due to the framework that SharePoint uses. To get information or to change data from a network on internet location, a SharePoint custom web service or web application can come in handy. Other ways of passing information will work too, like server-client applications, as long as the part running the above code is on the SharePoint server machine.

So we now have a way to store data and manipulate it according to our needs. We can control it, we can validate it and most important of all, we decide how the user interacts with the data.

We’re now ready to start doing some serious SharePoint development!

Labels: c#, code quality, SharePoint, string conversion, web development, Win32

There is a constant need in SharePoint feature development to bridge SharePoint 2007 with other web applications. In order to create such a bridge, a variety of user information must be stored in the SharePoint database.

Warning: Do not tamper with the SharePoint database! No matter how tempting it is!

Although this might sound as simple as a small SQL application, tampering with SharePoint’s database could lead to disastrous results and even complete and irreversible server crashes, since many of SharePoint’s recovery features rely on the database being intact. “Feeding” information to SharePoint through its database is unadvisable and sometimes very hard to do, mainly due to the complex structure of the database.

Fortunately there is a built-in solution to this problem that is both simple and efficient: User Profiles and User Profile Properties.

In this post we will see how SharePoint’s user profiles and profile properties can help us do our job fast and easy without worrying about crashing the server or breaking more features than we create.

Let’s start with the storing information problem.
Many developers have already considered using Profile Properties as way to store the required data, but have given up on using them due to their limitations (limited validation, control, variety). Controlling the user’s input and making sure that the values are correct is essential in any bridge, and often auto-generated values based on that data are necessary. SharePoint can only do so much, and this is usually the main reason why developers avoid using the custom profile properties.

Solution: Manage information using the Microsoft.Office.Server.UserProfiles namespaces.

SharePoint Server 2007 stores user profiles in SQL Server, but the information can be imported from other data sources, such as:
· Active Directory
· Lightweight Directory Access Protocol directories (which is not Active Directory)
· Databases
· Enterprise applications (such as SAP or PeopleSoft) by defining a Business Data Catalog connection
· Web applications
· Custom SharePoint web services
· Standard .NET applications, etc.
The main classes are found in the Microsoft.Office.Server.UserProfiles namespaces. The assembly is Microsoft.Office.Server.dll found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.
The main objects to handle information within the User Profile store are:
UserProfile
Allows you to access profile properties, the My Site, personalization links, and so on.

UserProfileManager
Gives access to a collection of UserProfile objects and allows you to create, edit, and retrieve user profile objects and properties from the user profile store.

UserProfileConfigManager
Manages the user profile configuration.

Note: In order to manage data in a custom user profile property, the property must be first created. You can use the following steps to create a profile property:

1. Start > Administrative Tools > SharePoint 3.0 Central Administrator
2. In the left panel, under Shared Services Administration, click SharedServices1
3. Click User Profiles and Properties
4. Under User Profile Properties, click Add Profile Property
5. Fill in the required data and click OK

Now that we know that SharePoint accepts data from external sources and that it stores individual user values in user profile properties, it’s time to put the two together and find out how to store user data in profile properties from external data sources. This is the topic for part two of this post: Getting/Storing user data from external sources.

Labels: .NET, Authentication, SharePoint, testing, web development

When I work on a web application, I usually have the luxury of running everything that I need locally on my developer machine. My browser, Web-server and database all working together without ever having to put a single packet on a real network.

With today's web applications growing more complex and making use of asynchronous calls to the web server, this idealistic development environment makes it very difficult for the developer to assess the performance characteristics of the application. This can lead to surprises when the application is deployed to a real environment where users actually access it from remote locations.

A good way to bring reality back to this equation is to make use of a proxy server. I like to use Don's Proxy. It is simple Java-based application that takes 1 minute to setup and lets you inject latency, errors and throttle your connection bandwidth. All of this is made in a manner that is independent of your browser or your web server. Most importantly. it does not require any changes to your application's code or setup.

To use Don's Proxy, simply download the package, unzip and double-click the jar file. A simple GUI will open (screenshot) that will prompt you for a port for the proxy to listen to and a host/port for the destination of your test web server. In the example screenshot, the test web server is running locally at port 8080 and the proxy is setup to listen on port 9090.

Once the proxy is started, you just redirect your browser to the proxy's port and everything should work as before. The difference is that now, you can inject realistic network parameters like latency and bandwidth limitations. Don's Proxy also allows you to capture traffic as it goes through and perform other diagnostics without the use of a packet-sniffer.

Hopefully, a more common use of tools like this will help curb developer enthusiasm for flashy Ajax behavior. Your users will thank you.

Labels: testing, web development

I'm not going to go into detail about the benefits of using CSS, which have been covered so many times before. In short, it provides a convenient way to separate presentation logic from actual web markup, it reduces duplication of style-related code, and best of all it's incredibly flexible! Ah, but that flexibility is a bit of a double-edged sword: allowing many ways to do the same thing means similar things will likely be done differently in different places, gradually leading to a mess of files which is a nightmare to maintain.

If you don't believe me, install a tool like FireBug and pull up a favourite large-scale web site. Set a small goal for yourself, like changing the colour of an entire page's background, or changing the bottom margin of all headings across all pages, something that should ideally only be a few lines to fix. Is it really as easy as it sounds? The answer is likely no, and there are many factors that can contribute to this:

• Multiple developers working on separate areas of the site, each using their own set of rules for how their CSS should be written.
• Years of modifications by different (or even the same!) developers are done with little consistency across the site.
• The original developers saw CSS as an afterthought; something you work on after the site "works" that can be done in any number of ad-hoc ways.
• The CSS was generated using a WYSIWYG-style editor (such tools are notoriosly bad for producing maintainable code).
• The original CSS is out of touch. The web changes quickly, and even sites that are only a few years old may be using syntax that has been updated or replaced.

Even well-meaning developers will make mistakes while modifying files that were started by others. If the existing file already does the same thing in several ways, which way should one use? What if the particular file only defines one way of doing it, but other files use a different method? What if the existing way is consistent, but far from optimal? Refactoring one CSS file (let alone several) is a remarkably grueling and time-consuming task. Is this unavoidable? No! It just requires a little planning and a little discipline.

The trick is to set up (and subsequently follow!) some design guidelines to make sure everyone starts, and most importantly stays, on the same page. This is best done at the beginning of a project, but it's never too late to start doing something right. For example, here are some things you may want to set guidelines for:

• How specific should selectors be? Is it all right to define a general rule for all instances of <div>, or should each <div> require a class? Should selectors be classes-only, or are ids allowed as well?
• Should traversing the DOM, as in "div.classA span.classB a" be allowed? encouraged? mandatory whenever possible?
• What sort of things are forbidden? This is important to consider for things like wildcards (*), inline-styles and <style> tags, etc.
• How should CSS be broken into multiple files? Does each section of the site get its own file (login.css, register.css, menu.css...) or are files broken up by functionality (layout.css, form.css, graphics.css...)?
• What level of CSS quality are you looking for? Does all CSS have to validate? What about browser-specific rules that are likely non-standard? (IE's conditional comments can work wonders here)

There is no right or wrong answer to any of those questions. What's important is to give each option some thought, and decide which is best for your particular needs. These are design decisions that involve real trade-offs in maintainability, functionality and resource needs, and just like any other design decisions, they will have a real impact on the outcome of the site. Deciding upon and following through on just a few well-defined guidelines makes these factors clear, and provides an optimal environment for developers to write maintainable code.

Labels: CSS, web development

Unless you have been living under a rock, or have never touched the source code of a web application you have likely heard of Flex or Silverlight.

I am not going to talk about the differences, in reality, I have never used Silverlight, nor have I ever written production code in Flex. But I tell you, from my research and R&D, this is the way of the future for web applications.

Now, the more astute of you will have noticed that I am saying web applications, not sites. This is because Flex and Silverlight are useful for making what is known as Rich Internet Applications.

Using these technologies for your blog site is like using a 30 pound sledge to hammer in finishing nails. Sure you can do it, but you are going to dent a lot of wood.

Personally, when I want to read about the latest souffle cooking recipe from my favourite blog, I don't want to wait for the site to load.

There is no reason to use Flex or similar technologies for simple web sites. The vast majority of sites don't require the vast level of interactivity that Flex provides. Using Flex will limit you to users that have the Flash player installed, which is most, but not all. Some web purists will also not visit your site if it uses Flash.

Then why use Flex to build RIA? Because the value of your application will outweigh any of the negatives that some people will associate with Flash based web applications. And the time you will save in development will allow you to add more content and value then you could with the standard HTML/CSS/JavaScript approach.

So let's get to the point, and talk about the benefits of using Flex.

• Ideal for creating web applications
• No cross platform support issues
  
• Completely portable to any platform that supports Flash (Firefox, IE, QNX, Linux)
  
• Allows for a high degree of interactivity very cheaply
• Flex has a comprehensive visual designer that allows you to drag and drop controls onto the form
• SDK is free
  
• Faster development with their IDE
  
• Better debugging capabilities
• Memory and performance profilers
  

Wow you must be saying, where do I sign up? Well before you do that, there are few cons as well:

• Flex is overkill for simple things
• If you are building UI that interacts with exposed web services, you need a strong middle tier to validate data
• The IDE is not free
• The relationship between MXML and ActionScript is absolutely not the same as the relationship between HTML and JavaScript
  

Overall, I would say Flex is incredibly useful for developing rich internet applications. In fact, if I had of known about this a year ago, I would have started a project with Flex instead of .NET/HTML/CSS and a set of third party charting widgets.

Live and learn.....

Labels: Flex, web development