Apex: in short
So Salesforce announced Apex. I’ll leave it to the industry press to dig in with great detail on what this new technical development means. I’ll try to sum it up in two sentences:
Before, you could write custom code that leveraged the Salesforce.com API that ran in the client browser, or on your own server. Now you can write and run compiled code on the Salesforce servers.
That means:
- If you want to do things you can’t do on a client (database access, etc.) you can now do it without having to build your own server and keep it running
- If you have intensive functions, like iterating though 3000 Campaign Members and modifying their status based on other criteria, you can do it fast on the server, avoiding the delays of roundtripping
That’s huge news. For me, it means that I can move the S-Controls that continually timeout because they are trying to process lots of data to the sf.com servers, increasing speed and user experience immensely.
It also means we need to rewrite our Salesforce Connector for Plone. We can write Apex code to handle the login and profile managment functions. We can make it faster by creating an API call based on Apex that will chain together multiple API calls that we’re now doing via the Python toolkit. At least our integration was ahead of the curve for one day…
For people like Accenture, with it’s 140,000 employees, they look at Apex and say, “this now gives us the development power to create very large applications in the on-demand environment.” We can now build “stored procedures” that run on the server. They’re investing ~$500K in on-demand next year, and they think it’s where software is going.
Update: I sat in on a session where the inventors of APEX explained what it is and isn’t. In this post I implied that you could do database access in APEX. That’s not true, in my current understanding. APEX will allow you to run procedures with Salesforce objects. It won’t let you call external services and the like.
