Skip navigation
All Places > Esri Technical Support > Blog > 2017 > January
2017
This blog post is the 2nd in a series of JavaScript debugging tips and tricks to help you on your way. See JavaScript Debugging Tips Part I – Google Chrome and the Network Tab for our first segment.


The most enjoyable part of any programming assignment is right near the beginning when you sit down with a pile of tools and resources and start hammering away at raw clumps of code. The more difficult part comes when you attempt to launch the application, only to watch that tightly-written code unravel into multiple late nights staring at a computer screen. However, all is not lost, as we have an excellent recommendation for you, which is the subject of this blog: the Console tab inside your favorite browser's Developer Tools.

If you’re feeling upset or emotional, the Console tab is the perfect choice for you. Maybe someone in your family is dealing with a difficult time, and could use some cheering up. Consider the Google Chrome Console tab (gluten free options are available). Users who like the Console tab might also enjoy the ArcGIS API for JavaScript.
Sad_Console.png

I obviously do not understand homographs



As we wrote in Part I, accessing the Chrome Developer Tools is easily done using shortcut keys (Control + Shift + I) or by navigating to the top right of the browser, clicking on the hamburger and choosing “More Tools”, then “Developer tools”.

Once the Developer Tools are open (other Developer Tools are available in other browsers), there are several Tabs that become accessible to you. Here we will focus on the Console. If you want to open the Console tab in Chrome Developer Tools directly, use this keyboard shortcut: Control + Shift + J (the “J” stands for jocular). For more neat tips, please check out the official Google documentation about Chrome DevTools: Using the console.

The Console is used for two purposes: 1) to display logged information from an application's JavaScript (usually during application development), and 2) to interrogate objects and execute JavaScript interactively. In this blog, we will look at both kinds of examples, and elaborate on some additional tips and tricks that we use in Technical Support.

The first thing we can do is to add some “console.log” statements inside our application. We will take a modified sample, hosted on GitHub, which can be found here: Sample Console Application. Feel free to follow along at home.

At lines 60-62, and again at line 66, we’ve added some of those “console.log” statements to display information about our Feature Layer. Our use case is that we are creating a web mapping application, and during our testing, we want to ensure that the data we are consuming from ArcGIS Online is the correct data to display on the map. To this end, we print out a few choice pieces of information about the Feature Layer: the title of the layer, and the URL of the layer. Since I do not know the syntax for the URL property, I use “URL” and “url” as seen below.
ConsoleLog_JavaScriptCode.png

JavaScript console.log statements



Here is a screenshot of the output of the “console.log” statements. We see the relevant information we were expecting. Also, please note that the output for “featureLayer.URL” is “undefined”. This is because items in the console are case sensitive. The valid property is “featureLater.url”, and invalid properties do not throw an error, and instead return an undefined result. This can be a tricky thing to trap, but later on in this blog we will look at some tips for dealing with this sort of issue.
JavaScript_Write_To_Console_Example1.png

JavaScript Console Output from console.log



With the Console still open, let’s try entering the same property values from the code:

featureLayer.titlefeatureLayer.URLfeatureLayer.url


Notice that all of these properties now return an error, instead of an actual value (or even “undefined”). This is because the local variables are no longer in scope after the app is initialized, so even the “featureLayer” object cannot be recognized.  Here is a screenshot of the output of the new console statements.
JavaScript_Write_To_Console_Example2.png

JavaScript Console Output after App is loaded



If we had made “featureLayer” a global variable, we would then see “undefined” returned for the object in the Console (variable is known, but the details are still not accessible). The point is: only variables that are in scope can be interrogated in the Console. So can we use the Console interactively and type in property values? Let’s find out.

The next thing we can do to our sample app is to add a “debugger;” statement in the code. We will take another modified sample, hosted on GitHub, which can be found here: Sample Console Application 2. Feel free to follow along at home.

