I'm wondering if someone can tell me if they have had a similar Portal experience?

2433
15
Jump to solution
09-12-2016 01:14 AM
MarkHotz
Occasional Contributor II

I have successfully created our organization's first web map in Portal.  Everything seems to have gone really well, and the map services (layers) are functioning well.  We installed ArcGIS for Server 4.1, and I'm using ArcGIS Desktop 4.1.

However, there is one issue that has been bothering me all week and it just doesn't seem to want to be resolved.  There are two map services that I have added that work well.  They draw to the screen exactly as built in ArcMap.  I can enable the popups and interact with the database.  The part that has me totally baffled is that I cannot configure the popups in any of the layers in either of these two map services.  To compound the frustration is that when these two map services are added, even though I can see and interact with all of the layers in my web map, I can no longer configure any of the popups in any layer.

However, when I remove those map services and save, I can then resume configuring all of the popups in all of the layers that I have added to my web map.  So I know that there is something about the layers in these two map services that is causing the problem.  But what?

In one map service I separated two layers out from the 8 creating to separate map services, and now I can configure all of the layers in both of those new map services.  So what's up with that?  How's that even possible?  Combined into one I cannot configure the popups...but the exact same layers in two separate map services and now I can?

I still have one map service (roads, ferries and railways) that cannot be configured, and it seems to corrupt the other layers already a part of the web map when this map service is added...until it is removed.

So my question is, does anyone know what could cause a map service layer to prevent popup configuration?  I have gone through the attribute tables to see if there is anything in there that could confuse a web map, but nothing seems to be apparent there.  Being steered in the right direction would probably all I really need at this point.

Thanks.

0 Kudos
1 Solution

Accepted Solutions
MichaelRobb
Occasional Contributor III

Great to hear!

Also to note, F12 usually will show you why any items such as Popup is not functioning.  I have ran into Instances of not being able to 'configure popup' in portal, due to invalid data stream from SQL from a specific FME Server Process.  This would happen when attempting to enable Popup and configure it on a layer:  

One this happens, if you save the Portal Web Map, the map is then euchred and unrecoverable. 

It is good practice to F12 and watch the calls while doing Web Map configurations .... if an X shows up.. abort, do not save, get out and get back in.. if you save the web map, it is not recoverable.  

Portalassistant is also your friend..

ArcGIS Online Assistant 

However, we downloaded this and use this locally.

View solution in original post

15 Replies
JayantaPoddar
MVP Esteemed Contributor

Did you enable pop-up?



Think Location
0 Kudos
MarkHotz
Occasional Contributor II

Jayanta:

Yes...all of my popups enabled.  It's just this one map service that is causing me grief.  The frustrating part is that when I publish the map service to AGOL it works.

0 Kudos
PaulDavidson1
Occasional Contributor III

Mark: this is a total shot in the dark and I'd be surprised if this changes or fixes your problem but take a look at:

https://community.esri.com/thread/175979

The fix this suggests is to change your default display field, perhaps to a text field.

The problem this thread describes is about a failure publishing an mxd.  Not related to your issue. 

However, the part that caught my eye is your statement that when you publish to AGOL, the problem went away.

I had the same behavior, the mxd published to AGOL but not to Portal until I changed the default display field to a text field.

Thought I'd bring this to your attention since it's a simple enough thing to try.  Best of luck solving this.

0 Kudos
MarkHotz
Occasional Contributor II

Paul:

Thanks very much for the feedback.  I will take a look at this when I get back into the office and explore this article deeper.  After reading your explanation of something as simple as changing a default display field to a text field I realize I had a similar experience when I used a default text field to look like <text>.  Apparently Portal reads that as bad HTML code and won't let you edit the data :-)....who knew?  However, what happens a lot in this business is one simple explanation may not solve the immediate problem, but it leads you to a solution that does fix things.

Thanks again.

0 Kudos
MarkHotz
Occasional Contributor II

I believe I have (finally) fixed the issue.  We were in the process of working at Windows authentication for Portal so we could then add restrictions to viewing and editing, and also to access our data through Collector.  This required us to change over to a web based URL for virtually everything, and away from a local GIS server URL to access our data.  However, the project ran into delays and we had to at least temporarily abort our project until later this year.  This then meant that we had to revert all of our paths and URL's back to their original setting, and it turns out that some were missed during this process.  The system can still function when using our main corporate web URL, but it is not a recommended practice to have different paths etc. until one is ready to make the switch permanently.

