agelfert

ArcGIS Enterprise Web Application Development - Connecting the Dots...

Blog Post created by agelfert on Feb 27, 2019

Several months ago, I completed ESRI's "Introduction to Web Development Using ArcGIS API for JavaScript" online course (3 days). All in all, this was a pretty good class, as ESRI courses go. Definitely targeted towards folks new to subject or with limited web programming experience. If you're interested in what the course covers, you can find a lot of the exercises on codepen.io.

 

After completing the class, I was fired up to start coding web maps and web applications using the Javascript API (JSAPI), HTML5 and css. At the same time, I was working through an ArcGIS Portal implementation (with lots of outside help thankfully). So my first post-class observation was that the JSAPI class completely ignored the existence of ESRI's Web AppBuilder. I don't know if that was to help you focus on learning the API, supposed to shield the budding web developers from the dark arts of "no code needed' development, or a complete oversight on ESRI's end.

 

For full disclosure and to my dismay, I have to admit that I haven't spent as much time on the web development side of things while working with our new ArcGIS Enterprise stack as I'd like. As a result, I find myself going in circles a lot. Coming up with a best practice for setting up web maps and building web applications that allows for various levels of users and a user's "permit to publish", is going to be a key recipe for success with Portal.

 

I wanted to collect my notes on how to attack web map and web application development in ArcGIS Enterprise both for my own reference and maybe as a helpful primer for anyone just starting out. Therefore, the 'blog post' category seems appropriate. This will be a work in progress because I'm definitely still filling in the gaps in my knowledge. As I stumble upon them,  will likely continue peppering this post with additional links. Some of my experiences are certainly tainted by banging my head against the wall a few too many times. So please take them with a grain of salt.

 

Straight-up JavaScript API Approach

So as a freshly anointed GIS web developer and graduate of the JavaScript API course, motivations runs high. Turns out that to get off the ground, as every JS 101 tutorials tries to convince you, all that's needed are three (3) files. The beauty of Web GIS 2.0, right?

 

  • One  *.html
  • One *.js
  • One  *.css

 

Inside the *.js, you reference any map services (as Map Image Layers), use your HTML layout of choice, and style it with CSS. This part is what the ESRI class I took covered in great detail.

 

So far, this is nothing new for anyone who has even tinkered with ESRI web GIS for more than a day, and in reality, most web applications will be more complicated than that. I am trying to illustrate simplicity here. You can literally create a cool looking web map in minutes this way, and if you start with some template code, it will go even quicker. Whether you create that on your local machine or another environment, if you're lucky like me and have access to your ArcGIS/Web Server's ..\inetpub\wwwroot\ESRI directory, you create a new directory \new_app and copy your three files in there, and wham-bam, you have a GIS web application that runs at webadapter.domain.com/new_app.

 

 

I know there may be all kinds of security issues depending on your own organization and how your AGS or AG Enterprise is configured, but this is how simple it can be in theory. This simplicity had me excited and willing to learn the JSAPI inside out. Which is the last time you'll hear the word 'simple' in this post.

 

