Over the last few years I've used Infopath from time to time to create a few nice simple forms. Mostly, for use as part of the development cycle or for nice quick and simple applications.  I've been lucky in tht most of the organisations I've beed working with have Infopath installed throughout, so I havn't had to live with the limitations of the Web version. Even so, whenever anything complex comes along, the decision has always been to go with hand crafted applications as  the requirement is beyond Infopaths functionality.

Thats just changed for me. I have been working on a more complex expenses based system and the initial thought was to use Infopath, even if this is just to help gather requirements, then code up in C#. However, as the complexity of the application grew, I started getting to grips with what you can actually achieve with Infopath and became more and more impressed. Let me give a ew examples:

• The form required lots of reference data to populate listboxes. Based on the selection of an employee list box, lots of employee information, location, manager, currency, etc, needed to be set in the XML based on the selected item.
• Expense items used various levels of cascading dropdown filters, starting with the expense type, which then limited the available categories, the selection of which limited the selection of cost centres, etc.
• An expense in non GBP currency required a call to a web service to get the exchange rate for the date of the expense.
• Business rules needed to be defined and enforced in a soft way. i.e. rules are defined in the Sharepint list, not by coding the form.
• All pretty common stuff, but my initial thoughts were that this could be done in Infopath but would require c# code behind. As I progressed I was suprised to see that everything could be achieved using rules and filters and no code was required. All in all, this resultd in a really good looking and complex form being created in a couple of days where I would expect a few weeks using ASP.NET....good saving. Plus there is the added advantage that as I am using no hand crafted code, the form itself should have less errors in testing, and the final win is the release and versioning process makes the change releae cycle far faster.

The flexibility and speed of this approach meant that I had a nice incremental development cycle working with the business users and could then concentate my coding on the workflows required to approve the forms and feed information into our back end financial and payroll systems.

Although I would still say that Infopath is only useful in certain business scenarios. If you find a good fit, but think that the requirements may be too complex for Infopath, I'd recommend giving it a more detailed look. It might save you a great deal of time and money in the long run.

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.

Ok, I admit it, I think Sharepoint is a really great product. It can help in so many business areas or be expanded to produce some really great applications. One of the biggest problems I find is that I.T. themselves often don't understand how useful it is so don't generally put it forward as a solution to business. The irony is, Sharepoint within an IT department is a god-send, and once you start to use it and see its benefits then it can really help you solve your business needs.

It seems to be a strange thing that I.T. departments are often the worst places for adopting technology...go figure ?

Let me give an example. I did some work recenlty in a team that developed Workflow and document management solutions for business. And often complained that business were not using their software to its true potential. Yet the same people complaining about business were managing their own processes using whiteboards and e-mails without ever thinking about using their own software ?

Ok, back to Sharepoint. Right, how many of you out there find the following familiar : During a project, all informtion is stored on a network drive in a complex directory structure. Project issues and tracking is done via a shared spreadsheet buried in a directory somewhere. The project plans are stored on the PM's own area who spend half their day telling people what tasks they should be doing and running round with printouts checking progress with the team.

Right same scenario but after installing sharepoint and Project Server :  An MS Project team site is set up with several documentation libraries to store project information (which is all versioned, change controlled and searcheable). The issues and activities logs (Sharepoint lists) are visible to all team member with individual alerts available. The Project plan is managed by the PM but stored in Sharepoint using a central resource pool (so that a developer can work on multiple projects without 2 PM'sgetting into a fistfight), once in Sharepoint, each user will see their own task list (derivable from all plans to which they are allocate), and they can send online updates of progress, whcih can automatically keep the plans updated with reality (you can enforce PM approval here).

So, for little overhead you now have a streamlined IT process with minimal process overhead, and your managers can get on with managing rather than admin. Plus, you now understand how Sharepoint works and can start to find benefits elsewhere in your organisation.

Win Win scenario.