Tag: REST

ArcGIS for Developers: Build apps with over 30 new DevLabs!

thumbnail

Today we’re releasing over 30 new ArcGIS DevLabs to help you explore and build powerful geospatial apps. What are DevLabs? If you are new to the ArcGIS DevLabs, they are short tutorials that step you through the process of building geospatial … Continue reading

Posted in App Developers, Developer | Tagged , , , , | Leave a comment

Blog Series – Importing and Using Your Own Data in Business Analyst – (5 of 6) Using Custom Data with Business Analyst Web Services

  by Tony Howser

This is the fifth entry of a six part product team blog series that will walk you through importing your custom data and exposing it in multiple aspects of Business Analyst – such as maps, reports, analysis, and applications. The upcoming entries will highlight some great tips and tricks for all things Business Analyst customization. Check out the original post here.

Hello everyone.  I am a product engineer on the Esri Business Analyst Team and I specialize in the Business Analyst Web APIs.  Today, I will introduce how you can quickly and easily leverage Business Analyst Server to perform advanced queries and generate reports against imported data—in the case of this blog series, the data will consist of some cancer risk data published by the EPA which my colleagues prepared and imported into a Business Analyst Server demo server.

The beauty of this simple walkthrough is that you will get Continue reading

Posted in Location Analytics | Tagged , , , , , , , , | Leave a comment

A server object extension for performing dynamic segmentation

This post explains how I extended an ArcGIS Server map service to calculate the location of mile markers along a user-submitted polyline. This type of calculation of measurements along a line is called dynamic segmentation.

You can try it out in this app by drawing a polyline. The mile markers will appear on the line when you complete your sketch. You can alternatively choose to place kilometer markers.

Example web app for placing distance markers along a line 

In order to get my server to perform dynamic segmentation, I had to write a server object extension (SOE). This post explains what an SOE is, and how I went about designing this particular extension. If you like, you can download the source code and follow along.

What is an SOE, and why is one useful for this particular problem?

ArcGIS Server map services have a list of methods that they can perform, such as drawing a map, querying geographic features, or returning a list of layers. These methods cover the most common things that someone might do with a map.

Sometimes you may need your service to do something that’s not available with one of these out of the box methods. SOEs allow you to extend the map service with methods that use ArcObjects, fine-grained programming components that expose ArcGIS functionality. This really opens up the realm of things you can do with a service, since advanced ArcGIS functions like dynamic segmentation can be achieved through ArcObjects.

ArcObjects has an extensive object model that can be daunting to beginning programmers. If you’re worried about writing ArcObjects, check whether you can put your workflow into a model in ModelBuilder and publish a geoprocessing service. This is sometimes an easy alternative to building an SOE. In my situation, I could not find an easy way in ModelBuilder to take a single input polyline, assign m-values to it, and locate the mile markers. I had a good case for an SOE.

Designing the REST schema

One nice thing about SOEs is that they can be exposed through REST web services, allowing them to be easily used by the ArcGIS web APIs for JavaScript, Flex, and Silverlight. The ArcObjects SDK contains templates (Visual Studio) or wizards (Eclipse) to help you get started writing a REST web service. I planned to write my SOE with C# in Visual Studio, so I started with a template. The first thing I needed to do was build the REST schema for the web service.

A REST web service SOE exposes both resources and operations. Resources are items of information that can be returned by the SOE. Operations are things that the SOE can do. When you write a REST SOE, you need to determine which resources and operations you are going to expose. The REST SOE template has some example ones stubbed out for you.

In my case, I kept it real simple. I had one resource (the required root resource) which did not return any information beyond the name of the SOE, and one operation which located the mile markers. I called this operation LocateMarkers. I also had to define the parameters that LocateMarkers would take, which were a polyline graphic and a segment length (allowing me to find kilometer markers, too).

Writing the resource and operation handlers

Each resource and operation in your SOE must have a handler function. A typical operation handler function for a REST SOE does the following things:

  • Deserializes the web service request, which comes in as JSON. Going from JSON to ArcObjects types such as IPolyline can be tricky, so an SOESupport library is referenced in the template that has some deserialization and conversion classes for you.
  • Calls into your ArcObjects code to perform whatever GIS functions you need.
  • Serializes your results into JSON for the web service to send back as a response. Again, you can use the conversion and serialization classes in SOESupport to help you with this.

