Simon Fell > Its just code > A (Disappointing) evening with Indigo

I worked around the previous problem with Indigo and Sforce and continued my exploration, and I now have the distinct impression that everyone who's trying Indigo out is doing Indigo -> Indigo testing, because well frankly for anything else it appears be fairly broken.

• element order in serialized request does not match WSDL
• generated SOAPAction header does not match WSDL
• Get an exception while de-serializing a soap fault
• the generated proxy for operations that are maxOccurs="unbound" don't generate an array in the generated xxx_RequestMessage object
• endpoint URL is in WSDL but doesn't end up in the generated proxy anywhere
• can't create a proxy with a HTTPS url

In addition I see my favorite compliant from ASMX is now in Indigo as well, I really really really hope they do something about this, it seems ridiculous to hobble Indigo with all the AMSX v1.0 decisions. I also hope that Don & Co's work on the programming model just hasn't made it to the client end yet, because it seems pretty yucky so far. (I know this is all early access beta, I just some feedback will make a difference), e.g. here's a call to Login, that dumps the resulting sessionId and serverUrl to the console

SoapProxy proxy = new SoapProxy(new EndpointAddress("http://www.salesforce.com/services/Soap/c/5.0"), new BasicProfileBinding());
login_RequestMessage loginMsg = new login_RequestMessage();
loginMsg.username = "test@test.com";
loginMsg.password = "hahahahaha";
login_ResponseMessage lr = proxy.login(loginMsg);
LoginResult res = lr.result;
Console.WriteLine(res.serverUrl);
Console.WriteLine(res.sessionId);

Compare this with .NET 1.1, note that in this case the programmer doesn't need to manually extract the endpoint URL from the WSDL and put it in his code

sforce.SforceService svc = new sforce.SforceService();
sforce.LoginResult lr = svc.login(username, password);
Console.WriteLine(lr.serverUrl);
Console.WriteLine(lr.sessionId);

All the above bugs meant i couldn't actually test much further than this, but it appears that the client is going to be responsible for hanging onto the header state (such as the SessionHeader) between each call and set it on every RequestMessage instance before calling the proxy. Perhaps I'm just doing something wrong, but I couldn't find much docs on using Indigo to call other non Indigo services. The wsdl was processed with svcutil /uxs /tm enterprise.wsdl which seems to be the only way it'll handle the sforce WSDL.