October 2008 - Posts

• Windows Sharepoint Services 3.0 as a Solutions Platform

  A lot of .NET developers still do not see the point behind using WSS 3.0 or MOSS 2007 as a development platform. I have therefore decided to write this blog to explain the benefits from the OS upwards to make it easier to understand. I do not claim that the Sharepoint platform is a solution for all kinds of development projects, but I have noticed that a lot of developers tend to ignore the benefits of what it has to offer and keep on re-inventing the wheel. Below is a diagram outlining all the sub layers involved before we get to MOSS 2007 and the functionality it provides. I will start with the OS and work my way up to MOSS 2007. OS (Operating System) The only OS's that Sharepoint can use currently is either Windows 2003 server or Windows 2008 server. This is due to the fact that Sharepoint requires application pools that are only available with IIS 6 or IIS 7. There are however a lot of advantages that these OS's offer the developer that they take for granted. Most developers focus on the desktop OS's like XP and Vista due to the fact that they develop on these platforms and miss the advantages that a Server OS has available as they almost never investigate these options. They always tend to re-develop what is already available due to ignorance. I am therefore trying the educate and emphasis the built in advantages of these OS'S so that we can stop re-inventing the wheel so to speak. Below is a list of the advantages that Server 2003 and Server 2008 have to offer: Windows Server 2003 Easy to Deploy, Manage, and Use Secure Connected Infrastructure Enterprise-Class Reliability, Availability, Scalability, and Performance Lower TCO Through Consolidation and the Latest Technology Create Dynamic Intranet and Internet Web Sites Fast Development with Integrated Application Server Work Smarter By Turning Your File Server Into a Powerful Collaboration Server Automate Operations with Script-based and Policy-based Management Tools Increase Document Protection and Availability via Intelligent File Storage Easy to Find, Share, and Reuse XML Web Services Below is a hyperlink with a lot more detailed information on the benefits mentioned above: http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/top10best.mspx Windows Server 2008 Server Manager and the Advanced Event Viewer Server Core Terminal Services Gateway Terminal Services RemoteApps Native IPv6 support Read Only Domain Controllers Hyper-V Network Access Protection (NAP) Secure Socket Tunneling Protocol (SSTP) Windows Advanced Firewall and Policy Based QoS Below is a hyperlink with a lot more detailed information on the benefits mentioned above: http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2008-Top-10-Reasons-Upgrade.html  .NET Framework Most developers are aware of what the .NET framework has to offer as they work with this on a daily basis. I therefore am not going to spend too much time on this section, but I do want to point out the advantages of the .NET framework 3.0 and the new features that to has to offer. Also keep in mind that WSS 3.0 has already created extensions on top of this platform and a lot of the development that is done at this level might not be required anymore depending on what is required. The .NET FX 3.0 is a core requirement for installing WSS 3.0. The reason for this is that it integrates very tightly with some of the .NET extensions listed below, especially WWF. Windows Workflow Foundation (WF): Windows Workflow Foundation (WWF) is a Microsoft technology for defining, executing, and managing workflow's. This is used extensively by WSS 3.0 to run built-in workflow's that ship with the product, but also provides the ability of building new and custom workflow's. This can either be done using Visual Studio or SPD (Sharepoint Designer). Windows Communication Foundation (WCF): The WCF programming model unifies web services, .NET Remoting, distributed transactions, and message queues into a single service-oriented programming model for distributed computing. This removes the complexity of trying to manager each of these methods individually in the application and also creates a standard to manage these communication mechanisms. Windows Presentation Foundation (WPF): WPF is a consistent programming model for building solutions that enables the use of richer controls, design, and development in Windows programs. This now allows the developer to easily insert and use components such as video, animation, 2/3D graphics, and various kinds of documents into the application whist removing the complexity of trying to use API's directly like we did in the past. Windows CardSpace (WCS): WCS (originally called Info Card) helps people keep track of their digital identities as distinct information cards. This allows easier authentications on many web sites without the need to re-enter usernames and passwords or even credit card information. It is also encrypted and therefore a lot more secure. Below is a hyperlink with a lot more detailed information on the benefits mentioned above: http://www.c-sharpcorner.com/UploadFile/rahul4_saxena/DotNetFramework04182007043446AM/DotNetFramework.aspx  WSS 3.0 (Windows Sharepoint Services) Many people think of WSS 3.0 as a free piece of software that allows people to quickly build an intranet portal that will allow people to collaborate and this viewpoint is not incorrect. I on the other hand prefer to view WSS 3.0 as a logical extension of the .NET framework that allows developers to quickly build web based applications without the need of physically coding the web pages yourself. If we had to sit back for a moment and analyse the logical steps that a developer would follow to build a web based application you will start to understand my viewpoint. Let's build a quick list: Entities - developers would normally plan their entities using UML tools and then convert these into classes that will ultimately be compiled into assemblies. These assemblies will then be referenced in the web pages that will be created at a later stage. Metadata - properties for these classes will also be designed to store and manipulate the data in question. Database - structures will be modelled and created in the database to stored the data being manipulated Connections - multiple connections will be created to stored and retrieve information from one or more databases Security - this is always quite a complex component for developers to control and takes up a lot of time and effort. Quite often this component is not adequately covered. Authentication - Logon screens need to be developed to control access to the web application. Optimising - caching and threading is always difficult to code and the outcome is not always guaranteed. Scalability - most developers code for a single server environment and scaling is quite often ignored completely. Auditing - custom components need to be developed to create audit trails for the application. Web page builds - this is a very time consuming process and very repetitive in nature. These are just some of the issue that developers have to deal with and is by no means a complete picture of what is required. I am merely using some of them to illustrate my point. Now that we have loosely defined the normal concerns that a web developer has to deal with, let's look at how WSS 3.0 can solve these problems: Entities - these get created as "Content Types" in WSS and require no coding. Metadata - these get created as "Site Columns" in WSS and get bound together as "Content Types". No coding. Database - WSS automatically stores all metadata in its own database without the need to create additional structures. No coding Connections - connections to the database handled by the WSS provisioning engine. No coding. Security - this is handled by WSS through NTLM, Kerberos, SSO or "Forms Based" authentication. No coding Authentication - this is done by IIS and WSS. No coding Optimising - WSS has built in caching components that can be configured using the browser. Scalability - the topology of WSS allows it to scale out into a farm configuration. All web pages are stored in the database as metadata and can therefore be rendered from any amount of WFE's. Auditing - WSS has built in audit trails. Web page builds - the provisioning engine of WSS creates web page on the fly without the need of coding them. The layouts can be controlled using the browser or SPD. I hope you are starting to see how WSS is making the developers life so much easier and now we can truly to use RAD (Rapid Application Development). Below is a list of the top 10 benefits of using WSS 3.0: Improve team productivity with easy-to-use collaborative tools Easily manage documents and help ensure integrity of content Get users up to speed quickly Deploy solutions tailored to your business processes Build a collaboration environment quickly and easily Reduce the complexity of securing business information Provide sophisticated controls for securing company resources Take file sharing to a new level with robust storage capabilities Easily scale your collaboration solution to meet business needs Provide a cost-effective foundation for building Web-based applications Below is a hyperlink with a lot more detailed information on the benefits mentioned above: http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb684456.aspx MOSS 2007 (Microsoft Office Sharepoint Server) Even tough WSS 3.0 does all these wonderful things for us, there is a lot more than can be done. Microsoft has spent a lot of time and effort researching what applications business require and then went along and created a commercial product that make these available in the format of MOSS 2007. This is also an area were developers tend to re-invent the wheel by building applications that can be purchased for a fraction of the costs of what it would take to build them. Keep in mind that MOSS 2007 is built on top of WSS 3.0 and therefore all the benefits discussed in the previous section also apply to MOSS 2007. WSS 3.0 is therefore a pre-requisite for MOSS 2007. Let's take a look at the core areas that MOSS 2007 has to offer and were we can benefit from it out of a custom development perspective: BI - MOSS allows us to build digital dashboards to display BI data using "Excel Services", connections to external databases (BDC), caching reports for reporting services and built-in KPI web parts. Quite often developers spend huge amounts of time developing presentations layers for there BI solutions and these are now available Collaboration - MOSS is tightly integrated into MS Office and now allows user to share information like tasks, calendars, contacts and many more through Sharepoint with no need to develop additional applications. All documentation is now also stored in Sharepoint negating the need to email attachments too each other. Portal - Sharepoint has the ability to created full blown Internet facing web sites with built-in CMS capabilities like publishing, approval workflow's, security and browser based editing of web pages. Search - this allows users to find any information on their network. This includes content within Sharepoint, Databases, File Servers, Mail servers and many more. It even indexing the content inside the documents to allow users to search on that basis. Most web applications developed as stand alone solutions have very limited searching capabilities built in and normally rely only on the search capabilities built into IIS. Content Management - built in workflow's and information management policies allow us to control how information is accessed, secured and archived without the need of developing these components. Business Forms - this component allows us to create data entry forms to capture information like leave, expense claim data and many more. This information can then be directly written to any back end database without the need of developing a custom application to do so. These can also be attached to workflow's. The points mentioned above is only a brief summary of what can be done and you will have to do some more reading to understand to full benefit. Below is a list of the top 10 benefits of using MOSS 2007 Provide a simple, familiar, and consistent user experience. Boost employee productivity by simplifying everyday business activities. Help meet regulatory requirements through comprehensive control over content. Effectively manage and re-purpose content to gain increased business value. Simplify organization-wide access to both structured and unstructured information across disparate systems. Connect people with information and expertise. Accelerate shared business processes across organizational boundaries. Share business data without divulging sensitive information. Enable people to make better-informed decisions by presenting business-critical information in one central location. Provide a single, integrated platform to manage intranet, extranet, and Internet applications across the enterprise. Below is a hyperlink with a lot more detailed information on the benefits mentioned above: http://office.microsoft.com/en-us/sharepointserver/HA101655201033.aspx  Additional Applications built on Sharepoint If you start analysing what the whole Sharepoint environment has to offer, you will come to the conclusion that it offers functionality that is required by many other applications that Microsoft has to offer. It therefore was only logical the Microsoft would start building their other applications to start running either on top of WSS 3.0 or using it's functionality. Some of these applications include: Project Server 2007 Microsoft CRM 4.0 Performance Point Server Microsoft is making Sharepoint part of their fundamental building blocks going into the future and I envisage many more applications coming from Microsoft that will run on the WSS 3.0 provisioning engine. Below are some links where more information can be found: http://office.microsoft.com/en-us/performancepoint/FX101680481033.aspx http://www.microsoft.com/dynamics/crm/default.mspx http://office.microsoft.com/en-us/projectserver/FX100739841033.aspx Argument Before I start my argument of why I think Sharepoint is a good platform for development, I would like to state that I do not believe that this is a solution for all application development projects. This is not built for applications with huge transactional volumes, but then not many applications require huge volumes. Below is a list of points that I believe make Sharepoint a good development platform: No need to develop your own web pages as the Sharepoint provisioning engine will create these for you. No need to worry about the database structure as Sharepoint will stored the data for you in it's own meta base. Sharepoint can be extended by writing your own web parts and application pages to build new solutions. Business object and entities can be modelled and mapped using "Content Types". This becomes the best workflow platform for manipulating business data. MS Office is to most common desktop office application and seamlessly integrates into Sharepoint. Built-in search engine makes incredibly easy to find information. These are just some of the reasons why I think Sharepoint is a good development platform for business applications and there are hundreds more. This then concludes the end of this blog. Please feel free to post comments, I would love to know what you think! Referenced Articles http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/top10best.mspx http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2008-Top-10-Reasons-Upgrade.html  http://www.c-sharpcorner.com/UploadFile/rahul4_saxena/DotNetFramework04182007043446AM/DotNetFramework.aspx http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb684456.aspx http://office.microsoft.com/en-us/sharepointserver/HA101655201033.aspx Related Blogs Differences between WSS and MOSS Overview of the .NET Platform MOSS - Enterprise Content Management Architecture  SharePoint - The role of a Web Part vs using application pages Posted Oct 19 2008, 04:19 PM by Neil with 2 comment(s) Filed under: Sharepoint, .NET, Windows 2003, Windows 2008

