Andrew Connell [MVP SharePoint]
1741 Posts |  46 Articles |  5310 Comments
.NET  |  MCMS  |  SharePoint  |  Office System
Andrew Connell's RSS Feed    
AC's Blog Quick Links
SharePoint Quick Links
Article Categories
Archives
May, 2012 (3)
April, 2012 (4)
March, 2012 (4)
February, 2012 (4)
January, 2012 (12)
December, 2011 (6)
November, 2011 (3)
October, 2011 (17)
September, 2011 (8)
August, 2011 (6)
July, 2011 (7)
June, 2011 (13)
May, 2011 (9)
April, 2011 (15)
March, 2011 (1)
February, 2011 (6)
January, 2011 (5)
December, 2010 (11)
November, 2010 (6)
October, 2010 (12)
September, 2010 (5)
August, 2010 (4)
July, 2010 (5)
June, 2010 (6)
May, 2010 (11)
April, 2010 (11)
March, 2010 (9)
February, 2010 (9)
January, 2010 (3)
December, 2009 (10)
November, 2009 (15)
October, 2009 (15)
September, 2009 (7)
August, 2009 (4)
July, 2009 (10)
June, 2009 (8)
May, 2009 (2)
April, 2009 (9)
March, 2009 (6)
February, 2009 (16)
January, 2009 (6)
December, 2008 (12)
November, 2008 (12)
October, 2008 (27)
September, 2008 (13)
August, 2008 (14)
July, 2008 (14)
June, 2008 (12)
May, 2008 (23)
April, 2008 (12)
March, 2008 (15)
February, 2008 (13)
January, 2008 (12)
December, 2007 (10)
November, 2007 (8)
October, 2007 (15)
September, 2007 (20)
August, 2007 (21)
July, 2007 (16)
June, 2007 (8)
May, 2007 (25)
April, 2007 (16)
March, 2007 (18)
February, 2007 (18)
January, 2007 (12)
December, 2006 (16)
November, 2006 (13)
October, 2006 (18)
September, 2006 (22)
August, 2006 (27)
July, 2006 (23)
June, 2006 (23)
May, 2006 (23)
April, 2006 (9)
March, 2006 (17)
February, 2006 (15)
January, 2006 (23)
December, 2005 (31)
November, 2005 (32)
October, 2005 (38)
September, 2005 (53)
August, 2005 (30)
July, 2005 (63)
June, 2005 (30)
May, 2005 (59)
April, 2005 (29)
March, 2005 (74)
February, 2005 (27)
January, 2005 (22)
December, 2004 (32)
November, 2004 (42)
October, 2004 (39)
September, 2004 (20)
August, 2004 (14)
July, 2004 (27)
June, 2004 (40)
May, 2004 (5)
April, 2004 (6)
March, 2004 (16)
February, 2004 (26)
January, 2004 (23)
December, 2003 (7)
November, 2003 (14)
October, 2003 (20)
September, 2003 (4)
Post Categories



Managed Windows Shared Hosting

Sometimes throughout the course of your work you find something that just makes you wonder what the heck the developers were thinking. Recently that was me and working with the SalesForce Web Service API. So far there have been quite a few challenging things in working with this API that were new and strange to me… a big one being when you query for objects, you get an object back that has all the properties available, but if you didn’t explicitly put the field you need in the SELECT statement, the SalesForce Web Service would still return the field in the return result, but it just wouldn’t be filled in. Uh… if i don’t select it, then don’t give it to me… anyway… that was relatively minor until recently.

Then I ran into something that just drove me nuts. Let’s say you want to update a record, but you first want to give the user the ability to see what’s in it. So what’s the flow? In every API I’ve worked with the process is:

  1. Query & select item.
  2. Show item’s properties.
  3. User updates fields.
  4. You send item back to service for updating.

Pretty logical right? What if you wanted to clear out a field back to its default “empty” or null state? Well, just set it to string.empty or null… right? Nah… not if you’re the SalesForce API designers!

You have to explicitly tell the SalesForce Web Service what fields you want to null out like this:

Contact sfContact = // code to load a contact object from SalesForce
sfContact.FirstName = “John”;
sfContact.LastName = “Doe”;
sfContact.Phone = “”; // sure would make sense doing this right? nope!
sfContact.fieldsToNull = new string[] { “Phone” }; // this is how you clear the Phone property... ugh!
// call Web Service update method