At line 60, we’ve added a “debugger;” statement to help display information about our Feature Layer in the Console.
JavaScript_Write_To_Console_Example3.png

JavaScript debugger statement



How does this statement work? Click the link to run the application. Then, open the Developer Tools (Control + Shift + I or Control + Shift + J), and refresh the application. The application should pause, and you should see a “Paused in debugger” message at the top of the screen, and the “debugger” line highlighted in the Sources tab:
PausedDebugger2.png

Paused in debugger 1



Now, with the application paused, we can go back to the Console tab, and try interrogating the featureLayer properties again. Here we see that we have proper scope to the variable and we can see the output:
PausedDebugger3.png

Paused in debugger 2



Cool, right?

Let’s look at another option, similar to “debugger”. Back to the Sources tab, notice the line numbers to the left of the code. If we left-click on a line number, we can set a breakpoint, which will have the exact same effect as writing “debugger” in the code. Left-click on lines 56, 62, and 66 in the same application, then refresh the application.
Breakpoint1.png

Breakpoint 1



The application pauses immediately at the first breakpoint. Now, we could go back to the Console tab and again inspect variables and properties to our heart's content. Not only that, by clicking the curved arrow to the right of the Play button at the top of the screen, we can step through our application and watch the excitement as we see how the code executes step-by-step. Or, we can click the Play button at the top of the screen, and let the application run to completion, or to the next breakpoint.
Breakpoint2.png

Breakpoint 2



And another Play button click brings us to the next breakpoint.
Breakpoint3.png

Breakpoint 3



The point of this blog is to highlight the usefulness and functionality of the Console, but we do want to point out another usage of setting breakpoints here as well. Breakpoints allow the developer the ability to see the order in which asynchronous code executes, how functions are run and what parts get skipped or fail. For more information about debugging tips with JavaScript applications, here are a couple additional resources from the past several years:
In this installment, we learned how to access and use the Console tab inside Chrome Developer tools to reveal the properties and values of variables and objects in our JavaScript code. This information can greatly facilitate the debugging and coding of a web-based application. This concludes part two of a multi-part series on JavaScript Debugging Tips. Join us next time when we delve even deeper into some Developer Tools, and we all get raises. Happy debugging!
Noah S. and John G. - SDK Support Services

Tips for figuring out what is going on when things aren’t working in ArcMap

Have ever you called Esri Support Services (ESS) with one question and the analyst asks you a seemingly unrelated question? Perhaps you are trying to open a DBF in ArcMap, and we want to know what version of Excel you use. Or perhaps you cannot access printing drivers and we ask you how much memory ArcMap is using. Sometimes the questions we ask can seem random, but they help us narrow down the root cause of the problematic behavior. Most processes in ArcMap involve multiple parts and file locations, so it can be difficult to determine what drives a specific behavior without taking a systematic approach to ruling out possible causes. To that end, this post provides a series of questions that will help you narrow down what may be causing problematic behaviors.

 

Do you Meet the Minimum System Requirements?

This is a simple question and hopefully one that was asked prior to installation, but it is always encouraged to check, particularly if you recently upgraded your software. A quick way to check if you meet the system requirements is to use the Can You Run It tool. If your system does not meet the requirements, you may need to upgrade your system.

 

Does ArcMap Open?

If ArcMap does not open, or crashes when opening a new, blank map document, this indicates that either something is wrong with the installation of ArcGIS Desktop or with the local customization of the program. In this case, here are a few troubleshooting steps:

  • Perform a soft reset (remove local customizations including folder connections and toolbar arrangement) by renaming the "C:\Users\<USERNAME>\AppData\Roaming\ESRI" folder as "Esri_old". When you reopen ArcMap, the folder is re-created.

Note: the AppData folder is a hidden folder, so you may need to unhide it.

  • Repair the software by navigating to Control Panel > Programs and Features > right click on ArcGIS Desktop > Uninstall/Change. Select the option to repair. Once the repair is finished, reboot the machine and test again.

 

