If you are reading my blog, you know just how aggravating and utterly pointless debugging configuration errors can be. Pouring through lines of code looking for the source of the error is guaranteed to accomplish two things:
- Give you a headache.
- Waste hours of your day if not the entire day in search of the problem.
Sooner or later, when we finally do figure out what the core problem is, the solution is usually easily implemented.
We really don’t have to tell anyone that the whole problem could have been avoided if we had used the correct naming conventions… Nobody has to know those details. The problem is fixed and that is the important part of the story.
Earlier this week, I was working with a friend who had a problem with a certain workflow step. No matter what he had tried the workflow process was absolutely not working. We checked the design from top to bottom and back for a few hours with no results.
One of those Sherlock Holmes moments when after debugging the entire program and finding nothing wrong - twice... the answer you seek is not logically with the program. The problem is somewhere else.
In the end, this problem came down to the wrong configuration.
Like most of us, I try really hard not to face the same problem over and over again. To solve this problem from repeating itself any time soon, we decided to insert a validation step to check for the workflow steps configuration information.
The Workflow Validation Step checks if the DLL exists in the correct path and inside the DLL, that the specific namespaceclass exists.
Workflow Validation Step Screen Capture
Here's what the Workflow Validation Step screen looks like:
A small sampling of the Workflow Technology for BPM Solutions contained within our cDevWorkflow product offering can be found here: Workflow Technology That Works.
Learn more about our Process Automation & IT, QA Services or Software Development products and solutions on the Web! Visit us at: Innovative Process Solutions