Why you need the ArcGIS API for Python in your life...

Why you need the ArcGIS API for Python in your life...

ArcGIS API for Python got a recent new release (v1.2.1), but what is it? ArcGIS API for Python is a web GIS integrator for arcpy and other Python 3 packages and you can think of it as a unifying technology for the ArcGIS Platform.

Read More

Need a more flexible way to search for addresses?

Following feedback from our customers on the standard address searching functionality within the ArcGIS Platform, Esri UK have developed a new developer widget to provide an alternative way of searching for addresses which allows the user to drilldown through the hierarchy of streets and properties to the individual records in the locator.

Read on to see it in action and for documentation on how to use the widget.

Read More

GeoHackDay!

Earlier this month, 40 participants entered Inmarsat's offices on Old Street roundabout to participate in GeoHackDay. GeoHackDay was an opportunity for developers, designers and idea makers to get together to help build software applications and/or hardware integrations to tackle real life problems. 

Read More

ICHack!

This weekend 80+ hackers took to GoCardless's office near Angel tube station in London for the ICHack student hackathon. Hackathons allow people of all backgrounds to get together and build small projects with code that they demo at the end. Hacks can often feature location and mapping elements and I was at the hackathon to offer teams assistance with this and making use of Esri developer technologies. Within is my breakdown of what happened at the event.
Read More

Esri UK and open systems

In the world of Government IT we often make the mistake of thinking open means free and I include myself in that. In fact, open normally means interoperable and accessible. Many organisations building an open system start by thinking they need to choose between commercial software and open-source software. This is incorrect. Commercial software can still be compatible with open standards, making it ‘open’ and able to easily share data with other systems and other people.
Read More

EDN Days: Helping you to build GIS Applications

Part of my role in the Technical Solutions Group at Esri UK involves helping customers who purchase an Esri Developer Network (EDN) licence with a day’s ‘get you started’ consulting. The last couple I have run have been very successful and put the client on course to developing GIS applications using Esri technology.

An EDN subscription is an easy way to get started developing GIS solutions with Esri software.  It comes with all the tools needed to start developing GIS applications, whether that is desktop, server, Web or mobile. It also includes discounts on training and support, data and personal support from a consultant like myself. Prior to the visit we gather as much information as possible including what you want to get out of the day. We will also make sure the Esri software that is needed is installed correctly and give guidance with this beforehand if needed. Once we have gathered this information we can plan the day so the client gets the most out of it. The level of customer knowledge can vary, from developers who have never heard of GIS before to competent GIS developers looking to know more about how to develop using Esri software and the best practices to do this.

EDN day Technology Trends

Of late, most of the EDN days I have been involved in have focused on using ArcGIS for Server and the JavaScript (JS) API. From my recent experience this is the most popular development options for developing custom GIS applications or adding GIS functionality to existing programs. I think this is because many clients already have JS developer experience and unlike the other API’s (Flex and Silverlight) it does not need an additional plug-in within the browser. This can be an issue in organisations with tight restrictions on IT infrastructure. JS is also the technology that goes hand in hand with HTML5 which is the path many people see as the future of Web development. Esri’s JS API does come with HTML5 support (which is always growing in functionality) and this has been an area we’re discussing more and more recently. We’ve also noticed a trend away from traditional desktop development and onto the Web, while Esri offer a full range of desktop development tools, Server is where most new development is taking place. Having said that, my most recent EDN day focused on developing a smart desktop application with the WPF API and with the upcoming release of our new ArcGIS for Runtime product at 10.1, desktop development will remain a viable option for many.

Recent EDN Experiences

As mentioned the structure of an EDN day is driven by the client’s needs gathered a few weeks in advance. I am going to go over the two most recent EDN days I have conducted to give a feel for what can be achieved during the day.

The first example was with a client developing an application centred on ArcGIS for Server and the JS API. My colleague, Sam who is a web mapping expert, and I went along already knowing the client had a good understanding of our Server technology and the JS API, having developed one application using the tools already. They were interested in making sure they were following the best practices and doing things correctly. They were also keen to get a more in depth knowledge of geoprocessing (GP) with Server and the API’s as this was something they would need for an upcoming project. GP with ArcGIS Server and the Web API’s in an interesting topic. When done correctly it is very powerful, being able to perform complex analytical procedures in a web application is one of the major benefits of using ArcGIS for Server and one of the major advantages in using Esri software over other options. Setting up a GP model that will run on Server is different from desktop GP models and it was these differences as well as best practices in publishing and running GP on Server that the day was mainly focused on. The main constraint in publishing GP from desktop to Server is on input and output data types, other important considerations such as model data, where new data is stored, output data types and how the output is finally drawn are also important and were discussed. GP Performance tips and testing tools were also touched on. Sam then discussed programming with the JS API, again focusing on best practises, interacting with GP, HTML5 and how all this could be applied to the application they were developing.

