SharePoint designer workflow and Activity Duration report

If you design a workflow from SharePoint designer and try to view the"Activity Duration Report", you are most likely to see the following error









Report contains no data. at Microsoft.Office.RecordsManagement.Reporting.Report.Generate(Hashtable query) at Microsoft.Office.RecordsManagement.Reporting.ApplicationPages.GenerateReport.Generate(String strReportId) at Microsoft.Office.RecordsManagement.Reporting.ApplicationPages.GenerateReport.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint




Workaround

After lot of frustrations and trials and errors, I discovered that this report is only get generated if you have some entries in the hidden "Workflow history" list. The only way to put something int he history list from SharePoint designer is to have a "Log to History" list action item as shown below







The assembly responsible for generating these reports are mostly obfuscated. I have a support ticket open with Microsoft with no luck. So far can not figure out how this report is suppose to be generated and why this report is available for Visual studio generated workflow and NOT for SharePoint designer

If someone know the solution, please send me an email

<CustomAcion>/<UrlAction> and opening a link in a new window

The <customelement> element lets you build a custom menu item for various SharePoint UIs and you can easily deploy your menus using Feature framework.

If you need to include a custom hyper link - You need to use - The problem with is that there is no attribute to open it in a new window - There is no equivalent of "target" attribute of an Anchor - I guess whoever designed this feature must have thought hmmm...since there are lot of pop-blockers who would want to open a hyper link in a new window - So why bother putting this feature :) Well pop-blocker are good for blocking ad windows but at a time you do want to open a link in a new window for usability purpose -

So in order to open a link in a new window you can use the good old javascript:window.open(url)

e.g.

<urlaction url="javascript:window.open('url')" >


What is wrong with the above line ???

Well, the above line works when deployed in SharePoint - The target link in fact does opened in in a new window but while IE opens the link in a new window, it also replaces the current window with [Object] message (IE tries to open the javascript as a link in the current window) - This is pretty annoying - You need to click the back button to go back to the previous screen in the current window...

How to solve the problem in IE ?

Well , you can trick IE to think this is not a window.open() command and you are executing a custom script - So just replace the above url with something like


<urlaction url="javasscript:void window.open('url')">

And now IE will only open the link in a new window -

I hope Microsoft fixes this during SP1 time frame by providing a "target" attribute on UrlAction element

Content Query WebPart(CopyUtil.aspx) and Anonymous Access on your site

Content Query WebPart (CQWP) is a great little webpart, which lets you display any content from any level of your site on a webpart page. The problem with this webpart is that it was not designed for anonymous access, at least not completely. O.



If you have a site enabled with anonymous access and if you drop this web part on a page. you will notice that this webpart shows the contents to anonymous user correctly however when you click on any of the list item(hyperlink), It will challenge you to enter windows credentials or you will get "403" forbidden error.

After examines I found that Content Query Webpart usages copyutil.aspx page in layouts folder which in turn redirects to appropriate edit form depending on the type of the list. That's where the problem lies.

The "CopyUtil" class inherits from a generic class called "UnsecuredLayoutsPageBase". This class has a property called AllowAnonymousAccess . Which the inheriting class should override and set it to the true or false based on how web application is configured







Workaround:

1) Override the ContentQuery Web Part's XSLT and instead of using copyutils.aspx use the "dispform.aspx"

2) Create a cusotm copyutil.aspx page and override the AllowAnonymous property

FBA and friendly display name in SharePoint 2007

If you have ever implemented the form authentication(FBA) in SharePoint, you will soon experience that SharePoint treats non AD authentication as a step child. Though , its very simple and straight forward to implement a form based authentication however it is not the same user experience as you would expect or see with Active Directory based authentication.

One thing immediately becames visible is the user name. When you log with Active Directory you see a friendly name like shown below.

However , with the form authentication you see the loginId and NOT the FirstName & Last Name, you would like to see.The reason is simple. The standard MembershipUser interface, only has one property called "UserName", This properly holds the fully qualified user name ( domain/username) or (membershipprovider/userId) .

So how do we display a friendly name? After investigating, I came up with two options.

