Patent Grant
9864762
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
One or more implementations relate generally to computer systems and software, and, more particularly, to mapping a value to a new domain.
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
Reports are a fundamental part of many organizations working towards improved business intelligence and knowledge management. There are many different ways reports can be useful. For example, reports can help to provide status, help people manage resources and make decisions, and provide information. But, report information has little value unless it is organized, aggregated, and presented in a usable form.
Many report building and designing tools, however, are cumbersome and difficult to use—especially if the user desires to see the data arranged along a new dimension. For example, the reporting tool may require specialized knowledge in computer coding. Users such as end-users and business analysts are unlikely to possess such knowledge because their area of expertise may be more business and industry focused. It can be very difficult for such users to customize reports in order to present different perspectives of the data.
Therefore, there is a need for improved systems and techniques for making reports.
In an embodiment, source values are mapped to new user-defined categories. The new user-defined categories are stored in a new user-defined field. In an embodiment, a user-selection of an existing field is received. Based on a data type of the existing field, a specific mapping interface is displayed. The interface guides the user through specification of the new field and categories, and identification of the source values to map to the new categories.
In an embodiment and by way of example, a method for mapping a value to a new domain includes receiving a selection from a user of a first field for storing a plurality of source values, prompting the user to name a second field that will store one or more target categories, prompting the user to identify at least a subset of the plurality of source values to map to a target category, prompting the user to name the target category, storing the target category in the second field, and mapping the at least a subset of source values to the target category.
While one or more implementations and techniques are described with reference to an embodiment in which mapping a value to a new domain is implemented in a system having an application server providing a front end for an on-demand database service capable of supporting multiple tenants, the one or more implementations and techniques are not limited to multi-tenant databases nor deployment on application servers. Embodiments may be practiced using other database architectures, i.e., ORACLE®, DB2® by IBM and the like without departing from the scope of the embodiments claimed.
Any of the above embodiments may be used alone or together with one another in any combination. The one or more implementations encompassed within this specification may also include embodiments that are only partially mentioned or alluded to or are not mentioned or alluded to at all in this brief summary or in the abstract. Although various embodiments may have been motivated by various deficiencies with the prior art, which may be discussed or alluded to in one or more places in the specification, the embodiments do not necessarily address any of these deficiencies. In other words, different embodiments may address different deficiencies that may be discussed in the specification. Some embodiments may only partially address some deficiencies or just one deficiency that may be discussed in the specification, and some embodiments may not address any of these deficiencies.
In the following drawings like reference numbers are used to refer to like elements. Although the following figures depict various examples, the one or more implementations are not limited to the examples depicted in the figures.
Systems and methods are provided for mapping a value to a new domain, which may be referred to as “bucketing.”
A specific application of the tool is with a report builder 115. Reports provide information in a presentable, human-readable form. A report can be a printed or paper report. Alternatively, a report may be in an electronic format and displayed on an electronic screen. Reports can be used to display the result of an activity, operation, experiment, investigation, or inquiry. Reports are used in many different types of entities and organizations such as business and government. Organizations rely on reports to help make decisions, understand different alternatives, and gain business intelligence insight—just to name a few examples. A report can include elements such as charts and tables that summarize, categorize, group, and classify information.
In a specific implementation, user 110 is an end-user or business analyst. The user may want to create new categories of report information to present the information along a new dimension or perspective. With this tool, the user who may not have specialized application coding knowledge, can quickly and easily make (and edit) a new field category, specify new categories for the field category, and map source values to the new categories. The tool provides users with the ability to create custom reports having user-defined fields, categories, and mappings without administrator involvement.
For example, a sales operations analyst may want to group certain stock-keeping units (SKUs) into product lines. Many organizations have thousands of products and mappings constantly change. Some products may have associated revenue and other products may not have associated revenue. With the tool, the analyst can “bucket” or categorize products having no associated revenue into an “other” product line. As another example, a sales manager may want to see deals they have by deal size. With the tool, the sales manager can “bucket” the deals by deal size (e.g., “large” deals, “medium” deals, and “small” deals). As another example, a support manager may want to see how many cases have been open in different age groups. With the tool, the support manager can “bucket” the cases by the different age groups.
In brief, in a step 210, the tool receives a user selection of a first field for storing a set of source values. The first field may be referred to as a source field or an existing source field. In a step 215, the tool prompts the user to name a second field that will store one or more new user-defined target categories. The second field may be referred to as a bucket field, a mapping field, a category field, or a destination field. In a step 220, based on a data type of the first field, the tool displays a specific mapping user interface or widget. In a step 225, through the interface, the user is prompted to identify at least a subset of the source values to map to a new target category. In a step 230, the tool prompts the user to name the new target category. In a step 235, the tool maps the at least subset of source values to the new target category.
Referring now to step 210, in a specific implementation, the tool provides a graphical control or widget that allows the user to select a first field that stores, holds, contains, or is associated with a set of source values that the user would like to “bucket” or categorize into one or more new user-defined categories. That is, the categories do not yet exist or have not yet been created. The user may make the selection using an input device such as a keyboard or a pointing device, such as a mouse or stylus. The user may instead or additionally indicate a selection using a voice command or their finger such as in implementations where there is a touch screen (i.e., a computer display screen that can function as an input device).
As an example,
In this specific implementation, the screen shots are of web pages displayed on an electronic screen to a user. The web pages are generated by a report building product provided by salesforce.com, inc. of San Francisco, Calif. It should be appreciated, however, that the tool may be implemented in any report builder product. These screen shots and the accompanying description are provided merely as a sample implementation. It should be understood that the invention is not limited to the specific examples and features presented. A system of the invention may have additional features (not necessarily described in this application), different features which replace some of the features or components presented, fewer features or a subset of the features presented, or features in a different order than presented, or any combinations of these. Aspects (e.g., screens or web pages) of the invention may be modified or altered as appropriate for a particular application, industry, business, or use.
First pane 408A includes a field list 411, and a bucket fields folder 414. The fields are implemented as an expandable and collapsible folder tree. The field list includes a set of report fields or columns that correspond to report fields or columns of report table 409. For example, an “Employees” field 416 in the field list corresponds to “Employees” field 417 in the report table. A “Last Activity” field 420 in the field list corresponds to “Last Activity” field 422 in the report table, and so forth.
In this specific implementation, the tool provides several techniques for the user to specify the source field to “bucket.” This provides the user with the flexibility to choose the technique they are comfortable with. In a first technique, the tool provides a pop-up column menu 425 having an option 428 “Bucket this Field.” The column menu may be triggered by hovering a pointing device over the field in the report table to bucket and clicking. For example, to “bucket” or categorize the values in the “Employees” field, the user may click field 417 to trigger the column menu and then select option 428.
In a second technique, the tool provides a drag-and-drop control or command. The tool permits the user to drag a field from the fields list to the bucket fields folder. For example, the user can drag employees field 416 to bucket fields folder 414 in order to “bucket” or categorize the source values in the employees field.
In a third technique, the tool provides a user-selectable control 435 “Add Bucket Field.” Specifically, the user can click (e.g., double-click) the “Add Bucket Field” control and a window 510 (
Window 510 includes a drop-down list 515 that includes fields which can be bucketed. The user can select a field from the drop-down list and confirm their selection by clicking “OK.” In a specific implementation, the tool allows bucketing of specific data types only. In this specific implementation, the drop-down list includes only fields with data types that the tool allows to be bucketed and other fields having data types that are not allowed to be bucketed are omitted or excluded from the drop-down list.
Referring now to
For example, as shown in
In the example shown in
The second section includes a table 630. The table permits the user to define source value ranges and the mapping of the ranges to the new target categories. The table includes a first column 635 labeled “Range” and a second column 640 labeled “Name” to name or label the new target categories. A “Reset Ranges” link 641 allows the user to reset the ranges (e.g., delete the inputted ranges).
In this example, a first row 642 of the table includes, in the first column, a mathematical or relational operator 645 and a text box 650 positioned on a right-hand side of the mathematical operator, and, in the second column, a text box 655. The mathematical operator is the operator for “less than or equal to.” Text box 650 allows the user to input an upper limit for the “less than or equal to” operator. In other words, to input a numerical value (e.g., 100) to specify in conjunction with the operator a mathematical expression, statement, or condition. In this example, the user has defined a first range to include a condition “number of employees less than or equal to 100.”
Note that the example shown in
More particularly, the condition between the lower and upper limit values can be a “less than,” “greater than,” “not equal to,” “less than or equal to,” or “greater than or equal to.” The “less than condition” may be indicated by the mathematical symbol or notation “<.” The “greater than” condition may be indicated by the notation “>.” The “not equal to” condition may be indicated by the notation “≠.” The “less than or equal to” condition may be indicated by the notation “≦.” The “greater than or equal to” condition may be indicated by the notation “≧.” A range may be referred to as an inequality statement or function. In an implementation, the tool allows users to define custom inequality statements. This may include displaying or providing input boxes so that users can define a left side of an inequality statement, a right side of the inequality statement, an inequality condition between the left side and the right side, or combinations of these.
As shown in
Text box 655 allows the user to name a new target category, i.e., to specify a name or label for the new target category. In this example, the user has indicated that the first range is to be mapped to the new target category labeled “Small.” Based on the mapping indication, the tool associates report records satisfying the first range condition “number of employees less than or equal to 100” with a first new target category that has been labeled “Small.”
An “Add” link 657 permits the user to add a second row 660 to the table to include a second range. The second row of the table includes, in the first column, a mathematical operator 663 and a text box 666, and in the second column, a text box 669. There is a “Delete” link 672 for the user to delete the second row or to delete the second range. In this specific implementation, mathematical operator 663 is the operator for “greater than.” The upper limit from the first range (e.g., 100) defaults to be the lower limit of the second range. Text box 666 allows the user to input an upper limit for the second range (e.g., 1000). In this example, the user has defined the second range include a condition “number of employees between 100 and 1000.”
Text box 669 is similar to text box 655. That is, text box 669 allows the user to name another new target category. In this example, the user has mapped the second range to a new target category labeled “Mid.” Based on the mapping indicated by the user, the tool associates records satisfying the condition “number of employees between 100 and 1000” with a second new target category that has been labeled “Mid.”
An “Add” link 675 permits the user to add a third row 678 to the table to include a third range. In this example, the third row includes, in the first column, a mathematical operator 682 and a lower limit 691, and in the second column, a text box 688. In this specific implementation, mathematical operator 682 is the operator for “greater than.” The upper limit of the second range defaults to be lower limit 691 of the third range. In this example, the third range is defined to include a condition “number of employees greater than 1000.”
Text box 630 is similar to text box 672. That is, text box 630 allows the user to name another new target category. In this example, the user has mapped the third range to a new target category labeled “Large.” Based on the mapping indicated by the user, the tool associates records satisfying the condition “number of employees greater than 1000” with a third new target category that has been labeled “Large.”
In this specific implementation, the tool guides the user through defining and mapping ranges. The user-inputted upper limit of the first range (e.g., 100) defaults to a non-editable lower limit of the second range. Similarly, the user-inputted upper limit of the second range (e.g., 1000) defaults to a non-editable lower limit of the third range. This helps to ensure that there are no gaps between the ranges. In some cases, however, users may desire less guidance or may desire gaps between the ranges. So, in other specific implementations, a user-inputted upper limit of a first range may default to be an editable lower limit of a second range.
Second section 610B further includes radio buttons 693 and 694 below table 630. The radio buttons allow the user to indicate how they would like the tool to treat blank values. For example, the user can select radio button 693 to treat blank values like the number zero. Thus, records having a blank or null value for the number of employees are treated as having zero employees and would be associated with the first new category that has been labeled “Small.” Alternatively, the user can select radio button 694 to put these values (or records) in their own bucket or new category.
When the user has completed the range definition and indicated the range mappings to the various new target categories, the user may click the “OK” button. The tool then maps or associates the relevant source values from the source field (e.g., Employees) to the target categories (step 235,
Although
Further, it should also be appreciated that the specific mathematical operators shown in
More specifically, based on the mapping in table 630 (
When a new record having a new source value is added, the tool can automatically categorize the record based on the particular value of the new source value and the mappings (or conditions) defined previously. For example, when a new account is added, the tool can automatically categorize the account based on the number of employees associated with the new account. The user does not have to perform another mapping process for the newly added account.
For example, if the new account includes a number of employees less than or equal to 100, the new account is automatically categorized in the “Small” category. If the number of employees is between 100 and 1,000, the new account is automatically categorized in the “Mid” category. If the number of employees is greater than 1,000, the new account is automatically categorized in the “Large” category. Thus, it is not always the case that an existing source field will have existing source values. New records having new source values can be added after the bucket field is created.
The bucket field may be associated with a particular user or user account so that each user can have their own view of a report. For example, sales vice presidents and sales managers are usually concerned with the number of deals they have open by deal size. Depending on their sales segment, different sales managers will have their own definitions of deal sizes. For corporate sales, they may be concerned with small deals that are less than $10K, medium $10K-$25K, and big deals that are over $25K. For field sales manager, these deal sizes would be less important since their deals are may be much bigger. For them, small deals are less than $250K, medium $250K-$1M, and big deals are over $1M.
In a specific implementation, a first user-configured view of a report includes a first bucket field based on a source field. The first bucket field includes a first set of categories mapped to a first set of source values from the source field. A second user-configured view of the report includes a second bucket field based on the source field. The second bucket field includes a second set of categories mapped to a second set of source values from the source field. The first set of categories may be the same or different from the second set of categories. For example, the category labels of the first and second set of categories may be the same or different. The first set of source values may be different from the second set of source values. Thus, a field sales manager may have a view of a report with a bucket category labeled “medium” that maps to deal sizes between $250K and $1M. A junior sales manager may have a different view of the report with a bucket category that may also be labeled “medium,” but that maps to deal sizes between $10K and $25K. A report may have any number of user-defined bucket fields. In a specific implementation, there is a limit of 20 bucket fields in a single report. It should be appreciated, however, that the limit may be less than 20 bucket fields or greater than 20 bucket fields.
First section 810A is similar to first section 610A in
The interface in overlay window 805 provides several techniques for a user to indicate the mappings. In a first technique, the user can indicate the mappings using “Map To” menu 832. For example, referring now to
A user can map one or more of the source values to a new category by selecting the desired source values via the corresponding checkboxes and clicking “Map To” menu 832. As shown in
Alternatively, in a second technique, the user can map source values by dragging them onto the second section or left sidebar. The user can click “New Mapping” button 829 and enter a name of the new mapping (or new category) in text box 915. In this example, the user has named the new category “east.” As shown in
The source value listing has been tagged with the category to which the source value has been mapped to. For example, as shown in
In a specific implementation, the mappings or categories are color-coded to help distinguish the different categories. For example, the category “central” may be displayed in a first font color and the category “east” may be displayed in a second font color, different from the first font color. For example, the first font color may be blue. The second font color may be green. It should be appreciated that any color or combination of colors may be used, e.g., orange, purple, yellow, pink, red, and so forth. It should be appreciated, however, that any graphical element or visual indicator (not necessarily a color) may be used to visually distinguish the categories. Some examples of other visual indicators that may be used instead of or in addition to color include icons, shapes, symbols, and the like.
As discussed above and shown in
As discussed above, if the user adds a new record having a new source value whose mapping was defined previously, the new source value is categorized automatically. For example, if a new account having a new “Billing State” of “MA” is added, “MA” is mapped automatically to the “east” category. If a new account having a new “Billing State” of “CA” is added, “CA” is mapped automatically to the “west” category, and so forth.
In this specific implementation, the bucket field column (e.g., “Region”) has been inserted on a left-hand side of the source field column (e.g., “Billing State/Province”). It should be appreciated, however, that the bucket field column may be inserted at any location in the report table such as on a right-hand side of the source field column. In a specific implementation, a bucket field column replaces the source field column. In a specific implementation, the insertion location of a bucket field depends on the type of report. In this specific implementation, for tabular format reports, the bucket field is added on the left side of the original source column. In summary format reports, the bucket field is added as an additional summary step above the original source field. In matrix format reports, the new bucket field replaces the original source field.
As shown in the example of
The mapping interface examples shown in
It should be appreciated that the tool is not limited to the specific GUI controls, widgets, objects, elements, containers, icons, windows, views, navigation, help text, and layouts shown in the screenshots. Various specific implementations may include GUI elements such as floating windows, modal windows, palette or utility windows, pop-up boxes, dialog boxes, frames, list boxes, context menus, sliders, spinners, menu bars, combo boxes, scroll bars, tabs, tree views, grid views, tooltips, balloon help, infobars, links, buttons, icons, and the like. There may be validation rules for the input boxes so that certain fields are mandatory (e.g., bucket field name may be mandatory or a field name may be limited to 250 characters).
This specific implementation describes mapping values from an existing reporting field into a new, report-specific field. For example, “opportunity.revenue” can be mapped to a new field called “BinnedRevenue” with values “High,” “Medium,” and “Low.” The field “BinnedRevenue” may exist only within the scope of the report in which it is defined. In another specific implementation, the field is available for other reports.
A field that is created by the bucketing process may be referred to as a “bucket field.” In an embodiment, a bucket field is based on a single “source field” that is visible within a report, e.g., opportunity.revenue, opportunity.stage, product.name. The user interface (“UI”) for defining a bucket specifies a mapping of values from the source field to a set of destination values, e.g., a bucket field called AcctRegion maps values from the source field account.BillingState to target bucket values “East,” “West,” “North,” and “South.” A special bucket value, “Other,” can be defined to catch all values that have not been explicitly mapped.
In an embodiment, a bucket field has a data type, similar to other report fields. The data type is String (text), as bucket values in this specific embodiment are limited to string values. In an embodiment, the mapping for a bucket field source must be unique, i.e., a source field value must deterministically map to one and only one target bucket. However, multiple ranges can map to the same bucket value, e.g., the mapping for a numeric field can map values less than 10 to a bucket value “outliers,” 11 to 50 to “small,” 51 to 100 to “high,” and values greater than 100 to “outliers.” In another specific implementation, a source field value may map to multiple target buckets (e.g., two or more target buckets).
In an embodiment, a bucket field can be included in these parts of a report: (1) column list, (2) grouping column, (3) field filter, (4) limit rows, aka top-N, and (5) sort. A filter on a bucket field can be included in Filter logic.
In an embodiment, a bucket field is prevented from being summarized because it can be a field of a Text data type. In another embodiment, a bucket field may be summarized.
In this specific implementation, SQL for a bucket field is not stored in the database (db) but is generated at runtime as it should be a fast operation. For numeric source fields, ranges defined by from_number and to_number must not overlap or are prevented from overlapping. In this specific implementation, the UI has no gaps in ranges. So the from_number and to_number of the preceding one is the same. It should be appreciated, however, that the schema can be more general to allow gaps if ever needed. Source_value column is unique within a bucket field value for text and picklist source fields. In a specific implementation, SQL is generated and executed to evaluate bucket fields.
In an embodiment, the UI for defining a bucket is dependent on the data type of the source field. The UI for numeric fields may look different from that of picklists and text. For example, the UI for picklists may involve displaying all available picklist values to the user. Determining which picklist values to display may be the same list that is shown when a user clicks the lookup icon in the filter panel for the value of a picklist field. Generating the list of values to display in the UI for text fields may be accomplished in a number of ways.
In an embodiment, the UI for picklists and text has a checkbox to force all source values that have not been explicitly mapped to a target value to be auto-mapped to a special “Other” bucket value. If this option is not selected, then all non-mapped values may appear as if they mapped to a bucket value with the identical name as the source value.
Report Available Fields
Bucket fields may be displayed in a special bucket folder in the available fields tree. Similar to other fields, they can be dragged to the preview pane, double-clicked, multi-selected, and searched. In an embodiment, async execution is supported when a bucket field is added to a report.
Field Filter Available Fields
In an embodiment, all bucket fields defined in a report are included in field selector dropdown for filters. They appear at the beginning of the list. They can be quick searched like other fields. In an embodiment, ext store for the available field is created once only on page load. With bucket fields created/deleted on the fly, the store may need to be kept in sync.
Report Preview Column UI
In an embodiment, once a bucket has been defined and added to the report's column list, the column selector for this new bucket field can support sorting, grouping, etc. similar to regular fields. The “summarize this field” may be greyed out. Bucketing for fields that have already been bucketed may be disabled. A bucket field can be re-positioned with the report's list of columns.
In an embodiment, a SQL statement or a single SQL statement is generated to calculate a bucket or multiple buckets (e.g., two or more buckets).
ReportTypeInfo
In an embodiment, the class contains all ReportColumn objects specific to a standard or custom report type. It may be used to validate if a column name/id is valid. The class, or a wrapper, may need to include bucket fields as well that are specific to a report. This class, as suggested by the name ReportType, may not be aware of report level information where bucket fields live.
The SQL code generation for bucket fields may differ from other fields because a bucket is a calculation that is based upon another reporting column. This dependency adds complexity because Oracle does not allow an expression in the Select list to refer to an alias of an expression that is defined in the same select list. However, it may be necessary for the bucketing calculation to refer to an alias in order to deal with complicated expressions like Opportunity.AGE, as well as to minimize the SQL string length. (Without an alias, the source column's SQL may require repetition for every bucket value, e.g., if you segment opportunity age into 20 ranges then the expression for opportunity.age is replicated 21 times.)
In an embodiment, to avoid Oracle's aliasing restriction, one may construct an outer query block around the original query block and evaluate the bucketing calculation in the outer block. This may create a few differences in code generation:
1. must add a nesting query, i.e., an outer query block that wraps the inner query block
2. the bucket field should generate no SQL in the inner block.
3. the bucket field should generate bucketing SQL in the outer block. This SQL refers to the source column via a column alias defined in the inner block.
In an embodiment, a bucket field in a report starts out as a ReportBucketColumn and is then transformed into a bucket query column as part of query optimization/execution. A bucket query column is modeled as a ReportBucketQueryColumn in the QueryColumn family.
SQL Code Generation
In an embodiment, bucketing may be implemented using custom field formulas. Implementing bucketing for numeric fields may involve defining a custom formula field using nested IF functions. The generated SQL below uses nested Oracle CASE-WHEN expressions. Note that it maps null values to 0.
In an embodiment, implementing bucketing for picklists and text fields is done with a custom formula field using the CASE function. Below is an example of some generated SQL:
Implementing bucketing for picklists for the “uncategorized” bucketing feature may be done with a similar formula to above except the default value is replaced with the source field. Due to constraints on picklists and formulas this may also require an explicit data type cast via the TEXT function.Below is another example of some generated SQL:
Security
In an embodiment, visibility (FLS) to a bucket field is controlled by the visibility to the bucket's source field. For example, if account.billingstate is bucketed by a bucket field called BillingRegion, then the visibility of BillingRegion is determined by the visibility to account.billingstate.
In an embodiment, CRUD is determined by the user's ability to customize the report. If access is granted to the report builder, then that access may include the ability to create/edit/delete bucket fields. Various methods may be implemented to prevent SQL injection.
Environment 1810 is an environment in which an on-demand database service exists. User system 1812 may be any machine or system that is used by a user to access a database user system. For example, any of user systems 1812 can be a handheld computing device, a mobile phone, a laptop computer, a work station, and/or a network of computing devices. As illustrated in
An on-demand database service, such as system 1816, is a database system that is made available to outside users that do not need to necessarily be concerned with building and/or maintaining the database system, but instead may be available for their use when the users need the database system (e.g., on the demand of the users). Some on-demand database services may store information from one or more tenants stored into tables of a common database image to form a multi-tenant database system (MTS). Accordingly, “on-demand database service 1816” and “system 1816” will be used interchangeably herein. A database image may include one or more database objects. A relational database management system (RDMS) or the equivalent may execute storage and retrieval of information against the database object(s). Application platform 1818 may be a framework that allows the applications of system 1816 to run, such as the hardware and/or software, e.g., the operating system. In an embodiment, on-demand database service 1816 may include an application platform 1818 that enables creation, managing and executing one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems 1812, or third party application developers accessing the on-demand database service via user systems 1812.
The users of user systems 1812 may differ in their respective capacities, and the capacity of a particular user system 1812 might be entirely determined by permissions (permission levels) for the current user. For example, where a salesperson is using a particular user system 1812 to interact with system 1816, that user system has the capacities allotted to that salesperson. However, while an administrator is using that user system to interact with system 1816, that user system has the capacities allotted to that administrator. In systems with a hierarchical role model, users at one permission level may have access to applications, data, and database information accessible by a lower permission level user, but may not have access to certain applications, database information, and data accessible by a user at a higher permission level. Thus, different users will have different capabilities with regard to accessing and modifying application and database information, depending on a user's security or permission level.
Network 1814 is any network or combination of networks of devices that communicate with one another. For example, network 1814 can be any one or any combination of a LAN (local area network), WAN (wide area network), telephone network, wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. As the most common type of computer network in current use is a TCP/IP (Transfer Control Protocol and Internet Protocol) network, such as the global internetwork of networks often referred to as the “Internet” with a capital “I,” that network will be used in many of the examples herein. However, it should be understood that the networks that the one or more implementations might use are not so limited, although TCP/IP is a frequently implemented protocol.
User systems 1812 might communicate with system 1816 using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, user system 1812 might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages to and from an HTTP server at system 1816. Such an HTTP server might be implemented as the sole network interface between system 1816 and network 1814, but other techniques might be used as well or instead. In some implementations, the interface between system 1816 and network 1814 includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. At least as for the users that are accessing that server, each of the plurality of servers has access to the MTS′ data; however, other alternative configurations may be used instead.
In one embodiment, system 1816, shown in
One arrangement for elements of system 1816 is shown in
Several elements in the system shown in
According to one embodiment, each user system 1812 and all of its components are operator configurable using applications, such as a browser, including computer code run using a central processing unit such as an Intel Pentium® processor or the like. Similarly, system 1816 (and additional instances of an MTS, where more than one is present) and all of their components might be operator configurable using application(s) including computer code to run using a central processing unit such as processor system 1817, which may include an Intel Pentium® processor or the like, and/or multiple processor units. A computer program product embodiment includes a machine-readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the embodiments described herein. Computer code for operating and configuring system 1816 to intercommunicate and to process webpages, applications and other data and media content as described herein are preferably downloaded and stored on a hard disk, but the entire program code, or portions thereof, may also be stored in any other volatile or non-volatile memory medium or device as is well known, such as a ROM or RAM, or provided on any media capable of storing program code, such as any type of rotating media including floppy disks, optical discs, digital versatile disk (DVD), compact disk (CD), microdrive, and magneto-optical disks, and magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Additionally, the entire program code, or portions thereof, may be transmitted and downloaded from a software source over a transmission medium, e.g., over the Internet, or from another server, as is well known, or transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as are well known. It will also be appreciated that computer code for implementing embodiments can be implemented in any programming language that can be executed on a client system and/or server or server system such as, for example, C, C++, HTML, any other markup language, Java™, JavaScript, ActiveX, any other scripting language, such as VBScript, and many other programming languages as are well known may be used. (Java™ is a trademark of Oracle America, Inc.).
According to one embodiment, each system 1816 is configured to provide webpages, forms, applications, data and media content to user (client) systems 1812 to support the access by user systems 1812 as tenants of system 1816. As such, system 1816 provides security mechanisms to keep each tenant's data separate unless the data is shared. If more than one MTS is used, they may be located in close proximity to one another (e.g., in a server farm located in a single building or campus), or they may be distributed at locations remote from one another (e.g., one or more servers located in city A and one or more servers located in city B). As used herein, each MTS could include one or more logically and/or physically connected servers distributed locally or across one or more geographic locations. Additionally, the term “server” is meant to include a computer system, including processing hardware and process space(s), and an associated storage system and database application (e.g., OODBMS or RDBMS) as is well known in the art. It should also be understood that “server system” and “server” are often used interchangeably herein. Similarly, the database object described herein can be implemented as single databases, a distributed database, a collection of distributed databases, a database with redundant online or offline backups or other redundancies, etc., and might include a distributed database or storage network and associated processing intelligence.
User system 1812, network 1814, system 1816, tenant data storage 1822, and system data storage 1824 were discussed above in
Application platform 1818 includes an application setup mechanism 1938 that supports application developers' creation and management of applications, which may be saved as metadata into tenant data storage 1822 by save routines 1936 for execution by subscribers as one or more tenant process spaces 1904 managed by tenant management process 1910 for example. Invocations to such applications may be coded using PL/SOQL 34 that provides a programming language style interface extension to API 1932. A detailed description of some PL/SOQL language embodiments is discussed in commonly owned U.S. Pat. No. 7,730,478 entitled, METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by Craig Weissman, filed Sep. 21, 2007, which is incorporated in its entirety herein for all purposes. Invocations to applications may be detected by one or more system processes, which manages retrieving application metadata 1916 for the subscriber making the invocation and executing the metadata as an application in a virtual machine.
Each application server 1900 may be communicably coupled to database systems, e.g., having access to system data 1825 and tenant data 1823, via a different network connection. For example, one application server 19001 might be coupled via the network 1814 (e.g., the Internet), another application server 1900N-1 might be coupled via a direct network link, and another application server 1900N might be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are typical protocols for communicating between application servers 1900 and the database system. However, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.
In certain embodiments, each application server 1900 is configured to handle requests for any user associated with any organization that is a tenant. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server 1900. In one embodiment, therefore, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 1900 and the user systems 1812 to distribute requests to the application servers 1900. In one embodiment, the load balancer uses a least connections algorithm to route user requests to the application servers 1900. Other examples of load balancing algorithms, such as round robin and observed response time, also can be used. For example, in certain embodiments, three consecutive requests from the same user could hit three different application servers 1900, and three requests from different users could hit the same application server 1900. In this manner, system 1816 is multi-tenant, wherein system 1816 handles storage of, and access to, different objects, data and applications across disparate users and organizations.
As an example of storage, one tenant might be a company that employs a sales force where each salesperson uses system 1816 to manage their sales process. Thus, a user might maintain contact data, leads data, customer follow-up data, performance data, goals and progress data, etc., all applicable to that user's personal sales process (e.g., in tenant data storage 1822). In an example of a MTS arrangement, since all of the data and the applications to access, view, modify, report, transmit, calculate, etc., can be maintained and accessed by a user system having nothing more than network access, the user can manage his or her sales efforts and cycles from any of many different user systems. For example, if a salesperson is visiting a customer and the customer has Internet access in their lobby, the salesperson can obtain critical updates as to that customer while waiting for the customer to arrive in the lobby.
While each user's data might be separate from other users' data regardless of the employers of each user, some data might be organization-wide data shared or accessible by a plurality of users or all of the users for a given organization that is a tenant. Thus, there might be some data structures managed by system 1816 that are allocated at the tenant level while other data structures might be managed at the user level. Because an MTS might support multiple tenants including possible competitors, the MTS should have security protocols that keep data, applications, and application use separate. Also, because many tenants may opt for access to an MTS rather than maintain their own system, redundancy, up-time, and backup are additional functions that may be implemented in the MTS. In addition to user-specific data and tenant specific data, system 1816 might also maintain system level data usable by multiple tenants or other data. Such system level data might include industry reports, news, postings, and the like that are sharable among tenants.
In certain embodiments, user systems 1812 (which may be client systems) communicate with application servers 1900 to request and update system-level and tenant-level data from system 1816 that may require sending one or more queries to tenant data storage 1822 and/or system data storage 1824. System 1816 (e.g., an application server 1900 in system 1816) automatically generates one or more SQL statements (e.g., one or more SQL queries) that are designed to access the desired information. System data storage 1824 may generate query plans to access the requested data from the database.
Each database can generally be viewed as a collection of objects, such as a set of logical tables, containing data fitted into predefined categories. A “table” is one representation of a data object, and may be used herein to simplify the conceptual description of objects and custom objects. It should be understood that “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Each row or record of a table contains an instance of data for each category defined by the fields. For example, a CRM database may include a table that describes a customer with fields for basic contact information such as name, address, phone number, fax number, etc. Another table might describe a purchase order, including fields for information such as customer, product, sale price, date, etc. In some multi-tenant database systems, standard entity tables might be provided for use by all tenants. For CRM database applications, such standard entities might include tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. It should be understood that the word “entity” may also be used interchangeably herein with “object” and “table.”
In some multi-tenant database systems, tenants may be allowed to create and store custom objects, or they may be allowed to customize standard entities or objects, for example by creating custom fields for standard objects, including custom index fields. U.S. Pat. No. 7,779,039, filed Apr. 2, 2004, entitled “Custom Entities and Fields in a Multi-Tenant Database System”, which is hereby incorporated herein by reference, teaches systems and methods for creating custom objects as well as customizing standard objects in a multi-tenant database system. In certain embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. It is transparent to customers that their multiple “tables” are in fact stored in one large table or that their data may be stored in the same table as the data of other customers.
While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.
This application claims the benefit of U.S. Provisional Patent Application 61/500,219, entitled SYSTEMS AND METHODS FOR MAPPING A VALUE TO A NEW DOMAIN, by Marko Koosel, filed Jun. 23, 2011, the entire contents of which are incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5577188 | Zhu | Nov 1996 | A |
| 5608872 | Schwartz | Mar 1997 | A |
| 5649104 | Carleton | Jul 1997 | A |
| 5715450 | Ambrose et al. | Feb 1998 | A |
| 5761419 | Schwartz | Jun 1998 | A |
| 5819038 | Carleton | Oct 1998 | A |
| 5821937 | Tonelli et al. | Oct 1998 | A |
| 5831610 | Tonelli et al. | Nov 1998 | A |
| 5873096 | Lim et al. | Feb 1999 | A |
| 5918159 | Fomukong et al. | Jun 1999 | A |
| 5963953 | Cram et al. | Oct 1999 | A |
| 6092083 | Brodersen et al. | Jul 2000 | A |
| 6169534 | Raffel et al. | Jan 2001 | B1 |
| 6178425 | Brodersen et al. | Jan 2001 | B1 |
| 6189011 | Lim et al. | Feb 2001 | B1 |
| 6216135 | Brodersen et al. | Apr 2001 | B1 |
| 6233617 | Rothwein et al. | May 2001 | B1 |
| 6266669 | Brodersen et al. | Jul 2001 | B1 |
| 6295530 | Ritchie et al. | Sep 2001 | B1 |
| 6324568 | Diec et al. | Nov 2001 | B1 |
| 6324693 | Brodersen et al. | Nov 2001 | B1 |
| 6336137 | Lee et al. | Jan 2002 | B1 |
| D454139 | Feldcamp et al. | Mar 2002 | S |
| 6367077 | Brodersen et al. | Apr 2002 | B1 |
| 6393605 | Loomans | May 2002 | B1 |
| 6405220 | Brodersen et al. | Jun 2002 | B1 |
| 6434550 | Warner et al. | Aug 2002 | B1 |
| 6446089 | Brodersen et al. | Sep 2002 | B1 |
| 6535909 | Rust | Mar 2003 | B1 |
| 6549908 | Loomans | Apr 2003 | B1 |
| 6553563 | Ambrose et al. | Apr 2003 | B2 |
| 6560461 | Fomukong et al. | May 2003 | B1 |
| 6574635 | Stauber et al. | Jun 2003 | B2 |
| 6577726 | Huang et al. | Jun 2003 | B1 |
| 6601087 | Zhu | Jul 2003 | B1 |
| 6604117 | Lim et al. | Aug 2003 | B2 |
| 6604128 | Diec | Aug 2003 | B2 |
| 6609150 | Lee et al. | Aug 2003 | B2 |
| 6621834 | Scherpbier | Sep 2003 | B1 |
| 6654032 | Zhu | Nov 2003 | B1 |
| 6665648 | Brodersen et al. | Dec 2003 | B2 |
| 6665655 | Warner et al. | Dec 2003 | B1 |
| 6684438 | Brodersen et al. | Feb 2004 | B2 |
| 6711565 | Subramaniam et al. | Mar 2004 | B1 |
| 6724399 | Katchour et al. | Apr 2004 | B1 |
| 6728702 | Subramaniam et al. | Apr 2004 | B1 |
| 6728960 | Loomans et al. | Apr 2004 | B1 |
| 6732095 | Warshavsky et al. | May 2004 | B1 |
| 6732100 | Brodersen et al. | May 2004 | B1 |
| 6732111 | Brodersen et al. | May 2004 | B2 |
| 6754681 | Brodersen et al. | Jun 2004 | B2 |
| 6763351 | Subramaniam et al. | Jul 2004 | B1 |
| 6763501 | Zhu | Jul 2004 | B1 |
| 6768904 | Kim | Jul 2004 | B2 |
| 6782383 | Subramaniam et al. | Aug 2004 | B2 |
| 6804330 | Jones et al. | Oct 2004 | B1 |
| 6826565 | Ritchie et al. | Nov 2004 | B2 |
| 6826582 | Chatterjee et al. | Nov 2004 | B1 |
| 6826745 | Coker | Nov 2004 | B2 |
| 6829655 | Huang et al. | Dec 2004 | B1 |
| 6842748 | Warner et al. | Jan 2005 | B1 |
| 6850895 | Brodersen et al. | Feb 2005 | B2 |
| 6850949 | Warner et al. | Feb 2005 | B2 |
| 7062502 | Kesler | Jun 2006 | B1 |
| 7340411 | Cook | Mar 2008 | B2 |
| 7401094 | Kesler | Jul 2008 | B1 |
| 7620655 | Larsson | Nov 2009 | B2 |
| 7698160 | Beaven et al. | Apr 2010 | B2 |
| 7703021 | Flam | Apr 2010 | B1 |
| 8010663 | Firminger et al. | Aug 2011 | B2 |
| 8082301 | Ahlgren et al. | Dec 2011 | B2 |
| 8095413 | Beaven et al. | Jan 2012 | B1 |
| 8095594 | Beaven et al. | Jan 2012 | B2 |
| 8275836 | Beaven et al. | Sep 2012 | B2 |
| 20010044791 | Richter et al. | Nov 2001 | A1 |
| 20020072951 | Lee et al. | Jun 2002 | A1 |
| 20020082892 | Raffel | Jun 2002 | A1 |
| 20020129352 | Brodersen et al. | Sep 2002 | A1 |
| 20020140731 | Subramaniam et al. | Oct 2002 | A1 |
| 20020143997 | Huang et al. | Oct 2002 | A1 |
| 20020162090 | Parnell et al. | Oct 2002 | A1 |
| 20020165742 | Robbins | Nov 2002 | A1 |
| 20030004971 | Gong | Jan 2003 | A1 |
| 20030018705 | Chen et al. | Jan 2003 | A1 |
| 20030018830 | Chen et al. | Jan 2003 | A1 |
| 20030066031 | Laane et al. | Apr 2003 | A1 |
| 20030066032 | Ramachandran et al. | Apr 2003 | A1 |
| 20030069936 | Warner et al. | Apr 2003 | A1 |
| 20030070000 | Coker et al. | Apr 2003 | A1 |
| 20030070004 | Mukundan et al. | Apr 2003 | A1 |
| 20030070005 | Mukundan et al. | Apr 2003 | A1 |
| 20030074418 | Coker et al. | Apr 2003 | A1 |
| 20030120675 | Stauber et al. | Jun 2003 | A1 |
| 20030151633 | George et al. | Aug 2003 | A1 |
| 20030159136 | Huang et al. | Aug 2003 | A1 |
| 20030187921 | Diec et al. | Oct 2003 | A1 |
| 20030189600 | Gune et al. | Oct 2003 | A1 |
| 20030204427 | Gune et al. | Oct 2003 | A1 |
| 20030206192 | Chen et al. | Nov 2003 | A1 |
| 20040001092 | Rothwein et al. | Jan 2004 | A1 |
| 20040015981 | Coker et al. | Jan 2004 | A1 |
| 20040027388 | Berg et al. | Feb 2004 | A1 |
| 20040128001 | Levin et al. | Jul 2004 | A1 |
| 20040186860 | Lee et al. | Sep 2004 | A1 |
| 20040193510 | Catahan et al. | Sep 2004 | A1 |
| 20040199489 | Barnes-Leon et al. | Oct 2004 | A1 |
| 20040199536 | Barnes Leon et al. | Oct 2004 | A1 |
| 20040249854 | Barnes-Leon et al. | Dec 2004 | A1 |
| 20040260534 | Pak et al. | Dec 2004 | A1 |
| 20040260659 | Chan et al. | Dec 2004 | A1 |
| 20040268299 | Lei et al. | Dec 2004 | A1 |
| 20050050555 | Exley et al. | Mar 2005 | A1 |
| 20050091098 | Brodersen et al. | Apr 2005 | A1 |
| 20080126476 | Nicholas | May 2008 | A1 |
| 20090063415 | Chatfield et al. | Mar 2009 | A1 |
| 20090319403 | Schlueter et al. | Dec 2009 | A1 |
| 20100306199 | Andrea et al. | Dec 2010 | A1 |
| 20110264628 | Sokolan | Oct 2011 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20120330960 A1 | Dec 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61500219 | Jun 2011 | US |
