For those of you developers,  there is a new feature that will dramatically improve your debugging experience in developing Force.com application on the horizon: The new System Log Console! This blog provides a sneak preview of this new feature and lets you peak under the kimono. Remember, this feature  is currently in pilot and may change in the future.If you want to participate in the pilot program, please contact Salesforce.com. 

Yes, I would like the call this newly improved version of System Log window something else. It is definitely a Log Console now but not a Viewer, as it encapsulates a variety of ways to peak into your execution log. 

When I first saw this, it reminded me immediately driving in my car with a GPS enabled device that shows me where I am.  In terms of the experience, the old System Log  was more like an odometer dump of your journey in executing code, that told you where you passed by and where my engine was spending most of its time. It was hard to visualize the execution map and the source code that corresponded to the execution. As a developer, it was your responsibility to look into where you have been, correlating the "map" of the journey with the actual experience. For a large development project which involves pages, custom controllers, triggers, workflows, etc. it was somewhat cumbersome to relate all of it. Remembering my good old Java terminology, the debugging was more of a "developer managed" activity rather than "platform managed" activity. 

The new System Log Console is more like a dynamic map enabled version of your trip, where you can step through the Execution log and see how it correlates with your code. You can also see the congestion along the way or the unexpected side turns, or the heating in your engine, if needed. You can take away the parts of the journey which went well and focus on the tight spots and replay them. 

Yes, the new Console does not allow you to "debug" in real time, but it gives you a way better sneak peak into your car's, pardon code's, whereabouts and where you made the wrong turn or spent your valuable Cloud gasoline determined by your governor limit driven gastank. 

Lets start looking at some of the basics.

The Console of Change:

The console has several collapsible windows that focus on a different aspect of the execution! I really like this aspect. Focus on what you need, take the other views away! No longer an anonymous execution window (which you could not adjust the size of the window as you are typing in and somewhat annoyed me personally in the past) and bunch of log statements with the markers that focused on various aspects of the execution. Instead the window is divided into several areas. Lets look at them briefly. 

Here is what it looks like! 

There are two different ways you can use the new console. To execute Anonymous code blocks, or to view a Debug Log that has been saved. Yey! 

In order to enter your anonymous code, just start typing next to the Execute button in the text field. You pop a different window and you can start writing your code. Once you are done, it is out of the way and you can focus on the execution log itself. If you want, you can bring it up and change it. The code window collapses when you are done and you press the Execute button to execute the anonymous code block. It is now tucked nicely away. 

Notice that the Log Level settings are also nicely tucked away. Again, you can bring them, if needed, in a separate area. I really like this feature a lot as well.

In order to view an existing log, the method is to bring the Console into view and then execute some code, i.e. open up a page that initiates a trigger, etc. If you have already started monitoring logs, the console stars polling to see what you have not viewed so far and lets you know how many logs there are that you have not Read. In this manner, the console lets you see the execution of existing logs as well as anonymous code blocks. You choose one of the log files that have not been viewed from the pull down. 

Replaying the Execution:

Now lets look what is being displayed with respect to an execution. 

 
 There are 4 different areas as you can see. 

• On the left, there is the hieararchical execution of a transaction of your stack. 
• In the middle there is the Execution Log, which can be Filtered in a variety of ways (that i will come to), and stepping through it relates to the code executed on the right side in the Source window. 
• On the right, a numbered list of your actual code you are executing!
• The different execution methods (not user methods), are stacked below, in the reverse order of execution, last things first,  with detailed snapshots of how much it took to execute them, the amount of heap size, etc. Note that this section also gives you a different way of filtering the info, whether you want to focus on Query, DML, etc. 

Yes! As you step through the execution log in the middle, these four areas reflect the state of the execution respectively, i.e. the actual code on the left gets highlighted according to what is being selected from the Execution window, the stack reflects the size of the heap, etc. See the snapshot above to see how the Execution Log corresponds to the Source code on the right as one steps through it. 

The execution Log window in the middle is your way of  filtering and focusing on the information as you need it with respect to your execution. 

Do you want only the info related to a specific section of the execution? Either use encapsulating bracketed section of the execution by using This Frame checkbox, or alternatively you can Filter what is of interest to you. You can single out debug statements, allocation, etc. by stating your filter condition in the text box which is case sensitive. The Execution Log displays just the relevant information as you set the Filter conditions. If you want to focus only on the execution steps, i.e. specifically for debugging and you do not care for the compiled statistics of your code that help you especially with governor limits, i.e. number of SOQL statements, and the like, just check the Executable checkbox to display statements that pertain to execution only. Please note that the UI interaction of the Filter checkbox is going under some improvements during the pilot phase and the interaction is subject to future improvement. 

While you are doing this, you can also see the corresponding code on the right hand side. As the code size can be at times rather large, the new Console allows you to search for a specific line in the code by using Jump button and a specific line number. Doing so, you will find that specific line and select it. If you want to see the full code, use the Open button to display the code in a different window. Note that this last feature is not available in viewing the execution of the anonymous code blocks, you need to open up the window where you typed in the code. 

Currently, the execution can be traced only from the execution log to display the actual lines of code, not the other way around. Tracing the steps of execution from the code to find the related execution log is currently not available. However, remember that this is a pilot and the first version of this exciting new feature. 

When you are viewing a complex execution log that includes pages, triggers, workflow, etc. the hierchical stack displayed on the right and bottom come handy. As you step through the "blocks" of a transaction, you see the relevant section of the execution log and the corresponding source code on the right. I noted that this feature is particularly useful when you are viewing the actual Debug Logs for a user, not the anonymous code execution when you want to see an entire complex transaction that involves pages, controllers, triggers, etc. 

Conclusion 

This will be a major tool for developing in the platform. Therefore, I am personally very excited to see the evolution of the logging tools in the platform. This is definitely another improvement that will help Force.com developers to be more productive. 

The content of this blog will soon be an article in Force.com as an easy reference.  

If you are excited and would like to try out what you see here, please sign up for the pilot program and give us feedback. More detailed documentation is also available for the pilot customers. 

Please join me in trying it out. Don't forget that what you see in the pilot may change. Give us feedback. 

Thanks to Taggart Matthiesen for providing necessary background information and direction for this new feature.