Cryptic error message on update

[jvanulde]

Trying to update an existing registration as follows:

{ 
    "en": {
    "service_url": "http://section917.cloudapp.net/arcgis/rest/services/JOSM/Oilsands_en/MapServer/20",
    "service_type": "esriFeature"
},
    "fr": {
    "service_url": "http://section917.cloudapp.net/arcgis/rest/services/JOSM/Oilsands_fr/MapServer/20",
    "service_type": "esriFeature"
    },
    "version": "2.0"
}

I get the following error:

"Error: Problem communicating with service endpoint http://section917.cloudapp.net/arcgis/rest/services/JOSM/Oilsands_en/MapServer/20 No JSON object could be decoded"

How can I get this record to update?

[james-rae]

That oilsands service is no longer active. Also, section917 is a dev server used to test things outside of the firewall.

Can you provide more info on what the goal is here? What is the key for the entry? Are you trying to update something to no longer use section917?

[jvanulde]

Sorry, that was probably a bad example. Here is another service endpoint that is giving the same error even though it's live:

{"en":{"service_url": "http://www.agr.gc.ca/atlas/rest/services/mapservices/grain_elevators_in_canada/MapServer", "service_type": "esriDynamic"}, "fr":{"service_url": "http://www.agr.gc.ca/atlas/rest/services/servicesdecarte/les_silos_a_grains_du_canada/MapServer", "service_type": "esriDynamic"}, "version":"2.0"}

This is the key: 05870f11-a52a-4bf4-bc15-910fd0b8a1a3

On RCS: http://167.40.124.18/static/test.html

[james-rae]

Can you try with the correct service_type?

{"en":{"service_url": "http://www.agr.gc.ca/atlas/rest/services/mapservices/grain_elevators_in_canada/MapServer", "service_type": "esriMapServer"}, "fr":{"service_url": "http://www.agr.gc.ca/atlas/rest/services/servicesdecarte/les_silos_a_grains_du_canada/MapServer", "service_type": "esriMapServer"}, "version":"2.0"}

I'd do it myself but not sure if that's your prod rcs... I was able to run an update on our local instance with the correct type

[jvanulde]

Not sure what the correct service_type is except what is returned by the GET:

{
  "layers": [
    {
      "metadataUrl": "http://167.40.124.17:80/geonetwork/srv/fre/xml.metadata.get?uuid=05870f11-a52a-4bf4-bc15-910fd0b8a1a3",
      "name": "Les Silos \u00e0 grains du Canada",
      "url": "http://www.agr.gc.ca/atlas/rest/services/servicesdecarte/les_silos_a_grains_du_canada/MapServer",
      "layerEntries": [
        {
          "index": 0
        }
      ],
      "layerType": "esriDynamic",
      "catalogueUrl": "http://167.40.124.17:80/geonetwork/metadata/fre/05870f11-a52a-4bf4-bc15-910fd0b8a1a3",
      "id": "rcs.05870f11-a52a-4bf4-bc15-910fd0b8a1a3.fr"
    }
  ]
}

[james-rae]

The get is sending you data that is formatted for RAMP's consumption.

The json you are registering is for RCS.

The RCS Service Contracts provide a guide on how input payloads should be formatted. If any of the docs are not clear, please let us know so we can update them.

Did the snippet I provided solve the issue?

[jvanulde]

No the snippet still didn't work.

[jvanulde]

How do I get the actual RCS registration and not the RAMP registration?

[jvanulde]

I think you should be able to update just one attribute (e.g. the service_url) without having to provide additional ones (e.g. service_type). Since there doesn't seem to be a way to get at the service_type for a registration it's impossible to know what should be provided.

[dan-bowerman]

Hi Joost,

The UPDATE endpoint would enable you to change the service_url on a service, something like this:

{
    "fr": {
        "service_url": "http://www.agr.gc.ca/atlas/rest/services/servicesdecarte/les_silos_a_grains_du_canada/MapServer/0",
        "service_type": "esriMapServer"
    },
    "en": {
        "service_url": "http://www.agr.gc.ca/atlas/rest/services/mapservices/grain_elevators_in_canada/MapServer/0",
        "service_type": "esriMapServer"
    },
    "version": "2.0"
}

Unfortunately the UPDATE endpoint, while making it mandatory to provide a service_type, does not let you switch between service types - this would require a new registration or overwrite. So if you want to go from esriDynamic to esriFeature, for example, you will need to register again, not use UPDATE.

[jvanulde]

So the issue is that I just want to update the service endpoint URI but I don't know what the service_type is. Any way to get that out of the API?

[dan-bowerman]

service_type is mandatory, but also is ignored, so you can put any service type in there, it won't matter but will still update the URL. esriDynamic is what it is already registered under: http://167.40.124.18/v2/doc/en/05870f11-a52a-4bf4-bc15-910fd0b8a1a3

[james-rae]

Any way to get that out of the API?

There is no way to get the original request out of the API. If you go in debug mode and export the couchDB, you can see it in the records (so I'm told).

We've opened an issue to look into making that parameter optional per your suggestion. We also reviewed the documentation around the update endpoint and agree it needs some work, so have scheduled that as well.

[jvanulde]

Okay, so with the service_type being ignored I can update but some services are coming back with certificate errors:

payload:
{"en":{"service_url": "https://ec.gc.ca/arcgis/rest/services/data_donnees/4cdeec34-30e7-4070-8362-ae5bac21376b/MapServer", "service_type": "esriDynamic"}, "fr":{"service_url": "https://ec.gc.ca/arcgis/rest/services/data_donnees/4cdeec34-30e7-4070-8362-ae5bac21376b/MapServer", "service_type": "esriDynamic"}, "version":"2.0"}

Update response:
{
  "msg": "Error: Problem communicating with service endpoint https://ec.gc.ca/arcgis/rest/services/data_donnees/4cdeec34-30e7-4070-8362-ae5bac21376b/MapServer [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)"
}

Using RCS V2 on that server.

[james-rae]

We made some updates to better support services that had not-so-friendly certificates. If you want to try updating to v2.3.1, it might help get around some of these errors. We were able to update using that service on our instance.

v2.3.1 Release

[jvanulde]

Thanks @james-rae. Will try.