Load Webservice XML data into Javascript API/Webapp Builder

1187
4
10-12-2017 06:10 PM
EncikPiee
New Contributor

Hi. I've a web services, that provide Lat & Long for each object, from my previous Flex Application. Is there any method to load this data into Javascript API or Arcgis Webapp Builder?

Mind if you can share the references. Thank You.

0 Kudos
4 Replies
RobertScheitlin__GISP
MVP Emeritus

Encik,

   I have never gotten the JS API to work with SOAP based web services. You will need to re-create your web service to be a RESTfull web service.

0 Kudos
ThomasSolow
Occasional Contributor III

You can use esri/Request to make a request to your web service.  Then you can take the resulting XML and transform it into something JavaScript-friendly.  I've never had to do this before but it shouldn't be too hard.

This would look something like this:

esriRequest(<url to your webservice>, {
  responseType: "xml"
}).then(function(response){
  // response.data is an XMLDocument
  // let's say your features are described by <feature></feature> objects
  // with longitude and latitude attributes

  let nodes = response.data.getElementsByTagName("feature");
  let featureArray = [];
  for (let i = 0; i < nodes.length; i++){
    featuresArray.push({
      longitude: nodes[i].getAttribute("longitude"),
      latitude: nodes[i].getAttribute("latitude)
    });
  }
  return featureArray;  
});‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
0 Kudos
RobertScheitlin__GISP
MVP Emeritus

I would love to see a working example of a SOAP based web service that takes input parameters working using esriRequest.

0 Kudos
ThomasSolow
Occasional Contributor III

I imagine it would be a lot of work to do that.

But if you just have a simple server that's serving up a bunch of features in XML, not necessarily an Esri service, then this should be straightforward.

It also doesn't seem like it would too hard to query a SOAP based feature service and parse the features into something usable.  Getting that service to work seamlessly with with the JS API would be a long slog though, and I think you're right that the best move would be republishing that service so that it supports REST if that's your goal.

0 Kudos