Accessing on-premise and off-premise datastores that are organized using different application schemas

Techniques are disclosed for accessing on-premise and off-premise datastores organized using different application schemas. An interface serves requests, from a tenant, by accessing either the on-premise datastore or the off-premise datastore. The interface receives a request for a particular data set. Based on the request itself, the interface selects either the on-premise datastore or the off-premise datastore to retrieve the particular data set. The interface retrieves the particular data set from the selected datastore without attempting to retrieve the particular data set from the non-selected datastore. The interface transmits and/or presents the particular data set.

INCORPORATION BY REFERENCE; RELATED APPLICATIONS

This application is related to U.S. patent application Ser. No. 14/973,256, filed Dec. 17, 2015, which is hereby incorporated by reference.

This application is also related to U.S. patent application Ser. No. 13/631,815, filed Sep. 28, 2012, now published as U.S. Patent Application Publication No. 2014/0095530, published Apr. 3, 2014, which claims priority to U.S. Provisional Patent Application No. 61/707,726, filed Sep. 28, 2012; and U.S. Provisional Patent Application No. 61/707,726, filed Sep. 28, 2012; all of which are hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure relates to multi-tenant, cloud-based hardware and/or software services. In particular, the present disclosure relates to accessing on-premise and off-premise datastores that are organized using different application schemas.

BACKGROUND

In a multi-tenant, cloud-based environment, multiple tenants use one or more applications executing on shared computing resources. The shared computing resources may be located in data centers off the tenant's own premises (referred to herein as an “off-premise environment”).

In some cloud-based environments, a separate instance of a server is created for each tenant, either physically or via virtualization. Each instance of a server implements separate application code and application schema for each tenant.

In other cloud-based environments, a shared instance of a server is created for multiple tenants. The shared instance of the server implements the same application code for multiple tenants. The shared instance of the server also implements a common application schema for the tenants. Data sets for the multiple tenants are organized using the common application schema and indexed by tenant identifier (ID).

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in a different embodiment. In some examples, well-known structures and devices are described with reference to a block diagram form in order to avoid unnecessarily obscuring the present invention.1. GENERAL OVERVIEW2. MULTI-DATASTORE ARCHITECTUREa. OFF-PREMISE ENVIRONMENTb. ON-PREMISE ENVIRONMENTc. SINGLE INTERFACE FOR OFF-PREMISE AND ON-PREMISE ENVIRONMENTS3. ACCESSING ON-PREMISE AND OFF-PREMISE DATASTORES THAT ARE ORGANIZED USING DIFFERENT APPLICATION SCHEMAS4. EXAMPLE EMBODIMENTS5. CLOUD ENVIRONMENTS6. MISCELLANEOUS; EXTENSIONS7. HARDWARE OVERVIEW

1. GENERAL OVERVIEW

One or more embodiments include an interface serving requests, from a tenant, by accessing either an on-premise datastore or an off-premise datastore. The on-premise datastore may be a traditional datastore that is implemented using an on-premise application. The off-premise datastore may be a cloud-based datastore that is implemented using a cloud-based application. As an example, a single interface, serving datastores in both environments, allows an entity to use the single interface to access data sets without fully migrating the data sets from an on-premise environment to the off-premise environment. The entity may partially migrate some data sets and/or applications to the off-premise environment, while maintaining some data sets and/or applications at the on-premise environment.

One or more embodiments include an application selecting one of an off-premise datastore or an on-premise datastore to serve a request based on the request itself. The application executes an interface at an (a) off-premise environment corresponding to the off-premise datastore or (b) an on-premise environment corresponding to the on-premise datastore. The interface, executed by an application, receives a request for a particular data set. The request does not include a specification of which datastore is to be accessed. The application selects one of the datastores based on the request. The application retrieves the particular data set from the selected datastore without attempting to retrieve the particular data set from the non-selected datastore. The application transmits and/or presents the particular data set at the interface.

FIG. 1Aillustrates a multi-datastore architecture in accordance with one or more embodiments. The multi-datastore architecture (including modifications thereof) may be used in serving data from multiple datastores which may be distributed across an on-premise environment and an off-premise environment. The multi-datastore architecture is illustrated inFIG. 1Aas a system of components, referred to as system102.

In one or more embodiments, system102may include more or fewer components than the components illustrated inFIG. 1A. The components illustrated inFIG. 1Amay be local to or remote from each other. The components illustrated inFIG. 1Amay be implemented in software and/or hardware and may be distributed over one or more applications and/or machines. Operations described with respect to one component may instead be performed by another component.

