¿Cómo genero código a partir del WSDL de ESRI GPServer?

Question

Estoy tratando de usar svcutil para generar código a partir de este wsdl de GPServer.

Entonces corro este comando:

svcutil GPServer.wsdl

Lo cual genera ESRI_Currents_World_GPServer.cs.

El código tiene comentarios que dicen que el generador de código "requiere información de esquema adicional", ¿hay algún otro archivo que pueda pasar a svcutil que tenga esta información adicional?

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://www.esri.com/schemas/ArcGIS/9.3", ConfigurationName="GPServerPort")]
public interface GPServerPort
{

    // CODEGEN: Parameter 'Result' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlArrayAttribute'.
    [System.ServiceModel.OperationContractAttribute(Action="", ReplyAction="*")]
    [System.ServiceModel.XmlSerializerFormatAttribute()]
    [System.ServiceModel.ServiceKnownTypeAttribute(typeof(Patch))]
    [System.ServiceModel.ServiceKnownTypeAttribute(typeof(Field[]))]
    [return: System.ServiceModel.MessageParameterAttribute(Name="Result")]
    GetJobInputValuesResponse GetJobInputValues(GetJobInputValuesRequest request);

Obtengo los mismos resultados con

svcutil GPServer.wsdl /ser:XmlSerializer

Me gustaría implementar la interfaz en un servicio web y hacer que aparezca para los clientes (como arcmap) como si fuera un servidor de arcgis. ¿Alguien ha hecho esto?

Actualización: Este artículo aborda el problema, pero la solución es cambiar su WSDL para que sea compatible con svcutil. ¿Puedo hacer eso?

Actualización 2 Parece que lo que estoy intentando hacer se llama "diseño basado en WSDL". Aquí hay una buena discusión. Esta descripción podría aplicarse tanto a ArcGIS desktop como a Microsoft office:

Y puede ser contra intuitivo para algunas personas. La aplicación cliente, en este caso, Microsoft Office, especifica el contrato en cable, el WSDL. Muchas personas tienen una perspectiva de diseño centrada en el servidor y asumen que el servidor define el contrato. Eso a menudo tiene sentido, pero no en este caso. Dado que hay tantas implementaciones de Microsoft Office por ahí, tiene sentido que el cliente defina el contrato.

Actualización 3 (Resumen simplificado) La API REST de Esri es abierta, pero incompleta. Algunas características admitidas por SOAP no son soportadas por REST, como cancelar un trabajo de GP. Dado que el WSDL es público, debería ser posible escribir un servicio de mapas que implemente tanto la API SOAP como la REST. ¿Alguien conoce alguna herramienta que me ayude a implementar un servicio de mapas que cumpla con el contrato SOAP de Esri?

Answer 1

Argh. Última respuesta. No está relacionado con los otros dos, así que no tengo ganas de intentar mejorar los otros ya que son todos ortogonales.

Abandoné svcutil y utilicé en su lugar la utilidad wsdl:
wsdl [http://sampleserver1.arcgisonline.com/ArcGIS/Services/Specialty/ESRI_Currents_World/GPServer/MessageInABottle?wsdl](http://sampleserver1.arcgisonline.com/ArcGIS/Services/Specialty/ESRI_Currents_World/GPServer/MessageInABottle?wsdl)

Lo cual genera un código que parece muy plausible. Sin embargo, debo admitir que no lo he probado aún.

Editar: Me tomé diez minutos y lo probé.

using System;

namespace ESRITests
{
  class EsriWSDLTest
  {
    static void Main( string[] args )
    {
      Catalog svrCatalog = new Catalog();
      string[] folders = svrCatalog.GetFolders();
      foreach( String f in folders )
      {
        Console.WriteLine( f );
      }
      Console.ReadLine();
    }
  }
}

Resultados:

Demographics
Elevation
Locators
Louisville
Network
Petroleum
PublicSafety
Specialty
TaxParcel
WaterTemplate

Declaro victoria en este punto y cese de cualquier esfuerzo adicional (hasta que alguien diga que no pueden hacerlo funcionar por alguna razón).

Answer 2

Por lo que parece, tienes un desajuste de espacio de nombres. He tenido un problema similar en el pasado, vale la pena intentarlo.

Fíjate cómo el wsdl tiene un espacio de nombres de destino de: http://www.esri.com/schemas/ArcGIS/10.0

Y tu código tiene: http://www.esri.com/schemas/ArcGIS/9.3

.NET no deserializará si los espacios de nombres no coinciden.

Eso explicaría por qué no hace nada. Si usas TraceViewer, revisa si estás recibiendo un mensaje de respuesta válido. Si estás obteniendo una respuesta válida y .NET simplemente no está deserializando el xml a objetos, entonces estoy bastante seguro de que este es tu problema.

Cambia uno de ellos para que coincida con el otro.

Inténtalo, buena suerte.

Answer 3

Nos encontramos con este problema al intentar realizar geocodificación por lotes con GeocodeAddresses(). Desafortunadamente, ESRI no cumple adecuadamente con el contrato wsdl. Para que tu código funcione correctamente contra la interfaz SOAP, necesitas una biblioteca del lado del cliente que se envía en la instalación del Servidor ArcGIS y sólo en la instalación del Servidor ArcGIS. ESRI no te enviará los archivos por correo electrónico ni a través de ninguna otra vía de distribución.

Con la lógica contenida en la biblioteca del lado del cliente, no puedes generar los stubs correctos para usar la interfaz SOAP desde el lado del cliente.

Sabiendo esto, sospecho que sin saber qué está ocurriendo del lado del cliente, no puedes hacer una implementación del lado del servidor que parezca a ArcGIS Server. En particular, aparentemente la información está incrustada en los OIDs que deben ser decodificados por el cliente para emparejar los registros enviados con los resultados recibidos. Intentamos descifrar el patrón de codificación de este OID, pero no tuvimos suerte después de una semana de trabajo. Desafortunadamente, dudo que se trate de un error u otro accidente.

¡Editado: Recibí información nueva sobre este problema en el ESRIUC! Intenta usar los proxies pregenerados que puedes descargar en: http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/index.htm#Pre-generated_java_proxies.htm

La otra información en la parte inferior de esa página probablemente también será útil.

Answer 4

Creo que una combinación de un par de cosas ayudará, pero puede que no cure completamente lo que estás viendo.

• Hacer referencia al archivo ESRI.ArcGIS.System.dll

• Agregar el switch /importXMLTypes

  svcutil http://sampleserver1.arcgisonline.com/ArcGIS/Services/Specialty/ESRI_Currents_World/GPServer/MessageInABottle?wsdl /r:D:\ArcGIS\DotNet\ESRI.ArcGIS.System.dll /importXmlTypes

Podría funcionar - todavía recibo algunas advertencias, pero parecen ser un poco menos enfáticas en tono. Esto obliga a la generación de enumeraciones llamadas "esriArcGISVersion" y "esriServiceCatalogMessageFormat", pero en un espacio de nombres diferente, lo cual es inconveniente, pero probablemente no letal para el proyecto.

Answer 5

Prueba a utilizar el servicio de fábrica de patrones y prácticas (más fácil de instalar usando el Administrador de extensiones de VS, también necesitas instalar GAX y VS SDK) fábrica de servicios en vsgallery O fábrica de servicios en codeplex La fábrica de servicios suele ser mejor para usar al intentar hacer WSDL/contrato primero. Hay una extensión de Importación WSDL que se puede instalar Importación de WSDL en vsgallery O Importación de WSDL en codeplex.

Lo intenté e importa el WSDL y genera código y se ve bien, pero no tengo acceso a ArcMap en este momento, pero lo intentaré más tarde...

Actualización 2010-10-13: Intenté esto hoy y no logro que funcione. Algún tipo de mala manipulación de nombres en el VS causa:

El elemento XML 'GetMessageVersionResponse' del espacio de nombres 'http://www.esri.com/schemas/ArcGIS/9.3' hace referencia a un método y un tipo. Cambia el nombre del mensaje del método utilizando WebMethodAttribute o cambia el elemento raíz del tipo utilizando XmlRootAttribute.

Encontré una explicación para esa excepción aquí: "El Framework .NET añade el sufijo "Response" al nombre del método para crear el nombre de operación WSDL. Así que tendremos tanto la operación (método) como el tipo con el mismo nombre. Esa puede ser la razón." Cambiar la firma del método resulta en una excepción