Design Patterns: ISV Recipes For Success Andrey Volosevich Principal ISV Technical Evangelist Salesforce @andreyvol Andy Fawcett CTO Financialforce.com @andyinthecloud
Design Patterns: ISV Recipes For Success Andrey Volosevich Principal ISV Technical Evangelist Salesforce @andreyvol
Andy Fawcett CTO Financialforce.com @andyinthecloud
Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
Safe Harbor
App Configuration
Asynchronous apex
Agenda
Are you building too much?
Do not fight the platform
Do you know how your app is used?
Bonus: Custom Indexes and Skinny tables
Q&A
Pattern is a common reusable solution to a recurring problem within a given context
Anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.
Session Theme: Patterns and Anti-patterns
Anti-pattern
Anti-Pattern Scheduling a session right before the cocktail hour
Anti-pattern Using Custom Objects and Custom Settings for App Configuration
New
App Configuration Anti-pattern: Using Custom Objects or Custom Settings for App Metadata
Name Active__c Resizeable__c Width__c
Panel1 true true 200
Panel2 true true 200
Panel3 true true 400
Panel4 false true 400
Header false false 800
Footer false false 800
Sidebar true true 200
Configuration Metadata NOT Packaged Configuration Metadata is Packaged (protectable at field or record level)
Name Active__c Resizeable__c Width__c
Panel1 true true 200
Panel2 true true 200
Panel3 true true 400
Panel4 false true 400
Header false false 800
Footer false false 800
Sidebar true true 200
Custom Objects or Settings Custom Metadata Types
Custom Metadata Types: Save Years of Development on App Configurations Park Central Hotel, Franciscan Ballroom, Wednesday 11:00 a.m
Anti-pattern Inappropriate Use of Asynchronous Apex
Asynchronous Apex
Four “flavors”
Single request
• Queueable Apex
• @future
Batch requests
• Batch Apex
• Scheduled Apex
Example “Save and Submit Order” Visualforce Page
1. Update an Order
2. Save
3. Submit for Shipment (external web service callout)
4. Update the page (saved order)
5. Update the page (shipment status)
Asynchronous Apex Anti-pattern: Using @future
VF Page App Server
DB
Internet submitForShipping()
Async Queue
3rd Party Shipping Provider
Asynchronous Apex Anti-pattern: Using @future
?
VF Page App Server
DB
Internet submitForShipping()
Async Queue
3rd Party Shipping Provider
Asynchronous Apex Shared Queue: Async != Near Real Time
• Shared queue across all tenants
• Time to dequeue request will vary
• Pod load
• Org load
• Flow control (“Fair Request Handling”)
• High request volume triggers extended delay (“Penalty Box”)
Asynchronous Apex What about…
… Queueable Apex? Better than @future
BUT - it won’t guarantee consistency
… Scheduled Batch Apex?
Should scale better
Queue is not “flooded” with single requests
Users will expect a delay from the beginning
BUT - it still won’t guarantee consistency
Asynchronous Apex SLAs and Customer Expectations
Expectation of Consistency (Implicit SLA)
Customer perception drives customer satisfaction and trust
Any place where users’ expectations are formed: “but it usually runs in 20 seconds and this time it took 30 minutes??”
Explicit SLA
Order processed within 5 minutes of receipt
Quarterly Statements Generated by Monday morning
Asynchronous Apex Alternative Pattern: Apex Continuation
Continuation Server
VF Page App Server
DB
Internet submitForShipping()
Asynchronous Apex Alternative Pattern: Apex Continuation
Continuation Server
VF Page App Server
DB
Internet submitForShipping()
Asynchronous Apex Recap and Good Patterns
Use the right tool for the right job
Understand platform architecture
Engineer to scale
The bar is set higher for ISVs
Do not do this…
Reliable Async Patterns that Scale
Implicit or Explicit SLA => use synchronous context => choose consistency over convenience
GREAT FEATURE
no SLA Shared Queue Variable dequeueing and processing Dependencies you can’t control (Org, Pod)
BUT REMEMBER…
Easy to use native async Relaxed governor limits Process larger data volumes
Examples
Callout scenarios: Apex Continuation Pattern
Consistent batch processing: Client side to orchestrate the process => Browser (Javascript/Ajax) => Server side (Heroku agent)
Place Customer or
Partner logo in white area of
slide, centered horizontally
Andrew Fawcett CTO, Financialforce.com @andyinthecloud
About
GREAT ALONE. BETTER TOGETHER. • Native to Salesforce1™ Platform since 2009 • Investors include Salesforce Ventures • 650+ employees, San Francisco based
Why is this bad?
Less likely to align with new features and innovations on the platform
Just because you can build it, doesn’t mean you should! Anti-pattern: Building too much!
Good patterns….
Be part of the platform, look for ways to extend it rather than just using it
Understand how your customers customize your applications
Invocable Methods extend subscriber use of Process Builder and Visual Flow
Good Pattern Example: Invocable Methods Anti-pattern: Building too much!
Just because you can build it, doesn’t mean you should! Anti-pattern: Building too much!
Lightning Components extend subscriber use of Lightning App Builder
API’s API’s API’s (including Apex API’s) more critical than ever…
Know what the platform API’s provide
Only add value with your own
Internet of Things #IoT growing market, be aware of it!
If something feels hard it's likely because you're not thinking “platform” Anti-pattern: Fighting the platform
Why is this bad?
Limiting the value the platform can give you and your users
Good patterns….
Make sure your Business Analysts know the platform
• If they do, they will be more inclined to state requirements that fit with the platform
• Platform App Builder certification is a good start (formerly ADM 401)!
Make sure you consider all routes into your code not just your custom pages,
• Salesforce WebService and Apex API’s, Workflow, Process Builder etc…
• Ensure your developers understand how customers use the platform to customize
Have the consulting / IT teams talk to developers
Anti-pattern: Not understanding how the app is used...
Why is this bad?
Customer satisfaction will suffer
Slow to react to bugs and issues
No metric-based insights
Leverage the information License Management App gives you
Investigate and understand what Salesforce Usage Metrics gives you
For composite apps, profile and monitor things like API usage
See Limits Resource to query this
Anti-pattern: Not understanding how the app is used... Good Patterns: Drive product change with measurable, observable and quantitative metrics...
Route your Apex Exceptions from your manage packages to some place central
Using Inbound Email Services and Regex to Monitor Apex Error Emails
Good Patterns: Drive product change with measurable, observable and quantitative metrics... Anti-pattern: Not understanding how the app is used...
Bonus Anti-pattern Building non-selective queries Relying on Skinny Tables to Improve Query or Report Performance
Custom Indexes and Skinny Tables Background: Selective queries rely on indexes
ISV Scale: How to Scale Your App for Enterprise Customers Park Central Hotel, Franciscan Ballroom, Tuesday 3pm
Custom Indexes
Standard indexed fields
Primary keys (Id, Name and Owner) Foreign keys (lookup or master-detail) Audit dates (SystemModStamp)
Custom indexes • standard multi-tenant construct • not package-able • created by support via a case • supported for ISVs
Custom indexes
Custom Object Use Unique or ExternalId where possible (packageable!) Otherwise, request custom index
Standard Object Do not add Unique or ExternalId fields to your package Request custom index
Custom Indexes How to log a case to request them
Now a standard process
TODO: Get exact instructions from support (Greg/Nia) - pending
Skinny Tables Supported for Customers (not guaranteed for ISVs)
Large data volumes (~ millions of rows)
Standard or custom indexes are not sufficient
Also not package-able
Not copied to sandboxes
Requires R&D investigation to create each time
Not truly multi-tenant
Support not guaranteed for ISVs apps
Skinny Tables Warning sign, not a scalable solution
Skinny tables for ISV apps
• ok as a one-off
• Not a scalable solution
• Consider them a warning sign
Alternative Design Patterns
• Reduce data set (archive, purge)
• Pre-aggregate data into a separate object
• Explore Data Pipelines and Big Objects pilots
• Reporting: consider building a Wave app
• Work with your TE to assess the best approach
Recommended Sessions
Custom Metadata Types: Save Years of Development on App Configurations Park Central Hotel, Franciscan Ballroom, Wednesday 11:00 a.m
Catch the Wave of ISV Analytics Apps Park Central Hotel, Franciscan Ballroom, Thursday 3pm
ISV Scale: How to Scale Your App for Enterprise Customers Park Central Hotel, Franciscan Ballroom, Tuesday 3pm
(Watch the recording)
Building ISV Apps with Force.com + Heroku Park Central Hotel, Franciscan Ballroom, Tuesday 2pm
(Watch the recording)
Apex Enterprise Patterns: Building Strong Foundations Moscone West, Innovation Theater, Tuesday 1.30pm
(Watch the recording)