The disclosure relates to the field of presentation of data in enterprise applications and more particularly to techniques for automatic generation of hierarchical data for presentation in hierarchy visualizations.
Many businesses and other organizations use software applications and/or suites of such applications to organize their business affairs, track business performance, manage employee data, and perform similar functions. These “enterprise” applications are often quite complex, relying on numerous database tables to store and manage data for virtually every aspect of an organization's business.
The enterprise applications often incorporate, display and/or perform operations on data or information that is hierarchical in nature. For example, enterprise applications often deal with corporations and other entities that correspond to hierarchical organizational structures.
Conventional enterprise applications allow users to create different types of hierarchies, but there is no easy or convenient way to view a graphical representation of the hierarchies. Nor do the conventional tools provide an effective interface to configure the graphical representation of that data. Moreover, the conventional tools fail to provide an effective interface to configure data-specific analysis, aggregation and presentation of such hierarchical data.
The present disclosure describes various embodiments that use a flexible framework to allow a user to configure the data displayed in the visualization, which permits users to visualize the relationships and data aggregation (e.g., sum of children data, counts of child data, etc.) of the hierarchical data. Therefore, there is a need for improvements.
The present disclosure provides an improved method, system, and computer program product suited to address the aforementioned issues with legacy approaches. More specifically, the present disclosure provides a detailed description of techniques used in methods, systems, and computer program products for automatic generation of hierarchical data for presentation in hierarchy visualizations.
The method form commences by identifying a hierarchy of data maintained by an enterprise application (e.g., in a database). A hierarchy processor or other processor reads the hierarchy of data to configure a graphical representation of the hierarchy of data to be displayed on a display device. The graphical representation includes a graphical display indication corresponding to a relationship between items in the displayed hierarchy. Additional display indications include a calculated summary value of aggregated data, such as where the aggregated data is calculated using an aggregation function.
Further details of aspects, objectives, and advantages of the disclosure are described below and in the detailed description, drawings, and claims. Both the foregoing general description of the background and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the claims.
Disclosed herein and in the accompanying figures are exemplary environments, methods, and systems for automatic generation of hierarchical data for presentation in hierarchy visualizations.
The structure of data of any sort, including business data, often observes a hierarchical organization. For example, a company may have subsidiaries, a subsidiary may have operating units, an operating unit may have an executive team, etc. In some cases, a particular hierarchical structure is used to initially define the data (e.g., into a relation within a relational database system). In some cases, a hierarchical relationship can be imputed from relationship(s) in the data itself.
Legacy systems for presenting hierarchical data have relied on hierarchical input in accordance with hierarchical input rules (e.g., for building “org charts”), and data collected in accordance with the given hierarchical input can be presented in a hierarchy chart. However, as is disclosed herein, hierarchical relationships can be found in the data even in absence of explicit observance of hierarchical input rules. Moreover, legacy systems have not kept pace with the need for presenting and analyzing data in a hierarchical fashion. For example, while business managers might avail themselves of a hierarchical presentation of the relationships between a particular subsidiary and its constituent operating units, a business manage might want to see (for example) a revenue contribution for each of the operating units, and have the sum of the contributions aggregated for display on a hierarchical chart that shows (1) the entities (e.g., subsidiary, operating units, etc.), (2) the relationship or relationships between the entities, and (3) the individual contributions of the entities in the operating units.
Some of the terms used in this description are defined below for easy reference.
The presented terms and their respective definitions are not rigidly restricted to these definitions—a term may be further defined by the term's use within this disclosure.
Reference is now made in detail to certain embodiments. The disclosed embodiments are not intended to be limiting of the claims.
As shown, the environment 1A00 includes one or more users 105 (e.g., user 1051, user 1052) situated at one or more user stations (e.g., user station 102). The user station 102 comprises any type of computing station that may be used to operate in conjunction with and/or interface with any one or more enterprise applications (e.g., enterprise application 1111, enterprise application 1112, enterprise application 111N, etc.), which enterprise applications are hosted on one or more servers (e.g., server 1181, server 1182 etc.).
Strictly as examples, enterprise applications can include supply chain management (“SCM”) applications that manage raw materials, work-in-process and/or finished products, and coordinate with suppliers; customer relations management (“CRM”) applications that are used to track, store and/or manage customer information; financial applications that track and/or analyze the financial performance of the organization; human resources applications that provide management of the human resources functions of the organization, and other applications. In some cases, these applications are standalone applications; in other cases, a single business application or suite of applications might provide some or all such functionality.
Examples of user stations include workstations, personal computers, or remote computing terminals. Exemplary user stations comprise a display device 103, such as a display monitor, for displaying a user interface to users at the user station. A user station 102 may comprises one or more input devices for the user to provide operational control over the activities of the system such as a touch screen, and/or a mouse, and/or a keyboard to manipulate and/or point to an object displayed in a graphical user interface in order to generate user inputs to the enterprise application(s) at server 118.
In addition to the shown enterprise applications, a server hosts a hierarchy processor 120, which in turn hosts an interface rendering module 127. In some embodiments, an interface rendering module 127 is used to generate graphical hierarchy display data into computer readable code to form a graphical representation 123 (e.g., in HTML, HTML5, gifs, jpegs, etc.) that can be communicated over a communication path as graphical hierarchical display data 101 (e.g., HTML, HTML5, gifs, jpegs, etc.) to be displayed at a display device 103 at the user station 102. The hierarchical display interface 107 advantageously allows a user to visualize and interact with any of one or more relationships between the displayed entities (e.g., using a graphical display indication such as a line or arrow). The hierarchical display interface 107 shows various data corresponding to a particular entity (e.g., customer, business unit, etc.). Furthermore, aggregated data retrieved from the entity's children/descendants is presented, and screen devices are provided to allow a user to drill down to display more detail and/or to take next actions to change or otherwise interact with the hierarchical display interface 107.
As shown, constituent processes hosted on a server can communicate with a database engine 125. Such a database engine can process queries (e.g., using a query processor 121) and can retrieve data from database storage 110. Database storage can store business data 141 and templates 131. The database storage 110 is a computer readable storage device. The computer readable storage device comprises any combination of hardware and software that allows for ready access to the data that is located at the computer readable storage device. For example, the computer readable storage device could be implemented as computer memory operatively managed by an operating system. The computer readable storage device could also be implemented as an electronic database system having storage on persistent and/or non-persistent storage. Further characteristics of databases implemented using computer readable storage are described in
As shown, a computer readable storage (e.g., database storage 110) holds one or more templates 131 that be set up to control the parameters of how the interface rendering module 127 operates to generate the hierarchical display interface 107. Furthermore, one or more templates can be set up to control the parameters of how the data pertaining to an entity (e.g., customer, supplier) is collected (e.g., see
The templates may be populated using any forms of business data. While the illustrative embodiments specifically refer to a “customer hierarchy”, and/or to “customer data”, it is noted that the disclosed techniques are applicable to any forms of a hierarchy of data 142 (e.g., a hierarchy of entities) as may be stored and as may be used in an enterprise application. For example, the disclosed techniques may be applied to graphically display “supplier” data for a supply chain application. Further, the hierarchies discussed in the disclosed techniques can be any hierarchy present in the data, and such hierarchies are not limited to hierarchies as may be described in any particular instance of a schema or data definition. Entities within a hierarchy are related by one or more relationships (e.g., relationships between entities 143, as shown).
The shown hierarchy visualization comprises graphical depictions of entities juxtaposed into a hierarchy. This example includes a focus node 160. The shown focus node 160 has children and other descendants shown as child node 1611, child node 1612, child node 161N, and Nth level node 163. Further, the hierarchy visualization depicts relationships between entities (e.g., parent-child relationships 181 between entities), and may include a downline relationship 167, and/or an upline relationship 165. Such relationships are shown as line segments, however other techniques to depict a hierarchical relationship are possible (e.g., juxtaposition, shadowing, etc.).
Some of the descriptions herein refer to aspects of hierarchy visualizations using the following terms:
In an interactive implementation of the shown hierarchy, a user can select to view different types of data and/or select items (e.g., “clickable items”) to see more details. For example, a hierarchical display interface 107 can include interactive controls for user interaction. Strictly as examples:
A user can also select to view more data or more of the relationships (e.g., using a zoom operation). The display may present any number of levels for the hierarchy. Therefore, while entity hierarchy 1B00 illustratively presents only a two-level hierarchy, it is noted that the techniques described herein are applicable to any number of depth levels of hierarchy and/or to any extent or width of any number of nodes.
A node can be presented in a hierarchical display interface (e.g., an interface screen), and can be decorated with various node-specific information. An exemplary interface screen is presently discussed.
As shown, the depiction of interface screen 200 includes a hierarchical display interface 107. The particular look-and-feel of the display can be at least partially defined by a template 131, and such a template can be named using template indication 202. Templates can be used to describe characteristics of a hierarchical display interface including specification of how hierarchical data is collected (e.g., see
In this specific example, the template indication identifies an object named “MYTMPL-My Template”. Such an object may further reference other objects that are used when presenting a hierarchical display interface 107. And, such further referenced objects may specify data to be aggregated into one or more roll-up indications 203 (e.g., using a roll-up indication 2031, roll-up indication 2032, etc.). Such a roll-up indication can be the name of a data item in a database or can be a user-specified label. As shown, the roll-up indication is associated with a roll-up value (e.g., roll-up value 2011, roll-up value 2012, etc.).
Any node (e.g., the focus node, as shown) can comprise a next action screen device 204. In this example, the next action screen device is a triangular screen device that indicates availability of next actions. Such next actions can include next actions that are relevant to the underlying application. For example, in an accounting application, such next actions may comprise:
Such next actions can be indicated using a pop-up screen device or any other screen device as may be implemented by the underlying application.
Controls can be established and control screen devices can be displayed to aid the user in navigating between nodes. For example, any node shown in the display (e.g., a child node of the then current focus node) can be selected to become the new focus node, and the display will be recalculated and refreshed.
An application may form a hierarchical display interface using application-native routines (e.g., lists and/or lists of lists), or an application may form a hierarchical display interface using a hierarchy processor 120. In either case (or other cases as may be selected by an implementer), an application may form a hierarchical display interface using an approach that includes retrieving and processing hierarchical data. Such an approach is presently discussed.
As shown, the flowchart commences to retrieve a hierarchy by selecting a focus node (see operation 302). The selection can come from a user selection, or can come from a computer-implemented selection of a focus node. As earlier indicated, a focus node can correspond to a particular business entity (e.g., customer, supplier). A query can be formed using the business data to retrieve relationship information (e.g., parents, children, siblings, etc.) to determine a hierarchical organization (see operation 3061 and operation 3062). This might be performed recursively to retrieve the full hierarchical structure. Strictly as an example, Table 1 gives a relation having an implied hierarchy:
In the example of Table 1, “A” has a child “B”. And “B” has children “C”, “D”, and “E”. And, “E” has a child “F”. The node “F” is a grandchild of “A”. Table 1 also gives a data value column. In this case the data is given in dollars (e.g., $1, $2, $3, etc.). Such data can be aggregated or rolled-up through a hierarchy such that a given node in the hierarchy can display a rollup value. In the example of Table 1, node “F” (a lowest level node) has a node value of $8. Since “F” has no children, there is no contribution from lower level entities, so the rollup value of “F” is $0 and $0 is contributed to the rollup value of parent “E”. Parent “E” in turn has a node value of $7, and a contribution from its children (in this case, node “F”) of $8, so has an aggregated value of $15.
In some cases data is stored such that child points to parent. In such a case the hierarchy can be retrieved beginning with a focus node, and referring to it as a child node. Table 2 depicts storage of hierarchical relationships.
The hierarchy in Table 2 described a hierarchy where A is the focus node of the hierarchy. Relationship and rollup values are as follows:
After retrieving the hierarchy, the retrieved data is used with a template to generate graphical display data (see subsystem 307). A template is retrieved (see operation 305), and the flow then proceeds to use the retrieved template(s) to generate graphical display data. The operations to generate graphical display data can be partitioned such that objects constituent to a hierarchical display interface are organized into a hierarchical representation (see operation 308) and then such objects are populated with values corresponding to data fields (see operation 309). Having the objects hierarchically organized and populated with data values, the data can then be aggregated (see operation 310) so as to codify rollup indications and rollup values in a machine-readable representation. In the specific partitioning shown in
In some embodiments, a framework is provided to be used by the enterprise applications 111 to store parameters and configuration controls for display and interaction. This allows users to configure the data displayed in the hierarchy with flexible levels of customization. Strictly as one example, a framework may facilitate business data items (e.g., attributes of entity, such as customer's balance) to be defined (
A framework may further be configured to facilitate definition of one or more data fields, which data fields are added, for example, to a template that describes the layout, labeling, and formatting of the data. Labeling and formatting can be specific to a particular data item in a one-to-one correspondence.
The following provides a further description of the foregoing, and interrelationships between components. The selection of components, and their descriptions and interrelationships is purely illustrative, and is not limiting of the claims.
A template can comprise information configurable by users. A template can correspond to an individual user or can correspond to a user role. Different roles may have different levels of access to the template. By including or excluding data fields in the template accessible by user, it permits template to be used as a security measure to control the level of access given to individuals and groups in a company.
Data items in the template can be grouped into views to provide different analysis and visibility focus. As an example, a “Customer Balance” view can be used to display data fields that are useful in analyzing the customer's balance information. A “Customer Metrics” view can be used to focus on customer performance. Within each view, a zoom level can also be created to determine whether to display more or less data.
As shown, a data item 402 is identified by a name (e.g., “current balance”). Such a data item is retrievable from a storage facility (e.g., from a database using a query). The data item may refer to a data record that comprises multiple record fields, and the multiple record fields may each have a field name and a field value. For example, and as shown, a record format of data item 402 comprises a plurality of record fields (e.g., “Record Name”, “Value Fieldname”, “Currency Fieldname”, etc.). Among the record fields can be a variable to aggregate (e.g., a rollup variable 450), and the record fields can also comprise details used in an aggregation operation (e.g., aggregation function specification 452, aggregation function 453). An aggregation function 453 can be any function that can operate on two or more data values. As non-limiting examples, an aggregation function can be {“SUM”, “COUNT”, “MAX”, “MIN”}, etc.
Some embodiments of a data item definition screen 400 comprise a preview pane 454, which preview pane facilitates user verification of the look-and-feel (e.g., label, layout, formatting, etc.) of a subject data item.
As shown, a particular data item (see
A user can specify attributes of a data item, and such a data item can be referred to using a data field name 552. Additional attributes can be specified, for example using a rollup indication 554.
The ID of the subject data field (e.g., “SFB00002”) is then associated with a data item (e.g., “SIB00001”), which is then associated with a template, which further serves to describe the layout and presentation of the specified data fields of the subject data item. Such a template that serves to describe the layout and presentation of a hierarchical display interface is shown in
The shown node template definition screen includes a node view panel 602, a node zoom panel 604, and an array of node fields 606. Operation of node template definition screen is facilitated by UI controls (e.g., “First”, “Last” and “+”/“−” page controls).
The shown node template definition screen includes a template ID (e.g., “MYTMPL”), and a handle, (e.g., Description “My Template”). The node view panel 602 includes a view indication (e.g., “Balance”).
In the node fields panel, any number of data fields can be displayed, and various formatting options can be set by the user. For example, the field “Current Balance” is associated with a “Right” alignment. In addition to fields, the node fields panel may present formatting options for headers, labels, and actions. As an example, when a field is specified (e.g., by a configuring user) to correspond to an “Action”, the configuring user can provide a label to display in a displayed node, in which case, when a user 105 clicks on the label, a popup is displayed to allow user 105 to select any of the actions associated with the node.
As shown, the data aggregation approach commences by selecting a focus node (see operation 702), then retrieving data pertaining to the focus node and its child nodes (see operation 703) through to the lowest level of a hierarchy rooted at the focus node. The data aggregation approach determines a set of rollup variables, for example, from a template 131 or from data items (see operation 704). A set of rollup variables can be amassed by parsing a template corresponding to the focus node. Then, the flow traverses through the retrieved nodes while collecting a set of rollup values for the rollup variables (see operation 706). Having the set of rollup values for the rollup variables, an aggregation function can be applied (see operation 708). The particular aggregation function may observe levels of hierarchy when performing the aggregation function. For example, an aggregation function “Sum”, might be defined as “calculate the sum of the values given in one level below”, and the result or results of applying the aggregation function can be displayed (see operation 710). In some cases an aggregation function is applied top-down, and in other cases an aggregation function is applied bottom-up.
Described herein are novel approaches that allow a user of an enterprise system to visualize business data hierarchy relationships in a graphical format. The various embodiments use a flexible framework to allow a user to configure the data displayed in the visualization. The disclosure enables a better approach for users to access the hierarchical data, for example to facilitate making better business decisions.
As shown, the system comprises:
According to one embodiment of the disclosure, computer system 1000 performs specific operations by processor 1007 executing one or more sequences of one or more instructions contained in system memory 1008. Such instructions may be read into system memory 1008 from another computer readable/usable medium, such as a static storage device or a disk drive 1010. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the disclosure. Thus, embodiments of the disclosure are not limited to any specific combination of hardware circuitry and/or software. In one embodiment, the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the disclosure.
The term “computer readable medium” or “computer usable medium” as used herein refers to any medium that participates in providing instructions to processor 1007 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 1010. Volatile media includes dynamic memory, such as system memory 1008.
Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, or any other magnetic medium; CD-ROM or any other optical medium; punch cards, paper tape, or any other physical medium with patterns of holes; RAM, PROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge, or any other non-transitory medium from which a computer can read data.
In an embodiment of the disclosure, execution of the sequences of instructions to practice the disclosure is performed by a single instance of the computer system 1000. According to certain embodiments of the disclosure, two or more computer systems 1000 coupled by a communications link 1015 (e.g., LAN, PTSN, or wireless network) may perform the sequence of instructions required to practice the disclosure in coordination with one another.
Computer system 1000 may transmit and receive messages, data, and instructions, including programs (e.g., application code), through communications link 1015 and communication interface 1014. Received program code may be executed by processor 1007 as it is received, and/or stored in disk drive 1010 or other non-volatile storage for later execution. Computer system 1000 may communicate through a data interface 1033 to a database 1032 on an external data repository 1031. A module as used herein can be implemented using any mix of any portions of the system memory 1008, and any extent of hard-wired circuitry including hard-wired circuitry embodied as a processor 1007.
In the foregoing specification, the disclosure has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than restrictive sense.
The present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 61/706,408, entitled “METHOD AND SYSTEM FOR IMPLEMENTING GRAPHICAL HIERARCHY VISUALIZATION” (Attorney Docket No. ORA130355-US-PSP), filed Sep. 27, 2012; and the present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 61/780,685, entitled “METHOD AND SYSTEM FOR IMPLEMENTING HIERARCHY GRAPHICAL VISUALIZATION” (Attorney Docket No. ORA130355-US-PSP-1), filed Mar. 13, 2013, both of which are hereby incorporated by reference in their entirety.
Number | Date | Country | |
---|---|---|---|
61706408 | Sep 2012 | US | |
61780685 | Mar 2013 | US |