There are more smart phones in China than there are people in the United States.  These are the kinds of factoids that are shared when talking about mobile strategy to spur conversations about why it is imperative for your company to “go mobile”.  Mobility has been a consumer driven movement and not the enterprise.  Many years ago before iPhones and iPads, Microsoft produced extremely weak and laughable mobility offerings into business.  Windows was not lean and mean, and it ate batteries for breakfast.  Apps that ran on Windows consumed resources left and right, sucking up memory and constantly banging on your hard drive.  These devices were barely functional – they could run everything on the Microsoft platform, but barely and for not long unplugged.  It couldn’t be adopted by business because it just didn’t work.

Fast forward a few years.  Hardware and software is different and better.  Apple has made touch phones and tablets fun and intuitive, and now expectations on how to interact with devices and apps have been elevated.  Everyone is connected and has their collective noses planted into their favorite devices.  Consumer centric services have emerged as tens of thousands of apps and have grown through Internet standards (email, web, RSS, etc.).  Businesses refactored software they already made for the web to mobile apps to try to prevent competitors from getting a leg up.  And now, these devices that we’ve grown quite fond of are carried right into the workplace.

Now that each employee is carrying smart phones and/or tablets into work, these devices are trying to be used for business productivity.  There has been no displeasure from CIO’s about this – who wouldn’t be satisfied with their employees buying their own equipment with a constant flow of free hardware refreshes.  Portable access to email and web are fantastic, but is this what we are now calling business productivity?  Your phones and tablets have an unlimited supply of consumer apps, but really how are these devices helping me be more productive and a better worker?  Each business is very different, and although email and web access is the lowest common dominator, making better workers requires smarter business apps.  These are the apps we use every day in laptop/desktop form, and until today they have been relegated to these larger devices.

Hardware has become cheaper, better, and smaller despite Microsoft.  Business is still running on Windows, and this is not changing anytime soon.  Have you seen how many IBM mainframes are still being licensed?  It is not because business loves big iron – they have made too much investment in these systems to make switching platforms a ridiculous proposition.  The same is true about people’s desktops and laptops.  So when your next hardware refresh comes, and it runs Windows 7 or 8, the form factor is very likely to be that of a tablet.  You might still wish to carry your personal device that cannot be locked down and secured on your business network, but over time as more consumer centric tablet apps become available on Windows, there be less reason to do so.  Everything we do on our big desktops or laptops will run on a tablet.  We will have our smart business apps with us at all times, plus Angry Birds.  This is why Microsoft, the turtle in this race, has hope.

For a client we wrote some code that programatically consumes RSS feeds and stores key information into a SQL data warehouse.  When we decided to start surface SharePoint lists via RSS feeds, we ran into a small security problem.  The RSS feed was requiriing an authentication.  In order to only expose read access to this list anonymously, I had to go through several steps.

In central administration, you need to allow the ability to set anonymous access in the authentication provider as show below:

Make sure you pick your web application and then select your authentication provider:

Select Enable Anonymous access.  This doesn’t automatically open your existing sites to anonymous access – it allows you to be able to set what will have anonymous access.

Within your site, you need to control how anonymous access will be applied.  In Site Settings, select Advanced Permissions.  Within Advanced Permisssions, select Anonymous Access as show below:

At this time you can control how you want anonymous access within your sites.  For the purposes of this exercise, I only wanted to expose a single list to anonymous view access.  So select Lists and libraries as shown below:

Now I have the ability to set anonymous access at the list level.  Within the list I want to expose, go to List Settings and select Permissions for this list.  From there select Edit Permissions in order to break the permissions for this list from the parent so they are no longer inherited:

After breaking inheritance on the permissions, you will have the ability to set anonymous access on the list.  Under Settings select Anonymous Access.

To enable anonymous read access, check the View Items and click on OK.

The RSS feed for this list is now accessible anonymously.

SharePoint 2007 (MOSS) utilizes the Workflow Foundation (WF) to enable workflows on lists and content types.  But before you start doing cartwheels there are few things you should know before you get started.  The experiences I’ll be discussing are not from book smarts but from building real MOSS solutions that are in production today.

What You Can Tie Workflows To

There are two things you can tie workflows to:  lists and content types.  However it’s started and regardless of workflow type, a workflow needs to be anchored to an item within a list.  All of the current tools within the MOSS web interfaces and SharePoint Designer are “tuned” for deploying workflows to lists, but not content types.  There’s additional legwork to deploy workflows to content types.

