![]() When the Script Debugger has the session stopped, it will halt the transaction in process (as it must.) If broken long enough, the original session will timeout. The user logged into the interactive session and sending the triggering transaction must have breakpoints set, and that the session must have a window of the Script Debugger open. What Are The Limits Of The Debugger?Īs stated above, several conditions need to be true. If you continue from one section of scripting that later hits another breakpoint in a different script (such as a Business Rule calling a Script Include) the debugger will break at each point as it progresses. You can pause the debugging entirely (Shift + F2) or continue forward until the next breakpoint (F2). You can step over the next line (F8), step into the next line (F7), or step up and out of the current function (Shift + F8). All of these functions work from icons as well as keyboard shortcuts. ![]() The JavaScript Debugger has the basic functionality you expect in any modern debugger. This is a read-only view in the debugger, showing you where you are as you step through the code as you would expect. In the center pane, you’ll see the code being executed. You can see the parameters of the HTTP request if they exist (which in the case of a record update POST can be quite a lot of items.) Underneath that is a Transaction Detail pane that includes details about the transaction and session that initiated the code that invoked the debugger. Inside the left-hand pane, you’ll see all of the Breakpoints that have been set and the Call Stack of the code at the current breakpoint. The Closure section shows those pieces of top level code objects in the scope, which should be your outermost wrapping function if you have been a good developer and wrapped everything in IIFE style. This allows you at a glance to see which variables in your scope have been injected by the system and can be quite handy. In Scripted REST API this is request and response, in a Business Rule it is current, etc. In the Global section it specifically breaks out those globally scoped variables that are available to you. This includes both variables that you declared inside the script as well as any that have been places in the scope by the system. From Local, you can see all the variables in scope at the point of execution. You’ll note that variable pane contains several containers: Local, Closures, and Global. For those that are objects, they can be expanded to view the value of all the fields they contain. When stopped at a breakpoint, you can examine all the local variable. All of these conditions must be true for the break to happen. If user Abel doesn’t have his Script Debugger window open, even executing the code in this same session will not break. From her perspective, there is no breakpoint set. Even if Beth is actively developing on the same instance with a Script Debugger window open, her code will continue through that point. Code executed in that same interactive sessionīreakpoints work at the session level, so when user Abel sets a breakpoint at a point in code, user Beth will never experience it.Script debugger open in same interactive session. ![]() In order for code execution to be debugged you need: Think about the setting of the breakpoint as creating the potential for the code to be stopped in the debugger but other prerequisites must happen. However, we need to explore a little bit about what actually triggers a breakpoint. Inbound Email Actions have that editor and that interface so you can set a breakpoint. This means at this time, Scripts - Background scripts cannot have a breakpoint set in them directly. This means Business Rules, Script Includes, Scripted REST APIs and anything with that editor. What Can Be Debugged?Īny scriptable field with the full editor can have a breakpoint set as the interface for setting is part of that editor. The focus is really on usability and performance and I expect that developers will be quite happy to see this new and improved version. Since then, a new debugger was written from scratch and as of the Istanbul release it is in the product. The functionality never quite worked correctly and led to frustration and poor user interface. In the Fuji release, the old JavaScript debugger was removed from the interface.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |