REST endpoint for Site shows interesting order for MapServices
Hi to all
I am working on using the GetMapServiceInfo activity with the Workflow designer which requires supplying the MapService Id where the target layer is to be found. The number (as a string) of the layer I was supplying was 1 since it was the second in the REST manager UI
/customer/servlet/servlet.FileDownload?file=00P6000000e880eEAA
however when REST endpoint is checked then the result would suggest that a simple count in the UI will not work if you have shuffled the order of the map services since they were added to the site.
Map
Map Services:
Refuse (1) (url=http://gisagsdev/ArcGIS/rest/services/Refuse/MapServer)
Layers:
toInvestigate (0)
RefuseBagDelivery (1)
ValnLabels (2)
not_yet_assigned (3)
Cadastral (0) (url=http://gisagsdev/ArcGIS/rest/services/Cadastral/MapServer)
Layers:
ParcelBoundaries (0)
Parcel (1)
Address (2)
Road_Legal (Labels) (3)
Road_Legal (Centrelines) (4)
State Highways (5)
Lake (6)
Councils (7)
Aerials (Primary Map Service) (2) (url=http://gisagsdev/ArcGIS/rest/services/Aerials/MapServer)
Layers:
Aerial_1K_2011 (0)
Aerial_2K_2006 (1)
Aerial_5K_2007 (2)
LandSat_2002 (3)
Does anyone know if this is the intended behaviour?
Thanks
Ralph Price
-
Hi Ralph,
You are correct. If your workflow is referencing an ID that changes because of a modification to the site, the Workflow will have to be modified to address the ID change.
I don't know that it's "intended" behavior, I think it's more a case of it just being the way it is.
Steve
0 -
REST Manager assigns a unique ID to a Map Service when you add it to the site. The only way to change a Map Service ID is to edit the Site.xml directly. If you reorder your services it will not reassign the Map Service IDs.
--Ryan
0 -
Could the GetMapServiceInfo activity be extended to include map service names rather than IDs only?? I'm finding the whole workflow methodology too dependent on having map and layer IDs stipulated and correct. Layer Ids can be obtained using the aforementioned activity, but sticking to names seems an easier option as these could change less over the course of a applications development? Yet there is the possibility of like layer names in sites - perhaps?
Interesting one..
G
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
3 kommentarer