A word on content types because they are important to understand.  Think of what you do to a document in a document library.  You give it metadata.  All documents within that document library are all similar in that they have the same metadata.  This is what we’re used to from SharePoint 2003 and what I see most people still doing in MOSS.  Documents like this have no context when they are removed from their document library.  But what if we could give them context regardless of what document library they are allowed to live in?  This is what content types are for – giving your documents a context regardless of what document library they live in.  Regardless of where the document lives, the workflows bound to the respective content type will be invoked.

Three Different Types of Workflows

When talking to our customers I tell them there are three different types of workflows:  out of the box, SharePoint Designer, and custom.

Out of the Box

Out of the box workflows are baked into MOSS when it’s installed.  When workflow is enabled, you will automatically see them off the MOSS list menu:

Figure 1.  Manually starting a workflow.

And what follows are all the available workflows for the list item selected.

Figure 2.  MOSS page showing workflows that can me manually started on the respective list, running workflows, and workflow history.

When you install your own workflows, you will also see them in this context.  In publishing type portals, the approval workflows are started automatically.  However, all of these workflows shown above are standard manually.  Because you cannot control the sophistication of your users, manual workflow initiation should be discouraged as you want to insure your workflows will be started.

The out of the box workflows also have integrated web pages that end users will use when workflows are started.

Advanced pages such as this are not easily created for other types of workflows, so be careful to manage your expectation on how rich the user interface experience will be when initiating workflows.  This was a mistake we made long ago before we cracked open SharePoint Designer.

SharePoint Designer

SharePoint Designer workflows are those that are created with SharePoint Designer.  You will be spending the majority of your time here.  Spend a fair amount of time exploring your options in the user interfaces, including how to lookup items in related lists.  This is important so you can manage expectations of those creating requirements for you on what you can and cannot do with these types of workflows.

Figure 4.  SharePoint Designer’s slick and simple workflow creation tool.

Deployment is a breeze with SharePoint Designer.  After deploying a new workflow to a list, it is accessible to others to modify when they use SharePoint Designer.  If the workflow has been allowed to start automatically, then it’s accessible with the out of the box workflows.

Custom

Your last resort is building custom workflows with the WF tools in Visual Studio.  All the power comes with a price – you need to know WF and the MOSS object model in order to be effective writing custom workflows.  Expect a length ramp up time.  Also, the deployment story around custom workflows is currently very weak.  There are several manual steps to perform in order to deploy custom workflows.

The SharePoint Designer workflows are intended not to solve a wide range of problems, but to go deep quickly on a narrow set.  It’s easy to cross over out of this narrow set and find yourself commiting to custom workflow creation, so understand well what you can do with SharePoint Designer workflows before setting expectations.  In order to control costs, we actively work to re-shape our customer’s requirements to maximize MOSS’s features.  However, we often find ourselves extending MOSS with custom workflows and webparts.

The Ways Workflow Get Started

A workflow can be initiated in one of three ways, or any combination of the below:

·         Manually

·         When a new list item is added

·         When a new list item is updated

Figure 5.  Different ways that workflows can be started.

Manually started workflows are initiated by a user and on a specific list item.  In all the solutions we have built on MOSS, we have never relied on this feature because we needed to guarantee that the workflow was executed.

Typically you will fire off your workflows with some combination of add new item and update item.  Ultimately it will depend on what you are trying to accomplish with the workflow.   The conditions that you place in the workflow will determine how far the workflow will execute.

You can end up with several workflows on a list that always get fired off when a list item changes, but because of the conditions setup within each workflow how far and long each workflow executes will vary.

SharePoint Designer

We receive many questions on the true purpose of SharePoint Designer, and typically the first comment from the developer community is that “this is not a developer tool”.  And they are right.  It’s not intended to fill that space.  The types of people that we engage with this tool are specialists on the MOSS platform, HTML/CSS designers, and Business Analysts.  It is the Business Analysts, with a little training, who can become almost immediately effective in creating and modifying workflows.

Workflow Deployment

Deployment of custom workflows is not for the faint of heart.  It’s a lengthy multi-step process with no wizards provided.  It is a completely different and positive experience with SharePoint Designer which is entirely encapsulated with wizards.

Workflow Permissions

In MOSS we now have list item level permission.  In the applications we create on MOSS, we often have requirements to manage permissions at this row level.  For maintenance and administration, “programmatic” assignment of row level permissions is almost always preferred.

