Locating your processing.........
Nov
1
Written by:
11/1/2012 7:39 AM
The problem with today’s compiled code is reproducing a problem. .Net code stack trace is able to point out the location of where the code is failing, but it’s very difficult to see what code did or processed. Any process execution has two paths, control flow and the data flow. Control flow determines and executes the application from start to end using a chosen path. The data flow manages the changes to data through the execution path. Both are very important in any process.
With a paradigm shift in programming, if you were to use cDevWorkflow process definition to map out a given process graphically. Then if you were to execute that process, cDevWorkflow can render the execution graphically. This make very easy to locate your processing.
A clear execution path is graphically rendered based on the decisions and data evaluated while processing through the execution path. The graphical view also lets users view bottlenecks within the process that cannot be located without some serious debugging of code.
Many times developers try to reproduce a problem that occurs in a production environment through a development environment or a QA environment. In some cases it is reproducible, in other cases it is not able to reproduce at all. Imagine if you were able to graphically view the execution decisions and data changes that happen, you will be able to reproduce the problem much more easily……