In one or more embodiments, a tenant (such as tenant112and/or tenant114) is a corporation, organization, enterprise or other entity that accesses a shared computing resource, such as application116. In an embodiment, tenant112and tenant114are independent from each other. A business or operation of tenant112is separate from a business or operation of tenant114. As described below, data and operations associated with different tenants may be isolated from one another.

In one or more embodiments, off-premise environment104includes one or more devices that are remote from the premises of tenants112-114. Off-premise environment104may include, for example, one or more data centers located remote to corporate offices. Off-premise environment104is accessed via a public network, such as the Internet, using a communications protocol, such as Hypertext Transfer Protocol (HTTP). In an embodiment, off-premise environment104includes hardware executing application116and datastores organized using application schemas122-124.

In an embodiment, off-premise environment104may refer to a cloud environment that is accessed by multiple tenants112-114. The cloud environment includes a centralized pool of resources that are shared amongst the multiple tenants112-114. Examples of resources include a processor, a server, a data storage, a virtual machine, and a platform. Client devices of tenants112-114may independently request computing services, such as server time and network storage, as needed. The resources assigned to each particular client device may be scaled up or down based on the computing services requested by the particular client device. The resources assigned to each particular client device may also be scaled up or down based on the aggregated demand for computing services requested by all client devices.

In an embodiment, data sets stored at off-premise environment104that correspond to different tenants are isolated from each other. As illustrated inFIG. 1A, data set132corresponds to tenant112, and data set134corresponds to tenant114. Tenant isolation may be achieved using, for example, tenant identifiers (IDs), application schemas122-124, and/or tenant-specific overlay networks. Examples of operations executed within a cloud environment to manage resources and implement tenant isolation are described below in Section 5, titled “Cloud Environments.”

Continuing withFIG. 1A, application116includes executable code and/or logic that is configured to execute operations, such as retrieving and/or accessing one or more data sets132-134. Application116is a shared computing resource available to tenants112-114. Application116executes on hardware (such as one or more servers and/or computers) located in an off-premise environment104.

In one or more embodiments, base schema118indicates the names of data fields, the number of data fields, the number of tables, and other aspects of a default datastore that is used by application116. Base schema118indicates the basic features and/or functions of a default datastore that is used by application116. Base schema118is shared amongst tenants112-114and is modified and/or customized to form application schemas122-124.

In one or more embodiments, an application schema (such as application schema122and/or application schema124) indicates the names of data fields, the number of data fields, the number of tables, and other aspects of a particular datastore that is used by application116. The particular datastore corresponds to a particular tenant (such as tenant112). Differences between base schemas and application schemas are further detailed below.

In an embodiment, each data field is associated with a name and a data field identifier (ID). A name of a data field, as referred to herein, is a set of words, text, and/or characters that is displayed at a user interface to reference the data field. As an example, a particular data field may be named, “Date.” A user interface may display a textbox for inputting a value into the particular data field. The user interface may display the name “Date” adjacent to the textbox, to indicate which data field is being modified by user input entered into the textbox. An identifier of a data field, as referred to herein, is a set of words, text, and/or characters that is used by executable code and/or logic of application116to reference the data field. As an example, a particular data field may have the identifier, “1234.” An application may perform certain operations on the particular data field. The application may reference the particular data field by using the identifier, “1234.” Each application schema may have different sets of data fields. A particular application schema may have a data field that overlaps with a data field of another application schema. A particular application schema may have a data field that is unique to the particular application schema and not included in other application schemas derived from a same base schema. Examples of overlapping data fields and unique fields are described in the examples below.

As an example, a data field of application schema122and another data field of application schema124may have a same data field ID but may be referenced by different names. The data field of application schema122and the data field of application schema124, having the same data field ID, may be an overlapping data field of application schema122and application schema124. The same data field ID would indicate that the same operations may be performed, by an application116, on the data field of application schema122and the data field of application schema124. However, the data fields may be referred to using different names. The different names may be, for example, “First Name” and “Given Name,” both referring to a name of an individual.

As another example, a data field with a particular data field ID may exist in application schema122but not in application schema124. The data field with the particular data field ID may be a unique data field to application schema122. The data field may have been added in application schema122through customization of application schema122. But the data field was not added in application schema124.

In an embodiment, application schemas122-124are derived from base schema118. A first set of modifications are made to base schema118to form application schema122, and a second (different) set of modifications are made to base schema118to form application schema124. The first set of modifications may include, for example, modifying a name of a data field already existing in base schema118. The second set of modifications may include, for example, adding a data field for storing data that is applicable to tenant114but not to tenant112. Hence, application schema122and application schema124indicate different names of data fields, different numbers of data fields, different numbers of tables, and/or other differences.

As an example, a base schema may be associated with storing data sets related to vehicles. A first application schema may be associated with pickup trucks. A data field that is applicable to pickup trucks and not already existing in the base schema may be a size of the truck bed. A data field for the size of the truck bed may be added to the base schema to form the first application schema. Meanwhile, a second application schema may be associated with sedans. The size of the truck bed may not be applicable to sedans. Therefore the data field for the size of the truck bed is not included in the second application schema.

In an embodiment, application schemas122-124are used to organize data sets (such as data sets132-134) that are to be accessed by a same application116that is associated with base schema118. As an example, a particular application may be associated with a base schema. The base schema may be associated with storing data sets related to vehicles. A first application schema, derived from the base schema, may be associated with pickup trucks. A second application schema, derived from the base schema, may be associated with sedans. The particular application may be used to access a first data set organized using the first application schema. The particular application may also be used to access a second data set organized using the second application schema.

In an embodiment, application schemas122-124correspond to different datastores. A datastore includes one or more data structures for organizing one or more data sets (such as data set132and/or data set134) using an application schema (such as application schema122and/or application schema124). Examples of data structures include a table, an array, a linked list, a tree, and a container (which is a collection of data structures). The organization of a datastore enables the contents of the datastore to be accessed, managed, and/or updated by a computer.

In an embodiment, various implementations of datastores may be used. Examples of datastores include a database instance, a pluggable database, and a data structure within a database instance, each of which is further described below.

I. Database Instance

In an embodiment, application schemas122-124correspond to different database instances. A database instance is a physical database and includes a set of memory structures and background processes for organizing a data set.

In an embodiment, memory structures of a datastore include a buffer cache, a redo log, and/or a shared pool. A buffer cache stores copies of data blocks currently or recently read from the data set. On a subsequent access request, the cached data blocks may be retrieved from the buffer cache rather than the data set.

A redo log stores redo entries, which describe current or recent changes made to the data set. In case of failure with the database instance and/or the data set, the redo log may be used to restore the most current version of the data set.

A shared pool stores copies of various current or recent program data. The shared pool stores parsed code (such as commands in Structured Query Language (SQL) or Java) for accessing the data set. On subsequent calls to the same code, the parsed code may be re-executed from the shared pool. Additionally or alternatively, the shared pool stores results returned from a query and/or a function. Results include, for example, a subset of a data set that matches criteria of a particular query.

In an embodiment, background processes of a datastore include a background monitoring process, a listener registration process, and a database writer process. A background monitoring process is configured to monitor the database instance and perform process recovery in case a process fails. Process recovery includes freeing up resources that were being used by the failed process, such as releasing database locks. The background monitoring process executes periodically, for example, every 3 seconds.

A listener registration process is configured to register a database instance with a listener. The listener is a server-side process that listens for incoming client connection requests and manages client traffic to the data set. The listener registration process provides the listener with the name and/or identifier of the database instance, and the addresses of service handlers of the database instance. A service handler is a process that serves as a connection point to a data set. The registration information enables the listener to select an appropriate service handler when a client request arrives and forward the client request to the selected service handler.

A database writer process is configured to write contents of a buffer cache to the data set, which may be stored on disk. The database writer process executes periodically and/or on an on-demand basis (such as, when no clean buffer caches are available).

In an embodiment, application schemas122-124correspond to different pluggable databases that execute under one instance, or copy, of a container database. The container database holds the functionality and metadata that applies to all pluggable databases included therein. Each pluggable database includes a separate schema for the corresponding pluggable database. Examples of pluggable databases are described in U.S. patent application Ser. No. 13/631,815, filed Sep. 28, 2012, now published as U.S. Patent Application Publication No. 2014/0095530, published Apr. 3, 2014, which claims priority to U.S. Provisional Patent Application No. 61/707,726, filed Sep. 28, 2012; and U.S. Provisional Patent Application No. 61/707,726, filed Sep. 28, 2012; which are hereby incorporated by reference.