Is the Issue MXD Specific?

When encountering a problematic behavior in ArcMap, a good place to start is to determine if the problem only occurs in a specific MXD. You can do this by opening a brand new MXD, dragging and dropping the data from the original MXD to the new one, and then trying to reproduce the issue. You can also copy and paste layout elements from one MXD to another. If the issue does not occur in the new MXD:

  1. Use the new MXD you created to test if everything is working correctly.
  2. If you have elements that cannot be easily copied and pasted from one MXD to another, use the MXD Doctor utility.
Stay tuned for an upcoming blog on MXD troubleshooting!

Is the Issue Workflow Specific?

Many users have multi-step processes in ArcMap as a part of their workflow; however, the more steps used, the more likely it is that an error can creep in. An error early on in a multi-step process can make it difficult to determine the root cause, as the issue can be introduced several steps before being observed.

Some steps that can assist in sorting out these workflow issues are:

  1. Write out the entire workflow from data acquisition to the step where the issue is seen.
  2. Teach the workflow to someone else. Often we only catch our mistakes when we have to explain what we did to another person.
  3. If you are using a script or model to perform a workflow, try the same workflow manually. If it works manually, break the script or model into parts and test each part individually.

 

Is the Issue Data Specific?

If the issue still occurs when you move the data to a new MXD, it is possible that the issue is data specific. To see if this is the case, test similar data that is stored in the same location, is in the same format, and contains similar features. For example, if you have trouble editing a shapefile containing points, edit a different point shapefile. If you do not have appropriate data to test with, you can also create a new shapefile, add some features to it, and test with that. If the issue only occurs with a specific dataset, then it is possible to take some basic data troubleshooting steps such as:

  1. Export the file to a different format (for example, export shapefile to feature class or GRID raster to TIFF).
  2. With vector data, try the Check Geometry and Repair Geometry tools.
  3. If the data does not draw in the correct location, check the projection. If the layer was created in one projection, and the projection was not correctly assigned to the data, it can draw in unexpected locations. For more information about figuring out what projection data was collected in, see here.

 

Is the Issue Location Specific?

Another potential cause of unexpected behavior is the location of the data. Location includes both the physical location (local machine drive versus server) and the workspace (geodatabase or folder). If the data is being accessed over a network, any issues or restrictions on the network may affect the way the data behaves in ArcMap. Likewise, any issues or permission limitations in the geodatabase can contribute to problematic behavior. If you suspect the issue is location specific:

  1. Move the data. If it is in an SQL database, move it to a file geodatabase or another SQL database. If it is on a network drive, move it to a local drive, then see if the issue persists.
  2. Ensure you have appropriate permissions for the location of your data.

 

Is the Issue Install Specific?

If the problematic behavior persists in all MXDs and with different datasets in different locations, there may be an issue with the installation. It is possible that either the installation file was corrupt or that the file was corrupted after installation. The troubleshooting steps in this case are the same as those for when ArcMap does not open at all. If you suspect the install file might have become corrupt during download, you can re-download the install file from My.Esri.com and reinstall.

Slide1-1024x576.jpg

A diagramatic view of the ArcGIS troubleshooting workflow

The Internet Is Your Friend (Mostly)

Most of the time, you aren't the first person to experience a particular issue and chances are, you can unearth some relevant findings on the internet. A good starting place is always ArcGIS documentation. If an issue is particularly common, it may be documented in Esri’s Knowledge Base, a collection of technical articles written by Esri staff. Larger issues, such as troubleshooting ArcMap performance or not being able to load Esri basemaps, may have been topics on the ArcGIS Blog or Support Services blog. Additionally, Esri hosts a very active user forum, GeoNet, where developers and other members of the Esri community can ask or answer posted questions. However, if you do find a suggested workflow, always remember that what works for someone else may not work for you. Therefore, it is highly encouraged to make copies of any MXDs or data, and proceed with caution.

 

