STREAMING TRANSACTION NOTIFICATIONS
Methods and systems are provided for identifying data transactions satisfying a streaming query and providing data corresponding to those data transactions to subscribed client devices. One exemplary method involves receiving a subscription request for a streaming query from a client device, monitoring a database for indication of a data transaction corresponding to the streaming query, and in response to identifying the indication of the data transaction corresponding to the streaming query, obtaining data for an entry associated with the data transaction from the database and providing at least a portion of the obtained data to the client device.
Latest Salesforce.com Patents:
- RECOMMENDATION OF PRODUCTS VIA POPULATION OF A SPARSE DATA MATRIX
- HEADER FOR A USER INTERFACE TO TRACK DATA SUBMISSIONS
- Generating a legally binding object within a group-based communication system
- Method and system for decentralized message handling for distributed computing environments
- Systems and methods for verifying a firewall for a cloud provider
This application claims the benefit of U.S. provisional patent application Ser. No. 61/499,576, filed Jun. 21, 2011, the entire content of which is incorporated by reference herein.
The subject matter described herein is related to the subject matter described in U.S. patent application Ser. No. ______ (attorney docket 634US1 (102.0063)), filed concurrently herewith.
TECHNICAL FIELDEmbodiments of the subject matter described herein relate generally to computer systems configured to support on-demand applications, and more particularly, embodiments of the subject matter relate to methods and systems for providing notifications of data transactions substantially in real-time.
BACKGROUNDModern software development is evolving away from the client-server model toward network-based processing systems that provide access to data and services via the Internet or other networks. In contrast to traditional systems that host networked applications on dedicated server hardware, a “cloud” computing model allows applications to be provided over the network “as a service” or “on-demand” by an infrastructure provider. The infrastructure provider typically abstracts the underlying hardware and other resources used to deliver a customer-developed application so that the customer no longer needs to operate and support dedicated server hardware. The cloud computing model can often provide substantial cost savings to the customer over the life of the application because the customer no longer needs to provide dedicated network infrastructure, electrical and temperature controls, physical security and other logistics in support of dedicated server hardware.
Multi-tenant cloud-based architectures have been developed to improve collaboration, integration, and community-based cooperation between customer tenants without sacrificing data security. Generally speaking, multi-tenancy refers to a system where a single hardware and software platform simultaneously supports multiple user groups (also referred to as “organizations” or “tenants”) from a common data storage element (also referred to as a “multi-tenant database”). The multi-tenant design provides a number of advantages over conventional server virtualization systems. First, the multi-tenant platform operator can often make improvements to the platform based upon collective information from the entire tenant community. Additionally, because all users in the multi-tenant environment execute applications within a common processing space, it is relatively easy to grant or deny access to specific sets of data for any user within the multi-tenant platform, thereby improving collaboration and integration between applications and the data managed by the various applications. The multi-tenant architecture therefore allows convenient and cost effective sharing of similar application features between multiple sets of users.
In practice, it may be desirable to notify users substantially in real-time when their tenant's data maintained in the multi-tenant database is updated or changed. For example, when one user creates a new record or modifies an existing record in the multi-tenant database, other users associated with the same tenant as that user may desire to be apprised of the update to their tenant's data. However, the performance costs associated with each individual user continuously and/or periodically querying the multi-tenant database for the desired information pertaining to those records and/or transactions is undesirably high, particularly as the number of tenants and/or users supported by the multi-tenant system increases.
A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.
Embodiments of the subject matter described herein generally relate to identifying data transactions that satisfy registered streaming queries and providing notification of those data transactions to users subscribed to those streaming queries substantially in real-time. As described in greater detail below, a streaming query is associated with a query statement that is used to identify data transactions that users who are subscribed to that streaming query should be notified of substantially in real-time. In this regard, a data transaction that satisfies a query statement associated with a streaming query and any notification qualifier associated with the streaming query may be understood as a notification-triggering data transaction that results in notifications provided to subscribed users. As described in greater detail below, rather than continuously querying the database using the query statements for the streaming queries, in exemplary embodiments, an application server monitors data transactions performed on behalf of client devices accessing the database via the application server for data transactions that satisfy one or more of the query statements associated with the streaming queries. In response to identifying a data transaction that satisfies a streaming query, the application server automatically updates the database substantially in real-time to indicate the entry (or record) in the database that is associated with that notification-triggering data transaction along with the association between that database entry (or record) and the streaming query that the notification-triggering data transaction satisfied.
At the same time, other application servers monitor the database on a substantially continuous basis (e.g., by periodically polling the database) for indications of data transactions satisfying streaming queries that are subscribed to by client devices accessing the database via these other application servers. When an application server identifies an indication of a data transaction satisfying a streaming query that is subscribed to by a client device accessing the database via that application server, the application server automatically obtains, from the database, the data associated with the database entry (or record) associated with the data transaction that satisfied the streaming query and provides at least a portion of the obtained data to the subscribed client device. In exemplary embodiments, a streaming connection (or channel) is established with the subscribed client device upon receiving a subscription request for the streaming query, so that the application server may provide the portion of the obtained data to the subscribed client device with limited delay. For example, in accordance with one or more embodiments, a long-polling request is held open by the application server, thereby allowing the application server to push the obtained data to the subscribed client device by providing a long-polling response message that includes the obtained data. In this manner, a portion of the data associated with a notification-triggering data transaction can be provided to the subscribed client device without having to perform additional handshaking or other signaling to establish the connection. Accordingly, by virtue of application servers updating the database to indicate notification-triggering data transactions substantially in real-time as they occur and the other application servers pushing data associated with those notification-triggering data transactions to subscribed client devices, the users of the subscribed client devices may be notified of those data transactions substantially in real-time without having to continuously query the database for those data transactions, thereby conserving database resources.
In one or more embodiments, the application servers are part of a multi-tenant system and provide instances of virtual applications to multiple different tenants, wherein the database is realized as a multi-tenant database maintaining data associated with the different tenants. However, it should be noted that although the subject matter may be described herein in the context of a multi-tenant implementation, the subject matter is not intended to be limited to multi-tenant systems unless clearly indicated by the context.
Turning now to
As described in greater detail below in the context of
It should be understood that
Depending on the embodiment, the database 110 may be realized as a relational database or another suitable database capable of supporting the operations of the application system 100 described herein. In the illustrated embodiment, the database 110 maintains one or more data tables 114 which contain data associated with users and/or tenants in the application system 100 to support instances of virtual applications 124, 134 generated by the application servers 102, 104. In practice, the database 110 may include a database management system or other equivalent software that supports querying the data tables 114 (e.g., determining an optimal query plan and retrieving a particular subset of data from the data tables 114 in response to a query initiated or otherwise provided by a virtual application) and outputting the result of a query statement to a querying application server 102, 104.
In the illustrated embodiment, the database 110 also includes or otherwise maintains a definition table 118 that stores or otherwise maintains definition information pertaining to the streaming queries supported by the application system 100, as described in greater detail below in the context of
In exemplary embodiments, the database 110 also includes or otherwise maintains a notification table 116 that stores or otherwise maintains information pertaining to the data transactions satisfying a streaming query supported by the application system 100 that provide the basis for notifications provided to subscribed client devices. For example, as described in greater detail below in the context of
In the illustrated embodiment of
The client device 106 generally represents an electronic device that is utilized by a user to access the virtual application 124 and input and/or receive data pertaining to the virtual application 124. In practice, the client device 106 can be realized as any sort of personal computer, mobile telephone, tablet or other network-enabled electronic device. In an exemplary embodiment, the client device 106 includes a display device, such as a monitor, screen, or another conventional electronic display, capable of graphically presenting data and/or information provided by the virtual application 124 (including data retrieved from the database 110) along with a user input device, such as a keyboard, a mouse, a touchscreen, or the like, capable of receiving input data and/or other information from the user of the client device 106. In an exemplary embodiment, the user manipulates the client device 106 to execute a web browser application 107 and contact the application server 102 using a networking protocol, such as the hypertext transport protocol (HTTP) or the like, to request access to the virtual application 124, wherein the application platform 122 authenticates the user and generates the virtual application 124 at run time based upon information provided by the user of the client device 106 and/or data associated with the user (or the user's tenant) maintained by the database 110 (e.g., in one or more of the data tables 114). In this regard, the virtual application 124 includes code, data and/or other dynamic web content provided to the client device 106 that can be parsed, executed or otherwise presented by the browser application 107 running on the client device 106.
As described in greater detail below in the context of
Still referring to
In the illustrated embodiment, the application platform 132 and/or virtual application 134 generates or otherwise provides a streaming engine 136 that is utilized to establish a streaming connection with the client device 108 for providing data used to generate substantially real-time notifications of data transactions satisfying a streaming query that the user of the client device 108 is subscribed to. In this regard, the user of the client device 108 may interact with the virtual application 134 presented by the browser application 109 indicate a streaming query that the user would like to be subscribed to, wherein the browser application 109 communicates with the streaming engine 136 to provide the subscription request for that streaming query and establish a streaming connection with the distributing application server 104 associated with that subscription request. In exemplary embodiments, the subscription request includes an identifier associated with the streaming query the user would like to be subscribed to, wherein the application platform 132 and/or virtual application 134 generates or otherwise provides a subscription engine 137 that is coupled to the streaming engine 136 to receive the subscription request and an identifier associated with the client device 108. In some embodiments, the identifier associated with the client device 108 is generated by the distributing application server 104 (e.g., by the streaming engine 136 in response to receiving a request from the client device 108) and assigned to the client device 108 by the distributing application server 104. The subscription engine 137 updates a subscription table 138 maintained by the distributing application server 104 and/or application platform 132 (e.g., in memory) to include the identifier associated with the streaming query and the identifier for associated with the client device 108 subscribed to that streaming query. In this manner, the subscription table 138 reflects the streaming queries that are currently subscribed to by client devices accessing the distributing application server 104 and the respective client device(s) associated with (or subscribed to) each streaming query. As described in greater detail below in the context of
Referring to
Referring again to
In exemplary embodiments, the transaction identification process 200 continues by monitoring the data transactions initiated or otherwise performed on behalf of client devices for data transactions that satisfy an existing streaming query. The transaction identification process 200 determines or otherwise identifies whether a data transaction is relevant to an existing streaming query based on the metadata and tenant identifiers associated with the existing streaming queries by comparing the data fields, object types, tenant identifier and/or other metadata associated with the respective data transaction to the metadata and tenant identifiers associated with the existing streaming queries (task 208). For example, in accordance with one or more embodiments, the transaction monitoring engine 126 monitors each data transaction initiated or otherwise performed by the application platform 122, and for each data transaction, the transaction monitoring engine 126 identifies the data fields and/or other metadata involved in the data transaction and compares the data fields and/or other metadata for a respective data transaction to the metadata for each of the streaming queries maintained in the definition table 128 to identify data transactions having associated data fields and/or other metadata that match the metadata of a streaming query in the definition table 128. In this regard, if the data fields and/or other metadata associated with the data transaction do not match all of the metadata for a particular streaming query, the transaction monitoring engine 126 determines that data transaction is not relevant to that particular streaming query. For example, if a data transaction involves modifying the account value field of an ‘Account’ object or defining the account value field of a new ‘Account’ object and the metadata for a streaming query indicates that the ‘Account’ object account value field is referenced in the query statement, the transaction monitoring engine 126 may identify or otherwise determine that the data transaction is relevant to that streaming query. However, if the tenant identifier for that streaming query is different from the tenant identifier associated with the user responsible for the data transaction, the transaction monitoring engine 126 may determine the data transaction is not relevant to the streaming query because the tenant associated with the data transaction does not match the tenant associated with the streaming query. When the transaction identification process 200 determines a data transaction is not relevant to any streaming queries, the data transaction is effectively filtered out from further processing and/or analysis and the transaction identification process 200 exits or repeats the loop defined by tasks 202, 204, 206 and 208 to maintain updated streaming query definitions and continuously monitor subsequent data transactions performed on behalf of client devices.
When the transaction identification process 200 determines a data transaction is relevant to a streaming query, the transaction identification process 200 determines or otherwise identifies whether the data transaction satisfies the notification qualifiers for that streaming query (task 210). In this regard, if the data transaction involves updating or otherwise modifying an existing entry in the database 110 and the notification qualifier indicates that streaming query is limited to the creation of new entries in the database 110, the transaction monitoring engine 126 determines that the data transaction does not satisfy the notification qualifier for the streaming query. Similarly, if the data transaction involves creating a new entry in the database 110 and the notification qualifier indicates that streaming query is limited to updating or otherwise modifying existing entries in the database 110, the transaction monitoring engine 126 determines that the data transaction does not satisfy the notification qualifier for the streaming query. For example, continuing the above example, if the data transaction involves modifying the account value field of an existing ‘Account’ object and the notification qualifier for the streaming query limits the streaming query to creation of new ‘Account’ objects, the transaction monitoring engine 126 determines the data transaction does not satisfy the notification qualifier for the streaming query. In a similar manner as described above, when the transaction identification process 200 determines a relevant data transaction does not satisfy the notification qualifier for a streaming query, the data transaction is effectively filtered out and the transaction identification process 200 exits or repeats to continuously monitor subsequent data transactions performed on behalf of client devices. Conversely, when the data transaction involves creating a new ‘Account’ object having some user input value for the account value field and the notification qualifier for the streaming query limits the streaming query to creation of new ‘Account’ objects, the transaction monitoring engine 126 determines the data transaction satisfies the notification qualifier for the streaming query.
In exemplary embodiments, when the transaction identification process 200 determines a data transaction is both relevant to a particular streaming query and satisfies the notification qualifier for that particular streaming query, the transaction identification process 200 continues by determining or otherwise identifying whether the data transaction satisfies the query statement for that particular streaming query and updating the notification table in the database to indicate the entry associated with the data transaction when the data transaction satisfies the query statement (tasks 212, 214). In exemplary embodiments, the transaction monitoring engine 126 compares the values for data fields of the database entry associated with the data transaction to the query statement to identify whether the values for the database entry match or otherwise are within the range provided by the query statement. To put it another way, the transaction monitoring engine 126 effectively executes or otherwise performs the query statement on the database entry associated with the data transaction to determine whether the query statement would return the database entry associated with the data transaction as a result of the query statement if the query statement where executed by the database 110. It should be noted that by virtue of the transaction identification process 200 filtering out data transactions that are not relevant to the streaming query or otherwise do not satisfy the notification qualifiers for a streaming query, processing resources of the application server 102 are conserved by not evaluating the query statements for each of the streaming queries on each of the data transactions initiated by the application platform 122.
When the transaction monitoring engine 126 determines that the database entry associated with a data transaction would be returned as a result of executing the query statement associated with the streaming query, the transaction monitoring engine 126 updates the notification table 116 to indicate the database entry associated with the data transaction. In an exemplary embodiment, the transaction monitoring engine 126 creates a new entry (or row) in the notification table 116 that includes a unique numerical identifier (or record identifier) corresponding to the location of the database entry associated with the notification-triggering data transaction in one or more of the data tables 114, the identifier associated with the streaming query, and the transaction type associated with the data transaction. Additionally, in exemplary embodiments, the new entry in the notification table 116 is timestamped with a transaction identifier generated by the database 110 upon creation of the new entry in the notification table 116.
For example, continuing the above example, if the data transaction involves creating a new ‘Account’ object having a value for the account value field of 12,500 and the query statement is intended to return ‘Account’ objects having a value for the account value field greater than 10,000 (e.g., ‘SELECT name, value from account WHERE value >10000’), the transaction monitoring engine 126 may determine the data transaction satisfies the query statement in addition to the notification qualifier thereby satisfies the streaming query. In response to identifying the data transaction satisfies the query statement, the transaction monitoring engine 126 creates a new entry in the table 116 that includes a numerical identifier corresponding to the location of the new ‘Account’ object in the data tables 114, the streaming query identifier associated with the query statement, and the transaction type as the creation of a new entry in the database 110. Conversely, if the data transaction involved creating a new ‘Account’ object having a value for the account value field of 5,000 and the query statement is intended to return ‘Account’ objects having a value for the account value field greater than 10,000, the transaction monitoring engine 126 would determine the data transaction does not satisfy the query statement and the transaction identification process 200 exits or continues by monitoring subsequent data transactions without updating the notification table 116.
Referring again to
Referring again to
In an exemplary embodiment, the transaction notification process 500 begins by receiving a subscription request for a streaming query from a user of a client device (task 502). As described above in the context of
After receiving the subscription request from the user, the transaction notification process 500 continues by updating a list of streaming query subscriptions currently being supported by the application server (task 504). As described above in the context of
In an exemplary embodiment, the transaction notification process 500 continues by establishing a delivery protocol with the client device for providing data associated with data transactions triggering real-time notifications (task 506). In accordance with one or more embodiments, the browser application 109 on the client device 108 automatically attempts to establish a streaming connection with the distributing application server 104 using long-polling. For example, the browser application 109 on the client device 108 may initiate a handshake with the streaming engine 136 and/or application platform 132 using the Bayeux Protocol or CometD programming language to request a long-polling connection associated with the subscribed streaming query that will be held open by the streaming engine 136 and/or application platform 132, as described in greater detail below in the context of
Still referring to
Referring again to
Still referring to
For example, referring again to
In an exemplary embodiment, after querying the database to obtain the data and/or information associated with the database entries that correspond to the pending notification entries for a subscribed streaming query, the transaction notification process 500 continues by determining, for each respective user subscribed to that streaming query, which of the database entries are viewable or otherwise accessible to that respective user based on that respective user's permissions within the application system and/or security settings for the respective database entries (task 516). In this manner, the database entries are mapped or otherwise allocated the database entries to each user subscribed to that streaming query by performing row level security checks to filter database entries from individual users. In exemplary embodiments, the subscription engine 137 performs row level security checks to ensure a user subscribed to a particular streaming query has access to each database entry associated with that streaming query to ensure the user does not receive data and/or information that the user is not authorized to access and/or view. Referring again to
After filtering database entries that are not viewable to the different users subscribed to a particular streaming query, the transaction notification process 500 continues by determining, for each respective user, which of the fields of the database entries are viewable or otherwise accessible to that respective user based on that respective user's permissions within the application system before providing data to that subscribed user's client device (tasks 518, 520). In this regard, in exemplary embodiments, the subscription engine 137 performs field level security checks to ensure a user subscribed to a particular streaming query is only provided data for fields that are viewable or otherwise accessible to that user. In other words, field level security checks are performed for each subscribed user to filter out fields of data for the database entries mapped to that user that that subscribed user does not have permission to view and/or access. Referring again to
In exemplary embodiments, the subscription engine 137 provides the fields of obtained data that are viewable by the user of the client device 108 to the streaming engine 136, which, in turn, provides those fields of data to the user of the client device 108 according to the delivery protocol established with the browser application 109 on the client device 108. In this regard, if a long-polling connection has been established and held open by the streaming engine 136 and/or application platform 132, the streaming engine 136 pushes the fields of data to the client device 108 by transmitting or otherwise providing a response to the long-polling request (e.g., a long-polling response message) that contains the fields of data provided by the subscription engine 137. Upon receiving the fields of data from the application platform 132 and/or distributing application server 104, the browser application 109 generates or otherwise provides a notification of the data transactions that satisfy the subscribed streaming query based on the received fields of data associated with those data transactions. For example, referring again to
Still referring to
After updating the table 138 to indicate the streaming query subscribed to by the subscribing client device 108, the subscription engine 137 polls 608 the notification table 116 of the database 110 and obtain any entries created after the most recent polling of the notification table 116. In this regard, entries created after the most recent polling of the notification table 116 correspond to data transactions satisfying a streaming query that occurred after the previous polling of the notification table 116 by the subscription engine 137. In the illustrated embodiment, at some point after the first polling 608 by the subscription engine 137, a user associated with the same tenant as the user of the subscribing client device 108 (e.g., ‘ORGID_2’) utilizes the utilizes the virtual application 124 on the originating client device 106 to input or otherwise provide data 610 for storage in the database 110. In response to receiving the user input data 610, the application platform 122 and/or virtual application 124 initiates or otherwise performs a data transaction 612 on behalf of the client device 106 to store the received user input data in one or more of the data tables 114 in the appropriate manner, for example, by creating a new database entry in one of the data tables 114 that contains the user input data or by modifying an existing database entry in one of the data tables 114 to reflect the user input data. As described above in the context of
As described above in the context of
Still referring to
Referring now to
As used herein, a “tenant” or an “organization” should be understood as referring to a group of one or more users that shares access to common subset of the data within the multi-tenant database 730. In this regard, each tenant includes one or more users associated with, assigned to, or otherwise belonging to that respective tenant. To put it another way, each respective user within the multi-tenant system 700 is associated with, assigned to, or otherwise belongs to a particular tenant of the plurality of tenants supported by the multi-tenant system 700. Tenants may represent customers, customer departments, business or legal organizations, and/or any other entities that maintain data for particular sets of users within the multi-tenant system 700. Although multiple tenants may share access to the server 702 and the database 730, the particular data and services provided from the server 702 to each tenant can be securely isolated from those provided to other tenants. The multi-tenant architecture therefore allows different sets of users to share functionality and hardware resources without necessarily sharing any of the data 732 belonging to or otherwise associated with other tenants.
The multi-tenant database 730 is any sort of repository or other data storage system capable of storing and managing the data 732 associated with any number of tenants. The database 730 may be implemented using any type of conventional database server hardware. In various embodiments, the database 730 shares processing hardware 704 with the server 702. In other embodiments, the database 730 is implemented using separate physical and/or virtual database server hardware that communicates with the server 702 to perform the various functions described herein. In an exemplary embodiment, the database 730 includes a database management system or other equivalent software capable of determining an optimal query plan for retrieving and providing a particular subset of the data 732 to an instance of virtual application 728 in response to a query initiated or otherwise provided by a virtual application 728. The multi-tenant database 730 may alternatively be referred to herein as an on-demand database, in that the multi-tenant database 730 provides (or is available to provide) data at run-time to on-demand virtual applications 728 generated by the application platform 710.
In practice, the data 732 may be organized and formatted in any manner to support the application platform 710. In various embodiments, the data 732 is suitably organized into a relatively small number of large data tables to maintain a semi-amorphous “heap”-type format. The data 732 can then be organized as needed for a particular virtual application 728. In various embodiments, conventional data relationships are established using any number of pivot tables 734 that establish indexing, uniqueness, relationships between entities, and/or other aspects of conventional database organization as desired. Further data manipulation and report formatting is generally performed at run-time using a variety of metadata constructs. Metadata within a universal data directory (UDD) 736, for example, can be used to describe any number of forms, reports, workflows, user access privileges, business logic and other constructs that are common to multiple tenants. Tenant-specific formatting, functions and other constructs may be maintained as tenant-specific metadata 738 for each tenant, as desired. Rather than forcing the data 732 into an inflexible global structure that is common to all tenants and applications, the database 730 is organized to be relatively amorphous, with the pivot tables 734 and the metadata 738 providing additional structure on an as-needed basis. To that end, the application platform 710 suitably uses the pivot tables 734 and/or the metadata 738 to generate “virtual” components of the virtual applications 728 to logically obtain, process, and present the relatively amorphous data 732 from the database 730.
The server 702 is implemented using one or more actual and/or virtual computing systems that collectively provide the dynamic application platform 710 for generating the virtual applications 728. For example, the server 702 may be implemented using a cluster of actual and/or virtual servers operating in conjunction with each other, typically in association with conventional network communications, cluster management, load balancing and other features as appropriate. The server 702 operates with any sort of conventional processing hardware 704, such as a processor 705, memory 706, input/output features 707 and the like. The input/output features 707 generally represent the interface(s) to networks (e.g., to the network 745, or any other local area, wide area or other network), mass storage, display devices, data entry devices and/or the like. The processor 705 may be implemented using any suitable processing system, such as one or more processors, controllers, microprocessors, microcontrollers, processing cores and/or other computing resources spread across any number of distributed or integrated systems, including any number of “cloud-based” or other virtual systems. The memory 706 represents any non-transitory short or long term storage or other computer-readable media capable of storing programming instructions for execution on the processor 705, including any sort of random access memory (RAM), read only memory (ROM), flash memory, magnetic or optical mass storage, and/or the like. The computer-executable programming instructions, when read and executed by the server 702 and/or processor 705, cause the server 702 and/or processor 705 to create, generate, or otherwise facilitate the application platform 710 and/or virtual applications 728 and perform one or more additional tasks, operations, functions, and/or processes described herein. It should be noted that the memory 706 represents one suitable implementation of such computer-readable media, and alternatively or additionally, the server 702 could receive and cooperate with external computer-readable media that is realized as a portable or mobile component or application platform, e.g., a portable hard drive, a USB flash drive, an optical disc, or the like.
The application platform 710 is any sort of software application or other data processing engine that generates the virtual applications 728 that provide data and/or services to the client devices 740. In a typical embodiment, the application platform 710 gains access to processing resources, communications interfaces and other features of the processing hardware 704 using any sort of conventional or proprietary operating system 708. The virtual applications 728 are typically generated at run-time in response to input received from the client devices 740. For the illustrated embodiment, the application platform 710 includes a bulk data processing engine 712, a query generator 714, a search engine 716 that provides text indexing and other search functionality, and a runtime application generator 720. Each of these features may be implemented as a separate process or other module, and many equivalent embodiments could include different and/or additional features, components or other modules as desired.
The runtime application generator 720 dynamically builds and executes the virtual applications 728 in response to specific requests received from the client devices 740. The virtual applications 728 are typically constructed in accordance with the tenant-specific metadata 738, which describes the particular tables, reports, interfaces and/or other features of the particular application 728. In various embodiments, each virtual application 728 generates dynamic web content that can be served to a browser or other client program 742 associated with its client device 740, as appropriate.
The runtime application generator 720 suitably interacts with the query generator 714 to efficiently obtain multi-tenant data 732 from the database 730 as needed in response to input queries initiated or otherwise provided by users of the client devices 740. In a typical embodiment, the query generator 714 considers the identity of the user requesting a particular function (along with the user's associated tenant), and then builds and executes queries to the database 730 using system-wide metadata 736, tenant specific metadata 738, pivot tables 734, and/or any other available resources. The query generator 714 in this example therefore maintains security of the common database 730 by ensuring that queries are consistent with access privileges granted to the user and/or tenant that initiated the request. In this manner, the query generator 714 suitably obtains requested subsets of data 732 accessible to a user and/or tenant from the database 730 as needed to populate the tables, reports or other features of the particular virtual application 728 for that user and/or tenant.
Still referring to
In exemplary embodiments, the application platform 710 is utilized to create and/or generate data-driven virtual applications 728 for the tenants that they support. Such virtual applications 728 may make use of interface features such as custom (or tenant-specific) screens 724, standard (or universal) screens 722 or the like. Any number of custom and/or standard objects 726 may also be available for integration into tenant-developed virtual applications 728. As used herein, “custom” should be understood as meaning that a respective object or application is tenant-specific (e.g., only available to users associated with a particular tenant in the multi-tenant system) or user-specific (e.g., only available to a particular subset of users within the multi-tenant system), whereas “standard” or “universal” applications or objects are available across multiple tenants in the multi-tenant system. The data 732 associated with each virtual application 728 is provided to the database 730, as appropriate, and stored until it is requested or is otherwise needed, along with the metadata 738 that describes the particular features (e.g., reports, tables, functions, objects, fields, formulas, code, etc.) of that particular virtual application 728. For example, a virtual application 728 may include a number of objects 726 accessible to a tenant, wherein for each object 726 accessible to the tenant, information pertaining to its object type along with values for various fields associated with that respective object type are maintained as metadata 738 in the database 730. In this regard, the object type defines the structure (e.g., the formatting, functions and other constructs) of each respective object 726 and the various fields associated therewith.
Still referring to
Referring now to
The foregoing description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the technical field, background, or the detailed description. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations, and the exemplary embodiments described herein are not intended to limit the scope or applicability of the subject matter in any way.
For the sake of brevity, conventional techniques related to computer programming languages, techniques and/or protocols, computer networking, on-demand and/or multi-tenant systems or databases, authentication, data security, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein. In addition, those skilled in the art will appreciate that embodiments may be practiced in conjunction with any number of system and/or network architectures, data transmission protocols, and device configurations, and that the system described herein is merely one suitable example. Furthermore, certain terminology may be used herein for the purpose of reference only, and thus is not intended to be limiting. For example, the terms “first”, “second” and other such numerical terms do not imply a sequence or order unless clearly indicated by the context.
Embodiments of the subject matter may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. In this regard, it should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. In this regard, the subject matter described herein can be implemented in the context of any computer-implemented system and/or in connection with two or more separate and distinct computer-implemented systems that cooperate and communicate with one another. That said, in one or more exemplary embodiments, the subject matter described herein is implemented in conjunction with a virtual customer relationship management (CRM) application in a multi-tenant environment.
While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application. Accordingly, details of the exemplary embodiments or other limitations described above should not be read into the claims absent a clear intention to the contrary.
Claims
1. A method of identifying data transactions satisfying a streaming query, the method comprising:
- receiving, by a server, a subscription request for the streaming query from a first client device having a first user associated with a first tenant;
- monitoring, by the server, a notification table in a database for an indication of a data transaction corresponding to the streaming query performed on behalf of a second client device having a second user associated with the first tenant; and
- in response to identifying the indication of the data transaction corresponding to the streaming query: obtaining, from the database, data for an entry associated with the data transaction; and providing at least a portion of the obtained data to the first client device.
2. The method of claim 1, further comprising
- initiating, by a second server coupled to the database, the data transaction for the entry in response to input data from the second client device;
- determining, by the second server, a tenant identifier associated with the second user matches a tenant identifier associated with the streaming query;
- determining, by the second server, the data transaction satisfies the streaming query after determining the tenant identifier associated with the second user matches the tenant identifier associated with the streaming query; and
- updating, by the second server, the notification table in the database to indicate an association between the entry and the streaming query after determining the data transaction satisfies the streaming query, wherein the server obtains the data for the entry in response to the second server updating the notification table.
3. The method of claim 1, wherein monitoring the notification table comprises monitoring the notification table in the database for a notification entry associated with the streaming query.
4. The method of claim 3, the notification entry including a unique identifier for the entry in the database, wherein obtaining data for the entry comprises querying the database using the unique identifier to obtain the data associated with the entry.
5. The method of claim 1, further comprising determining the portion of the obtained data based on permissions associated with the first user.
6. The method of claim 1, further comprising maintaining an association between the first client device and the streaming query after receiving the subscription request.
7. The method of claim 1, further comprising establishing a streaming connection with the first client device, wherein providing the portion of the obtained data to the first client device comprises providing the portion of the obtained data using the streaming connection.
8. The method of claim 7, wherein:
- establishing the streaming connection comprises receiving a request from the first client device; and
- providing the portion of the obtained data using the streaming connection comprises providing, to the first client device, a response including the portion of the obtained data.
9. The method of claim 1, wherein monitoring the notification table comprises:
- periodically polling the notification table for notification entries created after a preceding polling; and
- grouping the notification entries by their associated streaming query, resulting in a group of one or more notification entries associated with the streaming query.
10. The method of claim 9, wherein providing the portion of the obtained data to the first client device comprises, for each notification entry in the group of one or more notification entries associated with the streaming query:
- determining the respective entry in the database associated with the respective notification entry is viewable by the first user; and
- filtering the data obtained for the respective entry based on field level permissions associated with the first user, resulting in a subset of the data obtained for the respective entry; and
- providing the subset of the data obtained for the respective entry to the first client device.
11. The method of claim 9, the group including a plurality of notification entries associated with the streaming query, wherein obtaining data for the entry associated with the data transaction comprises:
- generating a modified query statement using a query statement associated with the streaming query and identifiers associated with a plurality of database entries corresponding to the plurality of notification entries; and
- providing the modified query statement to the database to obtain data for the plurality of database entries.
12. The method of claim 1, the server comprising an application server providing a virtual application to the first client device, the application server monitoring the database for the data transaction corresponding to the streaming query, wherein:
- the virtual application receives the subscription request and provides the portion of the obtained data to a browser application on the first client device; and
- the browser application generates a notification of the data transaction based on the portion of the obtained data.
13. A method of monitoring data transactions, the method comprising:
- receiving, by an application server, a subscription request from a client device to subscribe the client device to a streaming query;
- polling, by the application server, a notification table in a database for a notification entry associated with the streaming query, the notification entry maintaining an association between the streaming query and a unique identifier associated with a data entry in the database associated with a data transaction satisfying the streaming query; and
- in response to identifying the notification entry associated with the streaming query: querying the database to obtain data for the data entry associated with the data transaction using the unique identifier; and providing at least a portion of the obtained data to the client device.
14. The method of claim 13, further comprising receiving, by the application server, a long-polling request from the client device, wherein providing the portion of the obtained data comprises transmitting, by the application server, a long-polling response including the portion of the obtained data to the client device.
15. The method of claim 13, wherein polling the notification table comprises polling the notification table for one or more notification entries created in the notification table after a preceding polling.
16. The method of claim 15, wherein identifying the notification entry associated with the streaming query comprises identifying the notification entry of the one or more notification entries including a streaming query identifier matching an identifier associated with the streaming query.
17. A server comprising a processing system and a memory, wherein the memory comprises computer-executable instructions that, when executed by the processing system, cause the server to:
- monitor a notification table in a database for a data transaction performed on behalf of a first user associated with a tenant that satisfies a streaming query subscribed to by a second user of a client device, the second user being associated with the tenant;
- obtain data for an entry associated with the data transaction from the database using a unique identifier for the entry obtained from the notification table; and
- provide at least a portion of the obtained data to the client device.
18. The server of claim 17, wherein the computer-executable instructions cause the server to periodically poll the notification table of the database for a notification entry associated with the streaming query and identify the entry associated with the notification entry as the entry associated with the data transaction.
19. The server of claim 17, wherein the computer-executable instructions cause the server to maintain an association between the streaming query and the client device in response to receiving a subscription request for the streaming query from the client device.
20. The server of claim 17, wherein the computer-executable instructions cause the server to provide a long-polling response including the portion of the obtained data to the client device after receiving a long-polling request associated with the streaming query from the client device.
Type: Application
Filed: Jun 21, 2012
Publication Date: Dec 27, 2012
Applicant: salesforce.com, inc. (San Francisco, CA)
Inventor: Vinod Mehra (Pleasanton, CA)
Application Number: 13/529,700
International Classification: G06F 17/00 (20060101);