FIG. 1Billustrates an example of multiple pluggable databases executing under one instance of a container database, in accordance with one or more embodiments. As illustrated inFIG. 1B, system100includes tenants112-114, an application116, and container database182. Container database182includes root184, seed186, pluggable database188, and pluggable database190. In one or more embodiments, system100may include more or fewer components than the components illustrated inFIG. 1B. The components illustrated inFIG. 1Bmay be local to or remote from each other. The components illustrated inFIG. 1Bmay be implemented in software and/or hardware and may be distributed over one or more applications and/or machines. Operations described with respect to one component may instead be performed by another component.

In an embodiment, system100operates in an off-premise environment (such as off-premise environment104inFIG. 1A). Application116is a shared computing resource of tenants112-114. Application116accesses container database182to access data sets, of tenant112and/or tenant114, stored at pluggable database188and/or pluggable database190.

In an embodiment, container database182includes metadata that is used for organizing data sets across pluggable database188and pluggable database190. The metadata is stored at root184and/or seed186. Container database182further includes none, one, or more pluggable databases.

In an embodiment, container database182is implemented as a database instance. Container database182includes a set of memory structures (such as a buffer cache, redo log, and shared pool) and background processes (such as a background monitoring process, a listener registration process, and a database writer process).

In an embodiment, root184stores one or more code packages (such as SQL packages, or Procedural Language Extensions to SQL (PL/SQL) packages) common to accessing pluggable database188and pluggable database190. A code package serves as an interface between application116and pluggable databases188-190. The code package declares the types, variables, constants, exceptions, cursors, and subprograms available for use by application116. Root184also stores common users, which are users that may access container database182and all pluggable databases188-190of container database182.

In an embodiment, seed186is a template that container database182uses to generate new pluggable databases188-190. Tenants112-114may not modify seed186. In an embodiment, seed186includes base schema118as the template. As described above, base schema118indicates the names of data fields, the number of data fields, the number of tables, and other aspects of a default datastore that is used by application116. Alternatively (not shown), seed186includes a template that has less data fields than base schema118. Base schema118is derived from seed186and used in a pluggable database (such as pluggable database188and/or pluggable database190).

In an embodiment, a pluggable database (such as pluggable database188and/or pluggable database190) includes specific features for organizing a data set of a tenant (such as tenant112and/or tenant114). Pluggable database188stores a data set of tenant112, and pluggable database190stores a data set of tenant114. Each pluggable database is derived from seed186(or another pluggable database) and modifiable by a tenant. In an embodiment, application schema122is used in pluggable database188, and application schema124is used in pluggable database190. Each of applicable schema122and application schema124is derived from base schema118.

In an embodiment, each pluggable database relies on the set of memory structures (such as a buffer cache, redo log, and shared pool) of container database182. Each pluggable database relies on the background processes (such as a background monitoring process, a listener registration process, and a database writer process) of container database182. Each pluggable database does not have a separate set of memory structures and/or background processes performing the functions of container database182.

III. Data Structure within Database Instance

In an embodiment, application schemas122-124correspond to separate data structures within a same database instance. As described above, a database instance is a physical database, requiring certain memory structures and background processes. Meanwhile, the separate data structures may not necessarily have individual respective memory structures and background processes. As an example, the separate data structures may rely on and share the background monitoring process of the database instance. As another example, the separate data structures may rely on and share the buffer cache of the database instance. The database instance is a datastore of the data structures contained therein. Each data structure is a datastore of a collection of data corresponding to a tenant.

In an embodiment, the separate data structures within a same database instance may be associated with different characteristics. As an example, separate data structures within a same database instance may be separate tables within a same database instance. As an example, the separate data structures may be of different types (such as a relational database, or an object-oriented database). As an example, the separate data structures may be accessed via different processes. A first set of processes, responding to requests received at a first port of a server, may be used to access a first data structure. A second set of processes, responding to requests received at a second port of a server, may be used to access a second data structure. As an example, the separate data structures may be set with different configurations. One example configuration is a caching policy, including for example the size of the cache, and triggers for caching. Another example configuration is an isolation level, which defines how and when changes to a data set made by one operation become visible to other operations. Another example configuration is a logging level, specifying the events (such as warnings, errors, and critical errors) that are to be logged.

In one or more embodiment, an on-premise environment (such as on-premise environment106) includes one or more devices located on a premise corresponding to a particular tenant (such as tenant112). An on-premise environment may include, for example, a private data center of a particular tenant, or an office location of a particular tenant. An on-premise environment includes local computing resources that are accessed via local and/or private networks of a particular tenant.

