Details for the much anticipated Salesforce API 2.0 have been released and I will have to say that my first impression is that there is a whole lot of marketing going into this. As an example they have registered a new 1-800 number (didn’t all 1800 numbers become extinct at one point) – 1-800-NO-SOFTWARE.
The number gives away the whole idea behind Apex (afore mentioned API upgrade). General idea is that a subscription to Salesforce allows all out of the box capabilities (Account, Contact, Lead’s etc. management) of the standard CMS, with an extremely flexible architecture which allows unique custom application development. The tag line is “Develop. On Demand.” I have some mixed opinions about this but before I weigh in let me talk a bit about some of the features it does have:
Java based development interface
Essentially, what they have done is taken the application tier and opened it up to interact with Server Side applications that you build. If you are familiar with the current Java API, they look very similar. The difference being that you can:
1.) Bind business logic coding to almost any user interaction – buttons, views, forms, reports etc…
2.) Build triggers to update data to enhance the Business Process Flow (something that was very lacking before this).
3.) Expose interaction as Web services
4.) Completely write compile and execute code in a “test” environment without the cost of hardware/software licenses (this is the marketing side)
Some of the extension coding that you can do (outside of the previous SOQL language and Salesforce Object instantiation) now is incredible, especially for this individuals that use or have built custom objects. For instance now you can:
Create a custom object and allow content that is updated in that custom object directly modify content located in standard Salesforce Object. In our case, we have built a custom Statement of Work object that we bound to the Projects custom object. When a Statement of Work is created it would be nice to update the Project’s Statement of Work delivery date. Or, if you have a Time Entry objects against a Statement of Work object, each Time Entry can update the Estimated Statement of Work and Project Tasks Custom Object.
All tasks that you would do in normal application development.
Questions currently unanswered
What about security? Since users will essentially be loading scripts to a server that is technically available to everyone, how do we prevent people from uploading miscellaneous scripts to extract data from other accounts?
What about the interface? It would seem likely that this would fit nicely into the Eclipse platform. A plugin that allows a developer to enter their SForce username and password and develop “locally” with no startup hardware/software costs.
What about .NET developers? Not that I care too much, but the syntax for this API is based on the constructs of Java which means users that have currently built applications that integrate with Salesforce and are written in .NET will be missing out (unless they want to learn another language).
What about access for Professional level accounts? Currently the extensible API calls for Salesforce are only available for Enterprise customers. Salesforce would have a larger audience if they opened this API up to Professional Level subscribers.
In retrospect?
Is this really that new of an idea? What if you compare this to say ColdFusion (or the like). ColdFusion applications can be pre-compiled server side objects that interact with data. What about the Building Blocks API in Blackboard where you have a core set of data objects, interface objects and global methods for data manipulation. Is Salesforce building something revolutionary, or are they putting a lot of marketing behind a few ideas that have been around before but that nobody has positioned correctly for proper public acceptance?
powered by performancing firefox