During this process data was added to our current MXD's, so some of them had acquired data from the geodatabase through different paths and URL's than others.  This then undoubtedly corrupted the MXD's...perhaps not in their entirety but at least in some way.  Once I recreated those MXD's after all of the paths and URL's had been properly configured, I was once again able to configure the pop-ups in Portal.  It was that simple.

Lesson:  Don't mess around with your system's paths and URL's while you're still using and building data in that system :-).

0 Kudos
MichaelRobb
Occasional Contributor III

Are you SURE you want to IWA Portal?  

You know that each user that logs in is auto assigned a Named User account, right?  Meaning.. if you have 100 staff type in the portal url... you better have 100 named users handy. This can be quite costly with large enterprise organizations.  

Restricting editing and viewing could just as easily be done using web tier authentication on arcgis server / web adaptor, rather than portals. (and save you the licensing nightmare).

Collector can also be one named user group, if I understand you correctly, for internal (corporate) use.  

I am not quite following your lesson here. Why would you use local GIS Server URL at all?  Were you not using the web adapters at least?

Are you not using a DEV/ Acceptance/ Production silo approach? (it does not sound like it)  or at bare minimum, EDN (DEV and Prod) 

From a web end, id also be using a Load balancer... that points to whatever machine you want it to, you can change FQDNs all day long, wont impact having to go back and change stuff...  Portal for example, would be adding a REST service from your ArcGIS Server THROUGH the NLB which points to whatever web adaptor you want..   e.g. gis.company.com/arcgis/rest/services/   regardless where that GIS server(s) sit or the web adaptors for them are... 

MarkHotz
Occasional Contributor II

Michael:

Yes, and using web tier authentication is the direction we're heading.  Thanks for the pointers too as this is helpful.  I, for one, would like to avoid a licensing nightmare :-).  We were in the process of configuring our system (using the web adaptors) as a part of an implementation project, and initially it did not go as well as we had hoped, and we just ran out of time.  As a result we have half a system running properly and the other half still needing to be configured.

So what we did was backpedal and will now get our system fully functioning with just a handful of users to start.  Once this has been officially achieved we will then move toward a system that is properly configured through the web adaptor.  We need to have something running very soon so that users can use it to test and experiment this month, so we don't have a lot of time to learn how to do everything correctly.  We need user's input at this point to better see where this system needs to go, and how it will evolve.  We're almost there, but we just feel that rather than rush forward we're going to take a bit of a breather and learn if we're on the right track.

Much of this is being set up by ESRI, and in the future they will be working through a DEV-TEST-PROD environment to make sure it works before we make the switch.  Our IT only just acquired the DEV-TEST-PROD servers and they are now ready to be used (they were not available when we started our implementation this past summer).

What we have achieved so far is pretty slick though...and it is impressive.  But next month, after our user workshop and demo we will be moving this to the next level.  By the end of this year we will have our system up and running the way it was meant to be.

Thanks again

0 Kudos
MichaelRobb
Occasional Contributor III

Great to hear!

Also to note, F12 usually will show you why any items such as Popup is not functioning.  I have ran into Instances of not being able to 'configure popup' in portal, due to invalid data stream from SQL from a specific FME Server Process.  This would happen when attempting to enable Popup and configure it on a layer:  

One this happens, if you save the Portal Web Map, the map is then euchred and unrecoverable. 

It is good practice to F12 and watch the calls while doing Web Map configurations .... if an X shows up.. abort, do not save, get out and get back in.. if you save the web map, it is not recoverable.  

Portalassistant is also your friend..

ArcGIS Online Assistant 

However, we downloaded this and use this locally.

MarkHotz
Occasional Contributor II

Michael:  Wow...thanks for this tip.  That's exactly what I have been doing, and I have rebuilt more than a couple of MXD's to republish map services that were suddenly giving me popup grief in Portal (I initially thought that the MXD was corrupted so I just rebuilt a new one and this seemed to fix the problem...but now I know better).  

I will definitely give that F12 option a try the next time I run into an issue....I did not know this.  What I did manage to do recently is shut down Portal and then launch it again, and this at least allows me to configure the popups in the other layers that seem to freeze when one starts giving me grief.  However, like you said, the one layer that started the problem is then unrecoverable and has to be republished (as instinct always tells me to save before I quit).  Now I will use F12 and then quit without saving...all good to know.

0 Kudos