If you want to watch a more detailed explanation of this process with an example, see the workshop Extending ArcGIS Server Services using .NET recorded from the 2011 Esri Developer Summit.

I followed these steps for my LocateMarkers operation handler. I began by deserializing the input polyline and segment length. I converted the polyline to IPolyline, assigned m-values to it, and added it to an in-memory feature class I had created. At that point, I was able to use methods in the ArcObjects Location library to find the marker locations given the input segment length. Finally, I had to serialize those locations into JSON so that they could be sent back as a web service response.

All of the above wound up taking a fair amount of code. I found that the ArcObjects Location library was well-documented when it comes to locating points with dynamic segmentation. Other things took longer to figure out, such as how to assign m-values to a single polyline. Thanks to the many generations of Esri developer documentation archived online, I was able to find answers to get past each hurdle. You might have a similar experience when developing your SOE.

Using the SOE in a web app

The most exciting thing about SOEs is that they allow your web applications to tap into advanced GIS functionality. With the flood of simple “points on a map” apps out there today, some may question whether any advanced GIS operations or analysis can be performed on the web. REST SOEs demonstrate that all the power of ArcObjects is accessible to your web apps.

Each web API has its own way of calling SOEs, but the common aspect of each technique is that they are making web service requests. The way to call an SOE from the ArcGIS API for JavaScript, for example, is to set up a JSON object with all the input parameters. Once you’ve got the parameters, use the esri.request() method included with the API to make the call to the SOE. You can then write handler functions to work with the response JSON. In my case, the handler function cycles through the returned JSON points and adds them to the map as graphics.

Using the ArcGIS API for JavaScript, I created the simple app mentioned at the beginning of this post. It allows the user to sketch a polyline on the screen and see the resulting distance markers. The app’s intent was to test the speed and usability of my SOE in a web setting.

I was pretty happy with how fast this SOE could place even hundreds of points. To test it yourself, zoom out until you can see the whole county, then sketch a very long freehand line (like a spiral). Usually the points are placed in under a second. (Note that I have placed a limit on this particular service to place only 500 points at a time.) This demonstrates that when ArcObjects code is invoked directly on the server through an SOE, it can run very quickly.

Download the example

There are a number of aspects of SOE development and deployment that I was not able to cover in this post, such as SOE properties and registration, and all the ArcObjects logic used in performing the dynamic segmentation. I have made all the source code of both the SOE and the JavaScript app available on ArcGIS Online so you can explore it yourself. The download comes with a detailed readme file.

Download the code

Contributed by Sterling Quinn of the ArcGIS Server software development team

Posted in Services | Tagged , , , | 3 Comments

Considerations for ArcGIS Server developers: A look toward 10.1

Not long ago, we published an early deprecation notice announcing upcoming changes to ArcGIS Server in its 10.1 release. Reading between the lines, many of you realized that in the future, ArcGIS Server will become purely a server of GIS Web services. This is an architecture that has many advantages, but considering the code you may be accustomed to writing on top of local (DCOM) connections,it will bring significant changes to the way you think about developing with ArcGIS Server. Particularly, the 10.1 changes affect applications built with the Web ADF that make use of ArcObjects and nonpooled services.

This post is an early discussion of the path to move to a pure Web services pattern for communicating with ArcGIS Server. We will also disclose some additional information regarding our ArcGIS 10.1 plans so you have a better context to some of the changes in the deprecation notice. The intent of this post is not only to help you evaluate the impact of ArcGIS 10.1 on your existing applications, but also to outline and promote a Web services pattern in your development that aligns with the ArcGIS Server road map.

When ArcGIS Server first hit the market, we provided two hooks into it: you could access its Web services through HTTP, and you could also use local connections over DCOM. Local connections were handy when out-of-the-box Web services did not give you all the functionality you needed. In fact, through local connections, you could execute ArcObjects code on your server that your Web application could use. While the concept of executing ArcObjects logic in the server remains a powerful concept, the way in which this happens is changing.