Now that’s just strange to me. But it gets even better. Say you follow the process above where you get the object, update some fields and then want to clear out the phone number. Well, if you originally selected the Phone property & then you try to set it to null, SalesForce throws an error (in the new v8.0 Web Service API). Why? Because you sent back two instructions for the Phone property: (1) update it’s value and (2) set it to null.

So how to do you get around it? I give you my own person daily WTF: you have to send a separate object to tell the Phone to be set to null:

Contact sfContact = // code to load a contact object from SalesForce
sfContact.FirstName = “John”;
sfContact.LastName = “Doe”;
// call Web Service update method
Contact sfContact_ResetFields = new Contact();
sfContact_ResetFields.Id = sfContact.Id;
sfContact_ResetFields.fieldsToNull = new string[] { “Phone” };
// call Web Service update method

And I give you dumb! Of course the update method can take an array of objects to update so you don’t make two round trips, but that’s just stupid if you ask me. Think I’m making this up or don’t understand the API? Guess again… straight from their forums and the mouth of a SF API moderator.

Technorati Tags: ,
posted on Tuesday, February 02, 2010 5:52 AM

Feedback

# re: Stupid API Rant: the SalesForce Web Service API 2/2/2010 6:48 AM Charlie Holland
Gravatar Man I feel your pain!

Spent many months working with www.northgate-ispublicservices.com/.../integration and their crazy Java web service endpoints for Oracle Forms.

At least you've got the option to set nulls with SF. With the Northgate system, setting a value to Null was completely ignored because of the way records were versioned. (It effectively carried forward the previous value to a new version rather than clearing it out!)

It makes you wonder, if we did that kinda thing we'd be slated from far and wide. I suppose it could be because the Microsoft.net developer community is wider and possibly more inclined to share and follow best practice.

Who knows!





# re: Stupid API Rant: the SalesForce Web Service API 2/2/2010 8:19 AM Himadrish
Gravatar Cool!

So, SF needs to be improved :)….What about MS CRM :)

# re: Stupid API Rant: the SalesForce Web Service API 2/3/2010 12:31 AM Michhes
Gravatar > And I give you dumb!

You should be used to working with dumb APIs AC--isn't this a SharePoint blog?! ;-)

# re: Stupid API Rant: the SalesForce Web Service API 2/3/2010 5:07 AM Fire Snake
Gravatar Ever considered that a) string.Empty <> null and more importantly b) how the stuff is transported over the wire? For Web service calls fields which are null not neccessarily need to be included in the message, making it smaller. Now, how exactly is the server supposed to know whether you wanted to set the field to null vs. you just did not want to update its value?

The downside of you approach is that for an object with 1000 properties, and you wanted to update a single one, you would need to send all 1000 even if unchanged. Well that's chunky, but not exactly smart.

Think again before posting this.

# re: Stupid API Rant: the SalesForce Web Service API 2/3/2010 1:34 PM AC [MVP MOSS]
Gravatar Himadrish-
I wish I was working with MS CRM, but such is life :)

Michhes-
Har har har :)

Fire Snake-
This wasn't posted on a whim... the fact that I"m not th eonly one who's complained about this (see the SF forums) shows that it's a wierd decision. Even worse, this was somethign the SF API team threw in with their 8.0 update that caught many folks off guard... a bad breaking change IMHO.

The guidance from the SF guys is that you should only be sending the properties you want to update and not the whole object. While I get that, it's not a common practice, esp. when most object you're sending for SF records are tiny and should not create much overhead. Best practice? Sure... is that was eveyrone does? Not even close.

Regardless... the fact you have to explicitly tell it which fields you want to be set to null instead of just setting the field to either null or string.empty is poor. It's a fix to the SF model where you work with the same object you get. IOW, if I get a Lead object, it sends down the lead object. But to update a Lead, I send a lead object back. All those properties are there, jsut some aren't filled in. Thus the only way to address this by the SF API team is to require folks call out which fields need to be updated.

# re: Stupid API Rant: the SalesForce Web Service API 9/22/2010 1:02 PM Tom
Gravatar A best practice is something that makes code cleaner and more maintainable. Simplifying the code "under the covers" should be the responsibility of programmers working "under the covers."