1) User Profile (MOSS Only)

It appears that SharePoint read the friendly display name from the user profile of a user if one exists. By default there is no user profile created for FBA. You can manually create a user profile for all users via SSP or programmatically create for all users.

I found following utility by Sahil , which takes a xml file and does bulk user profile import. Sahils' also shows a code snippet on how to programmatically create user profile

http://blah.winsmarts.com/2007-1-SharePoint_2007_Utility_-2_-_PI_-_Utility_to_Import-Export_actual_user_profiles.aspx

2) UserInfo table (WSS and MOSS)

This solution requires direct update to SharePoint table but does work. So I recommend carefully planning before any update.

At every site collection level, SharePoint stores the firstname + last name in the userInfo table . The friendly name is appears to be picked up from the tp_title column. I believe SharePoint creates entry in this table, the first time you add a user in any list or a site ACL. Look for your form authenticatation (FBA) userId in this table and replace it with a friendly name.

I think this is a good enhancement request for MembershipProvider and SharePoint team

Microsoft breaking its own rules of cookie security

In order to minimize the XSS vulnarabilites, Microsoft had implemented a "HttpOnly" cookie feature in IE 5.0 and above versions. This feature prevents other scripts or applications (e.g. applets) from directly accessing the cookie marked as "HttpOnly". Fair enough, though not everyone agrees that this really prevents any attack but I think its a good idea. ( http://www.gnucitizen.org/blog/why-httponly-wont-protect-you)


What is the relation of HttpOnly cookies with SharePoint? Well, as you know SharePoint 2007 is a ASP.NET 2.0 application, which means its utilizes all underlying features of ASP.NET 2.0 such as authentication and authorization. When ASP.NET authenticate user via form, it generates a cookie called ".ASPXAUTH" cookie. This cookie by default is marked as httpOnly, which mean no other applications should be able to access this cookie, including windows call such as InternetGetCookie (http://msdn2.microsoft.com/en-us/library/aa384710.aspx) which gets all cookies stored on your computer for a given site but respects the "HttpOnly" flag..

Office applications such as Word, Excel and SharePoint designer does not work well with Form Authentication but you can make it by setting the authentication cookie to persistent cookie. When you set the form authentication, the SharePoint login page has a check box to remember the userId/Password, this creates a persistent cookie, After this setting, if you open the Office applications, you are not prompted for authentication. If the Office applications are playing by rule and using the InternetGetCookie() method to get the cookies for a given url then they should not be getting the ASPXAuth cookie as this cookie is set as "HttpOnly" cookie by SharePoint/ASP.NET Form Authentication Handler? After monitoring the office appliations, I noticed that I office applications directly access the local cookie folder to read the cookies files.

My only guess is they are bypassing any standard windows call s and reading the temporary internet folder for cookies and parsing the cookies using undocumented features:) . Agreed, its a good feature to support the form authentication with office applications but directly accessing cookies is not something I expected specially after all the preaching they did on the securities

Your thoughts please?

ChangePassword page for FBA(Form based Authentication) for SharePoint 2007

One of the nice features of SharePoint is its pluggable authentication. Its actually a ASP.NET 2.0 feature. Since SharePoint 2007 is an ASP.NET application, SharePoint inherits it for free.

SharePoint provides an out-of-the-box login.aspx page , located in 12 hives /layouts folder, which is automatically enabled when you turn on FBA on any of the Zone. There are plenty of postings on the web on how to get your forms authentication working in WSS and MOSS

What I didn't find is change password . Once you enable the form authentication, how a user can change the password? There is a ASP.NET control but nothing out-of-the-box in SharePoint, to support this

So I decided to write a custom ASPX page to handle changepassword and provision it via "Feature" . It is very simple

Here is what the final output look like. You can download the entire sample from here.

Change Password Menu Item in Welcome menu (PersonalActions)

Change Password aspx page

Here is what I did

1) Created a simple aspx page and inherited "application.master" master page. Application.Master is located in /layouts folder . You can use any of the master pages from the /layouts folder or create a custom one.

2) Drop asp:changepassword control in the content area

