![]() Since the code paused after that variable was assigned, we would expect that variable to have a value! that’ll show you the values of the variables in your code at the moment the code halted.Īs you can see in the image to the right, the variables in the local function scope in my code look as you’d expect, except for assigneeMgrID. In the Scope section, Local is usually going to be the most relevant bit. Collapse Call Stack, and you’ll see Scope. ![]() By default (in Chrome), this will be just below the Call Stack section on the right side of the debugger. This can all look pretty overwhelming at first, but the main thing to pay attention to, is the Scope section. Join me after the jump, for a walk-through! In this short article, we’re going to see exactly how to do that, using a not-very-smart Client Script that runs on the Incident form. In fact, you can! Better yet, you can put calls to the debugger directly in your code! The question then becomes: “ How do I trigger the client-side debugger? I can’t easily put breakpoints in my code that runs client-side, especially if it runs on-load right?” The good news is, modern browsers already have an incredible debugger that’s at least as good as the server-side script debugger in ServiceNow, built right in! So, how do you troubleshoot client-side scripts in ServiceNow? Well, since those scripts execute inside the user’s browser, you’re going to have to use some browser-magic to make that happen. When available, that tool is incredibly useful but unfortunately, it does not work with client scripts. When dealing with server-side scripts, the ServiceNow Debugger makes debugging relatively easy (most of the time), as you can actually see into the call stack, and the contents of your server-side variables as you step through your code, line-by-line.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |