Simon Fell > Its just code > Indigo / SForce sample

Using the Beta1 RC bits of Indigo, here's a sample of using Indigo with the Sforce enterprise WSDL

1. Login to your account and download the enterprise WSDL (goto setup -> Integrate -> WSDL Generator)
2. You need to modify the WSDL to work around a bug in svcutil relating to where namespaces are declared, copy the definition of the fns namespace from the root element, down into the schema element that is just before the <simpleType name="ExceptionCode"> element
3. generate the Indigo proxy by running svcutil /uxs /tm /config:client.exe.config enterprise.wsdl
4. edit the generated enterprise.soap.sforce.com.cs and add the Position attribute to the login_RequestMessage class, e.g.

   [System.ServiceModel.MessageContractAttribute()]
   public class login_RequestMessage
   {
       
       [System.ServiceModel.MessageBodyAttribute(Namespace="urn:enterprise.soap.sforce.com", Position=0)]
       public string username;
       
       [System.ServiceModel.MessageBodyAttribute(Namespace="urn:enterprise.soap.sforce.com", Position=1)]
       public string password;
   }
   

5. compile the sample client code with csc client.cs enterprise.soap.sforce.com.cs /r:"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\System.ServiceModel.dll"
6. run the generated client.exe, with client.exe <username> <password>

If you're used to working with Sforce from .NET then it should all look familiar yet different.

• The proxy instance is created with SoapProxy proxy = new SoapProxy(new EndpointAddress("https://www.salesforce.com/services/Soap/c/5.0"), new BasicProfileBinding(BasicProfileSecurityMode.Https)); because using new SoapProxy("Soap") which should read the config from the generated config file fails.
• The typed message model used by Indigo in this case means that what used to be a one liner to make the login call, now takes 4, urrgghhh, this is progress ?
• To handle the server redirect part of the login process, it creates a new proxy using the previous Binding object, proxy = new SoapProxy(new EndpointAddress(res.serverUrl), proxy.Endpoint.Binding);
• The proxy no longer holds the state of the headers between the different calls on the proxy, its now the client programmers job to track this, every authenticated Sforce call will need to set the SessionHeader property of the request message object for that call. (see above, urrgghhh, is this progress?)
• Note that the nonsense with the Specified flags hasn't gone away.

I'm sure if you're doing Indigo to Indigo it rocks, but if you're connecting to an average no frills WS-I compliant service, then I really don't see why I'd be excited about Indigo, the only thing it seems to over the .NET client stack in Whidbey is the better handling of the detail element in soap faults. (but apparently without Whidbey's handling of HTTP response compression) I'm not sure that the verbose and tedious programming model is worth that benefit, YMMV, As I said yesterday the programming model feels like a clunky mix of messaging and rpc, either give me proxy.send(login_requestMessage) or proxy.login(username, password), not this weird hybrid