When using workflows with multiple participants, each participant can have a different level of access not only to records but to entire lists.  When a workflow is initiated, it runs under the permissions context of the user that started the workflow.  In order to guarantee the proper operation of your workflow regardless of the participants, you may need to run your workflow with elevated permissions.  This is something that can only be done with custom workflows.

Task Centric

In this context, a task is something you will find in an MOSS workflow task list.  When a participant is required to interact with a workflow, MOSS gives the participant a task assigned to them.  The participant sees the task, and click on a link to the associated list item.  Once the task is marked as completed, the workflow resumes execution.

Because of the permissions context of a running workflow, one cannot lock down the Task list so that only you can edit your own entries.  All tasks that are generated by a workflow, regardless of who they are assigned to, are owned by the person who started the workflow.  The side effect of this is that everyone requires contributor access to the entire Task list.  Otherwise participants downstream in the workflow that are assigned tasks will not be able to view them because the originator of the workflow owns the task.

Building Custom Activities

As you work more with SharePoint Designer and with the out of the box activities, you will begin to wonder how one would create your own activities that others in your organization can use in their workflows.  This is where the true power would come in – to be able to wrap your own custom logic into a re-usable activity within SharePoint Designer.  This is the perfect separation between developer and Information Worker.

Unfortunately, this is not yet supported.  When MOSS Beta 2 was released, we actually make this work but it was painful.  Once the TR was released, none of our custom activities would work.  When speaking to Microsoft about this, there were no concrete plans to ship Visual Studio designers in the short term to manage custom activity creation and deployment.

Thought I’d share the latest architectural diagram we created for the TSRI Collaborative Molecular Environment WPF application:

SharePoint 2007 (Microsoft Office SharePoint Server 2007 or MOSS) lists support a sophisticated versioning model.  Multiple options for configuring versioning are available, including how versions to keep, major/minor version numbering, and restoring previous versions.  When changing any of the columns on a list, that information can be versioned.  Although the previous versions are readily available through the MOSS user interfaces, the versioned data is not easily reported on.  If I wanted to know how must List data changed over time, one is pretty much out of luck.

In order to support this type of functionality, we developed a custom MOSS workflow that stores List changes in SQL tables.  It is a generic workflow that can be applied to any MOSS List.  The code behind the workflow dynamically generates the SQL based on the encoded column values of the associated List.  A SQL table with the respective column names needs to be constructed beforehand.  Once prepped, by deploying the workflow to any list or content type, anytime any changes occur within the respective list it would also be stored in SQL Server.

Figure One.  Custom workflow that can store versioned MOSS list information into SQL.

The data is stored in a highly normalized state in order to maximize performance.  The data is later processed into a de-normalized data warehouse structures that can be used to build cubes for analysis.

Some time ago we completed a project for a large customer that federated documents into multiple SharePoint installations across the world.  There were several challenges we overcome because of the system requirements, which included:

·         The files that were transferred were sometimes extremely large (more than 500 MB) .

·         The transferred information was extremely sensitive.  All information transfers over the wire must be encrypted, and authentication was to be done with certificates.

·         The locations of the SharePoint systems were behind the firewalls of very large corporations.  Also, they were dispersed around the globe.

Figure One.   Logical diagram of our SharePoint document federation solution.

The following describes, at a high level, the processes in the above diagram.  There were many dozens of consumer companies of the main source database, but only one is shown above:

1.       A .NET WinForm application was created to streamline the document markup process of the source document management system.  Document federation profiles were also created that channeled documents with specific tagging to the appropriate destination SharePoint systems.

2.       A Windows service was created to prepare content for transfer.  Because the system is designed to transfer files of virtually infinite size, the service “chunked” the files for individual binary transfers.  The file was later hydrated on the other side once all the “chunks” were transferred.  The service placed all the chunks into a database.

3.        A .NET web service loaded balanced on a web farm was created to allow a surface point for the all the content.  It was important to place the web service here (forcing a pulling mechanism) versus the web service on the consumer side (forcing a push mechanism).  The reasoning is that each consumer would have had to do firewall work in order for the single source system to communicate to it.  The web service was secured via certificates, and the certificates were used to uniquely identify each consumer.  The web service returned a file manifest of new files that needed to be transferred (to the respective consumer).  Subsequent queries from the consumer retrieved chunks of files.  SSL communication was utilized to encrypt all information.