• Building a Custom Workflow in Sharepoint Designer

  The concept of workflow is not a new one and many commercial products on the market have been offering solutions for years, but at a very high cost. As most of you know by now, Microsoft was started working on this problem since the creation of the .NET framework 3.0 with the addition of WWF (Windows Workflow Foundation). This has become the basis of workflow for most new Microsoft products like Office 2007, Project Server 2007, CRM 4.0 and MOSS 2007. Sharepoint specifically has many entry points into WWF and can basically be broken into the following levels of complexity: Built-in or Downloaded workflow's - these come standard with Sharepoint or can be installed with add-on templates. Sharepoint Designer - this tool allows you to customize many aspects of Sharepoint including custom workflow's. Visual Studio 2005/2008 - this is the ultimate tool for building workflow's, but is quite often overkill for what is required. The focus of this blog is to introduce you to the basic steps in building workflow's with Sharepoint Designer if you are not already familiar with it. It all starts with an object and a content type. Workflow's need to be attached to object so that they know what they are interacting with and there are basically two types of objects in Sharepoint, a list or a document library. Content types define what metadata is stored with an object and is vital in building a useful workflow. Even the default object instances like "Contacts" or "Tasks" have content types associated by default. Therefore the basic steps required to build a workflow is the following: Create an instance of an object like a "Document Library" in Sharepoint. Define the meta data required and build it into a content type. Associate the content type with the object. Build the workflow using SPD or VS and bind it to the object. In the following example I will be building a custom workflow on a document library using Sharepoint Designer. Start by creating a document library in a Sharepoint site and add some content to it. The next step would be to open an instance of SPD (Sharepoint Designer). Select "Open" from the file menu and point it to the site containing the document library. To create a new workflow, select "New" --> Workflow from the file menu. This action will initiated a wizard that will start up and guide you through the process. A number of options are available to configure on this screen: Name - each workflow requires and unique name to distinguish it from other workflow's in Sharepoint. Bind Object - the workflow needs to be bind to and object that exists in the site that was opened in SPD. Start Settings - the workflow is started by events triggered by the object. This can be "New" or "Edit" and is defined by the checkbox selections available. Variables - custom variables can be created to store values that can be used throughout the steps that will follow. These can be used later in phase 2 of the wizard. Initiation - it is possible to define questions that the user will be prompted with when the workflow is initialised. The responses can be used to determine the flow or outcome of the workflow. Once the initial options have been configured, select the "Next" button on the wizard to continue. The second phase of the wizard basically consists of an design pane that is used to create the logic of the workflow. Think of it as writing and "If Else If" statement in code, without actually having to write it yourself. Also keep in mind that this is only the first step of logic in the workflow and additional steps can be created by selecting the "Add Workflow step" option on the right hand side of the screen. Let's start by taking a look at the "Conditions" part of the logic first. This would map onto the "IF" part of a virtual script. When selection the drop down option called "Conditions" a number of options appear that allow you to define a condition for comparison to determine if this workflow should initialise or not. The workflow will always be invoked (Hydrated) when the events connected to he object fires, like "New" or "Edit", but the condition will determine if this particular workflow will be initialised. These condition can range from comparing dates to specific file values connected to the document. This is were the importance of the content types come in. If you did not spend sufficient time initially to determine what meta data needs to be associated with a particular document and built this as a content type associated with the document, then at this particular point the workflow becomes difficult to build. I personally believe this is why many people believe that SPD is not sufficient to build workflow's in Sharepoint. Keep in mind that specific values can be compared against each other by selecting the "Hyperlink" options that appear and then supplying either metadata fields or hard coded values for comparison. Additional branch logic can be created by selecting the "Else If" branch option further down the screen. It is also possible to create "AND" and "OR" scenarios by selecting the "Condition" option more than once. Now that the logic has been determined, it is time to decide what to do if the logic is "True" by setting the actions. To create an action for a particular condition is a simple matter of selecting the action from the drop down list called "Actions". In a similar fashion to the conditions, this will create "Hyperlink" options that can be configured by selecting them. Keep in mind that you always want to us metadata fields that come from the content type instance associated with this particular "Document" or "List Item" that invoked the workflow. There are too many options to discuss them in detail and you will have to experiment and play with them to see what is available and how each of the options work. There are also a lot more options available by selecting the "More Actions" option from the drop down list as illustrated in the image below. Also keep in mind that some of the options only apply to lists and others only to documents. For Example: When selecting the option called "Send and Email", do not hard code the email address by typing it into the action, but rather retrieve the email address from an meta data field associated with the content type. Assuming that you built it into the content type to start with. It is also possible to add multiple actions to a condition by selecting the "Action" option more than once. Once this step has been completed with its conditions and actions you need to determine if you need more steps. This was only the first step in the workflow and optionally more can be added by selecting the "Add Workflow step" on the right hand side of the screen. When you have completed building the workflow, select the button called "Check Workflow" to determine whether your workflow will compile and the logic actually works. If you get the "All Clear", then select the "Finish button" to build the workflow. You will also notice that a new folder structure gets created in SPD called "Workflow's" that did not exists previously. This allows you to edit the custom workflow in future by editing the "xoml" file in the folder structure. There is obviously a lot more that can be written about writing custom workflow's in SPD, but I hope this blog gives you enough of a starting point to start experimenting. There are some additional links below written by some other authors on this site relating to workflow's and Sharepoint. Related Blogs: Creating an Approval Workflow in Sharepoint BizTalk Orchestrations vs SharePoint Workflow vs Windows Workflow Foundation High level overview to what workflow's are Using SharePoint Designer Workflow for Helpdesk email notifications SharePoint Designer Workflow Tips Content Types the Core of ECM in Sharepoint Posted Oct 14 2008, 08:43 AM by Neil with 1 comment(s) Filed under: Sharepoint, SharePoint Designer, WWF