At ArcGIS Server 9.3, we introduced new APIs for the development of Web applications. These APIs (for Flex, Javascript and Silverlight) did not use local connections at all. Instead, their only hook into the server was Web services. All these APIs invoked GIS functions through stateless REST-ful Web services.

This new Web services architecture is a simpler one. It results in easier-to-maintain applications, and faster and more scalable deployments. As of today, most ArcGIS Server development is happening through these APIs.

A particular point of concern for many developers revolves around ArcObjects access. The pattern for accessing ArcObjects functionality in the Web ADFs is widely known, but how do you get to ArcObjects from the ArcGIS Web Mapping APIs? And how will ArcObjects access occur in ArcGIS 10.1 with the deprecation of local connections?

In this post we’ll describe specific scenarios where Web ADF developers have traditionally used ArcObjects programming and local connections to ArcGIS Server. For some of these scenarios, we’ll describe how you might accomplish the same thing using alternative techniques. Where appropriate, we’ll also describe how you could address these scenarios using a Web services programming pattern with ArcObjects.

Reasons people use ArcGIS Server local connections…and some alternatives

As we browse the user forums and attend Esri conferences, we hear several common reasons that developers still use local connections in their Web applications. Here are a few of those reasons, accompanied by some alternatives.

Creating layouts for printing

We’ve met some developers who have used ArcObjects to access the Layout object of the map service, specifically for putting high quality printing functionality in their Web applications. They use ArcObjects to work with ArcMap-quality maps and their surrounding elements, generate printable documents in large formats, and so on.

At ArcGIS 10.0, we recommend you use the arcpy.mapping Python module to script your layout construction and map printing. Then, expose the script through a geoprocessing service. With arcpy.mapping, you can manipulate map documents to a very fine degree: you can add layers dynamically to the map, update their symbology, and more. You can also access the layout of the map, manipulating elements such as text and images.

See this blog post for a brief introduction to the arcpy.mapping module and its use within ArcGIS Server.

As we move on to ArcGIS Server 10.1, keep in mind that we will enhance the arcpy.mapping capabilities. Specifically, we plan to make it very easy to dynamically load the contents of a Web mapping application (including map services and graphics) into a map document using arcpy.mapping.

Changing symbols and renderers

Another reason developers use local connections is to change the symbology of a particular layer in a map service. This workflow often required the use of non-pooled services, limiting the scalability of your applications. Some developers managed to do this with pooled services, although switching the state of a service back and forth to satisfy requests from multiple users often resulted in poor performance and left a great deal of responsibility in the developer to keep a healthy state on the map instance itself. Let’s discuss a couple of alternatives here.

The ArcGIS Web APIs give you an easy way to symbolize features using a client-side feature layer or graphics layer, whose rendering properties can be changed at any time. The idea is that the geometry and the attributes of visible features are all downloaded to the client, so it’s easy for the client to draw the features using any colors, widths, or class breaks defined by the application developer.

The feature layer technique is particularly effective for thematic mapping, interacting with and highlighting features, and so on; but it falls short when you are working with thousands of features or very complex polygon features. In those cases, the best approach is to request symbology changes at the service level and have the map service render the map image. This currently requires ArcObjects.

ArcGIS Server 10.1 will enhance the map service such that you can alter the contents and symbology of the map at runtime (like you could with ArcIMS). You will no longer need to use nonpooled services and fine grained ArcObjects to change symbology on your map service layers. Instead, you will be able to decide, on a per request basis, the contents or symbology to be used in the map you want to create.

This enhancement will make your applications significantly more scalable, while simplifying development and maintenance. Defining the symbology of your layers in the map service at runtime will be done by including the renderer information in your Web service request to draw the map, along with the typical information such as visibility of layers, extent, and so on. All the Web Mapping APIs will include utility classes so you can easily define content, renderers, class breaks, symbology, and so forth.

Web editing