<asp:changepassword id="ChangePassword1" newpasswordregularexpressionerrormessage="Error: Your password must be at least 7 characters long, and contain at least one number and one special character." newpasswordregularexpression=""></asp:changepassword>

3) Copy this page to 12 hives /layouts folder

4) Create a <CustomAction> Feature set the feature URL to /_layouts/changepassword.aspx page

<customaction id="ChangePasswordMenuId" title="Change Password" description="Change Password control" sequence="2000" location="Microsoft.SharePoint.StandardMenu" groupid="PersonalActions" > <UrlAction Url="~site/_layouts/changepassword.aspx"/>

5) Install the feature using STSADM.exe

And there you go!! You have the changepassword page with very little effort.

May be Microsoft can include this as a out of the box feature in the next version of SharePoint :)

InfoPath Forms vs. ASPX Pages in SharePoint Designer

Marketing is such a wonderful thing; it makes you believe in something which doesn't exist.
Now, why am I taking about marketing on a SharePoint blog??? Well, lately, I have been asked by many of my customers on using InfoPath 2007 for all their form developments. Now that’s a great idea. InfoPath 2007 is designed for efficient forms management and very powerful tools if used properly. What is not clear to me is that somehow Microsoft have sold this idea that InfoPath is for non-geek, you need absolutely no coding or programming knowledge to design
InfoPath. Again this may be true for simple forms or handful of non-geeky folks who were born to be curious and dare to try new things but Majority of computer users are not geeky. I have yet to find a average computer user or a knowledge worker who can design following InfoPath form (with calculation and data lookup and posting back to SharePoint ) Or someone who can understand What "Data Connection" or "Repeater" means.

When it comes to SharePoint 2007, one always has to make a choice whether to use InfoPath 2007 or design ASPX page. Here is a comparison I came up with on when It make sense to use InfoPath vs. design an ASPX

SharePoint forms	InfoPath 2007 form	ASPX Page ( using SharePoint Designer)
Design tools	InfoPath 2007- a Desktop application, part of Office Suite. Since InfoPath forms are XML based, Programmers can theoretically design the InfoPath form in notepad	Can be designed in Microsoft© SharePoint Designer 2007 (aka Microsoft© FrontPage) For programmers: Dependingonthe choice of tools, ASPX pages can be designed in notepad to Microsoft Visual Studio,
No-code design	Drag and drop support for form controls, table layouts etc. This is by far the best feature I have seen in InfoPath	SharePoint designer does provide drag and drop, simple validation and business logic without writting a code. However as far as User experience is concern, SharePoint designer is subpar compare to InfoPath 2007
Integration	You can submit an InfoPath forms to variety of sources including web services and SharePoint. Lookup data can also be brought from simple xml file to any line of business application and databases.	The built-in integration components to pull data from other sources are not as rich as InfoPath 2007.
Advanced design	This is big differential point. InfoPath 2007 forms out of the box look very nice. However does not support advanced scenarios Tabs Custom AJAX/DHTML Show multiple/nested forms Hand	SharePoint designer allows you to design advanced ASPX Page by direct coding html and JavaScript
Master Page	Out of the box, InfoPath forms are hosted in a new page without a master page. If you need to put a master page around your form for consistency, this require some work 1) Design a InfoPath form 2) Design a ASPX Page with master page 3) Drop <XMLFormView> control in the ASPX page and point to InfoPath	Complete Master page support
Compatibility	By design, a InfoPath form can be opened in 1) Any browser (e.g. IE, Firefox, Safar etc.) 2) Desktop App You can optimize for Desktop, but you cannot optimize for a specific browser or an environment. This is a limitation with any form tools which support variety of tools. The choice of controls are limited to This	Unfortunately, an ASPX pages can only be designed for browsers. But you have lot of choices to optimize for a specific browser.
Publishing to SharePoint	In spite of Microsoft's best efforts, the publishing to SharePoint is not as smooth as you would have expected from a non-programmers tool. I love the "Blogging" feature of Word 2007; it's simple and intuitive for non-technical folks. I would have liked to see a similar approach in InfoPath 2007 Nonetheless with some training, I think InfoPath offers a great capability for publishing forms	In my personal opinion, designing an ASPX page and publishing to SharePoint is lot simpler in SharePoint designer than in InfoPath 2007
Error handling	Because InfoPath is designed for knowledge workers AKA non-programmers, the error handling is some what poor. Most exceptions only make sense to the technical folks. But if you get some cryptic exceptions such as "Unknown error" or "exception occurred" , you are really out of luck unless you find some clues in the /12 hive log or the Event log	Pretty friendly and intuitive, you can do better error handling. You have more control on the flow compare to InfoPath 2007.