For the last part of the day we went through creating a GP model similar to the one that would be used for their final application, publishing it and consuming it within the JS API. This was very useful and we did come up against a few issues along the way. This turned out to be a good thing as we could all go over best practices for de-bugging and solving the problems that did arise. Further tips on how to debug Server based GP tasks can be found here. In the end we managed to achieve what we set out to do and we left the client with a working model they could build on to create the final application. We had also established a good way forward for developing the application not only on the the GP side of things but also the many other best practices to make the final application as quick and user friendly as possible.

Figure: An example Geoprocessing Model being authored in ArcGIS for Desktop

The most recent EDN day I undertook was quite spur of the moment. We had a partner who won a large contract and needed to geo-enable their application to include Esri mapping as part of the final deliverable. The project was being delivered in stages and the first stage had quite a tight timeframe. Despite the short notice we spent time understanding the requirements with a few conference calls. I then went to visit the customer with the support of a colleague from our Professional Services who specialises in desktop development. We started by going over the initial requirement and decided the best way forward was to embed our WPF API into their current .Net application. ArcGIS for Server would be used to deliver the maps and GP to the client and initially for what they needed, this could be achieved by using the Esri UK online mapping services and the free ArcGIS Online services. The application could then easily be scaled up to include their own instance of Server; we designed the plug-in in such a way that it could be available for all future releases of the software not just this project.  Once this had been decided, I started going over the best practices for coding with the API and Server and getting our hands dirty with some coding. At the end of the day we had managed to create a new embedded plug in window in their application with just about all the functionality need for the first stage of the map development that was required. All in all a good day with much achieved, that I believe showed how quick and easy it can be to start developing using Esri technology.

Summary

The EDN is a great package that helps clients in getting started developing GIS applications. Not only do you get all the software you need but also I think most importantly the support to undertake what can be a completely new development environment. EDN days are one of my favourite things about my job and it is great to get people up and running with GIS development. They are always different and during the day you often get the 'Ahh…’ moment where everything I have been going through just clicks in the clients mind and away they go. It is especially rewarding when at the end of just one day a customer can walk away with the knowledge and a clear picture of how they are going to develop the GIS application they have always dreamed of having.   

Running Flex apps on iPhone/iPad and Android

The ArcGIS web APIs are a powerful way to create mapping applications using JavaScript, Flex or Silverlight. However, many mobile devices do not support Flex or Silverlight, and JavaScript apps have drawbacks: they don't always behave the same way across different browsers, they do not work well without an active network connection, and they generally have less functionality than Flex or Silverlight apps (simpler UI, inability to access as much hardware, etc).

Of course, mobile technologies evolve rapidly, and it's likely that these criticisms of JavaScript will seem outdated and unfair before very long. Still, we were excited earlier this year when Adobe released Flash Builder 4.5, a development tool that allows cross-platform Flex apps, including GIS apps built with Esri's ArcGIS API for Flex, to be deployed to iOS devices (iPhone, iPad, iPod Touch), Android devices (phones and tablets), and the BlackBerry PlayBook tablet.

On Android and BlackBerry PlayBook, Flex mobile apps run on AIR, a runtime developed by Adobe. AIR is pre-installed on PlayBook, and can be downloaded for free on Android. Since iOS apps distributed through the Apple App Store are not permitted to execute on third-party runtimes, Flex apps for iOS are normally compiled to native ARM assembly so they can be executed directly on the CPU.

The ArcGIS API for Flex 2.4 includes two mobile Flex samples to help developers get started. Since the API is now capable of recognising multi-touch gestures, Flex is a viable way to develop cross-platform mobile GIS apps. Quite a few of the Flex API code samples originally designed for the web can also be compiled without modification and run on mobile devices. For example, the following screenshot shows the Switching Basemaps web sample running on an iPhone 4. However, although the app may work without modification, sometimes the UI should be redesigned to take into account a smaller screen or lack of a physical keyboard.

AIR can access the GPS, accelerometer, microphone and camera on most mobile devices, although not the gyroscope or compass, so if you need these then you will have to use native code (i.e. Objective-C for iOS, Java for Android). The new AIR 3 runtime has support for Native Extensions, which allows native code modules to be linked with Flex apps.

Free ArcGIS apps written using Flex include MuniTracker, a public transport information app for San Francisco, and ArcGIS Viewer, a lightweight GIS viewer modelled on the ArcGIS Viewer for Flex, although it uses a different codebase because iOS devices do not support apps with a modular architecture like the Flex Viewer. You can download these apps through the App Store/Android Market. Flex apps seem to run quite well on mobile platforms, but runtime performance and battery use need to be considered. For example, MuniTracker disables animated transitions when a user zooms in and out on the map in order to conserve resources, although this behaviour may look a bit odd to users who are accustomed to seeing smooth zoom-level transitions.

More information about designing, building and deploying Flex mobile apps can be found in this guide: Developing Mobile Applications with Adobe Flex and Adobe Flash Builder.

Debugging GP Services

So here’s the deal: you’ve spent ages perfecting a GP model, incorporating loads of different tools and adding custom touches in python. In fact, maybe you’ve even gone the whole hog and scripted your GP tool from scratch – and it works like a charm in ArcMap. Bingo.

You publish it to ArcGIS Server, you pull up the ArcGIS Rest Services Directory and navigate through to the GP Server Rest Endpoint. You painstakingly harvest some valid JSON to define your input parameters, and patiently wade through the ‘Invalid value for parameter X’ messages. You hit ‘Submit Job’…..and it goes kaput. Nothing, zilch, nada, zippo.

Except of course:

 

Where do you go now? Why does a perfectly valid GP tool break the minute you turn it into a GP Service? Well, sometimes these things happen.

First things first, I extracted the whole thing to one big Python script, and I began to pepper it with arcpy.AddMessage() calls, mainly logging vital information like, err,  arcpy.AddMessage(“I am here”) and arcpy.AddMessage(“Now I’m here”). I saved the script, refreshed the model in ArcMap, saved the MXD, refreshed the map/GP services, cleared the Rest cache, (did a handstand and shut my eyes), and…

 

Hurrah! No, wait…

So I took a different approach. And I’m delighted to say that after a lot of huffing, puffing and flapping; a few cups of tea, the odd lunch break; maybe a quick chat about the weather with someone passing by, a few more cups of tea, a comfort break; some cheese-on-toast, a quick distraction to fix a LocatorHub web service, a stroll into town, and back again….

 

Um. Yeah. Cheese on toast never fixed anything.

So I bit the bullet and decided to recreate my script, line by line, to pin down the problem. With a deep breath, I started out with just a simple opener:

 

Failed

Soon I was pegged back to this:

 

Failed

What is going on?

My colleague Simon suggested I take a look at some log files in C:\Program Files (x86)\ArcGIS\Server10.0\server\user\log\. That was a good start. In one of them I came across the following (emphasis added):

<Msg time='2011-08-12T15:07:22' type='ERROR' code='20010' target='pipelines2.GPServerSync' methodName='GPServerSync.CheckMessages' machine='TAYLOR' process='3156' thread='6244'>Executing (GetIntersections2Model): Model1 Start Time: Fri Aug 12 15:07:22 2011 Executing (GetIntersections2): GetIntersections2 Start Time: Fri Aug 12 15:07:22 2011 ERROR 000576: Script associated with this tool does not exist. Failed to execute (GetIntersections2). Failed at Fri Aug 12 15:07:22 2011 (Elapsed Time: 0.00 seconds) Failed to execute (GetIntersections2Model). Failed at Fri Aug 12 15:07:22 2011 (Elapsed Time: 0.00 seconds)</Msg>

Then it dawned on me. While I had been carefully storing my MXDs and data in a location visible to the ArcGIS SOC process (critical for ArcGIS Server permissions) I had stuffed my python script in a folder inside my user space. ArcGIS Server doesn’t have permissions to see in there. Such a simple and obvious mistake. But such a time-waster!

Having moved the script outside my user space to somewhere more sensible, I regenerated my model, republished my MXD and once again, cleared my Rest cache, and my script succeeded first time.

 

But hang on a minute. Where are my debug messages?

Remember, I had bunged a load of arcpy.AddMessage() calls into my script just to try and get some debug info. Hey – I’d even got so frustrated I used an arcpy.AddWarning() just because I like to live dangerously. But now my script was clearly executing, where was my debug info?

Well, ladies and gentlemen, here’s the crux of it. Your GP service properties window has an option in the Parameters tab, called Show Messages, but its default state is unchecked. You need to turn this on in order to see any of your custom message information (and you’ll need to do this while your service is stopped).

For security reasons, debug information is not shown by default. But providing you’re aware of the risks of exposing potentially exploitable information (eg file names/paths/usernames/etc) you can turn this feature on. That way your end user sees status information, warnings and – most importantly – error messages, which could actually be incredibly useful to them. (After all, as an end user I would want to know that a call to a service has failed.) Plus as a developer I can then give users progress updates via status messages, especially for tasks that may take more than a few seconds to execute.

So in my book, the Show Messages option should  be checked as long as we’re aware of the sensitivity of outputting certain types of debug/status information.

 

(Aside: it is also possible to achieve the same results by changing the ShowMessages property in your service’s CFG file, but you’ll need to restart your whole SOM before the changes will take effect.)

So after all that, I finally had my messages coming through:

 

 

In summary…

If you are having problems debugging ArcGIS Server GP Services

1)      Make sure your GP tool works correctly in ArcMap before publishing it as a service

2)      Make sure all resources for your service – MXDs, toolboxes, data, script files, etc – are stored in a location that ArcGIS Server can access (ie outside your user space)

3)      Check your log files in C:\Program Files (x86)\ArcGIS\Server10.0\server\user\log\ for clues as to why your GP service is failing

4)      Turn on Show Messages and use arcpy.AddMessage() to send debug information to the client.

And if all else fails, ask a colleague called Simon*

*not all colleagues called Simon may have ArcGIS Server, GP and python experience. Use of Simons is at your own risk.

A Desktop future for the JavaScript API?

Some important Windows 8 demos have come bursting onto the scene lately which have significant implications for the future of the JavaScript API (including the compact build).  With the release of this attractive demo of the new Windows 8 touch interface, there has been a lot of talk about the future environment for developing desktop applications for Windows.  

All that has really happend is the addition of a new API which is based on HTML5 and JavaScript.  For JavaScript API developers this is good news - the addition of what will inevitably become a broadly adopted platform means we can start writing apps that will have a desktop feel, much like we would for a Chrome OS app.  We'll have to get better at utilising touch gestures for desktop apps and it remains to be seen which additional tags Microsoft will decide are required, but the future looks interesting.

Speed up your tiled map services

I want to tell you about a simple trick that will speed up the loading of map tiles from ArcGIS Server tiled map services in all browsers. We’ve recently incorporated this into LocalView Fusion and it requires only a handful of ingredients:

  • A tiled map service running on a server you control.
  • A few lines of JavaScript
  • Some extra "A" records (subdomain names) for the domain name of your site (use your hosts file if you are developing this and wish to test it)

The problem: Blocking

Browsers can only make a limited number of HTTP requests at once. In modern browsers, like Internet Explorer 9, Chrome and Firefox 4, up to 6 HTTP connections can be made per host name (although in FF at least you can configure this). So if your tiled map service is running on a server with the address like http://www.myserver.com, then these browsers can send up to 6 tile requests at once before they have to stop and wait for the responses to come back.

If more than 6 requests are sent to the same host name, the browser will wait for responses to be returned before sending requests 7, 8, 9 and so on. This is called “blocking”.

However, a browser will usually need to display more than 6 tiles at once to show a map. For larger resolution screens there may be 20 or 30 tiles making up the full map display. So after the first 6 tiles have been requested, the browser will “block” until it can send more tile requests.

The solution: multiple subdomains, and some code

Let me first make it clear that this is not a new trick, I just haven’t seen it implemented in an ESRI web API client yet. Google, Bing and Open StreetMap tiles are routinely requested from multiple subdomains in clients and APIs for those services: for example the OSM tile URLs are a.tile.openstreetmap.org, b.tile.openstreetmap.org, c.tile.openstreetmap.org and so on. This allows 6 tiles to be requested from each subdomain: 18 at once. (Older browsers may have a lower concurrent connection limit: IE7 is limited to two per subdomain for example).

This trick can be applied to ArcGIS Server map services as long as you have control over the registering of the extra “A” records for your domain (a.myserver.com, b.myserver.com and so on). The rule of thumb is that 3 or 4 “A” records will speed up requests but beyond this diminishing returns apply due to the extra burden of DNS lookups.

So – step one: register 4 extra “A” records for the domain where your server is running. In our example these would be:

a.myserver.com

b.myserver.com

c.myserver.com

d.myserver.com

The code

My example here is based on the JavaScript API but there is no reason why the same approach wouldn’t work in Silverlight or Flex, as long as you can implement a custom layer type using those APIs. You can do this easily in the JavaScript API as described in this article on the ArcGIS Resource Centre.

It is easy to extend the ArcGISTiledMapServiceLayer class in the ESRI JavaScript API, thanks to the Dojo framework upon which the API is built. By defining a new class that inherits from a base class, and implementing an override for the properties and methods you wish to change, the amount of code required can be kept to a minimum.

To make multiple requests to the same map service, the code will need to do the following:

  •  Read the service metadata from the “normal” map service URL as usual. This is the URL passed into the constructor method of the ArcGISTileMapServiceLayer class.
  • Define new properties for the list of server URLs to use, and to keep count of which one each tile request is using.
  • Override the getTileUrl method, to loop through the list of subdomains in turn and make a request from the next one in the list.

Here is a code sample of the custom layer class as used in LocalView Fusion:

 

dojo.provide("CustomLayer"); //define the namespace and class
dojo.declare("CustomLayer", esri.layers.ArcGISTiledMapServiceLayer, {

    /* Extends the ESRI class by adding a list of servers. 
    /* This needs to be manually populated when 
    *  the object is created.
    */

    servers: [],
    serversLength: -1,
    serverIndex: 0,


    getTileUrl: function (level, row, col) {
        var idx = 0; 
        //check how many URLs there are.
        if (this.serversLength < 0) { 
            this.serversLength = this.servers.length;
        }
      //if there is more than one URL, get the next in the list.
      if (this.serversLength > 0) { 
            // Multiple urls
            idx = this.serverIndex++ % this.serversLength;
            return this.servers[idx] + "/" 
                   + this.url + "/tile/" 
                   + level + "/" 
                   + row + "/" 
                   + col + ".png";
      }
      //if we don’t have extra URLs, just use the default one.
      else { 
            // Original single url
            return this.url + "/tile/" 
                   + level + "/" + row + "/" 
                   + col + ".png";
      }
  }
});

 

 

And here is a sample of how it might be used in an application:

var basemap = new CustomLayer(
 "http://www.myserver.com/ArcGIS/rest/services/MapServiceName/MapServer"
);
basemap.servers = [
 "http://a.myserver.com/ArcGIS/rest/services/MapServiceName/MapServer",
 "http://b.myserver.com/ArcGIS/rest/services/MapServiceName/MapServer",
 "http://c.myserver.com/ArcGIS/rest/services/MapServiceName/MapServer"
];
map.addLayer(basemap); //assuming "map" is the name of our map object.

To conclude

In our testing, using a modern browser like Firefox 4, Internet Explorer 9 or Chrome, the effect is that ArcGIS Server tiled maps load in the browser much faster than before, up to 24 tiles coming in at once compared to the batches of 6 you would normally get with those browsers.

If you use IE7 this will be less impressive as it uses a strict implementation of the HTTP 1.1 spec, and can only make two requests per host - even so, this will fetch 8 tiles at once using this method.

If you're using IE6, well....I don't suppose faster tile loading is going to make much difference as the general HTML rendering and script execution performance is so bad to start with!

This functionality will be in the next release of LocalView Fusion, but if you are running ArcGIS Server with a registered domain name and can make the edits I've described here to your application, then there's nothing stopping you implementing it right now.

HTML5 support in the JavaScript API

Well, the wait is over. 

HTML5

HTML5 is creeping into the JavaScript API & esri are aggressively propagating new HTML5 components in the API.  With the release of version 2.2 of the API we saw a set of experimental samples released using Canvas raster layers, file drag & drop, feature collections in local browser storage and tile caching in local storage in the browser. 

With the release of version 2.3 of the JavaScript API we will see support for IE9 which will overcome the longstanding issue of vector graphics performance in all versions of IE.  IE9 has implemented SVG as the new vector graphics language, bringing it in line with all other modern browsers.  This represents a significant speed performance upgrade for graphic display between IE9 & earlier versions which used the long-neglected VML technology for displaying vector graphics.

Printing in ArcGIS Server

Printing in ArcGIS Server is one of those topics we get asked about on a regular basis. If you are looking for something more than the out of the box functionality the solution was usually to roll up your sleeves and get stuck into ArcObjects. At 10 however Esri released the arcpy.mapping Python module. This gives a relatively simple option for some nice prints. If you haven't seen it before Esri have written a great getting started blog article with some nice examples. Well worth a read:

http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2011/04/12/An-introduction-to-arcpy.mapping-for-ArcGIS-Server-developers.aspx

Enjoy!

A beginner's guide to extending ArcGIS Viewer for Flex

If you're a non-developer looking to get started with building Flex Viewer widgets, you might find the following document useful:

A Beginner's Guide to extending the ArcGIS Viewer for Flex

When I started at Esri UK, I had a fair amount of development experience but I was completely new to Flex. I ended up taking a lot of notes while I was learning my way around the Viewer, which were eventually turned into a beginner's guide aimed at non-developers.

The guide is a high-level overview of the widget development process and the various technologies involved. For more detailed step-by-step instructions, ArcGIS.com has lots of helpful resources.

Any comments and suggestions are welcome, and we really hope you find it useful!

 

Approaches to Working with Enterprise Data in ArcGIS

For many years I have used X/Y Event Layers in ArcGIS to take data from a text file or a database, and then render it in a map.  I’ve then used the Data Export tools to place a copy of this snapshot into a Geodatabase for further analysis.  This has always worked well for me.

However, I’ve recently been working on an integration project with Microsoft Dynamics.  Within the SQL Server database I have a number of tables describing customers and the locations of incidents that I want to be able to visualise and analyse in a Silverlight Web Application.  My initial reaction was to use X/Y Event layers, but I found a number of issues with doing this.  This blog post discusses these issues  with reference to integration with MS Dynamics. It should be born in mind that the comments are relatively generic and can be used in any situation where you need to read data from a live non-spatial database.

The first issue I faced with using X/Y Event layers is that ArcGIS will always look for an ObjectID field which is not available as part of the standard Dynamics database schema.  You can choose to ignore this, but this removes much of the functionality.  For example, ArcGIS will render the points on your map, you can set symbology based upon values in a field, but you can’t select features or undertake geoprocessing with them.  I had a look at the documentation around X/Y Event layers and found a tool in the Data Management Toolbox called “Make Query Table” that allows you to append an ObjectID on the fly, as long as you have another numerical/unique field in the table (see screenshot below).  Unfortunately the Dynamics unique identifier is a GUID rather than a number , and whilst I could have added one, I did not want to play with the Dynamics schema too much.

 

Another option that has became available with ArcGIS 10 is the use of the “Query layer” data-type, which allows an ArcGIS User to connect straight to a database table with a geometry spatial column, without using ArcSDE.  The main issue here was that I need to be able to edit the location and the ArcGIS 10 “Query Layer” is currently Read-Only.

With two options discounted I had to look a little further.  The solution I chose to implement is sweet.  Essentially, I used the existing X/Y’s within Microsoft Dynamics, and the GUID, to create a feature class which only held the point geometry and the GUID.  This then allows you to create a relationship from the feature to the attribute information held in Dynamics.  This means that any changes in Dynamics are carried through to the next load or refresh of the data in ArcGIS.  Changes and additions were maintained using the Rest API Feature Service. Some bespoke code was required for the business logic to make this work but it was a relatively minor development task.  So, in this situation, ArcGIS is maintaining the parts of the data that it is best able to manage, and Dynamics looking after the same.  There is no duplication of data, and it all works harmoniously.

There’s a lot of information on creating ArcSDE views, such as this article here:

http://help.arcgis.com/en/arcgisserver/10.0/help/arcgis_server_dotnet_help/index.html#//0029000000s8000000.htm

One of the other advantages about this approach is that you can index the database and push all of the processing back to the DBMS.  The beauty of which is that the right tool, in my opinion, is then handling all of the data, and making it available to ArcGIS for the presentation/analysis work.  You are therefore consuming the best bits from each of the tiers in this architectural model.

There is, however, a limitation to this model.  It works well as long as you do not want to edit any attribution within ArcGIS.  But what if you wanted to take incident data out and edit in ArcGIS Mobile, for example?  In this model you would still be able to view the attribute data but not edit it.  The issue is that to edit using the native Esri components all data must be in the Geodatabase.  So, the model here would be to hold just as much data as is required in the Geodatabase and maintain duplicate data side by side.  This is obviously going to require a development activity, but could be managed through code or an Enterprise Service Bus.  Triggers would have to be used to Extract-Transform-Load the data in each direction but this would give a true enterprise level solution. 

Unfortunately time and requirements did not allow me to explore this final option further;  the ArcSDE view implementation worked well for my needs.