Ok, last time I mentioned I was having problems using VSSwSe 1.3 on my 2008 r2 server, in particular the problems developing Sharepoint Workflows. After going through the process of manually creating a workflow WSP, I decided that this workaround was just not good enough as I'm wanting to concentrate on workflow. Instead I thought I'd jump ship and try WSPBuilder. To be honest, the ast time I had used this I wasn't too impressed as there seemed to be too much manual work to do. However, that was when I was learning sharepoint development. This time around I found it very straightforward and provided the flexibility to do everything I wanted, plus building workflows on my 2008 r2 machine worked without a hickup....guess I'll be sticking with WSPbuilder until MS convince me that VSSwSe can beat it.

Workflow

So, back on to my workflows. First things first and I put together a nice simple workflow just to test things out end to end. After this worked, I then wanted to start to look at what I would really want from Workflow. Having spent a lot of time recently using K2 Blackpearl to put together some beefy workflows to support line-of-business applications, I want to see if Sharepoint WF can do the same and not just provide nice simple 'approval' style workflows.

My first step here is poducing a flexible form solution for task processing. To be honest I really don;t like having to use Infopath for this, so I want to support something that will provide beefy forms processing using ASPX. Now, there is a built in way to do this by using ContentTypes with custom Display/edit pages, along with the custom association/mod forms. My aim here is to build a generic form handler (like the IP forms handler), that will load up on-demand ascx files based on the task definition.

I'll let you know how I get on.

Workflow is becoming more and more popular within larger organisations trying to improve internal processes or integrate operations between various internal and external systems, but what exactly is it ? There are many systems on the market with the word 'workflow' within the title and all offering different features and solutions. So, can they all really solve the workflow problem.

I guess a good starting point is to decide on what we mean by workflow. Lets start by looking at this from a business perspective. Within any large organisation, there are various departments involved in processes designed to meet a business objective. Along the way there are many systems (I.T. and others) designed to make the process faster, with the ultimate business aim of needing the fewest number of people to carry out a business objective. These processes can be specific to a department/role or may involve many different departments and staff to achieve a single end to end process.

As described earlier, there are lots of supporting tools available to make the work easier depending upon the business type. Ranging from simple word processors to help produce documents/correspondence through to custom applications to perform a specific business service.

For me, the idea of workflow is to manage these individual business processes ensuring that work is moved through the organisation as efficiently as possible. For any workflow system there are going to be two types of operations that can take place.The first is an activity that is managed automatically by I.T. based systems, the second is an activity that required a member of staff's involvement.

If you have a clearly defined and simple process, you can probably achieve everything you need in a single application, however, as the business becomes more complex and fluid, this definition becomes more and more fuzzy. Additionally, investment in legacy and custom applications cannot simply be thrown away just because the system cannot participate with these disperate business processes.

So the perfect workflow solution needs to be able to support the following:

• Define end to end business processes quickly and simply.
• Allow integration with various internal and external systems and process source/targets.
• Provide for Human interaction within the process.
• Provide information on how processes are performing to measure the effectiveness of a business process.
• Must be reliable, perfromant and scalable. If your business is relying on this this is a must have.

Ok, thats my starter for 10 on what we need from workflow. Now, how to acheive all this quickly, simply and preferably without massive investment.....

Sharepoint, Biztalk & K2

I recently was involved in the constuction of a large workflow based environment. The underlying technologies used were:

• Biztalk, to provide the integration with various internal and external systems.
• Sharepoint providing front-end services and document management.
• K2 Blackpearl providing the Workflow design and hosting.

This system should have been perfect. Biztalk is a fantastic tool to transfer pocess requests between back end and remote systems, its scalable, extremely flexible and you can get really complex systems working really quickly. Sharepoint is a really great portal for collaboration, document management and housing custom data capture forms and applications. K2 Blackpearl is a little less familiar, but provides a workflow engine that easily integrates with both Sharepoint and Biztalk and as it is hosted seperately is very flexible.

So, did it work ? well, yes and no. The technology was sound, the overall architecture was sound. As a platform, this would be a great basis for providing a general purpose workflow solutions. However, where things went wrong on this particular project was a lack of understanding of both workflow and the tools by the management and analysts signing off the requirements. Once you start to break the workflow model to shoe-horn badly fitting requirements in, then you will start to hit problems. Alongside this, many developers on the project had come from standard ASP.NET web site development into Sharepoint with no real grasp of the differences. As such a lot of the Sharepoint development did not take advantage of the power of Sharepoint as the underlying code was simply traditional ASP.NET dropped into a Sharepoint site.

Amazingly, these same people who had effectively mis-used the tools, started trying to blame the tools. I guess this is pretty standard behaviour (thus the old adage), but does present a real problem for anyone wanting to implement real workflow. I guess the real lessons are:

• Ensure you have a good understanding of the Business Objectives before coming up with the product set.
• Ensure that the designers of the system fully understand the underlying products  - at a detailed level.
• Ensure you have good change management and keep you business and managers up to date with the product sets.
• Ensure your developers are fully conversant with the tools before letting them loose....Or have a really good technical lead.