Professional Documents
Culture Documents
“Safe harbor” statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-
looking statements including but not limited to statements concerning the potential market for our existing service offerings
and future offerings. All of our forward looking statements involve risks, uncertainties and assumptions. If any such risks or
uncertainties materialize or if any of the assumptions proves incorrect, our results could differ materially from the results
expressed or implied by the forward-looking statements we make.
The risks and uncertainties referred to above include - but are not limited to - risks associated with possible fluctuations in
our operating results and cash flows, rate of growth and anticipated revenue run rate, errors, interruptions or delays in our
service or our Web hosting, our new business model, our history of operating losses, the possibility that we will not remain
profitable, breach of our security measures, the emerging market in which we operate, our relatively limited operating
history, our ability to hire, retain and motivate our employees and manage our growth, competition, our ability to continue to
release and gain customer acceptance of new and improved versions of our service, customer and partner acceptance of
the AppExchange, successful customer deployment and utilization of our services, unanticipated changes in our effective
tax rate, fluctuations in the number of shares outstanding, the price of such shares, foreign currency exchange rates and
interest rates.
Further information on these and other factors that could affect our financial results is included in the reports on Forms 10-
K, 10-Q and 8-K and in other filings we make with the Securities and Exchange Commission from time to time. These
documents are available on the SEC Filings section of the Investor Information section of our website at
www.salesforce.com/investor. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-
looking statements, except as required by law.
Andrew Albert
Technical Evangelist
Raise your hand if….
What I hope you take away
Key factors:
– How was the Apex request
invoked?
– How many records initiated
request?
– What resource is in question?
Entry
Point
Integration
Logic updates
updates 100 Trigger on Trigger fires
related
Contacts Contacts on Accounts
Accounts
through API
Entry Entry
Point #1 Point #2
Common Issue:
– Coding a Trigger to only process a single
record
Sample Code #1: Bulkify Triggers
Best Practices:
– Always design the trigger to process the
array of records
– Iterate across the entire Trigger.new
collection; not just the first record.
Benefits:
– Trigger handles both UI operations and
API operations (single and batch
operations)
Sample Code #2: Efficient SOQL, DML & Loops
Common Issue:
– Too many Queries
– Too many DML statements
– Too many script statements
Sample Code #2: Efficient SOQL, DML & Loops
Best Practices:
– No SOQL queries inside Loops
– No DML statements inside Loops
– Use Collections in SOQL Where Clause to get
all records back in single query
– Execute DML statements with a Collection; not
individual records per DML statement
Benefits:
– Improved performance of operation
– Avoid governor limit exceptions by executing
SOQL and DML with Collections.
– Minimize impact on governor limits
Sample Code #3: Efficient Loops, Query
Relationships & Helper Methods
Common Issue:
– Inefficient FOR Loops
– Inefficient Statement control (ie more logic
than needed)
– Poorly designed helper method (not
bulkified)
Sample Code #3: Efficient Loops, Query
Relationships & Helper Methods
Best Practices:
– Streamline FOR Loops
– Avoid redundant iterations
– Use SOQL Relationships to reduce # of
queries
– Bulkify your helper methods
Benefits:
– Execute less lines of code
– Avoid governor limit exceptions with
poorly designed shared Apex methods
– Minimize impact on governor limits
Asynchronous Apex
Offload some of the processing by creating a
separate, independent Apex request that runs
asynchronously
Integration
Calls @future
updates 100 Trigger on Apex
method with
Contacts Contacts completes
Contacts
through API
Common Issue:
– Not all Apex logic needs to be
synchronous
– Asynchronous apex classes and methods
are not ‘bulkified’
Sample Code #4: Asynchronous Apex
Best Practices:
– Use @future annotation for Apex logic that does not
need to be synchronous.
– @future methods should be bulkified
Benefits:
– @future Apex gets higher governor limits than Trigger
invocations.
– Better user experience since logic is offloaded to run
asynchronously.
– Avoid governor limit exceptions when executing a
batch of records
– Minimize impact on governor limits
Summary of Key Concepts
Discussion Boards
Recommended Sessions
Slides, video, & other resources related to this session are on the web
http://developer.force.com/dreamforce
Don’t go home without a Workbook and set of Developer Cheat Sheets
– available for free in the Force.com Zone
Explore deploying your app to up to 100 users for free, thanks to
the new Force.com Free Edition
Help us help you, and maybe win an iPod! Please provide session
feedback online this year:
Log in to the Dreamforce attendee portal or find the Survey Counters in Moscone
North or South lobbies
14 iPod Nanos given away each day; fill out all the surveys to increase your chances!
QUESTION & ANSWER
SESSION
Andrew Albert
Technical Evangelist