Logging business logicWhere would we be without log files? They help users, system administrators, and developers peak under the hood of software. And while developers may have access to debuggers in some cases, avoiding time consuming debugging sessions with good log output is a smart practice.Something I've learned this year is that it can be very useful to specifically log business logic. More specifically, if you were to create a flow chart for your program's execution consisting of the various steps, decisions, etc, and then translate that into log output, you'd have a representation of what the program is doing. When the program starts behaving in a suspicious way, you compare the log output to the flow chart that you created, and from there you're in a very good place to proceed with either fixing the program or simply explaining why the program is doing what it's doing. Again, this level of logging should be highly analagous to the business logic / business processes and shouldn't include any trace output from low level functions to confuse the matter. If the logging output is polished enough, a technical support person should be able to read it comfortably. Here's an example:
Each of the lines with a question mark correspond to a decision point in the flow chart, and items such as "Charge credit card" are analagous to subroutine calls that may have their own flow chart. The next step is to mark your log output with a unique identifier that represents the transaction/event. For example, the above output could have the text "TRANSID:1892828" put on to each line. With this in place, the log file can be easily parsed into a database and transactions/events can be listed and made searchable on a web page, with the relevant logging output available by click. Furthermore, the error lines can be flagged in the database and presented in an error log, again clickable, so that given an error you can see what was happening at the time. |