Hey guys ! In the previous video I have
talked about the conditional breakpoint. You can find the link to that video in
the description below. In this video I am going to talk about the debugger actions.
Let's go back to the inventory table that we have created in the previous
video. We have two rows here. Now, let's update one of the rows using a
background script. Let's change the scope. Let's retrieve the list and let's get
the next one and set the item category of the first row from computers to
machine and let's update it. That should trigger the breakpoint. We got the
debugging notification and we are presented with the breakpoint which is
paused at line number 4. You have seen that in the previous video. Once we press
that, if there are no breakpoints, the execution will be completed. However, if
there is another breakpoint, the execution will be paused at that
particular line. Now, let's go back to the background scripts and update it
again and if we press the 'Resume Execution' over here, it takes us to line
number 12. Now, if we press that again, since there are no breakpoints, the
exhibition will be finished. Let's look at the first icon over here which is
'Pause Debugging'. If we press this, you can see that the debugger is turned off and
even if we update the table, it will not trigger the breakpoint even though the
debugger window is still open. You can turn it back and if you update the table
again, it triggers a breakpoint and it works as usual. Now, let's look at the
third icon, the 'Step Over'. If we go back to the background scripts and execute
the script, it will update the first row which will trigger a breakpoint.
If we press 'Resume', it takes us to line number 12. But if you press 'Step Over', it
takes us to the next line and if you press it again, it takes us to for loop
which will execute five times. So, that's two and once that is finished we reach line
number 12 and if you press 'Resume' here, it finishes the execution because we
don't have any more breakpoints left. Let's look at the next debugger action.
The 'Step Into'. This allows us to debug other scripts which doesn't have
breakpoints set inside them. For example, the 'InventoryPrices'. You can
see that we have two breakpoints only in this business rule. Let's go to the
inventory table and update a row. The breakpoint is triggered and let's step
over to the line 6 and if you press 'Step Into', it takes us to 'InventoryPrices'
first line. If you press 'Step Over', it takes us to line 6 again and if you
press 'Step Into' again, it takes us to the 'initialize' method and if you press 'Step
Over', it takes us back again and press 'Step Into' again to get into the 'getLatest'
method. If you press 'Step Over', it moves to the next line and then back to
the line 6. If you press 'Resume', it takes us to line
12 and then if you press it again the execution will be finished. Let's look at
the last debugger action, the 'Step Out'. We have two breakpoints. One in the
business rule and the other in 'InventoryPrices' at line 7. Let's go to the
inventory table and update a row which will trigger a breakpoint. You can see
that it stopped at line 4 and if we press 'Resume', it goes to line 7 in
the script include. But this is at line number 6 in the original business rule.
If we have to go back again, we can press 'Step Out' which will take us to line 6
from where the script include was executed. From here you can step over
into the rest of the script. So that is how you can use the 'Step Out' function to
move up the call stacks. So that's about the debugger actions. In
the next video we will talk about call stacks, transaction details and the
variable sections that we have on the right side. Meanwhile, if you have any
queries, please reach out to community.servicenow.com