SharePoint and Large files ( > 1GB) in a Document Library ?

I have been repetitively asked if SharePoint can be used as an alternative to FTP or Network Share. SharePoint does offer strong capabilities for document management but it by NO means is an alternative to FTP or Network Share

As you probably know, SharePoint stores all documents in database as a blob. Which, in itself is not an bad idea. I know you probably thinking I am smoking !. But the truth is that in SQL SERVER 2005 BLOB performance is vastly improved. Also SharePoint 2007 does smart caching on Web Front ends (WFEs) for most frequently used files ( e.g. JavaScript, CSS and images etc) .

However because its a web application and does not use special controls for most files ( except for Office documents, which are downloaded via FPRPC over HTTP - discussed later) it suffers with all following limitation if you try to upload or download

1) Your browser could timeout while uploading a large file

2) Your browser could run out of memory due to spooling

3) If lots of users are downloading or uploading large files, it could impact your web server performance

4) If your download fails for any of above reasons, Your download will not resume itself, You will need to start all over again...

So, what are your choices ?


1) Store File on a Network Share or SAN devices: One solution is to store the actual file on a fast network device and only keep the path in the document library (or create a simple list item and store the link) . You need to make sure that only the process account has direct access to network access and you may also need to write custom event to prevent unauthorised access.

This way you can take advantage of SharePoint UI, Security, Target Audience and Search feature and also optimise the user experience and performace

However, using this solution requires careful planning, coding and security testing.

2) Create custom download activeX control or Windows App : If you are building an application for a controlled environment, you could also write a custom ActiveX control or a Windows application and use WCF / MTOM with SharePoint Web services to download files asynchronously and chunk by chunk ( streaming) -

In case of an error, you can resume the download where you left before the error occured. You can also notify server on a successful download using custom hash.

Basically you have lot more choices in this approach then the first approach for download


3) Wait for SQL SERVER 2008 : Well, if you can wait, there is a rumor that SQL Server 2008 will have an alternative storage mechanism for BLOB. After all you might a get choice to store BLOB in a file. Does the name WinFS ring a bell?

Custom Workflow , SPWorkflowActivationProperties and "Current user"

Today, I saw an interesting post in one of the newsgroups where someone was looking for a way get the identity of the current logged in user. The user tried getting the current user's Id by SPWorkflowActivationProperties .Web.CurentUser which in normal circumstances make sense but not in the case of the windows workflow. Why? Lets try to break down this problem.

First of all SharePoint is a hosting windows workflow which means its running the windows workflow runtime possibly in the same process as the current web application, however it is NOT necessarily sharing the same session or context, moreover , there is no sequence or direct corelation in the execution of a workflow activity and and a browser session. Also, a workflow activity can be invoked from any external program, it does NOT have to be the current session. E.g. If you are writing a workflow to approve an item, it can be triggered by Outlook, Word, SharePoint or any custom application for that matter.

Why SPWorkflowActivationProperties .Web.CurentUser returns SharePoint/System user ??

The simple answer is SPWeb and SPSite properties of SPWorkFlowActivationProperties are instantiated by the workflow runtime and workflow runtime impersonate the current "Process account" to create SharePoint objects, hence the "SharePoint\System" user

But I want the current logged-in user ?

I think the question should be rephrased, Instead of the currently logged in user, you may want to access the user who last edited one of the list item on which you are executing the workflow. If that's what your use case then there are multiple ways to get it. The simplest way is to use "Modified By" column of SPListItem. All SPListItems has this properties. This will give you the Id of the user who last touched your item in question.

