Download as PDF, PPTX
Uploaded byVivek Chawla
Squash Bugs with the Apex Debugger (TDX'17)
The document outlines a presentation on the Apex Debugger, covering its setup, advantages, and special considerations when using it in Salesforce environments. It highlights the differences between the standard and ISV customer debugger versions and provides a roadmap for future developments. Additionally, it includes forward-looking statements regarding risks and uncertainties related to the company's operations and product offerings.
More Related Content
Similar to Squash Bugs with the Apex Debugger (TDX'17)
![Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day3-cfd-251120170304-ddef8112-thumbnail.jpg?width=640&height=640&fit=bounds)
Squash Bugs with the Apex Debugger (TDX'17)
- 1. Vivek M. Chawla DannyChang Squash Bugs with the Apex Debugger
- 2. #TDX17 @VivekMChawla @DannySFDC Danny Chang AssociateISV Technical Evangelist Vivek M. Chawla Senior ISV Technical Evangelist
- 3. Agenda • What isthe Apex Debugger? • Setup and Start a Debugging Session • Demo – Apex Debugger in Action • Special Considerations and the Debugger Roadmap
- 4. Forward-Looking Statements Statement underthe Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non- salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Website. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
- 5. What is theApex Debugger?
- 6. Advantages of anInteractive Debugger Set Breakpoints Single-Step Execution View Variables & Call Stack
- 7. Debug Logs vs.Interactive Debugging VS
- 8. 0 Sandbox Orgs The Two Flavorsof Apex Debugger Standard Apex Debugger ISV Customer Debugger Sandbox Orgs ISV (License Management Org) ISV Customer (Production Org)Production Org ISV Developer Customer Developer 1 Debug License 01 ISV Debug License
- 9. Setup and Starta Debugging Session
- 10. Set up theApex Debugger 1. Make sure your org has access to the Apex Debugger 2. Install or update the Force.com IDE plug-in for Eclipse 3. Create a permission set for Apex Debugger users
- 11. Start a DebuggingSession 1. Create project and connect to your sandbox org 2. Create a new Debug Configuration and apply to your project 3. Launch the Debug Configuration
- 12. Start an ISVCustomer Debugging Session Drag the Debug Icon from setup to Eclipse “Login as” Customer from Subscriber Console Navigate to the Apex Debugger setup page
- 13. #TDX17 Demo – ApexDebugger in Action
- 14. Special Considerations and theDebugger Roadmap
- 15. Special Considerations whenUsing the Debugger • Debugging allowed on Sandbox pods only • No support for asynchronous code • Certain actions will kill your debugging session – Any action that recompiles metadata – Installing / uninstalling a package • Beware of orphaned sessions
- 16. Apex Debugger Roadmap DebugAgainst Scratch Orgs Allow Debugging From Other IDEs Keep Expanding Access
Editor's Notes
- #2 Welcome to “Squashing Bugs with the Apex Debugger". My name is Vivek M. Chawla and I'm here today with my colleague Danny Chang. As the title says, we're going to be talking about the Apex Debugger today. So, if you're curious about the debugger but haven't yet had a chance to learn about it or see it in action, then you’re in the right place!
- #3 Danny and I are both ISV Technical Evangelists here at Salesforce. Within our team, he and I cover Apex as one of our areas of technical specialization, which is why we wanted to come here today to talk with you about the Apex Debugger. As you can see, we’re both on Twitter. If you have any questions after today’s session, please don’t be shy about reaching out to us. We’re happy to help.
- #4 In this session, we’re going to give a quick overview of... What the Apex Debugger is How to get setup and start a debugging session Hands on demo how to use the debugger to find and squash a tricky bug Special Considerations, Roadmap, and Q&A
- #5 OK, just about ready to get started. Before we do, one last thing. Our good-old “Forward Looking Statements” slide....
- #6 So, first things first. What is the Apex Debugger?
- #7 The Apex Debugger is an interactive debugger. An interactive debugger comes with some nice advantages, like... Breakpoints: The ability to choose places in your code where you’d like to STOP program execution in order to inspect the current state within your application logic Single-Step Execution: The ability to step line by line through your code, executing your logic bit-by-bit View Variables & Call Stack: The ability to see in real time what values are being assigned to your variables in both the current call and any other calls on the stack So, this is pretty cool stuff, but you might be wondering how any of this is better than using debug logs. After all, debug logs are free while the Apex Debugger can carry an additional cost...
- #8 Well, I look at it like this. Using the Debug Logs is a lot like doing an autopsy. You can learn a lot about everything that just happened, but it’s a 100% post-mortem exercise. On the other hand, using an interactive debugger is like getting an MRI. You can see what’s going on inside the body at a very detailed level, all while the subject is still breathing. This brings me to one of my first specific points about the Apex Debugger. The ability to pause execution to get this real-time, living, breathing, inside look at your code is why we only allow debug sessions against sandbox orgs. Look at it this way: You wouldn’t want someone holding a database connection open for 20 minutes on a production pod because a co-worker dropped by to chat while they were in the middle of debugging. Now that we’ve talked about the value of interactive debugging in general, lets learn more about the Apex Debugger in particular.
- #9 At a high level, there are two flavors of the Apex Debugger. A standard version that’s used by Salesforce customers to debug code in orgs that they own An ISV version that’s used by Partners to debug code in orgs that their customers own In either case, the debugger is only available in Enterprise, Unlimited, and Performance Edition orgs Let’s look at the standard version first For CUSTOMERS who want to use the debugger, the first thing to do is make sure you have a license for at least ONE debugging session assigned to your production org Unlimited and Performance Edition orgs each include a license for one session, but Enterprise Edition orgs don’t. For EE orgs, using the debugger will require an add-on purchase As I mentioned on the previous slide, the debugger can only be used with sandbox orgs Each debugger license allows one active debugging session to be initiated with any sandbox created by the production org. As a developer, I decide which sandbox I need to work in, create a project in Eclipse, and initiate a debugging session When I do that, my license count drops by one. If anyone else on my team wants to use the debugger, they’ll have to wait until I terminate my session. For ISV Partners, things are a bit different ISVs don’t have direct login access to customer orgs. They have to use the Subscriber Console in their License Management Org for access. This means that the license for the ISV Debugger has to go in the License Management Org The ISV Developer logs into the LMO and uses the Subscriber Console to connect to a customer sandbox where the ISVs package has been installed. Once the debugging session starts, the license count drops by one and you’ve got the same situation as the standard debugger. If anyone else wants to use the debugger, they’ll have to wait until my session is terminated. This was a high level look at the two flavors and how they work. Now let's get a little more specific.