SharePoint Workflow & BPM Vendor Comparison Chart
I had every intention of going into each of these software packages in much greater detail but as I started unwrapping these packages, I quickly found out that doing so is no easy task. There is so much depth to all of these products that I would simply not do any of them justice without spending an inordinate amount of time becoming deeply familiar with each and every one of them. So instead, I’ll capture whatever notes I’ve come up with here and will continue to update this as an evolving pseudo-wiki page going forward. Take these opinions with a grain of salt, but yes please do comment if any of it is mistaken or incorrect! With that said, let’s do a recap of what we learned so far…
Since I can’t do IFrames with WordPress, you’ll have to click here for the comparison chart. Sorry bub.
Workflow Software vs. BPM Software: What’s the difference?
I’m curious about what you think, so here’s a question for you:
Let’s think about this at the software level – In your opinion/experience/expertise, what are the key differentiators between a workflow product and a business process managmement (BPM) product? Your opinions can be formed with experience from within or outside of the SharePoint arena.
A lucky commenter that I choose at random on January 31, 2010 will win a super rare, ultra collectable copy of SharePoint Designer 2007 in mint condition pictured below 
.
Unopened and in mint condition!
SharePoint Workflow != Business Process Management (BPM)
Part 1; You are here.
Part 2: SharePoint Workflow & BPM Vendor Comparison Chart
Once upon a time, I was a fledgling IT business analyst with a concentration in enterprise collaboration tools and processes. So one day, a company executive said, “Henry, we need some tools to help us manage our business processes… you know… like something that can keep track of everyone’s tasks… send emails to the person that has the next action… Then have it email me when everything’s done.”
Well, having looked at oodles of Microsoft SharePoint presentations and pizza charts, I told him, “Mr. Company Executive, I have just the thing in mind. Since we’re already using SharePoint, we can take advantage of the cool workflow capabilities already built into the system!”
And so it began… We started off with some short and sweet implementations like having Joe (the CTO) approve James’ (QA Manager) TPS reports using the OOTB document approval workflows in SharePoint. Then we used SharePoint Designer to make some more robust workflows that enabled James to provide some more information to be used as variables inside the workflow. Then as soon as we outgrew that, we even busted out Visual Studio for some custom SharePoint workflows that copied these TPS reports out to customer extranet sites. Then we wanted to make the workflow talk to our accounting system, and our SalesForce CRM account, and then have it trigger some other processes… yada yada…You get the idea right? But going down this path, we quickly realized this one critical key point:
SharePoint Workflows are only good for managing business processes if your entire business process resides within SharePoint!
<!— Update (1/11/2010):
“Whoa nelly!” you might be saying to yourself. “That’s quite a loaded statement. Care to clarify?”
SharePoint is meant to be an end-user enabler. In our case, of all the self-service things that an end-user can do in SharePoint, the ability to create workflows by their lonesomes had become one of the most empowering tools. But once we got to the point of having to create custom workflows and workflow actions in Visual Studio for all the different systems, the thought of burdening developers to develop, maintain and enhance these proved to be an overhead that simply wasn’t worth it to us (in comparisons to third-party workflow solutions that are available).
Well I guess that’s not entirely true. If you can afford to have a development team dedicated to creating custom workflows in Visual Studio and are willing to have them update the workflows every two weeks (exaggeration?) as the business process changes, then you should be ok. But how many companies out there can actually afford to do that right?
So that’s when I figured out the difference between OOTB SharePoint workflow capabilities and the difference between user-centric workflow and business process management software.
—>
“Hold on one darn second there”, you’re saying. “So what’s the difference between SharePoint Workflows and Business Process Management Software?”
Well, in some ways they’re the same and in some ways the differences are black and white. In its most basic form (OOTB & SharePoint Designer) I would consider SharePoint workflows to have the following characteristics:
- Can be manually or automatically invoked by some human action.
- Workflow states typically consist of Start, Pause, Wait for User Action, End.
- Workflow states can be changed based on predefined business rules or logic.
- Actions are typically confined to the boundaries of SharePoint and in many instances, the actions are confined to even more granular levels like the site or document library.
- Although the results of workflow actions can be recorded and logged in history, multiple versions of the workflow models themselves cannot be saved.
- Changes to the workflow process can not be applied retroactively. Once a workflow process has begun, it can only follow its predefined path or be terminated.
On the other hand, Business Process Management is an idea or strategy typically executed with and supported by the use of Business Process Management Systems (BPMS). I would consider the following features to be available at minimum:
- Can be manually or automatically invoked by some human or system action.
- Actions are never bound to any particular system.
- Should be able to communicate with any software system in the enterprise by way of web services and other service oriented architectures.
- Can be used to model, implement and manage the entire lifecycle of any customer facing or internal business process regardless of the number of different systems it has to interact with.
- Can enable the business to change their process on the fly without detriment to processes already in flight.
<!— Update (1/11/2010):
Why is the title of this post “SharePoint Workflow != Business Process Management”? Because without getting into code, OOTB SharePoint workflow just doesn’t give you much flexibility in really managing full business processes… but it can be close!
There is a huge market space in between the 2 sets of characteristics that I had listed above. This space, which I will call the “SharePoint Workflow solutions that want to be pseudo BPM machines but can’t call themselves BPM machines because SharePoint people only know what workflow means” category. These solutions typically help business users overcome just about all of the issues with the OOTB SharePoint workflow capabilities, yet also include a multitude of custom actions that enable them to interact with things outside of SharePoint, thus sharing some characteristics of a true BPMS.
—>
Now if you just read that and are still scratching your head, my apologies. Just remember this important differentiator: OOTB SharePoint workflows don’t are difficult to scale outside of SharePoint without Visual Studio.
So how does all this information help you and your SharePoint implementation?
If you’ve been working with SharePoint workflows for awhile and have started looking at supplemental workflow solutions, you’ve probably come across quite a few options out there. As these third party products have matured, they are also increasingly blurring the lines between just being SharePoint workflow solutions to including capabilities that also enable them to become full blown business process management systems. In the next few posts, I’m going to take a good hard look at each of these SharePoint workflow/BPM solutions and give you the low down on the pros and cons of each that I will be evaluating. Stay tuned.
SharePoint + Windows 2008 R2 + SQL 2008 Report Viewer Error
Environment
Windows Server 2008 R2 x64 MOSS 2007 SP2 Web Front End
Windows Server 2008 R2 x64 SQL Server 2008 with all the services installed and SharePoint Integration Mode on.
Issue
Upon trying to launch Central Administration for the first time I was presented with the following error:
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: Could not load file or assembly ‘Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.
Troubleshooting steps
First I tried to manually drag the following DLLs from the SQL Server to the SharePoint Server:
Microsoft.ReportViewer.Common.dll
Microsoft.ReportViewer.ProcessingObjectModel.dll
Microsoft.ReportViewer.WebForms.dll
Microsoft.ReportViewer.WinForms.dll
I soon found out that it’s not possible to drag DLLs the GAC if you have UAC turned on with Windows Server 2008. I really didn’t want to turn that off so I stumbled across some other suggestions on the web that didn’t really work either. These other suggestions were to use the run as command on various Explorer windows to copy the files to the GAC. Eventually I ended up logging on as the SharePoint server’s local administrator account and was able to successfully drag the DLLs into the GAC. Only problem was that the versions didn’t match up…
Solution
Enter the Report Viewer 2005 Redistributable. Installing that deployed the proper DLLs to the GAC and SharePoint Central Admin was able to load successfully. Woot.
Visiting AgilePoint HQ this weekend
Howdy y’all,
The folks over at AgilePoint has invited me and a few other SharePoint community MVPs and “VIPs” to spend a few days with them at their company headquarters this upcoming Friday through Sunday. What for you ask? To find out what they’re all about! Well, not only that but to also help them execute on their growth strategy as a member of their very selective partner circle. From what I understand, I’ll be helping you guys better understand the technology behind how AgilePoint works and through the partnership with 6th Street Consulting, hopefully I’ll get to work with you implement some AgilePoint goodness as well.
What is AgilePoint?
Good question. According to their website they specialize in Business Process Management Systems (BPMS).
How’s this different from say K2 or Nintex workflows for SharePoint?
Honestly, I don’t know yet. But I’m eager to find out!
How does this integrate with SharePoint?
From what I’ve seen so far, SharePoint acts as a front end for rendering AgilePoint data. But I’m sure that’s just scratching the surface…
How long have you been working with the AgilePoint software?
Exactly 3 hours, 12 minutes, and 37 seconds. Aside from that, I truly am quite surprised that they have been around for a few SharePoint iterations now and seem to be doing quite well whereas I’ve seen many other vendors come and go.
What are some of AgilePoint’s competitors?
Off the top of my head, some direct and indirect competitors are K2, Nintex, Bluespring Software, Captaris, Skelta…
So while I’m out there for 3 days doing deep dive BPM stuff, do you guys have any questions you have for/about AgilePoint? I’ll get you the cold hard facts and answers. Promise.
Screenshot of an AgilePoint dashboard.
User Profile Replication Engine Error: Cannot Retrieve Properties or Cannot access Web Service
Howdy y’all, just doing some documentation here. If you ever need to use the User Profile Replication Engine from the SharePoint Administrator’s Toolkit, you may run into the following errors when trying to retrieve data from the properties list:
Cannot retrieve properties
Cannot access Web Service
After tinkering for over a day, I think I got it figured out. My farm configuration is as follows:
Port 80 : Collaboration Portal
Port 81: My Sites
Port 100: Central Administration
Port 103: SSP
Troubleshooting Steps
When I tried to connect to Port 81 as the Source URL I would get one of the above errors. Same thing when trying to connect to the SSP or Collaboration Portal as the source URL. I then proceeded to tear down my SSP and My Site Host a few times (on a dev box) and eventually rebuilt my My Site Host to be on Port 80. After I did that it finally worked. The bad news is that I didn’t have the luxury of tearing down the SSP and My Site Host in the production environment where I had to do this stuff. So I moved my My Site host back to Port 81, tried the User Replication Tool again and noticed that it was still working when using Port 80 as the source URL.
What was it?
The User Replication Tool seems to be looking for the “userprofileservice.asmx” web service on port 80 no matter which web application is hosting the My Sites. For some reason or another my port 80 didn’t have the proper web services in it. After resolving that issue, I also noticed that it still won’t work with port numbers in the URL. For example http://localhost works but http://localhost:81 doesn’t work even though the My Sites are hosted on port 81. I validated this by renaming the web service on Port 80 and used Port 81 as the source URL which still generated the error.
Another Error…
After getting the Configuration Tab all set up, I went over to the Full Replication tab to do an actual replication. I was once again presented with the “Cannot access Web Service” error. This time around I didn’t feel like figuring out what the root cause was and instead tried running the application as the app pool account and then it worked!
SharePoint Conference 2009 recap and the new features that I’m looking forward to
Wowzas! This conference was packed with so much information about the new SharePoint 2010 features that my head nearly exploded. In my opinion Microsoft actually proved to us that they do listen to the voice of the customers and in particular the SharePoint community. This was proven session after session with presentations (levels 1-400) covering breadth and depth across everything that is going to be SharePoint 2010 even before the public beta is released! Alright, enough of that mumbo jumbo – here’s a list of features that I am definitely looking forward to, how they had evolved and how you’ll be able to utilize them for your business.
In no particular order…
Cross-Farm Managed Metadata Services
Previously metadata definitions and properties were handled through the usage of Content Types. That was a good thing but unfortunately the scope of a Content Type did not span across Site Collections! That proved to be quite a barrier for enterprise taxonomy folks especially when they also had to take into consideration best practices like content database sizing, site structures and information sharing. Going forward metadata can now be managed as an enterprise wide service. What that means is we will no longer have to figure out how to sync Content Types across disparate Site Collections and even across disparate farms within the enterprise. That’s taken care of by the Managed Metadata Services.
FSHTTP and other New Protocols
In SharePoint V3/2007, documents that are uploaded and downloaded from SharePoint Document Libraries are transferred as the entire file. This is an issue not only for large files on the local LAN but proved to be extremely detrimental for geographically dispersed environments with unpredictable latencies to the client. SharePoint 2010 along with the Office 2010 Clients introduce some new transfer protocols that will greatly reduce the amount of traffic that gets passed from the client to the web front ends. This is done through the new FSHTTP protocol and what it basically does is only transfer the document deltas to and from the server with the help of local client caches.
The Client Object Model
I actually have mixed feelings about this one. It greatly enhances the flexibility of the Object Model to be able to interact with JavaScript, WPF, SIlverlight and other remote applications enabling them to interact with SharePoint List Data (and other data). Where I’m a little weary about this awesome new power is… with great power comes great responsibility! While this lowers the entry barriers for developers of other disciplines (Silverlight devs, Javascript devs, WinForm devs, etc.) to more easily work with SharePoint, this new wave of developers using SharePoint as an application development platform will have to quickly learn to be cognizant of the yet to be determined pitfalls and best practices. This will also put great pressure on the infrastructure teams to keep an eye on stability and performance metrics which leads me into the next cool feature…
The Developer Dashboard and Resource Throttling
All I can say about this is sweeeeet. There’s no longer a need to question the performance of a customization nor wonder how out of control customizations can be controlled. The Developer Dashboard gives both developers and administrators the ability to look at very specific key performance indicators to help them zone in on specific operations of the application that is not performing up to par. With this kind of insight, the team can decide whether or not to try and optimize the code or even perhaps throttle some of the resources being used, like the return size of SharePoint List queries.
Business Connectivity Services
Formerly Business Data Catalog, I would consider this new feature quite revolutionary. The idea may not be revolutionary in itself but the integration and ease of use provided by SharePoint Designer 2010 really knocked my socks off. Currently many organizations have been wanting to surface information from their legacy or line of business systems but may have found it difficult to create and configure BDC definitions for MOSS 2007. With SharePoint Designer 2010, you’ll be able to click through some very intuitive wizard interfaces that will create External Content Types that can be used by a native SharePoint List interface to create, read, update and delete data that is stored in any non-SharePoint content database. Now that is huge! But there are some drawbacks – SharePoint workflows, events receivers, and a few other native functionality will not be available for these kinds of lists. In that case you’ll want to handle that logic at the data level as SharePoint is only being used as a user interface.
Now those were just some of the new and upcoming features coming to SharePoint 2010 that caught my attention. I’m sure I’ll be coming across plenty more but until the beta release in November, I’ll leave you with some pictures I took (mostly notable slides I wanted to remember).
Creating a Central Help Desk Application for SharePoint Extranet Sites Part 1
Use Case
You’ve built a centralized help desk/issue tracking system within your intranet site for all of your employees to use. There are also personalized views for this list (based off of a SharePoint Task List) so that your internal customers can view status updates on their tickets whenever they want. You also have a bajillion extranet sites you have to support but you don’t want to give those extranet users access to your internal issue tracking system/list. But you do want them to be able to see the status of their tickets and be “social” with it from their respective extranet sites. What do you do?!
Possible Solutions
1. You could have a custom web part on each extranet site that queries and renders the appropriate tickets from the main list…. that could be a lot of querying going on, performance issues…
2. Write some kind of custom workflow that copies the ticket information to a similar list on the extranet site… that sounds complicated…
3. Create a workflow that sends an email to an incoming-email enabled list on the extranet site… too much management overhead & can’t separate email text into columns/views…
4. Create a workflow that sends an email to an incoming-email enabled discussion board on the extranet site… hmm, interesting the message would show up in the body… but we couldn’t control the metadata…
5. Create a custom event receiver to replicate the ticket in a list on the extranet site… hmm, that sounds like #2 and not very “social”.
6. Create a custom event receiver that writes the ticket information to a discussion board thread on the extranet site and replies to the discussion thread when ticket information is updated. Hmm, this sounds interesting. I can write to any column I want in the discussion board… I can update the thread so that users can reference later… users can reply using the discussion board… ding! ding! ding!
Solution Overview
I don’t know about you but I kind of like that last #6 idea. So I modeled it out and this is what I got:
Can you tell I had some time on my hands?
Check back later for part 2!
Code Access Security vs Global Assembly Cache vs Full Trust Bin Deployment for SharePoint
Here’s some food for thought if you’re developing custom SharePoint solutions that involve Visual Studio. These are just some things I’ve picked up along the way so feel free to comment if you’d like.
This is a much debated topic and further research should definitely be done on the merits of each approach when determining which method of code deployment should be used in deploying custom SharePoint DLL’s.
Using Code Access Security will introduce more elements of complexity to your custom SharePoint solution but may also be required in some environments. With that said, some custom SharePoint solutions will require that the code or DLL’s are deployed to the Global Assembly Cache (GAC) in order for it to even work in a SharePoint environment. This essentially renders the need for CAS irrelevant in some cases (I think?). Some examples of these special cases are workflows and event receivers. There are some other cases but I can’t remember them off the top of my head at the moment…
Deploying your code to the Global Assembly Cache is the easiest and most rudimentary way to deploy your code. For solutions such as custom web parts, this may be ok but in others this may not be acceptable. An example where this might not be acceptable are environments where the server is a shared resource amongst disparate organizations and code sharing should be prevented. To expand on that, consider if you had a custom web part that is configured to tap into some secret data sources that one organization can see but other organizations on other web apps on the server should definitely not be able to use it. Unfortunately, when code is deployed to the GAC, any web app will be able to activate the feature and execute the code.
A hybrid approach is to deploy the DLL to the web application’s BIN directory, much like you would when using Code Access Security, but you would also set the trust level of that web application to “Full” from the standard “WSS_Minimal.” Changing this trust level is analogous to deploying the code to the GAC whereas the code is fully trusted by the server, but having the DLL in the BIN adds a level of inaccesibility by other web applications. This is my current preferred method for deploying customizations since it gives me more flexibility in properly scoping my solutions and at the same time not as complex as having to implement CAS for everything.
<!– 11/04/09 Edit: I have since figured out how to effectively use Code Access Security with help from http://blog.tylerholmes.com/2008/11/creating-custom-cas-policy-file-for.html so I’ll be looking forward to using CAS more often now. –>
Slides from last week’s SoCal SPUG – SharePoint 2010 Preview and Upgrade Preparedness
From 8/27/2009 – SoCalSPUG.org presentation in Gardena, CA.
Just in case you were interested but couldn’t make it. Full slide deck with notes can be downloaded here.