"Policy for web application" and Form Based Authentication (FBA)

The authentication scheme in SharePoint 2007 is very flexible. Out of the box SharePoint supports multiple authentication schemes and also lets you build a custom one. Now every flexible thing comes at a price, The over-flexibility also increases complexity, specially if you start mixing Intranet and Extranet applications with different authentication.

One of the features in SharePoint is called "Policy for Web Application" (Personally I think they could have chosen a better name). What this feature allows you to do is define the top level security for a "web application" in central admin. This is really neat if specially if you are creating a new application and what to give certain groups or users access to an application before creating an Site collection or login into the application. This comes very handy in case of an Form authentication. N

Now, you should be very careful when you add a group in the web application policy screen. The minimum (assertive) access you can give in this screen is "Read all" . Now this literally means "Read all". Any user or group given "Read All" permission will always have "Read" access to all site collections, lists and items in that Application, That's right, even if you break the inheritance model, and put Item level security. And the most annoying thing I found is those users/groups are not visible in the "All People" screen from the site.






So next time, when you planning to use "Policy for Web Application" remember that any user you add here ALWAYS has minimum access to the entire application regardless of your security policies within the site .

"People Search" and My Site / SSP configuration

When you crawl the Local Office SharePoint Server sites content source and if you are getting the following error, you may want to check your SSP configuration

sps3://SERVERNAME ( MySite Application URL)
Error in PortalCrawl Web Service

What I discovered is while creating a new SSP, I did not create seperate web application for "Mysite" and "SSP Admin" ( as recommended by Microsoft), instead I created a single web application with two site collections - one for MySite and other for SSP admin . Now if you do this, SharePoint is not going to create a root Site Collection ie.. http://SERVERNAME:PORT (my site application) will be empty. This for whatever reasons causes stomach ache for SharePoint Indexer. If you go back and create a dummy Site Collection in the root of My Site Web application and then reindex your content source, the above error will go away ( at least it did for me)

Now, if you are still using SPS 2003 and getting similar error, you may want to check out MS Support article on this

http://support.microsoft.com/kb/835521

Different User profile screens

Recently, I was playing with user profiles in SSP and noticed something very strange. When you edit a profile of an admin user (userprofile automatically added by SharePoint) the screen is slightly different than that of a regular user ( Users you import from LDAP or manually inserted).

In case of an admin user, SharePoint automatically populates the MySite URL and shows browse button to import a picture. In case of a regular user both MySite URL and Picture fields are plain text with no picker control.


Admin User Profile Screen ( http://server/ssp/admin/_layouts/ProfAdminEdit.aspxdmin/_layouts/ProfAdminEdit.aspx)








Regular User
http://server/ssp/admin/_layouts/ProfAdminEdit.aspx










Its a minor difference but I am not able to figure out why?? I like the admin UI. Not sure why SharePoint team decided to implement it differently. I am curious to know, If anyone has any idea, please share with me

When SharePoint 2007 "Restore" fails

If you are a developer, "backup" and "restore" are not something you spell every often, most of the time we leave it up to the IT to take care of such jobs

Recently, I had to move one of demo web applications to a different machine. Well, I could have ghosted the whole image and restore it on other side then it stuck me that may be I can take a backup of my web application from the current machine and restore it on the new machine.


The backup process was smooth. SharePoint created a folder structure with all necessary .bak files. While restoring on the other machine, I ran into some issues. The restore process started fine but then I saw some errors in the restore.log file in my backup folder.

[5/6/2007 8:35:11 PM]: Error: Object WSS_Content_37a0332fb0794e7eb29b164e68d16910 failed in event OnPostRestore. For more information, see the error log located in the backup directory. SPException: Cannot attach database to Web application. Use the command line tool or Central Administration pages to attach the database manually to the proper Web Application.[5/6/2007 8:35:11 PM]: Debug: at Microsoft.SharePoint.Administration.SPContentDatabase.OnPostRestore(Object sender, SPRestoreInformation args)


When I checked the SQL server, it did attach the content database however because of the above error it failed to join my web application entry to the content database. Also, because the restore process abrupted, it did not created the IIS web application on the new machine. To resolve this issue, I had to do the following

1) From Central Admin Applications Add Content Database screen --> Add the newly atttached content database. By default, this screen will show values from backup machine




