How do I generate code from ESRI GPServer wsdl?

Question

I'm trying to use svcutil to generate code from this GPServer wsdl.

So I run this command:

svcutil GPServer.wsdl

Which generates ESRI_Currents_World_GPServer.cs.

The code has comments saying the code generator "requires additional schema information", is there some other file I can pass to svcutil that has this additional info?

[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);

I get the same results with

svcutil GPServer.wsdl /ser:XmlSerializer

I'd like to implement the interface in a web service and have it appear to clients (like arcmap) as if it were arcgis server. Has anyone done this?

Update: This article addresses the issue, but the solution is to change your WSDL so that it's compatible with svcutil. I can't do that, can I?

Update 2 It appears what I'm trying to do is referred to as "WSDL first design". Here's a good discussion. This description could apply to ArcGIS desktop as well as Microsoft office:

And this it may be counter intuitive for some people. The client application, in this case, Microsoft Office, specifies the on-the-wire contract, the WSDL. Lots of people have a server-centric design perspective, and assume that the server defines the contract. That often makes sense, but not in this case. Because there are so many deployments of Microsoft Office out there, it makes sense for the client to define the contract.

Update 3 (Simplified summary) Esri's REST API is open, yet incomplete. Some features supported by SOAP are not supported by REST, like cancelling a GP job. Since the wsdl is public, it should be possible to write a mapservice that implements both the SOAP and the REST API. Does anyone know of a tool that helps me implement a mapservice that adheres to Esri's SOAP contract?

Answer 1

We ran into this problem when trying to do batch geocoding with GeocodeAddresses(). Unfortunately, ESRI does not properly honor the wsdl contract. In order to have your code work correctly against the SOAP interface, you need a client side library that is shipped on the ArcGIS Server install and only on the ArcGIS Server install. ESRI will not send you the files in email or through any other distribution route.

With the logic contained in the client side library, you cannot generate the correct stubs to use the SOAP interface front the client side.

Knowing this, I suspect that without knowing what is going on client side, you cannot make a functioning server side implementation that looks like ArcGIS Server. In particular, information appears to be embedded in the OIDs that must be decoded by the client in order to match the records sent back up with the results received. We tried to figure out the pattern to this OID encoding, but had no luck after a week of work. Unfortunately, I doubt this is a bug or other accident.

Edit: Received some new info on this problem at the ESRIUC Try using the pregenerated proxies which you can download at: http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/index.htm#Pre-generated_java_proxies.htm

The other information at the bottom of that page will probably be useful too

Answer 2

Argh. Last answer. It's not related to the other two, so I'm disinclined to attempt to improve the others as they're all orthogonal.

I gave up on svcutil, and used the wsdl utility instead:
wsdl http://sampleserver1.arcgisonline.com/ArcGIS/Services/Specialty/ESRI_Currents_World/GPServer/MessageInABottle?wsdl

Which generates code that looks very plausible. I will admit to not having tried it out, however.

Edit: I took ten minutes and tried it.

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();
    }
  }
}

Results:

Demographics
Elevation
Locators
Louisville
Network
Petroleum
PublicSafety
Specialty
TaxParcel
WaterTemplate

I'm declaring victory at this point and ceasing further efforts (until someone says they can't get it to work for some reason).

Answer 3

Seems like you have a namespace mismatch. I've had a similar problem in the past, it's worth a shot.

Notice how the wsdl has a target namespace of: http://www.esri.com/schemas/ArcGIS/10.0

And your code has: http://www.esri.com/schemas/ArcGIS/9.3

.NET will not deserialize if the namespaces do not match.

That would explain why it's not doing anything. If use TraceViewer, check to see if you're getting valid response message. If you are getting a valid response and .NET is just not deserializing the xml to objects, than i'm pretty sure this is your problem.

Change one of them to match the other.

Give it a try, good luck.

Answer 4

I think a combination of a couple of things will help, but may not completely cure what you're seeing.

• Reference the ESRI.ArcGIS.System.dll

• Add the 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

Might do the trick - I do get some warnings still, but they seem to be somewhat less strident in tone. This does force the generation of enums called "esriArcGISVersion", and "esriServiceCatalogMessageFormat" but in a different namespace, which is inconvenient, but probably not lethal to the project.

Answer 5

Try using the pattern and practices service factory (easiest to install using VS Extension manager, you also need to install GAX and VS SDK) service factory on vsgallery Or service factory on codeplex Service factory is usually better to use when trying to do WSDL/contract first. There is a Import WSDL extension that can be installed WSDL Import on vsgallery Or WSDL import on codeplex.

I tried and it imports the WSDL and generate code and it looks ok, but I don't have access to ArcMap right now, but I try later on...

Update 2010-10-13: Tried this today and I can't get it to work. Some kind of name mangling in the VS causes:

The XML element 'GetMessageVersionResponse' from namespace 'http://www.esri.com/schemas/ArcGIS/9.3' references a method and a type. Change the method's message name using WebMethodAttribute or change the type's root element using the XmlRootAttribute.

Found an explanation for that exception here: "The .NET Framework adds the suffix "Response" to the method name to create the WSDL operation name. So we'll have both operation (method) and type with the same name. That may be a reason." Changing method signature results in an exception

Answer 6

Just for fun, I tried using Storm which somehow manages to generate code, and execute it against that WSDL. So this becomes kind of a good-news, bad-news thing.

• Good news: it's possible to generate .NET code from that WSDL that works
• Good news: someone else has figured out how to do it
• Good news: it's open source, so you can see how they did it
• Bad news: they used F#, which I only slightly understand