force.com multi tenancy wp 101508

8/14/2019 Force.com Multi Tenancy WP 101508

1/16

WHITEPAPER

The Force.com Multitenant ArchitectureUnderstanding the Design of Salesforce.coms Internet Application

Development Platform


2/16


3/16

The Force.com Multitenant Architecture: Understanding the Design of Salesforce.coms Internet Application Development Platform 1

WHITEPAPER

Contents

Abstract .................................................................................................................................................. 2

Introduction............................................................................................................................................ 2

Multitenant Applications ........................................................................................................................ 2

Comparing Raw Cloud Computing and PaaS ......................................................................................... 3

Metadata-Driven Architectures .............................................................................................................. 3

New Challenges and Emerging Solutions ................................................................................................ 4

Force.com Platorm Architecture Overview ............................................................................................ 4

Force.com Data Defnition and Storage .................................................................................................. 5

Te Objects Metadata able ............................................................................................................................5

Te Fields Metadata able ...............................................................................................................................5

Te Data able .................................................................................................................................................5

Te Clobs able ...............................................................................................................................................6

Te Indexes Pivot able ...................................................................................................................................6Te UniqueFields Pivot able ..........................................................................................................................7

Te Relationships Pivot able .........................................................................................................................7

Te FallbackIndex able ..................................................................................................................................7

Te NameDenorm able .................................................................................................................................7

History racking able ....................................................................................................................................7

Partitioning o Data and Metadata ..................................................................................................................8

Application Development, Logic, and Processing .................................................................................... 8

Te Application Framework ............................................................................................................................8

Metadata and Web Services APIs ...................................................................................................................9

Bulk Processing with API Calls ......................................................................................................................9

Deletes, Undeletes, and Te Recycle Bin .......................................................................................................10

Data Denition Processing ............................................................................................................................10

Internal Query Optimizations ...............................................................................................................11

Force.com Full-Text Search Engine ........................................................................................................11

Apex ......................................................................................................................................................12

Historical Statistics ................................................................................................................................13

Conclusions ...........................................................................................................................................14


4/16

WHITEPAPER

The Force.com Multitenant Architecture: Understanding the Design of Salesforce.coms Internet Application Development Platform2

AbstractForce.com is the preeminent on-demand application development platorm in use today,supporting some 47,000+ organizations. Individual enterprises and commercial sotware-as-a-service (SaaS) vendors trust the platorm to deliver robust, reliable, Internet-scale applications.

o meet the extreme demands o its large user population, Force.coms oundation is a metadata-driven sotware architecture that enables multitenant applications. Tis paper explains the patented

technology that makes the Force.com platorm ast, scalable, and secure or any type o application.

IntroductionHistory has shown that every so oten,incremental advances in technology andchanges in business models create majorparadigm shits in the way sotwareapplications are designed, built, and delivered toend users. Te invention o personal computers(PCs), computer networking and graphicaluser interaces (UIs) gave rise to the adoptiono client/server applications over expensive,inexible, character-mode mainrameapplications. And today, reliable broadband

Internet access, service-oriented architectures(SOAs), and the cost ineciencies o managingdedicated on-premises applications aredriving a transition toward the delivery odecomposable, managed, shared, Web-basedservices called sotware as a service (SaaS).

With every paradigm shit comes a new set otechnical challenges, and SaaS is no diferent.

Yet existing application rameworks are notdesigned to address the special needs oSaaS. Tis void has given rise to another newparadigm shit, namely platorm as a service(PaaS). Hosted application platorms are

managed environments specically designed tomeet the unique challenges o building SaaSapplications and deliver them more cost-eciently than ever beore.

Te ocus o this paper is multitenancy,a undamental design approach that candramatically help improve the manageabilityo SaaS applications. Tis paper denesmultitenancy, explains the benets omultitenancy, and demonstrates why metadata-driven architectures are the premier choice orimplementing multitenancy. Ater these generalintroductions, the bulk o this paper explains

the technical design o Force.com, the worldsrst PaaS, which delivers turnkey multitenancyor Internet-scale applications. Te paper detailsForce.coms patented metadata-driven architecturecomponents to provide an understanding othe eatures used to deliver reliable, secure, andscalable multitenant applications.

Multitenant Applicationso decrease the cost o delivering the sameapplication to many diferent sets o users,

an increasing number o applications aremultitenant rather than single-tenant. Whereasa traditional single-tenant application requiresa dedicated set o resources to ulll theneeds o just one organization, a multitenantapplication can satisy the needs o multipletenants (companies or departments within acompany, etc.) using the hardware resources andstaf needed to manage just a single sotwareinstance (Figure 1).

Figure 1: A multitenant application cost-eciently shares

a single stack o resources to satisy the needs o multipleorganizations.

enants using a multitenant service operatein virtual isolation rom one another:Organizations can use and customize anapplication as though they each have a separateinstance, yet their data and customizationsremain secure and insulated rom the activity oall other tenants. Te single application instanceefectively morphs at runtime or any particulartenant at any given time.

Multitenancy is an architectural approach thatpays dividends to both application providersand users. Operating just one applicationinstance or multiple organizations yieldstremendous economy o scale or the provider.Only one set o hardware resources is necessaryto meet the needs o all users, a relativelysmall, experienced administrative staf caneciently manage only one stack o sotwareand hardware, and developers can build andsupport a single code base on just one platorm(operating system, database, etc.) rather thanmany. Te economics aforded by multitenancyallow the application provider to, in turn,