In the early releases of ArcGIS Server, editing data over the Web had to be accomplished purely through ArcObjects custom code leveraging local connections. In version 9.2, an Editor Task was introduced in the Web ADF allowing basic editing such as creating, moving, and deleting features. Any customization of this task or the creation of editing tools from scratch still required extensive ArcObjects programming.

The REST-based APIs did not initially expose Web editing; however, with the introduction of the feature service at ArcGIS Server 10.0, editing is now possible through these APIs. Not only is editing possible through REST, it’s convenient to customize because many common editing methods such as cut, trim, extend, auto-complete polygons, and reshape are exposed through the REST implementation of the geometry service. Finally, when you edit with REST, you can use pooled services. This is a huge boon to performance.

To get an idea of how Web editing works through REST, we recommend this article on editing using the ArcGIS API for JavaScript. Most of the concepts also apply to the ArcGIS API for Flex and the ArcGIS API for Silverlight/WPF.

There is one workflow for which support will not be continued in ArcGIS 10.1: long transactions. In the Web ADF, you can leverage nonpooled services to perform edits following a long transaction model. In essence, you can start updating features and roll back at any time. With the feature service, all operations are stateless, meaning that you can’t really roll back at the database level (although you could with business logic in your application). A long transaction model for Web editing is one of the very few workflows where the new architecture of ArcGIS Server 10.1 will not offer alternatives.

It is important to highlight that lack of support for long transactions does not preclude you from implementing undo-redo operations. In fact, in the 2.2 version of the ArcGIS Web APIs, undo-redo operations are possible right from the API at the application level.

Another unique capability that nonpooled services give you is the ability to change versions while editing. This allows, for example, Web users to store their changes in different versions that can be reconciled later from ArcGIS Desktop. While feature services support editing on versioned data (as well as non-versioned), it is not possible to switch the version at runtime in ArcGIS Server 10.0. That is, the only version that Web clients can edit through a feature service is the one that was used when authoring the map service itself. For the 10.1 release, we are aiming to enhance feature services so you can efficiently target a version for your edits at runtime from any web application.

Performing business logic

Some GIS applications run a specific series of tools to perform advanced GIS business logic. These tools might predict timber yield from a forest, identify suitable sites for a restaurant, or estimate where a toxic cloud could spread. Many developers went the ArcObjects route to accommodate this.

In many cases, these processes can be expressed in ArcGIS Model Builder, where you can graphically “chain” tools together. These geoprocessing models can be exposed as Web services and consumed from your Web applications. Go here for a quick introduction to geoprocessing in ArcGIS Server. The benefits of this are obvious: Using a geoprocessing service can save you a lot of coding. Also, you can take advantage of the asynchronous execution of geoprocessing services, which is challenging to achieve by writing your own ArcObjects code.

Custom geoprocessing tools

Aside from the flexibility of having hundreds of out of the box tools that you can combine in Model Builder, geoprocessing gives you the ability to develop custom tools. The simplest way is to create Python scripts that can either run on their own, or in combination with other tools within a model. We described an example of this earlier with the use of arcpy.mapping to create high quality maps over the Web. For general guidance on building python script tools for the geoprocessing environment, go here.

For even further control, you can go beyond Python to create a custom geoprocessing tool with C#, VB.Net or C++. This allows you to embed your own fine-grained ArcObjects logic within your models. Here is a help topic with details on how to create a custom geoprocessing tool with C#.

Whether you use Python or another language, the advantage of creating custom tools is that you can reuse them in different workflows, since they will behave just like any other out of the box tool. Additionally, your ArcObjects or python code can execute within the asynchronous execution model of geoprocessing services, which is quite handy for long-time running processes.

The geometry service

Geoprocessing services are handy, but just like you should not jump into ArcObjects development when something can be easily achieved with geoprocessing, it’s wise to avoid jumping into geoprocessing if out-of-the-box services can already do the job. You may check to see if the SOAP or REST-based geometry service offers the methods that you need. A geometry service can perform basic GIS operations such as buffering, determining spatial relationships, measuring lengths and areas, and so on. Calling a series of methods on a geometry service and combining that with the query capabilities of map services and client side logic can be simpler and faster than using a geoprocessing service. In this white paper we explore a scenario comparing the use of the Geometry service versus a geoprocessing service for solving a simple selection by distance problem.