Call ESS

The above steps do not address all possible issues, but they are effective and thorough starting points when trying to narrow down issues in ArcMap. If you still cannot narrow it down, give Esri Support a call! Our job is to assist you with these particular issues, and we always enjoy helping our customers resolve whatever issues they may be facing! When you do have to call, we kindly ask that you have the following information available so we can route you to the best analyst for the job and ensure that analyst has the information needed to begin troubleshooting with you!

  • Software version and license level
  • Operating system
  • Device, if using a mobile application
  • Synopsis of the issue
  • Detailed workflow
  • Error message
  • Test data

Note: You can contact ESS through phone, web chat, and web form. Start here.

We look forward to hearing from you!


Rebecca R. - Desktop Support Analyst

If you want to know how much traffic your ArcGIS Server site can handle, you'll have to thoroughly test. And because you're probably not going to convince thousands of people to log on to your apps and services all at once, you need something like JMeter to perform load testing.

My first introduction to performance testing, and really just the JMeter in general, was with this awesome blog post from Randall Williams. I eventually started to use JMeter widely and also suggested users to run a sanity check and load test their GIS environments before moving to production.

In the enterprise world, a domain-based approach is widely used for secure authentication and authorization, where credentials of currently logged in Windows users are seamlessly passed to web applications, allowing single-sign-on. JMeter lets you emulate requests being sent from a real user by constructing relevant headers and passing them along with the request. This post focuses on configuring JMeter to perform load testing when the services are secured with Integrated Windows Authentication (IWA).

Here, I assume you have already installed JMeter and created a test plan. If you haven't, fret not! Refer to this blog for a detailed walkthrough: Preparing for the flood: Will your GIS Server sink or swim?

Once you have modified ArcGIS Server for Windows Authentication, you can forge ahead with adjusting JMeter to handle the authentication challenge. Here are the steps:

1. Navigate to the JMeter bin directory (apache-jmeter-2.7/bin).

2. Open the file jmeter.properties in text editor and set to the following:
httpclient.parameters.file=httpclient.parameters

3. Save and close the file.

4. Open the file httpclient.parameters and set to the following:
http.authentication.preemptive$Boolean=true

5. Save and close the file.

6. You must use the HTTP Authorization Manager configuration element to construct a relevant authentication header. The Authorization Manager lets you specify one or more user logins for web pages that are restricted using server authentication.

7. Complete the HTTP Authorization Manager as follows:

Username: “User logon name” for Windows domainPassword: Windows domain passwordDomain: [DOMAIN]
Other fields like “Base URL” and “Mechanism” can be left as it is.

HTTP-Authorization-Manager1.jpg


To accurately simulate the users, you can setup each thread to login with different credentials by placing an HTTP Authorization Manager configuration element in each thread group element.Tip: You can add a 'View Results Tree' listener to debug your test plan. Thus, you can review the request and response data to ensure that your test plan works well.

Below is a sample request with the Authorization Manager disabled:

HTTP-manager-Disabled.jpg


Below is a properly configured HTTP Authorization Manager:

Authorization-header1.jpg


Here you can see JMeter sending authentication information in an Authorization header: NTLM.

Because the way Microsoft NTLM (also known as Windows Challenge/Response) and IWA work, the first few requests return a 401 response as part of the NTLM handshake scheme. This means that for the first request, you might encounter an unusually high response time.

resulttable1-e1480568206105.jpg


This should help you understand how your services from ArcGIS Server would perform with Windows Authentication security. You may have a more complex situation if more Active Directory domains are involved (for example, domain trusts, forest trusts, complex nested groups, and so forth), or if there is a performance issue with your domain controller. Head over to your Active Directory Administrator for more information. If there's a performance bottleneck that cannot be eased, you may want to use the other type of security scheme.

Happy load testing!
Divyam Gulati - Server Support Analyst

Filter Blog

By date: By tag: