When I run my training courses, one of the main discussion points that come up is what level of granularity should you use when you are building a Workflow process.  This is particularly important if you are working with a non-technical business analyst – what appears on a Visio diagram as a simple two step process might well expand into a ten stage workflow process.

Here’s an example that I have used in the past which I’ll share here.  A business analyst produces a business process flow about how to search the database for records matching a certain criteria.  Once the search has been complete, there are some post-searching functions which need to be undertaken.  At the simplest level, here’s the Workflow process:

Bad design!

Whilst there is nothing wrong with the process at the most simple level, there is nothing right about it either!  Let’s make the process a bit more complex by adding some extra business rules.  Firstly, a date range is provided which may cover data that has been captured within the database or not – the search routine should validate this.  Secondly, there are different types of search which need to be performed, based on the inbound parameters.  Thirdly, if the search cannot be completed automatically, then the search will need to be performed manually.  Finally, there needs to be some external processing after the search, which needs to be communicated by updating a record in the database.

So, how best to implement the new business rules – in the existing code, or expand the process to accommodate the new logic?

No prizes for guessing what I’m going to suggest here – you should extend the Workflow process and separate the business logic into separate Workflow activities.  Workflow is designed for this – including complex (or even simple) logic within the process makes more sense than embedding it hidden in PL/SQL.  Here are a few reasons for doing it this way rather than in PL/SQL:

• Reduced complexity of the solution
• Easier to develop separate activities than one large procedure
• Easier to expand the process in the future by changing th Workflow rather than PL/SQL
• Easier to change the order of processing in a Workflow than in PL/SQL
• Changes to the Workflow require less testing than in PL/SQL, since the flow is obvious
• More visible solution to provide an overview of the business process

There are more reasons than these, but the main ones are the first and last – the lower complexity solution, which provides the best visibility of the process has to be the best solution.  So here’s an example of the same process expanded:

Good Design

Just to go back to the start of the article, I’ll reiterate – conceptually speaking, there is nothing wrong with building a workflow in the manner of the first diagram.  However, it completely defeats the object of using a Workflow engine (why bother with the “complexity” of three activities – why not just have one if you want to simplify the process?  Indeed why use a workflow engine at all, if this is the approach you want to take when building the solution???)

In addition to this article, you should read the entry on storing information in item attributes here .

This entry was posted on Tuesday, September 23rd, 2008 at 11:40 am and is filed under Oracle, Technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.