Apex Code for Beginners at the Salesforce.com Spring ‘07 release
The final session that I attended at the launch was Apex Code for Beginners, delivered by Adam Gross. It was a great talk, providing some nice slices of Apex Code to whet your appetite.
Adam sees the Apex Platform as based on five pillars:
[…] As the Salesforce Heretic says, Salesforce may see a big drop in API traffic when they implement these changes. They should remember that a drop in API traffic is probably a really good thing… […]]]>
Uh, maybe because Outlook Edition uses the API and syncs on a schedule automatically, even when the using isn’t doing anything?]]>
I suspect the asynch callback query feature, if announced at Dreamforce, will remove the need for constant pounding on the API and polling for changes.
As for JOINS, I don’t know. This is on my wish list too. I’ve developed the (bad?) habit of creating a lot of intersection objects, but this really starts chewing up the allotment of custom objects.
SFDC is doing a pretty good job of providing familiar, old school relational concepts and constructs, although their underlying metabase schema is clearly not condusive to adhoc queries.
The SOQL to physical SQL translation layer must be a nightmare to refactor, refine and tune.
Has anyone tried building star schemas and OLAP cubes from their SFDC data? That would be the BI approach to this problem.]]>
Why Building Scalable Web Sites is only Half The Problem…
Creating Scalable Websites
One concept I try and use in understanding the new world of feeds, open APIs and brittle but p…]]>
“Salesforce.com is in the hosting business, not in the software development business.”
Your comment really brings me to a core problem @ SFDC…
They are a CRM provider. They are in the hosting business (with the AppXchange edition — no CRM). They are catering to large companies, small companies, not-for-profits. Companies in the B2B space, B2C space, and probibly a company just in space…
They have companies with large integration requirements, no inegration requirements, extensive processes, and simple processes.
What unites them all - SFDC wants them all as customers.
You can’t be everything to everybody.]]>
I don’t think anyone is saying the API isn’t functional. What some of us are saying is that there are several changes that could be made to make things much more functional for us AND that we shouldn’t have to use the API as much as we do in the first place.
Some changes that would drastically improve the situation:
1) GetUpdated() call that will work on multiple objects at once, all objects in the system and allows fine grained time parameters instead of being truncated to the minute.
2) SFDC-side event triggers for data changes (all CRUD events) that can fire a client-side web service. No, the current workflow and e-mail notification is not acceptable for this. I would guess that a VERY large percentage of API calls are just people polling for data changes because there’s no better way.
3) A better workflow engine built-in that allows actual data changes based on other data. Instead of just being able to send an e-mail or create a task, it should be able to set values, create objects, etc.. (perhaps execute an scontrol?)
4) User schema versioning so that it’s easier to cache the SFDC schema for a particular user. Something simple like a version number that is returned when you log into the system and is incremented every time a configuration change is made that affects that user (new fields, fields removed, new objects, etc…)]]>
Let’s be realistic on two topics. First - the AppExchnage is less than a year old and the fact that over 300 companies have build applications - granted mostly trivial ones - means that the API is reasonably functional and we can only expect it to mature.
The second and most important point - never mistake the salesforce.com API for a developer library like you are used to have from a java package or a C++ lib - the API will always contain only as much facilities as is useful for Salesforce.com itself to grow salesforce.com ’s customer base - and not yours. Salesforce.com is in the hosting business, not in the software development business.]]>
I’m not a liberty to say much (yet), but I’ll make an offer to ya’ll - I’ll be happy to host this debate in person in San Francisco, and provide the beer.
Take a look at http://www.salesforce.com/conference/developers.jsp (and if there is something missing you’d like to see let me know.)
And since is the Heretic’s blog, I’ll let you know that if you register as a developer you can use the AppExchange Seminar code (DEVGR06) to get an additional $100 off.]]>
Mike L, let me take your comments point by point…
Caching is a double edged-sword. If you cache too long you’re using old data, too short and you add load. What is an acceptable cache expiration period for one org is likely different for another.
Upsert calls are also nice, if the things you want to do with the API can use them in the first place. Also, keep in mind if you write AppXchange apps, you can’t use upsert unless you create the field manually. Lets chalk that up to another incomplete feature.
Compression… Again arguments both pro and con. If you have an excess of bandwidth available, and are CPU contrained not using compression on calls benefits everyone by not adding the load of the compression/decompression on the API call. Given the instablity early in the year, I disabled compression on my calls to try to help shed load. Also keep in mind that compression doesn’t mean you make less calls, just that your calls are smaller in bytes, but harder on the CPU.
Lastly you refer to SFDC “running the meter” on the calls. They know (probibly better then I as I don’t normally aggregate those stats unless running in debug mode) exactly how many API calls this client makes in a given period — and I’ve spoken to them about it. At one point they were in the top 5 across all customers and we had a discussion at length as to why, including exact use cases.
Simply put - if what is billed as the world’s most customizeable on-demand CRM application requires me to issue an inordinate amount of API calls to stopgap missing functionality, that’s not a consumer problem. (And Summer ‘06 *cough* did such a great job of bridging that gap — but that’s another discussion entirely)]]>