For simple problems, geoprocessing and ArcObjects are too heavy-handed of a solution. You might save yourself some work by studying and understanding what is possible with map service queries, geometry service calls and so on.

Geoprocessing models are generally appropriate for long running and complex processes. As a developer you can always extend this framework with Python and custom ArcObjects geoprocessing tools to face the most challenging problems. In the next section we discuss yet another alternative, which may be the way to go for tasks that need to run very quick.

Server object extensions

If you have well-defined business logic that you want to execute quickly, an alternative approach is to develop a server object extension (SOE). SOEs are an advanced developer option that allow you to expand the base functionality of ArcGIS Server services. SOEs have two great advantages:

  1. SOEs can be exposed as SOAP or REST Web services, allowing clients built with the ArcGIS Web APIs (for JavaScript, Flex, Silverlight, iOS, etc.) to easily invoke them. In fact, your SOEs will appear in the ArcGIS Services Directory and can expose the typical object types that the ArcGIS APIs understand such as feature sets, primitive types etc.
  2. SOEs encapsulate ArcObjects efficiently, and provide an ideal environment to execute your calls very quickly.

You might build an SOE to extract an elevation profile from a raster, or work with dynamic segmentation to get the location of a mile marker. In these cases, SOEs expose functionality that is either not available through any other means (through out of the box geoprocessing tools or other ArcGIS Server services) or functionality that needs to be executed quickly.

Here is an example showing an SOE being used from an ArcGIS API for Flex application. This SOE uses the 3D Extension libraries in ArcGIS Server to perform a quick terrain profile. In this particular scenario, we did not find geoprocessing tools that could help us with the profile generation, so we knew we were going to write our logic in ArcObjects. Given that this is a very quick operation not requiring asynchronous execution, we decided to use an SOE.

SOE development requires knowledge of ArcObjects,.NET or Java, and Web service communication technologies such as REST and SOAP. The ArcObjects SDK has several samples that you can examine, both for Java and .NET.

If you plan on developing new SOEs, keep in mind that in ArcGIS Server 10.1 you will be required to analyze your map documents before publishing them and fix any errors that appear. Thus, one of the things you can do to get your SOE’s ready for 10.1 is to make sure they work against MSDs at 10.0. Building SOE’s on top of MSD based map services with ArcGIS Server 10.0 is perfectly possible. The biggest requirement is that you avoid using MXD-specific interfaces (such as IMap, ILayer, anything to do with page layouts, and so on). Here is a blog post describing how you can use IMapServerDataAccess to get to the data sources of an MSD-based map service.

We realize that accessing layers and layouts is handy when you want to do some of the things we described earlier, like changing the symbology of layers, high quality printing, and so on. Much of the new functionality in 10.1 will help you through the places where it’s currently challenging to make an MSD-compliant SOE. By looking at some of the scenarios described in this post such as map printing through the arcpy.mapping module and changing the symbology of layers, you will begin to understand how to properly address your workflows at 10.1.

Conclusion

This post offers important direction for ArcGIS Server developers as you make plans for current and future releases. Information provided is based on the current status of our 10.1 work and is subject to adjustment during the 10.1 beta cycle. We look forward to communicating with you further on these and other topics of interest to Server developers. Please use the comments section of this blog post to leave questions.

Contributed by Ismael Chivite of Esri Product Management and Sterling Quinn of the ArcGIS Server development team

Posted in Services | Tagged , , , , , , , , , | 4 Comments

Clearing the ArcGIS Services Directory cache "the easy way"

In ArcGIS Server 10, we added new options to clear the cache of your Services Directory more conveniently. This is not widely known, so I thought I would share with you what it’s about.

As you may know, the ArcGIS Services Directory caches information about your GIS services. This accelerates startup time of your Web applications and makes your server more responsive. The downside is that when you create, remove, or update your GIS services, you need to clear your Services Directory cache. Otherwise, your changes would not be visible to your apps.