• Waterfront.co.za moves to MOSS 2007

  It has been a long 3 months, but we are finally done. The new Victoria & Alfred Waterfront web site has been redesigned with a fresh look and feel and has also been built on MOSS 2007. We have been in beta testing for a couple of weeks and we asked a number of people that we know in the industry to comment on the design and functionality. The responses were quite diverse and ranged from hating it to loving it and I have come to the conclusion that it is impossible to please everyone. None the less, it was a very educational experience for both me and the other people that worked on this site and I would like to give some credit were it is due. Below is a list of the people that helped to build the site and their various job responsibilities. Name Job Role Company Neil van Wyngaard: Architect and Install/Config Airborne Consulting Cara Turner: Project Management and Content Airborne Consulting Garth Raulstone Sharepoint and .NET Developer Airborne Consulting Reuben Ndlovo Sharepoint Developer and Layout Airborne Consulting Fabian January Content editor V&A Waterfront Draft FCB Design / Look and Feel Draft FCB I also could not resist doing an before and after comparison, here are some screen shots of the difference. Before: After: This is also only the end of Phase I of the project. We currently have 3 phases planned and here is a rough breakdown of each: Phase I: Create a new look and feel for the web site Upload existing content from the old web site to the new Build the new web site on Sharepoint for the ECM capabilities Incorporate a powerful search engine to help find information. Build a scalable platform for future expansion. Phase II: Start building a community using blogs and wiki's and member areas. Potentially incorporate "Silver Light" and WPF into the design using "Expression Blend". Phase III: e-Commerce enable the site with on-line hotel bookings and Restaurant reservations. Victoria and Alfred Waterfront Intranet Case Study Many people are not aware of this, but the V&A Waterfront intranet was one of the very first MOSS 2007 deployments in the country. It was build in June 2006 on the Beta release of MOSS 2007 and is a documented case study with Microsoft. You find the link on the Microsoft web site here: Waterfront Sharepoint Intranet Case Study. I am pretty sure we will do another case study for the Internet web site as well. Please let me know what you think about the web site. We are always open to new ideas on how to improve things. Related Web Sites and Downloads: http://www.waterfront.co.za/ http://www.airborneconsulting.co.za/ http://www.draftfcb.co.za Waterfront Sharepoint Intranet Case Study Posted Oct 10 2008, 01:07 PM by Neil with 1 comment(s) Filed under: Sharepoint, News