2) Next, I had to restart the Windows SharePoint Services Web Application" Service . This service is responsible for creating IIS application on local web -front end and also to keep in sync with other servers in the farm.



After this, I was able to see my old application on the new machine. I had to copy my aspx customization from \_layout folder, some features and legacy COM controls to the new machine.

When not to use SharePoint Designer (AKA Microsoft FrontPage)

SharePoint designer is a great tool to edit SharePoint sites and pages without detail knowledge of ASP.NET or HTML. But like everything else in life this is not the perfect tool for everything, specially if you are modifying an aspx or a master page from "_layouts" folder.

In SharePoint the relative path to the page is represented using tilda (~) sign e.g. ~/_layouts/simple.master, which means the ~ will be replaced at runtime with appropriate site name. This is where the problem begin, when you open a page which is on a file systel e.g. _layout folder, SharePoint tries to resolve all relative path to the site (thinking its a "Ghosted" page) and end up replacing with "_layouts" . You don't get any error until you start using that page. At runtime, SharePoint will try to resolve all path to "absolute" _layout folder - which does not exists, as oppose to a relative ~/_layouts path . Wish there was a better way to handle this. I ended up editing these page the old fashied way - e.g. Notepad . Hopefully in SharePoint 2007 Service Pack1 this might get resolved.

Things to keep in mind when implementing Custom Authentication Provider for SharePoint 2007

Recently I had to implement a custom authentication provider for one of my clients. From the surface, it looked easy since SharePoint 2007 is an ASP.NET 2.0 application so all you need to do is implement - MembershipProvider and RoleProvider. Well, that part was easy but the hard part was to figure out how SharePoint make calls to your custom provider, which calls need to be optimised, what data can be cached.

Here are some findings

1) RoleProvider : Although this is optional, you are better of implementing this one. One biggest problem I ran into without implementing this one was "Admin" user, How do you add a user to Admin role? and Without a admin user, how to login and add other users ? Chicken and Egg problem. Though via Central admin you can give a user full access to a virtual user but when you try to login into your application(site), SharePoint will throw "Access denied" error

2)User Lookup and Addressbook : Anywhere in SharePoint, when you click these two icons , They call your Custom Authentication Provider. Interestingly both these button call the FindUsersByEmail method. If you are expecting a wildcard user search, the default wildchar character SharePoint usages is %, though this can be replaced to a different character by modifying your Authentication provider entry in web.config file

3) Editing Master Page : One problem I ran to was that I had to update default master page, Because I was using CustomAuthentication Provider, I could not open it directly from SharePoint designer ( though there is a way to achieve this - e.g. persistent cookie) I had to edit it the old fashioned way aka - Notepad. Well I made couple of syntax errors but I forgot to test it locally and directly check-in via "Masterpages Gallery" - Bomb!, I could not get my default page to load, It keep giving me - "Resource not found" ASP.NET generic error. I could not see any error either in SharePoint log or in Event log. The only way I could roll it back was by changing my authentication provider back to "Windows" and then loading my master page in "SharePoint designer". I wish there was a better way to do this.


I am still having fun with it. I will post more findings later. If you are looking for how to implement an custom authentication provider, here is a great MSDN article

http://msdn2.microsoft.com/en-us/library/f1kyba5e.aspx

"Domain\User" vs "User" What's the difference if the user is local?

Well, in SharePoint land its a big difference. SharePoint will throw all kinds of weird errors if you forget to include a "domain\" prefix for a windows user when you create a "site collection" or web application.

The best practice is to alway use "domain\user" to avoid any confusion.

Custom Protocol Handler vs BDC

I get this question a lot. If I have SharePoint 2007 enterprise version, I can index any repository with Business Data Catalog (BDC). Why should I care about Protocol Handler? Writting Protocol Handler is anyway is a pain in neck, even the experienced C++ developers find it hard to write