To clear the Services Directory cache, you need to log in to the ArcGIS REST admin page with your GIS server administrator password, which is inconvenient when you are developing apps and services and continually making changes.

In ArcGIS Server 10, you can clear the cache with a REST call to your server. This makes it possible to clear the cache with a simple click. This REST call needs to carry a token to make sure that the request is legitimate.

Here’s how you make this happen. First, go to the admin page of your Services Directory. It is generally http://yourserver/arcgis/rest/admin, although the ArcGIS Server instance name (in our example “arcgis”) may vary if you didn’t choose the default name.

REST admin page 

You will notice a new link in ArcGIS Server 10 named Generate Token Options. Click it to see this page:

Generate admin token page 

Tokens are valid for a specific IP address or Web application URL. If you chose an IP, your token will only work when the request to clear the cache is issued from that specific IP. For example, this could be the IP of the machine from which you are developing your apps. You can even restrict it more by creating a token that only is valid for a very specific URL. You will notice that there is a handy option that makes a valid token for the IP from which you are currently working.

Type your ArcGIS Server admin user and password. For the expiration date, you probably want something like a month, or even a year. For the output format, I normally pick JSON, and you will soon see why. Click Generate Admin Token.

Returned token

The JSON output is handy, because now you can easily copy the token string. Make sure to leave out the quotes at the beginning and end of the token string.

Now, just to test, open a Web browser and type a URL like this in the address bar, substituting your own server name and token:

http://yourServer/ArcGIS/rest/admin/cache/clear?token=_w1MmNsrSudZQbfCKUAELuFTETJvPhMFt1J5AuX8wfxe6HW2fCH1a6yJ4EldjIXV&f=json

Note that you’re making the admin/cache/clear REST call, followed by your token (to authenticate against the server with your ArcGIS Server Administrator user). Finally, you add &f=json to ask for the response to come in JSON format.

This will clear the Services Directory cache and give you back a simple JSON {“success”:”true”} message in the browser. If you get an error, the most likely cause is that the token is not being used from the IP or specific URL you created it for, or it may be because the token expired already. Errors can also occur if you failed to copy and paste the token string completely or correctly.

From this point, you probably know what to do. You simply create an HTML page with a link to the clear cache URL. Then, just click the link whenever you want to clear the cache. Remember that the HTML page should be hosted in the Web server with the IP for which you created the token.

Just to make things easier, here is a template you can follow for the HTML page:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Refresh ArcGIS Services Directory</title>
</head>
<body>
<a href='http://YOURSERVER/ArcGIS/rest/admin/cache/clear?token=YOURTOKEN&f=json'>Click here to clear your ArcGIS Services Directory Cache<a>
</body>
</html>

You do not want to expose this link to end users, of course. Keep this under your control so nobody clears the cache accidentally. Otherwise, you will force the server to populate the Services Directory information more frequently, slowing down your apps significantly.

Contributed by Ismael Chivite of the ArcGIS Server product management team

Posted in Services | Tagged , | 6 Comments

The GeoServices REST Specification: An open standard for GIS Web services

At the plenary session of the 2010 Esri International User Conference, company president Jack Dangermond announced, “In a few weeks [Esri] will release a new REST API into the open world using a standards process”. Dangermond likened this to Esri’s release of the shapefile specification and promised that it “will pioneer open access in the Web environment.”

His promise was fulfilled with this week’s rollout of the GeoServices REST Specification, Version 1.0, a document on the Esri Web site which is freely available through the Open Web Foundation license agreement.

The GeoServices REST Specification describes a way to develop GIS Web services that follow an expected pattern of communication. The introduction of the document describes how you would implement the specification:

“To implement the GeoServices REST Specification, developers architect the back-end server to respond to specifically structured REST requests in an expected way. For example, if someone issues a request to the server to export a map image, such as http://<mapservice-url>/export?bbox=-127.8,15.4,-63.5,60.5, the server should return a map image with a lower left coordinate of (-127.8, 15.4) and an upper right coordinate of (-63.5, 60.5). How the server generated the image is not so important as the fact that it responded in an expected way when issued a URL whose structure followed the GeoServices REST Specification.”