4.       A Windows service on the consumer side was responsible for insuring all of the latest files where downloaded and placed into the consumer’s SharePoint instance.

5.       The local SQL Server database retained all the binary for files in process.  Once all the chunks were received, the chunks were hydrated and removed from the temporary storage.

6.       The local SharePoint system received the content from the local Windows service one the content was hydrated.  The content was automatically tagged and indexed.

7.       Information Workers within the company were notified when new content was made available, and their portal was automatically updated.

This solution could have been made far simpler without the requirement to support extremely large files.  However, since MOSS currently doesn’t support document federation, a simplified solution like this would still be necessary.  For example, the chunking could be avoided along with the temporary data storage (both centrally and at each consumer).

SharePoint 2007 (Microsoft Office SharePoint Server 2007 or MOSS) has fantastic security improvements over SharePoint 2003.  One of the many we have been utilizing in our MOSS applications is row level security.  In SharePoint 2003, there was no such thing.  All the records within a list (or library) had the same permissions.  In MOSS, however, you can lock down individual records within lists.  What if you could lock down a column on a record?  This would introduce interesting scenarios when considering how to design your MOSS libraries.

An issue with row level security is that if there are many records in the list, it is a management nightmare.  We typically do programmatic assignment of security roles on row level security, but that is not always practical.  If I could lock a column in a single location, analogous to locking down the list in a single location, then security assignments only occurs in one place.  Depending on what roles you have would determine what columns you could edit.

Column level security is fundamentally not part of the MOSS architecture, so there is indeed to no way to lock down a column as you can a record, list, or site.  But if you provided an application level security mechanism that prevented the column from being modified by the user interface, then that provides base level control of who can edit the column.  This is the tact we took in one our MOSS applications.

We rebuilt the edit control that appears on all the edit list item pages for every list.  The control takes as properties which columns within the list are locked down, and which roles within MOSS are allowed to edit them.  If a user can edit the record, then that can launch the custom edit form (or normal edit form).  If a user is in at least one of the groups specified in the properties of the control, then they have access to the locked down columns.  If they are not in those groups, then the fields are view only.  We setup the control so that if a user was in the Site Owners control that edit access was automatically granted.

Figure One.  Edit view of a site owner.

Figure Two.  Edit view of a someone who does not have privileges to edit specific columns in the list.

Now that we have the ability to lock down columns in MOSS lists, a whole dimension of MOSS applications can be created.

SharePoint 2007 (Microsoft Office SharePoint Server 2007 or MOSS) is already being deployed in hosted environments in extranet and internet roles.  In either role, when dealing with authenticating users combined with hosting multiple companies on a single platform, you must consider MOSS’s architecture for authentication.

Authentication occurs through ASP.NET 2.0 Providers, of which there are two that come of the box for Active Directory and SQL Server.  As with ASP.NET 2.0, MOSS can take advantage of custom Providers to provide authentication services from any user data store.  MOSS’s architecture ties a Provider to a web application within IIS.  A site collection is created within a web application, and sites within a site collection.  Every site collection created within a web application will use the same instance of the Provider.  For example, I could create company ABC and company XYZ as two separate site collections within the same web application, but both of them would be authentication against the same set of users.

Figure 1.  Physical binding of authentication Provider.

If authentication providers are tied to web applications, why not just separate them into different web applications?  Well, adding web applications to your web server consumes considerable resources.  If had had hundreds of customers that you wanted to host on a single web farm, then this is not a scalable solution.  Ideally, you would be able to tie the authentication provider to the site collection and not the web application.  This is the approach we took to solve the problem.

Fundamentally, the Provider will always remain tied to the web application.  However, within our realm of control is the ability to pass the site collection context to the provider.  If we were to have a custom Provider that captured the context of the site collection that was invoking it, we could provide a logical separation of users.  All queries performed by the Provider would always need to pass in the context of site collection.  The net result provided the logical model we needed.  Within one single SQL repository of users and one Provider, we logically separated all of the users into their own islands.

Figure 2.  Custom logical binding we built to support authentication by site collection.

We chose to store all users in SQL just as the SQL based authentication Provider already uses.  Before looking at the source code of this provider and database diagram, we believed we would need to add a context field through the stored procedures and database in order to support query not only by user identity, but additionally with identifying information from the site collection.  Fortunately, this additional context is already present in the out of the box forms authentication data store, and it simply goes unused.  Our custom Provider inherited from the SQL Provider to overwrote all key methods that required the additional site collection context to be passed in.