5/16

WHITEPAPER


ofer the service at a lower cost to customers.Everyone involved wins.

Some interesting side benets o multitenancyare improved quality, user satisaction, andcustomer retention. Unlike single-tenantapplications, which are isolated silos deployed

outside the reach o the application provider, amultitenant application is one large communitythat is hosted by the provider itsel. Tis designshit lets the provider gather operationalinormation rom the collective user population(which queries respond slowly, what errorshappen, etc.) and make requent, incrementalimprovements to the service that benet theentire user community at once.

wo additional benets o a multitenantplatorm-based approach are collaborationand integration. Because all users run allapplications in one space, it is easy to allow any

user o any application varied access to specicsets o data. Tis capability greatly simplies theefort necessary to integrate related applicationsand the data they manage.

Comparing Raw Cloud Computing and

PaaSRaw computing clouds are machine-centricservices that provide on-demand inrastructureas a service (IaaS) or the deployment oapplications. Such clouds provide little morethan the computing power and storage capacityneeded to execute virtual servers that comprise

an application. Some SaaS vendors lookingor a quick go-to-market strategy avoid thechallenges o developing a true multitenantsolution and choose to deliver single-tenantinstances via IaaS.

Platorm as a service (PaaS) such as Force.comis an application-centric approach thatabstracts the concept o servers altogether.PaaS lets developers ocus on core applicationdevelopment rom day one and to deployan application with the push o a button.

Te provider never needs to worry aboutmultitenancy, high availability, load balancing,

scalability, system backups, operating systempatches and security, and other similarinrastructure-related concernsall theseservices are delivered as the S in PaaS.

Metadata-Driven ArchitecturesMultitenancy is practical only when itcan support applications that are reliable,customizable, upgradeable, secure, and ast.But how can a multitenant application alloweach tenant to create custom extensions to

standard data objects and entirely new customdata objects? How will tenant-specic data bekept secure in a shared database so one tenantcant see another tenants data? How can onetenant customize the applications interace andbusiness logic in real time without afecting the

unctionality or availability o the application orall other tenants? How can the applications codebase be patched or upgraded without breakingtenant-specic customizations? And how willthe applications response time scale as tens othousands o tenants subscribe to the service?

Its dicult to create a statically compiledapplication executable that can meet theseand other unique challenges o multitenancy.Inherently, a multitenant application must bedynamic in nature, or polymorphic, to ulll theindividual expectations o various tenants andtheir users.

For these reasons, multitenant applicationdesigns have evolved to use a runtime enginethat generates application components rommetadatadata about the application itsel. Ina well-dened metadata-driven architecture(Figure 2), there is a clear separation o thecompiled runtime engine (kernel), applicationdata, the metadata that describes the baseunctionality o an application, and themetadata that corresponds to each tenants dataand customizations. Tese distinct boundariesmake it possible to independently update thesystem kernel, modiy the core application, or

customize tenant-specic components, withvirtually no risk o one afecting the others.

Figure 2: A metadata-driven application had clear separation

between the runtime engine, data, common applicationmetadata, and tenant-specic metadata.


6/16

WHITEPAPER


New Challenges and Emerging SolutionsAttempting to weave multitenancy throughoutthe abric o an applications core logic andits underlying inrastructure is a complexundertaking. Building metadata-driven,multitenant applications rom scratch without

any prior experience is destined to be a time-consuming and error-prone efort. In the end,many would-be SaaS providers struggle tosucceed in building multitenant applicationsand end up wasting valuable time that couldhave been spent ocused on the innovation ocore application unctionality and eatures.

One problem is that traditional applicationdevelopment rameworks and platorms are notequipped to handle the special needs o modernInternet applications. As a result, new typeso platorms are emerging to help simpliy thedevelopment and deployment o multitenant

applications.Force.com is the rst and most mature general-purpose, multitenant, Internet applicationdevelopment platorm available today. Teremaining sections o this paper explain specicdetails about the technical design o Force.comso you can better understand its capabilities.

Force.com Platorm Architecture OverviewForce.coms optimized metadata-drivenarchitecture delivers extraordinary perormance,scalability, and customization or on-demand,multitenant applications (Figure 3).

Figure 3: Force.coms metadata-driven architecture optimallygenerates virtual application components at runtime.

In Force.com, everything exposed to developersand application users is internally represented

as metadata. Forms, reports, work ows, useraccess privileges, tenant-specic customizationsand business logic, even the denitions ounderlying data tables and indexes, are allabstract constructs that exist merely as metadatain Force.coms Universal Data Dictionary

(UDD). For example, when a developer isbuilding a new custom application and denesa custom table, lays out a orm, or writes someprocedural code, Force.com does not create anactual table in a database or compile any code.Instead,Force.com simply stores metadata thatthe platorms engine can use to generate thevirtual application components at runtime.

When someone wants to modiy or customizesomething about the application, all thatsrequired is a simple non-blocking update to thecorresponding metadata.

Because metadata is a key ingredient o

Force.com applications, the platorms runtimeengine must optimize access to metadata;otherwise, requent metadata access wouldprevent the platorm rom scaling. With thispotential bottleneck in mind, Force.com usesmetadata caches to maintain the most recentlyused metadata in memory, avoid perormancesapping disk I/O and code recompilations, andimprove application response times.

Force.com stores the application data or allvirtual tables in a ew large database tables thatserve as heap storage. Te platorms enginethen materializes virtual table data at runtime

by considering corresponding metadata.o optimize access to data in the systemslarge tables, Force.coms engine relies on aset o specialized pivot tables that maintaindenormalized data or various purposes such asindexing, uniqueness, relationships, etc.

Force.coms data processing engine helpsstreamline the overhead o large data loads andonline transaction processing applications bytransparently perorming data modicationoperations in bulk. Te engine has built-in aultrecovery mechanisms that automatically retrybulk save operations ater actoring out records

that cause errors.

o urther hone application response times,the platorm employs an external search servicethat optimizes ull-text indexing and searches.As applications update data, the search servicesbackground processes asynchronously updatetenant- and user-specic indexes in near realtime. Tis separation o duties between theapplication engine and the search servicelets platorm applications eciently processtransactions without the overhead o text index


7/16

WHITEPAPER


updates, and at the same time quickly provideusers with accurate search results.

As Force.coms runtime application generatordynamically builds applications in response tospecic user requests, the engine relies heavilyon its multitenant-aware query optimizer

to execute internal operations as eciently aspossible. Te query optimizer considers whichuser is executing a given application unction,and then, using related tenant-specic metadatamaintained in the UDD along with internalsystem pivot tables, builds and executes dataaccess operations as optimized database queries.

Now that you have a general idea o the keyarchitecture components that make up theunderlying mechanisms o Force.com, theollowing sections explain the structure andpurpose o various internal system elements inmore detail.

Force.com Data Defnition and StorageRather than attempting to manage a vast, ever-changing set o actual database structures onbehal o each application and tenant, theForce.com storage model manages virtualdatabase structures using a set o metadata, data,and pivot tables, as illustrated in Figure 4.

Figure 4: Force.coms data denition and storage model consistso a set o metadata, data, and pivot tables that allow or

unctional access to the actual data o virtual tables.

When organizations create custom applicationobjects (i.e., custom tables), the UDD keepstrack o metadata concerning the objects, theirelds, relationships, and other object denitioncharacteristics. Meanwhile, a ew large databasetables store the structured and unstructureddata or all virtual tables, and a set o related,

specialized pivot tables maintain denormalizeddata that makes the combined data setextremely unctional.

Figure 5 is a simplied entity-relationship (ER)diagram o three core Force.com metadata anddata structures that enable this approach: the

Objects, Fields, and Data tables.

Note: For brevity and clarity, the actual nameso Force.com system tables and columns are notnecessarily cited in this paper.

The Objects Metadata TableTe Objects metadata table stores inormationabout the custom objects (a.k.a. tables orentities) that an organization denes or anapplication, including a unique identier oran object (ObjID), the organization (OrgID)that owns the object, and the name given to theobject (ObjName).

The Fields Metadata TableTe Fields metadata table stores inormationabout the custom elds (a.k.a. columns orattributes) that an organization denes orcustom objects, including a unique identieror a eld (FieldID), the organization (OrgID)that owns the encompassing object, the objectthat contains the eld (ObjID), the name othe eld (FieldName), the elds datatype, aBoolean value to indicate i the eld requiresindexing (IsIndexed), and the position othe eld in the object relative to other elds(FieldNum).

Figure 5: Force.com uses metadata in the Objects and Fields

tables to dene application object and elds and to mapcorresponding data stored in the large Data database table.

The Data TableTe Data table stores the application-accessible

data that maps to all custom objects and theirelds, as dened by metadata in Objects andFields. Each row includes identiying eldssuch as a global unique identier (GUID),the organization that owns the row (OrgID),and the encompassing object identier(ObjID). Each row in the Data table also hasa Name eld that stores a natural name orcorresponding object instances; or example,an Account object might use Account Name,a Case object might use Case Number, and


8/16

WHITEPAPER


so on. Te Value0 ... Value500 columns storeapplication data that maps to the objects andelds declared in the Objects and Fields tables,respectively; all ex columns use a variable-length string datatype so that they can storeany structured type o application data (strings,numbers, dates, etc.).

Custom elds can use any one o a numbero standard structured datatypes such as text,number, date, and date/time as well as specialuse structured datatypes such as picklist(enumerated eld), autonumber (auto-incremented, system-generated sequencenumber), ormula (read-only derived value),master-detail relationship (oreign key),checkbox (Boolean), email, URL, and others.Custom elds can also be required (not null)and have custom validation rules (or example,one eld must be greater than another eld),both o which are enorced by the platormsapplication server.

When an organization declares or modies acustom application object, Force.com managesa row o metadata in the Objects table thatdenes the object. Likewise, or each customeld, Force.com manages a row in the Fieldstable, including metadata that maps the eldto a specic ex column in the Data table orthe storage o corresponding eld data. BecauseForce.com manages object and eld denitionsas metadata rather than actual databasestructures, the platorm can tolerate multitenantapplication schema maintenance activities

without blocking the concurrent activity oother tenants and users.

No two elds o the same object can map tothe same ex column (slot) in the Data tableor storage; however, a single ex column canmanage the inormation o multiple elds, aslong as each eld stems rom a diferent object.

Figure 6: A single ex column can store various types o data

that originate rom attributes o diferent objects.

As the simplied representation o the Datatable in Figure 6 shows, ex columns are o auniversal datatype (variable-length string), whichpermits Force.com to share a single ex columnamong multiple elds that use various structureddatatypes (strings, numbers, dates, etc.).

