design patterns: isv recipes for success (dreamforce 2015)

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



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




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


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


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


Apex Enterprise Patterns: Building Strong Foundations Moscone West, Innovation Theater, Tuesday 1.30pm


design patterns: isv recipes for success (dreamforce 2015)

Technology