In an embodiment, each on-premise environment is isolated from other on-premise environments. A tenant may not access an on-premise environment of another tenant. The isolation of an on-premise environment is implemented using a network security system over a private network. The network security system may include a firewall, which blocks unauthorized access to the network. The network security system may also include anti-virus and anti-spyware and intrusion prevention systems, to identify viruses and threats.

In an embodiment, on-premise environment106includes hardware executing application152and a datastore organized using application schema162. Application152and the datastore organized using application schema162are associated with tenant112and are not shared with other tenants. On-premise environment108includes hardware executing application154and a datastore organized using application schema164. Application154and the datastore organized using application schema164are associated with tenant114and are not shared with other tenants.

In an embodiment, an on-premise application is a traditional application that is executed in an on-premise environment. A tenant uses the on-premise application, while concurrently using an off-premise application116. As an example, a tenant may use an on-premise application for a period of time. Subsequently the tenant may desire to use an off-premise application in addition to the on-premise application. The tenant may use the off-premise application in an off-premise environment, without migrating the on-premise application to the off-premise environment.

In an embodiment, application116and applications152-154may be different applications, or may be different functions within a same application. As an example, application116may manage the payroll of tenant112in a payroll application, and application152may manage the benefits of tenant112in a benefits application. As another example, application116and application152may be functions of a same payroll application. Application116may be configured to output paychecks for tenant112, and application152may be configured to create a new employee record within the payroll application.

In an embodiment, dependencies exist between application116and applications152-154. As an example, a function of application116may call a function of application152. Conversely, a function of application152may call a function of application116.

In one or more embodiments, an on-premise application schema (such as application schema162and/or164) is an application schema corresponding to a datastore that is implemented in an on-premise environment (such as on-premise environment106and/or on-premise environment108). In an embodiment, an on-premise application, in the same on-premise environment, uses the on-premise application schema to access one or more data sets.

In an embodiment, application schemas122-124and application schemas162-164are different from each other. Each application schema has different names of data fields, different numbers of data fields, different numbers of tables, and/or other differences.

In one or more embodiments, each on-premise data set (such as data set172and/or data set174) is organized using a particular on-premise application schema (such as application schema162and/or application schema164). Each data set is isolated from the data sets of other tenants. That is, tenant112cannot access data set174of tenant114, and vice versa.

In an embodiment, an on-premise data set is stored in a traditional datastore in an on-premise environment. A tenant accesses the on-premise data set in the traditional datastore, while concurrently accessing an off-premise data set stored in a cloud-based datastore. As an example, a tenant may store a first data set at an on-premise datastore for a period of time. Subsequently the tenant may desire to store a second data set at a cloud-based datastore, which is implemented in an off-premise environment. The tenant may store the second data set at the cloud-based datastore, without migrating the first data set from the on-premise environment to off-premise environment104.

In an embodiment, data sets132-134and data sets172-174may include overlapping or mutually-exclusive information. As an example, data set132may include a record of employee information, including an employee name, an employee identifier, and a residential address of the employee. Data set172may also include a record of employee information, including an employee name, an employee identifier, and a birthday of the employee. In this example, data set132and data set172would include overlapping information. The overlapping information would be the employee name and the employee identifier.

As another example, data set132may include a record of employee information. Data set172may include a record of office locations. The information in data set132would not be included in data set172, and vice versa. In this example, data set132and data set172would include mutually-exclusive information.

C. Single Interface for Off-Premise and on-Premise Environments

In one or more embodiments, application121includes executable code and/or logic that is configured to execute operations, such as executing interface120for rendering user interface elements at a user interface device. Application121may be implemented in off-premise environment104and/or on-premise environments106-108.

In an embodiment, application121is implemented in off-premise environment104. Application121transmits user interface elements to be rendered to a browser. The browser is executed on a machine that is local to tenant112and/or tenant114. As an example, application121may be a server-side application. The server-side application may transmit a webpage with the user interface elements to a browser. The webpage may be transmitted to the browser for rendering on a tenant's machine.

In an embodiment, application121is implemented in on-premise environment106and/or on-premise environment108. Application121is installed on a machine that is local to tenant112and/or tenant114. Application121causes user interface elements to be rendered at the local machine. As an example, application121may be a standalone application installed locally on a tenant's machine. The standalone application may execute an interface that presents user interface elements on the machine.