What Fire Snake is suggesting is a "best work-around," which is what many Java "patterns" are--work-arounds.

Regardless, reducing the amount of data on the wire is a bandwidth consideration, and there are many ways to get around that without burdening application programmers. Passing the buck would have been an insult to system programmers in the 80s and 90s, but who would notice today?

Anyway, fields could be marked "dirty" when their values change (under-the-covers) so only dirty fields would need transmission or updating.


# re: Stupid API Rant: the SalesForce Web Service API 3/1/2011 6:18 AM tec-goblin
Gravatar Oh how I feel your pain. Definetely one of the worst APIs I've worked with.
Hard to set values to NULL.
Stupid batch size limits and no client-side abstraction of this
Magic strings everywhere
No ENUMs for selection boxes
No abstraction of login
No change tracking on the client
No LINQ (except from the basic things you can do to the IEnumerables you collect)
Ridiculous naming conventions (full of __c s everywhere, automatic replacement of é with _ etc)
Extremely constrained foreign keys (you can rarely perform a cascading delete, for example)
Very basic logging
Practically no transactions
The CHEATSHEET of api limitations in queries per day etc etc (which is not complete, but ok, includes APEX limitations as well) is 7 PAGES LONG.

And now just compare their new "REST" API to an OData one and cry...

# re: Stupid API Rant: the SalesForce Web Service API 6/7/2011 10:17 AM Stefan
Gravatar Guys,

I just tried to send a "space character" with my API, and it seems to update to empty. So I don't need to send the fields to null list of values.

Can any of you confirm this "stupid" trick?

Regards,



# re: Stupid API Rant: the SalesForce Web Service API 6/15/2011 1:47 PM Mark
Gravatar That is absolutely ridiculous. I only recently discovered that by setting the deletedate of a contact to null when he reactivates does not actually change the field. I was searching for what I have to do, and don't even want to do it because it's such a stupid way of doing it... I think I'll call salesforce support and yell at them again instead.

# re: Stupid API Rant: the SalesForce Web Service API 3/29/2012 1:35 PM Dan
Gravatar FYI - You don't need to send two sObjects (or make two calls). For the reasons you cited (can't perform two actions in one call), simply make sure you don't specify a value for the fields in the fieldsToNull array

This works:
Contact sfContact = // code to load a contact object from SalesForce
sfContact.FirstName = “John”;
sfContact.LastName = “Doe”;
sfContact.Id = //the Id
sfContact.fieldsToNull = new string[] { “Phone” };
// call Web Service update method

This does not:
Contact sfContact = // code to load a contact object from SalesForce
sfContact.FirstName = “John”;
sfContact.LastName = “Doe”;
sfContact.Phone="";
sfContact.Id = //the Id
sfContact.fieldsToNull = new string[] { “Phone” };
// call Web Service update method

Post Feedback

Title:
Name:
Email:
(email will not be displayed)
Url:
Comments: 
Please add 5 and 1 and type the answer here:    
All Comments Are Filtered & Moderated
Unfortunately comment spammers are just too effecient and are constantly dirtying up blogs with irrelevant and unwanted comments trying to improve their standing on search engines. All comments on this blog are moderated. I do not censor comments, but I don't approve comments with vulger language or those soliciting products. Most of the time comments are approved within a few hours of being submitted with the only exception when I'm traveling.

Why are you asking for my email address?
The only reason I'm asking for your email address, which isn't required to submit a comment, is to provide a gravatar if you've created an account for yourself and associated your email address with a small image. If you have a gravatar created for the email address you submit, it will appear next to your comment. Otherwise nothing will appear.

What is a gravatar?
A gravatar is a "globally recognized avatar." You can get more information about gravatars, as well as create your own for free, at www.gravatar.com. You can also view my gravatar here.


Copyright © 2003 - 2012 Andrew Connell
Creative Commons License 
This work is licensed under a Creative Commons License

 
SharePoint Training
Looking for SharePoint 2010 training for developers, administrators, power users, information workers, end users & web designers? Look no further! My company, Critical Path Training offers the best SharePoint training around! We offer public & private classes both as in-person instructor-loed hands-on classes and online classes. Check out our schedule and course catalog for all the ways we can get you going on your SharePoint path!