Force.com stores all ex column data using acanonical ormat and uses underlying databasesystem datatype-conversion unctions (e.g.,

O_NUMBER, O_DAE, O_CHAR), asnecessary, when applications read data rom and

write data to ex columns.

Although not shown in Figure 5, the Datatable also contains other columns. For example,there are our columns to manage auditingdata, including when and which user created anobject instance (row), and when and which userlast modied an object instance. Te Data tablealso contains an IsDeleted column that Force.com uses to indicate when an object instancehas been deleted.

The Clobs TableForce.com supports the declaration o elds

as character large objects (CLOBs) to permitthe storage o long text elds up to 32,000characters. For each row in the Data table thathas a CLOB, Force.com stores the CLOB out-o-line in a pivot table called Clobs, which thesystem can join with corresponding rows in theData table as necessary.

Note: Force.com also stores CLOBs in indexedorm outside the database or ast text searches.See Section 9 or more inormation aboutForce.coms text search engine.

The Indexes Pivot Tableraditional database systems rely on indexes toquickly locate specic rows in a database tablethat have elds matching a specic condition.However, it is not practical to create nativedatabase indexes or the ex columns o theData table because Force.com is likely usinga single ex column to store the data o manyelds that have varying structured datatypes.Instead, Force.com manages an index o theData table by synchronously copying eld datamarked or indexing to an appropriate columnin a pivot table called Indexes, as depicted in asimplied ER diagram (Figure 7).

Te Indexes table contains strongly typed,indexed columns such as StringValue,NumValue, and DateValue that Force.comuses to locate eld data o the correspondingdatatype. For example, Force.com would copy astring value in a Data table ex column to theStringValue eld in Indexes, a date value to theDateValue eld, etc. Te underlying indexeso the Indexes table are standard non-uniquedatabase indexes. When an internal system queryincludes a search parameter that reerences astructured eld in a custom object, the platorms


9/16

WHITEPAPER


query optimizer uses the Indexes table to helpoptimize associated data access operations.

Figure 7: Force.com uses a pivot table to index data stored inex columns.

Note: Force.com can handle searches acrossmultiple languages because the platormsapplication servers use a case-olding algorithmthat converts string values to a universal, case-insensitive ormat. Te StringValue columno the Indexes table stores string values in

this ormat. At runtime, the query optimizerautomatically builds data access operations sothat the optimized SQL statement lters onthe corresponding case-olded StringValuethat corresponds to the literal provided in thesearch request.

The UniqueFields Pivot TableForce.com lets an organization indicate whena eld in an object must contain unique values(case-sensitive or case-insensitive). Consideringthe arrangement o the Data table and sharedusage o the Value columns or custom elddata, it is not practical to create unique database

indexes or the table (similar to the problemdiscussed in the previous section or non-unique indexes).

o support uniqueness or custom elds,Force.com uses the pivot table calledUniqueFields; this table is very similarto the Indexes pivot table except that theUniqueFields tables underlying databaseindexes enorce uniqueness. When anapplication attempts to insert a duplicate valueinto a eld that requires uniqueness, or anadministrator attempts to enorce uniquenesson an existing eld that contains duplicate

values, Force.com relays an appropriate errormessage to the application.

The Relationships Pivot TableForce.com provides relationship datatypesthat an organization can use to declarerelationships (reerential integrity) amongapplication objects. When an organizationdeclares an objects eld with a relationshiptype, the platorm maps the eld to a Valueeld in the Data table, and then uses this eldto store the ObjID o a related object.

o optimize join operations, Force.commaintains a pivot table called Relationships, asdepicted in Figure 8.

Figure 8: Te Relationship table helps optimize object joins.

Te Relationships index table has twounderlying database unique composite indexes(OrgID+GUID, and OrgID+ObjID+RelationID+argetObjID) that allow or ecient objecttraversals in either direction, as necessary.

The FallbackIndex Table

In rare circumstances, the platorms externalsearch engine can become overloaded orotherwise unavailable, and may not be able torespond to a search request in a timely manner.Rather than returning a disappointing error toa user that has requested a search, the platormsapplication server alls back to a secondary searchmechanism to urnish reasonable search results.

A all-back search is implemented as a directdatabase query with search conditions thatreerence the Name eld o target applicationobjects. o optimize global object searches(searches that span objects) without having to

execute potentially expensive union queries,Force.com maintains a pivot table calledFallbackIndex that records the Name o allobjects. Updates to FallbackIndex happensynchronously, as transactions modiy objects,so that all-back searches always have access tothe most current database inormation.

The NameDenorm TableTe NameDenorm table is a lean data tablethat stores the ObjID and Name o each objectinstance that is in the Data table. When anapplication needs to provide a list o hyperlinksto object instances involved in a parent/child

relationship, Force.com uses the NameDenormtable to execute a relatively simple query thatretrieves the Name o each reerenced objectinstance or display as part o a hyperlink.

History Tracking TableForce.com easily provides turnkey history trackingor any eld. When an organization enables auditingor a specic eld, the system asynchronouslyrecords inormation about the changes made to theeld (old and new values, change date, etc.) using aninternal pivot table as an audit trail.


10/16

WHITEPAPER