In one or more embodiments, interface120refers to hardware and/or software configured to facilitate communications and/or interactions between a user and applications116,152-154. Interface120is configured to access a datastore in off-premise environment104and a datastore in an on-premise environment (such as on-premise environment106and/or on-premise environment108). Interface120renders user interface elements and receives input via user interface elements. Examples of interfaces include a graphical user interface (GUI), a command line interface (CLI), a haptic interface, and a voice command interface. Examples of user interface elements include checkboxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms. Interface120may be implemented in off-premise environment104and/or on-premise environments106-108.

In another embodiment (not shown), separate interfaces are executed by each of application116, application152, and application154. Each interface is configured to access a datastore in off-premise environment104and a datastore in an on-premise environment (such as on-premise environment106and/or on-premise environment108. Application116executes a first interface. Application116transmits user interface elements to be rendered to a browser. The browser is executed on a machine that is local to tenant112and/or tenant114. Additionally or alternatively, application152executes a second interface. Application152is installed locally on a machine of tenant112. Application152causes user interface elements to be rendered at the machine. Additionally or alternatively, application154executes a third interface. Application154is installed locally on a machine of tenant114. Application154causes user interface elements to be rendered at the machine.

3. ACCESSING ON-PREMISE AND OFF-PREMISE DATASTORES THAT ARE ORGANIZED USING DIFFERENT APPLICATION SCHEMAS

FIG. 2illustrates an example set of operations for accessing on-premise and off-premise datastores that are organized using different application schemas, in accordance with one or more embodiments. One or more operations illustrated inFIG. 2may be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated inFIG. 2should not be construed as limiting the scope of one or more embodiments.

Initially, an interface receives a request for a particular data set (Operation202). In an embodiment, the interface is implemented in an off-premise environment, and the interface receives the request via a public network, such as the Internet. In another embodiment, the interface is implemented in an on-premise environment, and the interface receives the request via a local network. The request does not include a specification of whether to access an on-premise datastore or an off-premise datastore to retrieve the particular data set.

One or more embodiments include identifying a tenant, application schema, and/or service associated with the request (Operation204). In an embodiment, the request includes a particular user identifier (ID) of a user account that is being used to initiate the request. A look-up table is used to authenticate the particular user ID. The look-up table indicates a mapping between user IDs and tenant IDs. Based on the look-up table, the tenant ID corresponding to the particular user ID is identified.

In an embodiment, metadata indicates a mapping between tenant IDs and application schemas corresponding to the tenants. The metadata is stored in association with an application that is being accessed by the request. After a tenant ID associated with the request is identified, the tenant ID is used to identify a corresponding application schema.

In an embodiment, the request is mapped to one or more services based on a look-up table and/or logic statements. As an example, a first request may seek to add a new employee record to an employee database. The first request may then be mapped to a service that is configured to manage employee records. A second request may seek to modify the security settings of a user account associated with a particular employee. The second request may then be mapped to a service that is configured to manage security settings of employee accounts.

In an embodiment, the request is mapped to a first service, which depends on the use of a second service. Both the first service and the second service are associated with the request. As an example, a request may seek to determine a total sales revenue for the past quarter. The request may then be mapped to a first service that is configured to compute total sales revenue. The first service may depend on a second service that is configured to access sales records for the past quarter. The second service may be used to access the sales records, and the first service may be used to compute the total sales revenue from the sales records. Both the first service and the second service would be associated with the request.

In one or more embodiments, based on the tenant, application schema, and/or service, an inquiry is made as to whether to select (a) an on-premise datastore or (b) an off-premise datastore, from which to retrieve the particular data set (Operation206). The selection of a datastore is based on a look-up table and/or logic statements.

In an embodiment, each datastore is associated with a tenant ID. A look-up table indicates a mapping between tenant IDs and datastores. Based on a tenant ID, an on-premise datastore or an off-premise datastore is selected.

In an embodiment, each datastore is associated with an application schema. The on-premise datastore has a different application schema than the off-premise datastore. When a particular application schema is being used, only the corresponding datastore may be accessed. If the particular application schema corresponds to an on-premise datastore, then the on-premise datastore is selected. Conversely, if the particular application schema corresponds to an off-premise datastore, then the off-premise datastore is selected.

In an embodiment, a look-up table indicates whether a service is associated with an on-premise datastore or an off-premise datastore. As an example, new services (for example, services that are published after a certain date) may be configured to access an on-premise datastore. Old services (for example, services that are published before a certain date) may be configured to access an off-premise datastore.

In one or more embodiments, if an on-premise datastore is selected, then an on-premise application is selected to execute the request (Operation208). The on-premise application is implemented in an on-premise environment. As an example, the on-premise application may execute on a server that is located in an on-premise environment.

In one or more embodiments, if an off-premise datastore is selected, then an off-premise application is selected to execute the request (Operation210). The off-premise application is implemented in an off-premise environment. As an example, the off-premise application may execute on a server that is located in an off-premise environment.

One or more embodiments include retrieving the particular data set from the selected datastore without attempting to retrieve the particular data set from the non-selected datastore. The particular data set is retrieved using the selected application (Operation212). The selected application executes the request and accesses the corresponding datastore. The selected application executes various database commands (such as Structured Query Language (SQL) commands) to retrieve the particular data set from the corresponding datastore. The selected application does not attempt to retrieve the particular data set from another datastore.

One or more embodiments include transmitting and/or presenting the particular data set from the selected datastore (Operation214). The particular data set is transmitted via a public and/or local network. The particular data set is presented using a set of user interface elements.

Detailed examples are described below for purposes of clarity. Components and/or operations described below should be understood as specific examples which may not be applicable to certain embodiments. Accordingly, components and/or operations described below should not be construed as limiting the scope of any of the claims.

FIG. 3illustrates examples of accessing on-premise and off-premise datastores using on-premise and off-premise applications, in accordance with one or more embodiments.FIG. 3shows a tenant502, cloud exchange506, application vendors518, and on-premise environment524.

Tenant502is one of multiple tenants that share computing resources provided by cloud exchange506. Tenant502gains access to cloud exchange506through an on-boarding process520. Through the on-boarding process520, a cloud tenant datastore508is assigned to tenant502. Users504corresponding to tenant502are also specified.

Cloud tenant datastore508corresponding to tenant502is isolated from other cloud tenant datastores, available through cloud exchange506, corresponding to other tenants. As an example, each tenant datastore may be implemented in a separate pluggable database. As another example, each tenant datastore may be implemented in a separate data structure within a same database instance.

Application vendors518provide cloud application definitions512, which are maintained on the shared computing resources of cloud exchange506, through a publishing process522. Each application definition includes application code514and base schema516. Application code514is configured to execute requests received from tenants of cloud exchange506(such as accessing cloud tenant datastore508of tenant502). The same application code514is executed for multiple tenants. Base schema516indicates data fields and other characteristics of a default datastore for the corresponding application definition.

Tenants to application subscription510includes a list of subscribed cloud applications for each tenant. Subscription to a particular cloud application gives a tenant access to the particular cloud application. When tenant502subscribes to a particular cloud application, base schema516of the particular cloud application is copied as an application schema for cloud tenant datastore508of tenant502. Tenant502may make customizations to the application schema for cloud tenant datastore508, such as modifying names of existing data fields and/or adding new data fields.

On-premise tenant datastore526is a datastore that is implemented on hardware located at on-premise environment524corresponding to tenant502. A data set stored at on-premise tenant datastore526may be accessed using on-premise application528.

On-premise application528is an application that is implemented on hardware located at on-premise environment524corresponding to tenant502. On-premise application528is configured to execute requests received from tenant502(such as accessing on-premise tenant datastore526of tenant502).

On-premise application528is accessible via a user interface implemented at cloud exchange506. As an example, a user interface implemented at cloud exchange506receives a request to access a particular data set from a particular user corresponding to tenant502. The request includes a user identifier (ID) of the particular user. The user ID is mapped to a tenant ID associated with tenant502.

Using a look-up table stored at a data repository, the request is mapped to a particular service corresponding to on-premise application528and/or on-premise tenant datastore526of tenant502. Based on the mapping, on-premise application528retrieves the particular data set from on-premise tenant datastore526. On-premise application528transmits the particular data set to the user interface implemented at cloud exchange506. The user interface presents the particular data set.

As another example, a user interface implemented at cloud exchange506receives a request to access a particular data set from a particular user corresponding to tenant502. The request includes a user identifier (ID) of the particular user. The user ID is mapped to a tenant ID associated with tenant502.

Using a look-up table stored at a data repository, the request is mapped to a particular service corresponding to a cloud application definition. The cloud application definition includes dependencies on on-premise application528. The particular service of the cloud application definition includes, for example, code and/or logic that calls a particular operation of on-premise application528. The particular operation of on-premise application528retrieves the particular data set from on-premise tenant datastore526. On-premise application528returns the particular data set to the particular service of the cloud application definition. The cloud application transmits the particular data set to the user interface. The user interface presents the particular data set.

In one or more embodiments, a cloud environment provides a centralized pool of resources that are shared amongst multiple client devices. Examples of resources include a processor, a server, a data storage, a virtual machine, and a platform. Client devices may independently request computing services, such as server time and network storage, as needed. The resources are dynamically assigned to the client devices on an on-demand basis. The resources assigned to each particular client device may be scaled up or down based on the computing services requested by the particular client device. The resources assigned to each particular client device may also be scaled up or down based on the aggregated demand for computing services requested by all client devices.

In an embodiment, the resources of a cloud environment are accessible over a network, such as a private network or the Internet. One or more physical and/or virtual client devices demanding use of the resources may be local to or remote from the resources. The client devices may be any type of computing devices, such as computers or smartphones, executing any type of operating system. The client devices communicate requests to the resources using a communications protocol, such as Hypertext Transfer Protocol (HTTP). The requests are communicated to the resources through an interface, such as a client interface (such as a web browser), a program interface, or an application programming interface (API).

In an embodiment, a cloud service provider provides a cloud environment to one or more cloud users. Various service models may be implemented by the cloud environment, including but not limited to Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS). In SaaS, a cloud service provider provides cloud users the capability to use the cloud service provider's applications, which are executing on the cloud resources. In PaaS, the cloud service provider provides cloud users the capability to deploy onto the cloud resources custom applications, which are created using programming languages, libraries, services, and tools supported by the cloud service provider. In IaaS, the cloud service provider provides cloud users the capability to provision processing, storage, networks, and other fundamental computing resources provided in the cloud environment. Any arbitrary applications, including an operating system, may be deployed on the cloud resources.

