Battle of the acronyms
In late-January, 2007, I presented a technical demo & discussion session at MOSSIG (Microsoft Office System Special Interest Group). I’d posted an overview of the content @ grumpywookie.com, but thought it would be worth including at devK2.net.
Tonight was my night to do a presentation @ MOSSIG – entitled Workflows in MOSS. Just thought I’d cover some of the basics of the prezzo/demo – for those who couldn’t make it – and those those wanting a re-cap (there was a LOT of content !)
Firstly, a brief overview of Business Process Management – collaboration, office automation, integration with back-office systems – and then onto MOSS (Microsoft Office Sharepoint Server)
Within Sharepoint 2007, there are a number of ways to introduce Workflow, each with varying levels of detail.
I like to refer to these as the “small”, “medium” and “large” flavours of workflow implementations.
This is the same when considering (1) functionality, (2) complexity and (3) skill-level-required.
Small – Out Of The Box (OOB)
A number of workflows are installed with the MOSS server is setup. This allows a user to have a document in a library (for example) – with an approval workflow with emails sent to different people requesting comments.
The workflows are pre-installed & pre-configured – you just have to “run them”.
Fairly small level of functionality – can’t change how they operate – and small level of complexity (good for users, bad for developers).
BUT – a relatively small level of skill involved – so most non-techy users can jump into some quick workflows.
To MOSS or not to MOSS? Workflow may be the answer. (screen-shots)
Medium – Sharepoint Designer (SPD)
The replacement for FrontPage is more than just a HTML editor, and web page creator. Open a “site” from within SPD, and you can add a workflow that you create from scratch.
This is point and click, with a list of Conditions and Actions. This is fairly detailed in it’s functionality – allowing a developer (or power-user) to have logic steps (if-then), and resultant happenings (update a list item, send an email, move/delete a list item, etc)
Medium level complexity, yet limited to the set list of options. And no ability to debug. And more skills required, but not rocket science.
SharePoint 2007 Workflow Jumpstart (some great links down the bottom)
Large – Windows Workflow Foundation (WF)
Using Visual Studio.NET and 3.0 of the framework, developers can codify almost anything with the custom-written workflow. This allows for many different integration points – such as the ability to call web services (I don’t know if SPD can do so – will check).
Basically watered-down BizTalk – very advanced functionality is possible – but it’s all code-driven – highly complex. And can be tricky to deploy to use within Sharepoint.
A fairly large amount of skill required to drive this one.
Regardless of the workflow “creation”, one thing lacking is a proper workflow “server”.
Sharepoint is handling this all behind the scenes – but you can’t see how workflows are progressing in an easy to understand GUI sense – nor report on workflow average durations, or staff through-puts – and thus refine & “tune” your business processes.
And so – “there’s a gap” – with the need to develop “more custom” workflows than those provided in SPD – but – needs to be easier & more productive than WF within VS.NET.
This a .NET written IDE and server for integrating to/from Sharepoint. With the ability to have GUI based workflow layout & design, K2.NET offers developer ease, while not relinquishing features & flexibility.
A number of templates within the toolbox provide different wizard screens, allowing for easy configuration of decisions & actions – or – you can jump into the code, and modify the auto-generated code – or include your own.
You could (in fact) override the generated code – and write an entire “application” within K2.NET Studio – in VB.NET or C#.
Integration with other systems is thus “EASY” – you would do as within any other .NET code module – or call a web service.
Sharepoint-wise, you can update to/from a document library or list item – as well as have InfoPath forms residing within a document library – and displaying work item details for users to interact with the workflow.
The only downside to K2.NET is the price – it can cost $40,000 or more for a K2 implementation – before any workflows have even been created.
BUT – the time-saving alone – for costly developers – and the ability for business-analyst (tech-savvy) to be involved in design & development of workflows is great.
Another BUT – the integration with MOSS is limited to some extent – not much more that with SPS-2003. Such as the inability to interact with InfoPaths “Forms Server” forms – that’s coming in vNext (code named Black Pearl – just hit Beta).
Even so – well worth a look. Here are some links to find out more about K2.NET :
In this article, Grant examines how to work with K2.net 2003 enterprise human workflow application for the Microsoft .NET platform.
Please feel free to email me with any further comments / questions following on from the MOSSIG wrap-up.