Error with publish a feature service

[pkdavidson]

We're trying to setup the Water Isolation Trace solution from Esri to our Portal and we keep getting the following error:

Failed to create the service.: ERROR: code:500, Failed to create the service 'Hosted/OutageDetails.FeatureServer'. The submitted field 'st_length(shape)' does not exist in the table 'db_oaosg.hsu_8yni3.outagedetails_outagearea'. Internal server error.

There is also this error: Error executing tool. Publish Portal Service Job ID: jb5f52409f57d4a6e904d66397aeae8c2 : ERROR 001369: Failed to create the service. Failed to execute (PublishServiceDefinition). Failed to execute (Publish Portal Service).

Any ideas?

Thanks

[pbobov]

I have no idea. Does publishing always fail or only with some specific data?

[pbobov]

Here is an input from a server developer.

---

The length and area fields of a FC are computed / maintained by the arcgis system.

On most dbs (oracle, sql, fgdb, ...) these are real fields in the FC table.

But on postgresql they are a ‘function’ (?) instead of a real field. Each time the row is accessed, the value is computed on the fly.

This is transparent for geodatabase / arcobjects clients (ex: for the arcobjects FS).

But for the SDS FS (java-based) that isn’t the case. SDS won’t find the physical field on the table and fail.

This service uses the length field for something (ex: as the renderer field, or as the display field for the layer). The SDS initialization is trying to find the field and not finding it.

---

[pkdavidson]

SDS? Service Definition?

I'm wondering if the error we're pulling isn't somewhat of red herring. The Water Isolation Trace solution: http://solutions.arcgis.com/utilities/water/help/web-isolation-trace/

is a solution from Esri that has been used at a number of sites, I believe. I'm actually working with our Esri account rep trying to implement it here on our Portal for a demo to our upper management.

What we're trying to do right now is to publish OutageDetails.mxd from ArcCatalog as a Feature Service. OutageDetails.mxd came from the above link's download. It points to OutageDetails.gdb Here's the two files... Curious what happens if you publish to one of your Portals via the mxd as a FS. OutageDetails.zip

When I publish it, I get the error message seen here:

and then when I go to ServerManager and look at the logs, I get error messages such as those originally posted.

I can publish the OutageDetails.gdb (as a .zip) file to my Portal via Add Item without a problem. And it gives me a Feature Layer but if I try to then publish the outagedetails.mxd and overwrite a service, this FL doesn't show up in the list of overwritable FS. I do note that file gdb: OutageDetails.gdb is at this stage a simple empty file geodatabase. I mean, it's just a schema skeleton if you will. I believe this is to be used by GEE to publish data into which is then viewed by a DashBoard.

I started thinking maybe there is an issue with permissions on the box. That the error messages are red herrings in the sense that they say the st_length field is missing when in reality what's missing is that the schema was not correctly published.

I thought I'd try running the serverScan.py tool that checks out the security settings of the ArcServer piece of the box. But that didn't run correctly. When I tried to run it from an admin command line, I pulled this error:

Which makes me wonder if I don't have a corrupted python installation. I tried to debug serverScan.py via WingIDE and pulled a lot more errors.

I've just rebooted the server to make sure it's not become corrupted.

[pkdavidson]

one note, we just successfully published the OutageDetails up to AGOL. So it appears to be something local. We're thinking something with datastore?

[pbobov]

The problem is the layer ‘Outage Area’ uses the 'length' field as the display field. You wouldn’t be able to publish the map in 10.4. To get around the problem you could change the display field to something else in the mxd.

In AGOL the publishing implementation is a bit different.

We are contacting ArcGIS for Water group to address the problem...

[pkdavidson]

That did it. You are the man... I am very curious how you figured this out. Fiddler?

This also explains a long standing problem we've had with trying to publish (via zipped file.gdb) some of our polygon data. Some polygons would fail to publish to Portal while others would not. All would publish to AGOL.

I had put in a ticket with Esri and the level 1 guy found a workaround, export the polygon to a shapefile and then import it back in. It's a usable work around but we were not able to find the underlying problem. Until now....

When I look at the problematic polygons, I see the same issue, Default Display field is set to SHAPE_LEN. When we do the export/import, a new field is created in the schema: SHAPE_Leng which is now the display field. So that explains why the export/import works.

As a note to others, changing the display field only works for a layer in an mxd when you then publish the mxd. In order to make the change permanent in the Feature Class (in a file.gdb or an egdb) you probably have to modify your schema so that the field used for the default display field is not the 'length' field.

_The default display field is chosen according to the following priorities: 1.First field of type Text whose name contains the word "name" (case-insensitive) 2.First field of type Text 3.First field of an integer type (Long or Short, presumably) 4.First field of any type

I don't think there is any way to specify the primary display field without using a layer or layer file, other than using the above logic to name/order your fields accordingly. _ The above is from: http://gis.stackexchange.com/questions/16934/how-is-the-default-label-field-chosen-by-arcmap

If you have a polygon with only a default schema (OBJECTID, SHAPE, SHAPE.AREA, SHAPE.LEN) then the default display field is going to be set to SHAPE.LEN and this won't publish to Portal 10.4.

I am fixing this in our polygons by creating a next text field: XXX.NAME I have verified this works for Portal 10.4

[pbobov]

Great!

It was not me who figured this out. I just forwarded your question to the right person.

[pkdavidson]

Interestingly, I found no similar issue on GeoNet. I would have thought others would have come across this already. I will post info up there so others have access.