In an embodiment, various deployment models may be implemented by a cloud environment, including but not limited to a private cloud, a public cloud, and a hybrid cloud. In a private cloud, cloud resources are provisioned for exclusive use by a particular group of one or more entities (the term “entity” as used herein refers to a corporation, organization, person, or other entity). The cloud resources may be located on the premises of one or more entities in the particular group, and/or at one or more remote off-premise locations. In a public cloud, cloud resources are provisioned for multiple entities (also referred to herein as “tenants”). Several tenants may use a same particular resource, such as a server, at different times and/or at the same time. In a hybrid cloud, the cloud environment comprises a private cloud and a public cloud. An interface between the private cloud and the public cloud allows for data and application portability. Data stored at the private cloud and data stored at the public cloud may be exchanged through the interface. Applications implemented at the private cloud and applications implemented at the public cloud may have dependencies on each other. A call from an application at the private cloud to an application at the public cloud (and vice versa) may be executed through the interface.

In a multi-tenant environment, where multiple tenants share a same pool of resources112, tenant isolation is implemented. Each tenant corresponds to a unique tenant identifiers (IDs). Data sets and/or applications implemented on cloud resources that are associated with a particular tenant are tagged with the tenant ID of the particular tenant. Before access to a particular data set or application is permitted, the tenant ID is verified to determine whether the corresponding tenant has authorization to access the particular data set or application.

In an embodiment, data sets corresponding to various tenants are stored as entries in a database. Each entry is tagged with the tenant ID of the corresponding tenant. A request for access to a particular data set is tagged with the tenant ID of the tenant making the request. The tenant ID associated with the request is checked against the tenant ID associated with the database entry of the data set to be accessed. If the tenant IDs are the same, then access to the database entry is permitted.

In an embodiment, data sets corresponding to various tenants are stored in different databases or data structures. Each database or data structure is tagged with the tenant ID of the corresponding tenant. A request for access to a particular data set is tagged with the tenant ID of the tenant making the request. The tenant ID associated with the request is checked against the tenant ID associated with the database or data structure storing the data set to be accessed. If the tenant IDs are the same, then access to the database or data structure is permitted.

In an embodiment, a subscription list indicates which tenants have authorization to access which applications. For each application, a list of tenant IDs of each tenant having authorization to access the application is stored. A request for access to a particular application is tagged with the tenant ID of the tenant making the request. The tenant ID associated with the request is checked against the subscription list to determine whether the tenant is authorized to access the application. If the tenant ID associated with the request is included in the list of tenant IDs of tenants having authorization to access the application, then access to the application is permitted.

7. HARDWARE OVERVIEW