Partitioning o Data and MetadataAll Force.com data, metadata, and pivot tablestructures, including underlying databaseindexes, are physically partitioned by OrgID(by tenant) using native database partitioningmechanisms. Data partitioning is a proventechnique that database systems provide tophysically divide large logical data structuresinto smaller, more manageable pieces.Partitioning can also help to improve theperormance, scalability, and availability o alarge database system such as a multitenantenvironment. For example, by denition, everyForce.com application query targets a specictenants inormation, so the query optimizerneed only consider accessing data partitionsthat contain a tenants data rather than an entiretable or indexthis common optimization is

sometimes reerred to as partition pruning.

Application Development, Logic, and

ProcessingForce.com supports two diferent waysto create custom applications and theirindividual components: declaratively, usingthe native platorm application ramework,and programmatically, using applicationprogramming interaces (APIs). Te ollowingsections explain more about each approach andrelated application development topics.

The Application Framework

Developers can declaratively build customForce.com applications using the nativeForce.com application ramework. Te platormsnative point-and-click interace supports all acetso the application development process, includingthe creation o an applications data model(custom objects and their elds, relationships, etc.),security and sharing model (users, organizationhierarchies, proles, etc.), user interace (screenlayouts, data entry orms, reports, etc.), as well aslogic and work ow.

Force.com application ramework userinteraces are easy to build because theres

no coding involved. Behind the scenes, theysupport all the usual data access operations,including queries, inserts, updates, and deletes.Each data manipulation operation perormedby native platorm applications can modiy oneobject at a time, and automatically commit eachchange in a separate transaction.

Force.coms native integrated developmentenvironment (IDE) provides easy access tomany built-in platorm eatures that makeit easy to implement common application

unctionality without writing complicatedand error-prone code. Such eatures includedeclarative workows, encrypted/masked elds,

validation rules, ormula elds, roll-up summaryelds, and cross-object validation rules.

A workow is a predened action triggeredby the insert or update o an object instance(row). A workow can trigger a task, emailalert, update a data eld, or send a message.

Workow rules speciy the criteria thatdetermine when to trigger a workow action.A workow can be set to re immediately orset to operate at a subsequent interval aterthe triggering event. For example, a developermight declare a workow that, immediatelyater a record is updated, automatically updatesthe rows Status eld to Modied and thensends a template email alert to a supervisor. All

workow operations occur within the contexto the transaction that triggers the workow. I thesystem rolls back a transaction, all related workowoperations that were executed also roll back.

When dening a text eld or an object thatcontains sensitive data, developers can easilycongure the eld so that Force.com encryptsthe corresponding data and optionally usesan input mask to hide screen inormationrom prying eyes. Force.com encrypts eldsusing AES (Advanced Encryption Standard)algorithm 128-bit keys.

A declarative validation rule is a simple way oran organization to enorce a domain integrityrule without any programming. For example,the rst screen capture in Figure 9 illustrateshow easy it is to use the Force.com IDE todeclare a validation rule that makes sure thata LineItem objects Quantity eld is alwaysgreater than zero.

A ormula eld is a declarative eature o theForce.com application ramework that makesit easy to add a calculated eld to an object. Forexample, the second screen capture in Figure9 also shows how a developer can use a simple

IDE orm to add a eld to the LineItem objectto calculate a Lineotal value.

A roll-up summary eld is a cross-object eldthat makes it easy to aggregate child eldinormation in a parent object. For example, thenal screen capture in Figure 9 shows how touse the IDE to create an Orderotal summaryeld in the SalesOrder object based on theLineotal eld o the LineItem object.

Note: Internally, Force.com implementsormula and roll-up summary elds using


11/16

WHITEPAPER


native database eatures and ecientlyrecalculates values synchronously as part oongoing transactions.

Metadata and Web Services APIs