Services that follow the specification will “speak the same language” as the REST-ful Esri Web services. That means clients can consume them with the popular ArcGIS APIs for JavaScript, Flex, Silverlight, iOS, and Android; as well as other Esri client APIs. However, you don’t have to own or use any Esri software in order to implement the specification or to build a client that works with the services.

As you examine the specification, you’ll probably notice that it looks like the ArcGIS REST API. This is deliberate. The pattern we have used at Esri for exposing REST-ful GIS services has been embraced by thousands of developers who use the ArcGIS Web APIs. It is a simple and intuitive way of structuring and talking to GIS Web services. We wanted you to feel free to implement services that follow the same pattern.

Posted in Services | Tagged , , | 2 Comments

Why don't some of the links work in my ArcGIS Services Directory?

“I’ve exposed my ArcGIS Server to the world and it works well for the most part. However, certain links in the Services Directory still point to internal URLs.”

We have seen many users face this issue and this blog post is an attempt to address it. There are a couple of updates you need to make to configure the Services Directory for external use:

  1. Update the REST configuration files with an external SOAP URL and REST API reference
  2. Update your server directories to use external URLs for their virtual directories

Update the REST configuration files with an external SOAP URL and REST API reference

In order to set up the Services Directory for access to external users, you need to modify the SOAP URL specified in REST configuration file to be an external URL. The SOAP URL is used to generate various links in the Services Directory, most notably “View in ArcMap”, “View in ArcGIS Explorer”, and some of the Supported Interfaces links.

Additionally, the URLs for the Services Directory Help and REST API reference need to be updated to be accessible by external users.

Platform-specific instructions are included below to help you.

Updating the REST configuration file (.NET)

If you’re using ArcGIS Server for the Microsoft .NET Framework, do this:

  1. Open the rest.config file in a text editor. This file is commonly located at c:inetpubwwwrootArcGISRestrest.config, but the location will vary depending on your ArcGIS Server instance name and the root directory for your Web server.
  2. Find the <SoapUrl> element and change the enclosed URL to use an externally accessible address. Example: <SoapUrl>http://externalServer.myDomain.com/ArcGIS/services</SoapUrl>
  3. Find the <SoapSslUrl> element and change the enclosed URL to use an externally accessible address. Example: <SoapSslUrl>https://externalServer.myDomain.com/ArcGIS/services</SoapSslUrl>
  4. Find the ApiHelp tag and change the baseUrl property to reference an externally accessible address. Example: <ApiHelp baseUrl=”http://externalServer.mydomain.com/ArcGIS/SDK/REST/index.html?”>
  5. Find the <ServicesDirectoryHelp> element and change the enclosed URL to use an externally accessible address: <ServicesDirectoryHelpUrl>http://externalServer.mydomain.com/ArcGIS/SDK/REST/servicesdirectory.html</ServicesDirectoryHelpUrl>
  6. Save and close the file.
  7. Restart IIS.

Note: Prior to 10.0, for ArcGIS Server for the Microsoft .NET Framework, running the Web Applications post install would overwrite the user edited settings in rest.config for SOAP and REST API reference URLs. At 10.0, the user settings are persisted when the post installs are re-run.

Updating the REST configuration files (Java)

If you’re using ArcGIS Server for the Java Platform, we recommend exporting the REST handler using ArcGIS Server Manager. One of the required inputs when exporting the REST handler is the SOAP URL. Specify an externally accessible SOAP URL for this input, and deploy the WAR file generated to a servlet engine of your choice.

Alternately if you prefer to edit the configuration files of an already deployed REST service, do this:

  1. In a text editor, open the server.properties file, which is stored in the REST war file in the path WEB-INFclassesserver.properties
  2. Update the com.esri.rest.SOAP_URL property with an externally accessible address. Example: com.esri.rest.SOAP_URL=http://externalserver.mydomain.com/arcgis/services
  3. Update the com.esri.rest.SOAP_HTTPS_URL property with an externally accessible address. Example: com.esri.rest.SOAP_HTTPS_URL=https://externalserver.mydomain.com/arcgis/services
  4. Save and close the file.
  5. In a text editor, open the rest-config.properties file, which is stored in the REST war file in the path WEB-INFclassesresources rest-config.properties.
  6. Update the base.url property with an externally accessible address. Example: base.url=http://externalserver.mydomain.com:port/arcgis/sdk/rest
  7. Save and close the file.
  8. Restart the application server.