Next, if you want to share your app through Portal (and this post is really about building apps with ArcGIS Enterprise, so I'm assuming you have Portal), all you have to do is add it as an item, provide a URL and TNT (tags and title)... then it becomes discoverable to Portal users. But all that is actually stored in portal is the reference to the app.

 

The Portal/Web AppBuilder Approach

(Documentation: http://enterprise.arcgis.com/en/portal/latest/use/welcome.htm)

Provided you are using ArcGIS Portal, you can create a web application based on ArcGIS Server map services in Portal.

 

 

You start under Content/My Content, Create a new Map (provide some TNT), then add map services (from your organization's Content), and save your app. Then you click on 'Create Web App' (enter some TNT) and enter the exciting world of Web AppBuilder (WAB) (that's the WBA version that's packaged with Portal). You pick a theme, choose your initial map extent, add any widgets from those available with this version of WAB and hit save.

 

 

You have just created a full blown web application, which is stored in ... ESRI's Portal black box where it can be accessed and referenced via Item ID.

 

The URL will looks something like this: https://webadapter.domain.com/portal/home/item.html?id=yadayada,  where "yadayada" is the item ID.

 

If you're using the Python API, you can reference content via item ID:

 

from arcgis import gis
yourgis = gis.GIS(your_portal_url, username = '*****' , password='*****')
yourgis.content.get('yadayada')

 

I'm really not sure where this app is saved. On my Portal server, I see an item folder...

 ..\arcgisportal\content\items

 

... which now contains a "yadayada" folder. But there is not much inside of this folder. My suspicion is that some configuration info is stored in the Postgres database under ..\arcgisportal\db but I haven't had the time to crack that open or found any documentation on how that database fits into Portal.

 

It would be nice to be able to access the code that's behind the app you've created. Making things more user friendly to the non-coder is great. Using the WAB for quick templating is also great. But how do I edit the code?

 

Another flavor of the Portal/WAB Approach becomes available when you select 'Using a Template' under 'Create Web App' in Portal. That gets you to an Interface that looks a bit like either an older version or a light version of WAB. Configuration options are similar to Portal WAB and again you save the app to the Portal as a Portal item. I don't really know if this is legacy functionality. I haven't been using Portal long enough to tell whether this was the first version. I don't think I have any use for this feature but it's there.

 

The Web AppBuilder for Developers Approach

(Documentation: https://developers.arcgis.com/web-appbuilder/guide/xt-welcome.htm)

 

Now, to the Grand Finale. The Developers version of WAB, which I will call WAB-D. You can download the app and install it on your client or on a server. The app runs in the browser. and you might have to try and see which browser and works best for you. I've had both success and issues with both IE and Chrome. You can install and run it on the server and access it with your local browser (if your security policies, arrangements, or mine fields don't get in the way), and you can run WAB-D as a service, so that you don't have start it via *.bat every time you want to do some work. This is how it looks post-install...

 

 

You start WAB-D, create a project and end up composing a web app very much like you did using Web AppBuilder for Portal (WAB-P). But your choice of widgets is a greater, and you can add custom widgets, although I believe those can be added to WAB-P as well...

 

So you create a web app as you previously did in Portal and save it. Then you're able to download your web app into a ZIP package. If you extract that into a folder in your wwwroot/ESRI folder, you end up with an app running at webadaptor.domain.com/new_app.

 

 

The big difference from WAB-P is that now you end up with this directory shock full of code that you can dig through. Yeah! But, ooohhh - what's that?

 

 

What's jimu.js? Just when I thought I'd never have to take another stab at dojo and even the last require's for dojo stuff appear to no longer be needed in the JSAPI, here comes marching along a whole 'nother framework. Welcome to jimu.js!  This is 20 MB of framework stuffed in each one of your apps to make it run. Ouff. I am always glad to learn something new ... but wasn't I already learning a new framework? Not blaming ESRI here.  I think this maybe the State of JavaScript in 2019 A.D. Bloated abstraction wrapped around bloated abstraction.

 

 

There is plenty of information on the ESRI website and elsewhere about building and deploying custom (not-out-of-the-box) widgets. I started working on some custom widgets using the JSAPI, and now I'm torn between doing that, or learning the jimu way. So for me, it's really not about the amount of stuff to learn but about figuring out which method makes the most sense. So plenty more for me to research and try to connect the dots, see what works best for me and my organization.

 

Some Useful or Just Interesting Links

 

Okay, I apologize for being rather verbose here. It sometimes helps me to spell things out when trying to understand them. I'm having a blast operating in the ESRI universe, so if this post sounded like I'm only complaining, that wasn't the idea.  I merely sometimes wish that there were one way to accomplish things, one clear way that's supported and that aligns with the training syllabus, especially since so many ESRI efforts are geared towards those GIS professional straddling the roles of data analyst, developer, mapping tech, DBA, etc. -- As always, I welcome any feedback or pointers down the paths I've failed to travel.

Outcomes