• Moving a List with Content between Sharepoint servers

  Recently I have been doing a lot of Content Deployment between various Sharepoint servers and in the near future I will write a whole series of blogs on how to do this. In a build up to those blogs, I have decided to start explaining how some of the less complicated components of Sharepoint can be moved and I decided to start with "Lists". Most of the content in Sharepoint is either stored in a list as meta data records or as BLOBS in document libraries. Quite often we want to move content between an development or test environment to a production environment and we do not want to manually redo all the work. Here are the basic steps in moving a list from one server environment to another with content: Create the list in the test environment and upload the required content. Save the List as a Template to the "List Gallery" Export the list from the gallery to and STP file. Import the STP file into the production list gallery. Create an instance with content of the new template in production. Step 1: Create the List with Content The first step would be the normal process of creating a list in a Sharepoint site and then populating it with content. This can be easily achieved by completing the following steps: Select "Create" from the Site Actions menu. Select the List template of your choice. Complete the various fields, like the name and title and then commit. Navigate to the list and add any custom columns required. Populate the list by adding records to it. Step 2: Save the List as a Template The next step would be to export the list as a template by navigating to the list and selecting "List Settings" from the drop down menu. There will be an option called "Save list as template" under the "Permissions and Management" section. Select this option. The following screen will provide you with a number of options in regards to saving the list: Provide the name that will be used when exporting the list as and STP file. Provide the logical template name by which this list will be referred too in the site. An additional description can be provided to explain the purpose of the list. The "Include Content" check box can be used to export the content of the current list with the template. Step 3: Export the list as an STP file The next step is to navigate to the "List Template" gallery that can be found under "Site Settings". The link can be found under the "Galleries" section called "List Templates". Select the link. In the "List Template Gallery" you should find the list that you save previously. Click on the list to export it. You can save the STP file anywhere you like, even on your own local machine. This is the file that we need to copy to the production Sharepoint server. Step 4: Import the STP into the production environment After the STP file has been manually copied to the production environment, you can start the import by navigating to the "List Template Gallery" in the production site or site collection of your choice. The same steps can be followed as outlined in the previous section. In the "List Template Gallery" you will find and option called "Upload Document" that can be found from the drop down menu on the toolbar. Use this option to navigate to the STP file and then import it into the new gallery. Step 5: Create a new list instance from the template The last step is to create a new list instance from the imported list template. This is a simple matter of selecting "Create" from the "Site Actions" menu. You will notice that the imported template now appears as a new option under the "Create" section. Select this option and complete the steps as per normal during the creation of a list. A new list will then appear in the production environment that looks identical to the one exported from the previous environment. The same principal can be applied when exporting and an entire site template. Related Blogs: Custom site template in Sharepoint Overview of features, templates, site definitions, solutions in Sharepoint SharePoint - The TEMPLATE folder in the 12 Hive Templates for Microsoft SharePoint Products and Technologies Posted Oct 05 2008, 04:25 PM by Neil with 5 comment(s) Filed under: Sharepoint