Force.com also provides programmatic APIsor building applications. Tese APIs arecompatible with SOAP-based developmentenvironments, including Visual Studio .NE(C#) and Apache Axis (Java and C++).

Applications can leverage Force.com APIsto integrate with other environments. Forexample, applications can leverage APIs toaccess data in other systems, build mashups thatcombine inormation originating rom multipledata sources, include external systems as parto an application process, or build at clients tointeract with the Force.com Platorm database

management system.

Figure 9: Declaring validation rules, ormula elds, and

rollup summary elds are simple conguration steps ratherthan complex coding tasks.

Te Force.com Metadata API is useul ormanaging application componentsto createand modiy the metadata that corresponds tocustom object denitions, page layouts, workows, etc. o create, retrieve, update, or deleteobject instances (rows o data), applications canuse the Force.com Web Services API.

o access the Force.com Web service,developers rst download a Web ServiceDescription Language (WSDL) le.

Te development platorm then uses theWSDL le to generate an API to access theorganizations corresponding Force.com Webservice (data model).

Tere are two types o Force.com WSDL les.An Enterprise WSDL le is or developers whoare building organization-specic applications.An Enterprise WSDL le is a strongly typedrepresentation o an organizations datamodel. It provides inormation about theorganizations schema, data types, and elds tothe development environment, allowing or atighter integration between it and the Force.com

Web service. An Enterprise WSDL changesi custom elds or custom objects are added to,renamed, or removed rom an organizationsapplication schema. In contrast, a Partner

WSDL le is or salesorce.com partners thatare developing client applications or multipleorganizations. As a loosely typed representationo the Force.com object model, a Partner

WSDL provides an API that is useul oraccessing data within any organization.

Bulk Processing with API Callsransaction-intensive applications generateless overhead and perorm much better whenthey combine and execute repetitive operationsin bulk. For example, contrast two ways anapplication might load many new instances oan object. An inecient approach would be touse a routine with loop that inserts individualobject instances, making one API call oreach insert operation. A much more ecientapproach would be to create an array o objectinstances and have the routine insert all o them

with a single API call.

Applicable Force.com Web Services API callssuch as create(), update(), and delete() supportbulk operations. For maximum eciency, theplatorm implicitly bulk processes all internalsteps related to an explicit bulk operation, asillustrated in Figure 10.


12/16

WHITEPAPER


Figure 10: Force.coms bullk processing engine executes each

internal step related to a bulk operation as a bulk operation

itsel and automatically does a best efort to continue pastrows that cause exceptions.

Figure 10 also illustrates the uniquemechanisms o Force.coms bulk processingengine that can account or isolated aultsencountered during any step along the way.

When a bulk operation starts in partial savemode, the engine identies a known start stateand then attempts to execute each step in theprocess (bulk validate eld data, bulk re pre-triggers, bulk save records, etc.). I the enginedetects errors during any step, the engine rollsback ofending operations and all side efects,removes the rows that are responsible or theaults, and continues, attempting to bulk processthe remaining subset o rows. Tis processiterates through each stage o the process untilthe engine can commit a subset o rows withoutany errors. Te application can examine a returnobject to identiy which rows ailed and whatexceptions they raised.

Note: At the discretion o the application, anall-or-nothing mode is also available or bulkoperations. Also, the execution o triggersduring a bulk operation is subject to internalgovernors that restrict the amount o work.

Deletes, Undeletes, and The Recycle BinWhen someone deletes an individual objectinstance (record) rom a custom object,Force.com simply marks the object instanceor deletion by modiying the object instancesIsDeleted eld (in the Data table). Tisefectively places the object in what is known

as the platorms Recycle Bin. Force.comlets users view and restore selected objectinstances rom the Recycle Bin or up to 30days beore permanently removing them romthe internal Data table. Te platorm limitsthe total number o records it maintains or anorganization based on the total number o userlicenses or the organization.

When someone deletes a parent record involvedin a master-detail relationship, Force.comautomatically deletes all related child records,provided that doing so would not break anyreerential integrity rules in place. For example,

when a user deletes a SalesOrder, Force.comautomatically cascades the delete to dependentLineItems. Should someone subsequentlyrestore a parent record rom the Recycle Bin,the platorm automatically restores all childobject instances as well.

In contrast, when someone deletes a reerencedparent record involved in a lookup relationship,Force.com automatically sets all dependent keysto null. I someone subsequently restores theparent record, Force.com automatically restoresthe previously nulled lookup relationshipsexcept or the relationships that were reassignedbetween the delete and restore operations.

Te Recycle Bin also stores dropped elds andtheir data until an organization permanentlydeletes them or 45 days has elapsed, whichever

happens rst. Until that time, the entire eldand all its data is available or restoration.

Data Defnition ProcessingCertain types o modications to the denitiono an object require more than simple UDDmetadata updates. In such cases, Force.comuses ecient mechanisms that help reduce theoverall perormance impact on the platormsmultitenant applications.

For example, consider what happens behindthe scenes when someone modies a columnsdatatype rom picklist to text. Force.com rstallocates a new slot or the columns data, bulk

copies the picklist labels associated with currentvalues, and then updates the columns metadataso that it points to the new slot. While allo this happens, access to data is normal andapplications continue to unction without anynoticeable impact.

As another example, consider what happenswhen someone adds a roll-up summaryeld to a table. In this case, the Force.comasynchronously calculates initial summaries


13/16

WHITEPAPER


in the background using an ecient bulkoperation. While the background calculation ishappening, users that view the new eld receivean indication that the Force.com Platorm iscurrently calculating the elds value.

Internal Query OptimizationsMost modern database systems determineoptimal query execution plans by employinga cost-based query optimizer that considersrelevant statistics about target table and indexdata. However, conventional cost-basedoptimizer statistics are designed or single-tenantapplications and ail to account or the data accesscharacteristics o any given user executing a queryin a multitenant environment. For example, agiven query that targets an object (table) with alarge volume o data would most likely execute

more eciently using diferent execution plansor users with high visibility (a manager that cansee all object instances) versus users with low

visibility (sales people that can only see rowsrelated to themselves).

o provide sucient statistics or determiningoptimal query execution plans in a multitenantplatorm, Force.com maintains a complete seto optimizer statistics (tenant-, group-, anduser-level) or each virtual multitenant object.Statistics reect the number o rows that aparticular query can potentially access, careullyconsidering overall tenant-specic object statistics

(total number o rows owned by the tenant as awhole, etc.) as well as more granular statistics (thenumber o rows that a specic privilege group orend user can potentially access, etc.).

Force.com also maintains other types o statisticsthat prove helpul with particular queries. Forexample, the platorm maintains statistics or allcustom indexes to reveal the total number o non-null and unique values in the corresponding eld,and histograms or picklist elds that reveal thecardinality o each list value.

When existing statistics are not in place or arenot considered helpul, Force.coms optimizer

has a ew diferent strategies it uses to help buildreasonably optimal queries. For example, when aquery lters on the Name eld o an object, theoptimizer can use the FallbackIndex pivot tableto eciently nd requested object instances. Inother scenarios, the optimizer will dynamicallygenerate missing statistics at runtime.

Used in tandem with optimizer statistics,Force.coms optimizer also relies on internalsecurity related tables (Groups, Members,

GroupBlowout, and CustomShare) thatmaintain inormation about the securitydomains o platorm users, including a givenusers group memberships and custom accessrights or objects.

Figure 11: When a request or data happens, Force.comexecutes pre-queries, the results o which the platorms

multitenant-aware query optimizer uses to build andexecute optimal database queries.

Te ow diagram in Figure 11 illustrates whathappens when Force.com intercepts a requestor data that is in one o the large heap tablessuch as Data. Te request might originate romany number o sources, such as a page requestrom an Application Framework application, a

Web services API call, or an Apex script. First,

the platorm executes pre-queries thatconsider the multitenant-aware statistics. Ten,considering the results returned by the pre-queries, the platorm builds an optimal databasequery or execution in the specic setting.

Pre-Query

Selectivity

Measurements Write fnal database access query, orcing ...

User Filter

Low Low ... nested loops join; drive using view o rowsthat the user can see.

Low High ... use o index related to flter.

High Low ... ordered hash join; drive using Data table.High High ... use o index related to flter.

As able 1 shows, Force.com can execute thesame query our diferent ways, depending on

who submits the query and the selectivity o thequerys lter conditions.

Force.com Full-Text Search EngineWeb-based application users have come toexpect an interactive search capability to scan


14/16

WHITEPAPER


the entire or a selected scope o an applicationsdata, return ranked results that are up to date,and do all this with sub-second responsetimes. o provide such robust unctionalityor platorm applications, Force.com uses anarchitecture based on an external search engine,as depicted in Figure 12.

As applications update data in text elds(CLOBs, Name, etc.), a pool o platormbackground processes called indexing serversare responsible or asynchronously updatingcorresponding indexes, which the searchengine maintains outside the core database.

o optimize the indexing process, Force.comsynchronously copies modied chunks o textdata to an internal to-be-indexed table astransactions commit, thus providing a relativelysmall data source that minimizes the amounto data that indexing servers must read romdisk. Te search engine automatically maintainsseparate indexes or each organization (tenant).

Depending on the current load and utilizationo indexing servers, text index updates maynoticeably lag behind actual transactions. oavoid unexpected search results originatingrom stale indexes, Force.com also maintainsan MRU cache o recently updated objectsthat the platorms application servers consider

when materializing ull-text search results. Teplatorm maintains MRU caches on a per-userand per-organization basis to eciently supportpossible search scopes.

Figure 12: Force.com uses an external search engine to

provide ast text searches or multitenant applications.

Force.com optimizes the ranking o recordswithin search results using several diferentmethods. For example, the system considers thesecurity domain o the user perorming a searchand weighs heavier those objects to which thecurrent user has access. Te system can alsoconsider the modication history o a particularobject, and rank more actively updated objectsahead o those that are relatively static. Te user

can choose to weight search results as desired,or example, placing more emphasis on recentlymodied objects.

Apex

Apex is a strongly typed, object-orientedprocedural programming language thatdevelopers can use to declare program variablesand constants and execute traditional owcontrol statements (i-else, loops, etc.), datamanipulation operations (insert, update, upsert,delete), and transaction control operations(setSavepoint, rollback) on behal o Force.comapplications. Apex is similar in many respects to

Java. Developers can build Apex routines thatadd custom business logic to most applicationevents, including button clicks, updates to data,

Web service requests, custom batch services,

and others.Developers can build Apex programs in twodiferent orms: as an anonymous standalonescript that is executed on demand, or as atrigger that automatically executes beore orater a specic database manipulation eventoccurs (insert, update, delete, or undelete). Ineither orm, Force.com compiles Apex codeand stores it as metadata in the UDD. Whenan Apex routine is called or the rst timeby someone in an organization, Force.comsruntime interpreter loads the compiled versiono the program into an MRU cache or that

organization. Tereater, when any user romthe same organization requires use o the sameroutine, Force.com can save memory and avoidthe overhead o recompiling the program againby sharing the ready-to-run program that isalready in memory.

Apex is much more than just another procedurallanguage. Apex is an integral Force.comcomponent that helps the platorm deliverreliable multitenant applications. For example,Force.com automatically validates all embeddedSorce Object Query Language (SOQL)and Sorce Object Search Language (SOSL)

statements within an Apex class to preventcode that would otherwise ail at runtime. Teplatorm then maintains corresponding objectdependency inormation or valid Apex classesand uses this inormation to prevent changesto metadata that would otherwise breakdependent applications.

Many Apex standard classes and systemstatic methods provide simple interaces tounderlying platorm eatures. For example, thesystem static DML methods such as insert,


15/16

WHITEPAPER


update, and delete have a simple Booleanparameter that developers can use to indicatethe desired bulk processing option (all ornothing, or partial save); these methods alsoreturn a result object that the calling routinecan read to determine which records wereunsuccessully processed and why. Other exampleso the direct ties between Apex and Force.complatorm eatures include the built-in Apex emailclasses, HP (RESul) services classes, and

XmlStream classes, just to name a ew.

o prevent malicious or unintentionalmonopolization o shared, multitenant platormresources, Force.com has an extensive set ogovernors and resource limits associated withApex code execution. For example, Force.comclosely monitors the execution o an Apex scriptand limits how much CPU time it can use, howmuch memory it can consume, how many queriesand DML statements it can execute, how manymath calculations it can perorm, how manyoutbound Web service calls it can make, andmuch more. Individual queries that the platormsoptimizer regards as too expensive to executethrow a runtime exception to the caller. Althoughsuch limits might sound somewhat restrictive,they are necessary to protect the overall scalabilityand perormance o the shared platorm orall concerned applications. In the long term,these measures help to promote better codingtechniques among platorm developers and create

a better experience or everyone. For example, adeveloper that initially tries to code a loop thatineciently updates a thousand rows one rowat a time will receive runtime exceptions due toresource limits and then begin using Force.comsecient bulk processing API calls.

o urther avoid potential platorm problemsintroduced by poorly written applications, thedeployment o a new production applicationis a process that is strictly managed. Beorean organization can transition a new customapplication rom development to productionstatus, salesorce.com requires unit tests that

validate the unctionality o the applications Apexroutines. Submitted unit tests must cover no lessthan 75 percent o the applications source code.Salesorce.com executes submitted unit tests in theForce.com Sandbox environment to ascertain i theapplication will adversely afect the perormanceand scalability o the multitenant population atlarge. Te results o an individual unit test indicatebasic inormation such as the total number o linesexecuted as well as specic inormation about thecode that was not executed by the test.

Once an application is certied or productionby salesorce.com, the deployment process orthe application consists o a single transactionthat copies all the applications metadata intoa production Force.com instance and rerunsthe corresponding unit tests. I any part othe process ails, Force.com simply rolls backthe transaction and returns exceptions to helptroubleshoot the problem.

Note: Salesorce.com reruns the unit tests orevery application with each development releaseo the platorm to pro-actively learn whether newplatorm eatures and enhancements break anyexisting applications.

Ater a production application is live, Force.comsbuilt-in perormance proler automaticallyanalyzes and provides associated eedback to

administrators. Perormance analysis reportsinclude inormation about slow queries, datamanipulations, and sub-routines that developerscan review and use to tune applicationunctionality. Te platorm also logs and returnsinormation about runtime exceptions toadministrators to help debug their applications.

Historical StatisticsYears o experience have transormed Force.cominto an extremely ast, scalable, and reliablemultitenant Internet application platorm. Asan illustration o Force.coms proven capabilityto support Internet-scale applications, consider

Figure 13. Specically notice that, over time,average page response time has decreased orheld steady (a measure o perormance) whileaverage transaction volume has concurrentlyincreased (a measure o scalability).

Figure 13: Platorm perormance and scalability have

consistently improved each year as Force.com maturesand evolves.

For more platorm data such as plannedmaintenance, historical inormation ontransaction volume and speed, etc., visit trust.salesorce.com, the Force.com communityshome or real-time inormation about systemperormance and security.


16/16

Copyright 2008, salesforce.com, inc. All rights reserved. Salesforce.com and the no software logo are registered tr ademarks of salesforce.com, iand salesforce.com ownsother registered and unregistered trademarks. Other names used herein may be trademarks of their respective owner

Corporate HeadquartersThe Landmark @ One Market

Suite 300

San Francisco, CA, 94105

United States

1-800-NO-SOFTWARE

www.salesforce.com

Latin America+1-415-536-4606

Japan+81-3-5785-8201

Asia/Pacic+65-6302-5700

Europe, Middle East & Africa+4121-6953700

For More Inormation

Contact your account executive to learn

how we can help you accelerate your

SaaS success.

ConclusionsPlatorm as a service (PaaS) and sotware as a service (SaaS) are contemporary sotware applicationdevelopment and delivery models that an increasing number o organizations are using to improvetheir time to market, reduce capital expenditures, and improve overall competitiveness in achallenging global economy. Internet-based, shared computing platorms are attractive becausethey let businesses quickly access hosted, managed sotware assets on demand and altogether avoidthe costs and complexity associated with the purchase, installation, conguration, and ongoingmaintenance o an on-premises data center and dedicated hardware, sotware, and accompanyingadministrative staf.

Te most successul on-demand SaaS/PaaS company at the oreront o these paradigm shitsis salesorce.com, which recently received the distinction o being the rst on-demand sotware

vendor to be added to the S&P 500 Index. Stepping out rom underneath the enormously successulsalesorce.com CRM SaaS application, Force.com is a generalized Internet application developmentand delivery platorm on which individual enterprises and service providers have built all types ocustom business applications, including supply chain management, billing, accounting, compliancetracking, human resource management, and claims processing applications. Te platorms metadata-driven architecture enables anyone to eciently build and deliver sophisticated, customizable,mission-critical, Internet-scale multitenant applications. Using standards-based Web service APIsand native platorm development tools, Force.com developers can easily build all components oa Web-based application, including the applications data model (tables, relationships, etc.), userinterace (data entry orms, reports, etc.), business logic (workows, validations, etc.), integrations

with other applications, and more.

Over the past 10 years, salesorce.com engineers have optimized all layers o the Force.com platormor multitenancy, with eatures that let the platorm deliver unprecedented Internet scalability to theheight o 170 million transactions daily. Platorm eatures such as the bulk data processing API, theApex programming language, an external ull-text search engine, and its unique query optimizerhelp make multitenant platorm applications highly ecient and scalable with little or no thoughtrom developers.

Salesorce.coms managed approach or the deployment o production applications ensurestop-notch perormance, scalability, and reliability or all dependent applications. Additionally,

salesorce.com continually monitors and gathers operational inormation rom Force.comapplications to help drive incremental improvements and new platorm eatures that immediatelybenet existing and new applications.

force.com multi tenancy wp 101508

Documents