Force.com Developer Console
Developer Console started off as a basic Log Viewer in Salesforce for executing apex code anonymously.
Over a couple of releases, Developer Console (known earlier as “System Log”) has become much interactive in a way where the users can look at logs on depths of a line of code like for example, how are the performance metrics at this point of execution and how is the execution cycle performing from timing perspective. Developer Console also brings the ability to edit the code and not just about viewing it. With the Spring ’13 release of Salesforce, Developer Console has also got the ability to perform compilation checks as you write code and as well as with visual force markup completion capabilities.
Let’s checkout various features in Developer Console
The textbox at the top is used for creating and editing apex code. On clicking on the textbox, a bigger code box appears on the screen as shown below.
You can execute the whole code by clicking on “Execute” button or executed any selected piece of code by using the “Execute Highlighted” button.
Developer Console comes up with the concept of Workspaces. Workspaces let us do different types of application debugging or operations in virtually different consoles. You can create/open/delete workspaces in Developer Console. By default, one workspace is always available named “Default”. You can change the name of the workspaces as necessary.
The console tabs currently available on Developer Console are
a) Logs
b) Heap Dumps
c) Repository
d) Tests
e) Query Editor
LOGS TAB
The log summary of the code that you run on the apex code editor is shown under the Logs tab. The log summary includes information about the user who has run the code, application information, the kind of operation, time of execution, status of the execution, log read or not and the size of the log data.
HEAP DUMPS TAB
Heap Dumps tab mainly are concerned with simulated breakpoints. Breakpoints can be set in apex code using the code editor that opens up when we open class/trigger/page in Repository tab. These breakpoints show up in the Heap Dumps and make it easy for the developer to look the concerned point of concern.
As you can see in the Heap Dump Locations, the entry shown there is same as the point where we have set breakpoint in the apex controller code.
REPOSITORY TAB
Repository tab is mainly used for understanding the related entities of any concerned apex code. In an organization, there could be thousands of apex classes through which the control navigates. Repository tab becomes handy in this situation where we can look and get to a particular related entity from a top level entity like a visualforce page.
For example, a visualforce page could be hooked up to a visualforce controller and that controller could be talking to around 5 or 6 apex classes. Now, how do we get to understand this relationship and get to a particular apex class in this relationship?
The screenshot shown below depicts a way to get to the related controller class where we have selected Pages as the Entity Type. Immediately, the Entities tab shows all the visualforce pages available in the organization. When we select a particular visualforce page, the related entities tab gets populated with classes hooked up with that visualforce page.
TESTS TAB
The Tests tab again becomes a handy tool for developers to be at one place and do testing of every available test class and understand the response of the system to the tests. We start a new test by clicking the “New Run” button. This opens up a window for us to choose the available test classes to be selected for this run.
The selected test class appears on the Test Run grid as shown below. The statistics of the test class run is also shown in summarized format in this grid. The cross or tick on the status column in the grid gives a quick snapshot of what happened with that test.
When analyzing the failed tests, we can open up the failed point of execution from the Test Run grid and the test statistics in depth would be shown on a grid below. The failed point can be seen in this grid and the reason for failure is also highlighted. A great point of interest is regarding the code coverage aspects. As we all know, Salesforce has governor limits in place to help the multi-tenant Force.com platform in stable state. We can check the code coverage and perform fine tuning in apex code to increase the code coverage. Code coverage from test run perspective and code coverage from each apex class point of view is shown in the Tests tab.
QUERY EDITOR TAB
Query Editor is fantastic tool integrated into Developer Console. We can run any SOQL and SOSL queries in the query editor and see the results immediately. We can refine the queries using Query Editor. The interesting thing about Query Editor is that the results grid also can be used to insert, update and even delete records from objects that you have queried for. This can be done using the action point buttons highlighted in the screenshot shown below. You can also interact with the detail page and edit page view of the selected records using the Record Level Interactivity Button.
Coming back to the Log Tab, we have other section like Stack Tree, Execution Log, Source, Variables and Execution Overview.
LOG TAB COMPONENTS
STACK TREE GRID
Stack Tree is concerned with two factors in log analysis.
a) Execution
b) Performance
The Execution Tree shows the key points of platform interactions like DB call or DEBUG points involved in our code logic. The duration and heap size used for the execution is mentioned alongside the execution points.
The Performance Tree shows the duration/duration percentage involved in the execution points mentioned in execution tree. It also shows the Heap size used and the Heap percentage on those execution points as well.
EXECUTION LOG GRID
Execution log shows the raw log of the execution point as selected in the Execution Tree. By default, the execution log of the root execution node (which means full log) is shown in this grid. We can use the Filter textbox to filter logs based on a specific keyword.
SOURCE AND VARIABLE GRID
The Source grid shows the source code that is active at the selected execution point.
The Variable grid shows the variables that are assigned at the selected execution point.
The screenshot shown below shows that during the Heap Allocate point of execution assigns 4 bytes in the heap memory and the code responsible for this heap assignment is the SOQL query and the result of the query is assigned to an Account variable.
EXECUTION OVERVIEW AREA
Execution Overview Area is responsible for showing an overall metrics of how many methods, queries, callouts, etc. ran, how much among the governor limits were used & performance graphs for everything that happened during the execution of an apex code.
This area has 3 tabs
a) Executed Units
b) Limits
c) Timeline
Executed Units Tab
It shows the individual units of runs that composed the whole apex code run. In our example, we had a SOQL query and a debug method call and commands initiating from the Developer Console to execute the code and finally browser taking control of execution in Salesforce organization.
That is why, we see a Query type execution unit, Method type execution unit and another two method calls in this tab. Some more information regarding individual execution units like Total time of run, Average time of run, minimum and maximum time of run, heap sizes allocated for each execution units and record counts associated with execution units are summarized in this tab.
Limits Tab
I have heard many people getting it hard to remember and find out the limits for a particular type of execution. Limits Tab solves this issue of running around. It shows points of execution that are related to hitting governor limits and show how much of those limits were used and how much limits are un-used from platform recommendations.
Timeline Tab
This is the performance indicators tab of Developer Console. This tab shows the types of execution units and the time which they took to complete among the complete request-response cycle.
Performance is affected in Salesforce application particularly in association with following components.
- Apex Code
- Workflows
- DB Calls
- Validation Rules
- Callouts
- Visualforce rendering
- System wise delays
In our example, we had a SOQL query which counts as an execution unit under the DB Calls and a debug statement that is counted as an apex code execution unit. As you can see, Apex code statement utilized 1.26 milliseconds and composed 19.39% of the execution timespan & SOQL statement utilized 5.24 milliseconds and composed 80.44% of the execution timespan. As all these things run on cloud infrastructure, there was also a system delay of 0.01 milliseconds.
From this analysis, we understand that DB calls take most of the execution timespan and thus we have to refine or optimize those areas so that performance always stays on top.
I hope this blog gave a basic idea of various features available on the Developer Console in Salesforce. Let us know your thoughts!! We would be happy to hear from you 🙂 .