So the simple answer is the BDC was designed for knowledge workers (those who Microsoft consider pseudo-programmers) to be able to extract busienss information from Line of Business Application using declarative langauge (XML) as oppose to a regular programing language.

Since the target audience of BDC are knowledge workers and not programmers, its NOT designed to scale or for complex scenerios. Its a very much black box design. You don't really know what happpens behind the close door ( and you probably don't care, if you are not a programmer)

This is what you don't get in BDC

• You have no control over what type of IFITLER ares applied. Agreed, you don't really care if this is just a matter of text extaction from binary documents, but if you really want to emit custom metadata, or links, you do need a good control on how its being handled
  
• You can not do any kind of custom throttling or optimization. Everything is a black box. SharePoint provides some throttling options for content-source, but thats as far as you can go
  
• You have no way to do any network optimization, custom error handling or debugging. If your document is not indexed, well you will in the gatherer log but with standard error message
  
• You can not emit custom security ACL for your document/items to BDC
• You can not control the incremental indexing, new items or deleted items.

• You can certainly specify in BDC definition but nothing compare to protocol handler
• Finally, putting PH developer on the resume is totally different than putting BDC developer :)
  

SharePoint SDK = .NET (Managed Code) + COM ( Unmanaged code)

Ever since I used reflector(a freeware tool to examine any .NET assembly) I check most third party assemblies before using in my code. SharePoint was no exception. I wanted to see how SharePoint communicates with SQL Server. So I started digging but to my disappointment, I couldn't find any references to database related code. But to my surprise, I discovered something entirely different (See the class below)

Most SharePoint data connection usages SPRequest class, which is in Microsoft.SharePoint.library.dll ( This dll gets copied in GAC on SharePoint machine, you will need to manually copy this DLL out of GAC if you want to see all interfaces). Now this assembly in turn usages OWSSVRLIB.DLL ( This dll is under 12\ISAPI folder). Interesting thing is, this is a COM (UNMANAGE CODE) dll, obviously reflector didn't work

So I was disappointed in my quest but I indeed found something which makes me wonder is this an intelligent design decision or simply lack of time?

Proof reading, usability or lack of time ?

I usually stay way from pointing out mistakes but I couldn't resist with this screen. This is in SharePoint 2007, one of the products that brings food on my table :)

So SharePoint 2007 supports multiple operations - Performing action on more than one items with a single button. If you go to "Site Action" | Portal Content and Structure, you will notice that all contents has a checkbox in front of it. You can select more than one content and then pick your action from the toolbar above.

In my test environment, I had few sites, which I created as part of my stress testing and I wanted to get rid of them with a single command, so multiple operation was the perfect action for this kind of stuff. Everthing worked nice and well but the confirmation message screen SharePoint displayed was funny... It appears someone either forget to test this or didnt bother :)

When and Where to use SharePoint SDK

In addition to standard SDK, SharePoint supports web-services, front page rpc and webdav(on front page RPC). How do you decide, which one is appropriate for your application? . To make it simple, I have put together a following matrix

Type	Purpose
SDK	When you application is hosted on the same box as SharePoint , it makes perfect sense to use SDK. SharePoint SDK requires the SharePoint to be installed on the same box.
WEB SERVICES	Now a days, Web-services makes sense for any application.Most technical and non-technical folks seems to throw this key word to show off their grasp on latest happening in technology. In case of SharePoint, web services makes sense when application is interacting from a different machine or network. The appropriate applications would be .NET application on a different machine Interaction from non .net application such as Java or Perl Access over internet (for SaaS)
FrontPage RPC / WEBDAV	SharePoint interacts with all Office clients mostly with Front Page Remote Procedure Call (FPRPC) and Webdav. If you are writtign a custom client or an integration for non-microsoft clients, this is your best choice. If you need more information on how to create handle front page RPC calls you you will find following links useful SharePad : is an open source application, designed to give more inside into how one can consume FrontPage RPC. Overview of the SharePoint Team Services Architecture