Update your server directories to use external URLs for their virtual directories

The virtual directories associated with the ArcGIS Server output, jobs, and cache directories must use a URL that is accessible externally. You can either edit the virtual directory of an existing server directory or create new server directories with an external URL for the virtual directory. Once the virtual directories are set up, ensure that all your services are configured to use them.

About server directories

Contributed by Ravi Narayanan of the ArcGIS Server development team

Posted in Services | Tagged , , , | 3 Comments

Welcome to the ArcGIS Mobile 9.4 beta blog

Thank you for visiting the ArcGIS Mobile 9.4 beta program and the blog site. The mobile team has been working hard to deliver quality software updates in the 9.4 release and will be using this blog site as a venue for providing you with content that supplements our documentation and is of importance not only to your testing of 9.4 but your understanding of ArcGIS Mobile.

Getting Started with Beta 1 Snapshot

There are some things that you need to know before getting started with ArcGIS Mobile at the 9.4 release. First is that ArcGIS Mobile (SDK and applications) are no longer installed as part of the ArcGIS Server .NET setup!! So where is it?? How do I get started??

ArcGIS Mobile at 9.4 has its own separate setup. The ArcGIS Server .NET setup ships the functionality required to publish a map as a mobile service – that is core functionality of the Server itself. However the Mobile SDK, the client applications (Windows Mobile and new Windows application), the new Mobile Project Center application and our Geoprocessing tools to support extraction and check-in of mobile caches are a part of the new, separate setup.

So to get going, you will need to run the ArcGIS Mobile setup on your client machine.

IMPORTANT NOTE: The Mobile Project Center is a new application that replaces the 9.3 functionality of creating and managing mobile projects. Mobile projects are stored on your web server. HOWEVER, the folder structure and web service that the Mobile Project Center uses to store projects on your web server WAS NOT INCLUDED in the Server .NET setup!! For the beta 1 release, you will need to do the following:

1. Install ArcGIS Server .NET and run the web post installer.

2. Install the ArcGIS Mobile Project Server setup (and integrated post-installer) on the same machine.

3. Install the ArcGIS Mobile setup on your desktop machine.

Also important to be aware of is that the Mobile Project Center uses active directory to connect to the Project Server that you installed on your web server. It will try to use your logged in or cached credentials to connect to the web server. If that fails, you will need to provide a username/password that is in the AGSAdmin group on the web server.

If you run into issues getting this to work with beta 1, please post questions to the Forum. We will be watching them regularly.

Thanks,

Jeff 

Posted in Mobile | Tagged , , , , , , , , , , | Leave a comment

Updated Source Code for the Water Operations Dashboard

We have updated the Water Operations Dashboard.  This version is based on the ArcGIS API for Flex 1.2 libraries and the Sample Flex Viewer that was released on May 29th.  

The Water Operations Dashboard is based on the Sample Flex Viewer with a few enhancments. 

  • Identification Widget:  This widget allows the user to click on a asset to get a pop up of the information on that asset.  To use this widget in another sample flex app, you need to copy the index.swf and the IdentifyWidget widget.  This is because we made changes to the core components.
  • ChartWidget/ChartWidgetBar:  A widget to provide a bar chart or pie chart.  This can be used with the sample viewer or the water dashboard
  • LiveMapsWidgetWRefresh:  Added code so the live maps can be refreshed at a certain interval
  • Handle for null attributes:  Added error checking to a few widgets so null values are handled, this should fix some of the 1009 errors you may have encountered(SearchWidget, LiveMapWidget were updated)

You can find the source code on the flex code gallery.

http://resources.esri.com/arcgisserver/apis/flex/index.cfm?fa=codeGalleryDetails&scriptID=16341

 

Posted in Water Utilities | Tagged , , , , , , , , , , , , , , , | 2 Comments