Enterprise software systems receive, generate and store data related to many aspects of a business enterprise. In some implementations, this enterprise data may relate to marketing, sales, customer relations, supplier relations, inventory, human resources, and/or finances. Graphical reporting systems are commonly used to present enterprise data to users in a coherent manner.
Conventional graphical reporting systems create graphical reports based on report specifications. A report specification defines the layout of report elements (e.g., sections, tables, columns, rows, header, footer, etc.), and the data which is to populate the report elements. When a report is requested, a reporting system generates the report based on a corresponding report specification and stored enterprise data. If the data changes, a report which is subsequently generated based on the same report specification will include the changed data.
Layout components 130 translate the data from the internal model to one or more layout models according to the report specification. Each of layout components 130 corresponds to a particular visualization type (e.g., chart, table, etc.). For example, the layout of a chart in a report may be delegated to one of layout components 130 which is dedicated to chart layout (e.g., a chart engine). This dedicated layout component utilizes its own model for data representation (e.g., data series). Accordingly, the internal model is converted to the model utilized by the layout component dedicated to chart layout.
Rendering engine 140 may include libraries or procedures dedicated to rendering specific visualization types. These libraries are exposed to layout components 130 via respective ones of APIs 145. Continuing with the above example, the layout component 130 dedicated to charting calls one of APIs 145 which corresponds to the chart-rendering libraries of rendering engine 140.
Output client 150 includes controllers 155. Each of controllers 155 is dedicated to outputting a specific visualization type. Output client 150 may include a controller 155 for outputting a chart as received from the chart-rendering libraries of rendering engine 140.
Architecture 100 presents extensibility issues. In order to add support for a new visualization type, architecture 100 requires a new layout component, a new rendering method, and a new client controller. Similarly, in order to change (e.g., enrich) an existing visualization type, corresponding ones of these elements must be rewritten, tested and deployed.
Each visualization type (and corresponding components) is independent of each other and interactions therebetween are not explicitly supported. Consequently, composition of different visualization types is impractical.
The following description is provided to enable any person in the art to make and use the described embodiments and sets forth the best mode contemplated for doing so. Various modifications will remain readily apparent to those in the art.
Structured data 210 may comprise any data source which supports entities and relations therebetween. Structured data 210 may comprise one or more relational, OLAP, XML, and/or tabular data sources.
Structured data 210 may comprise a semantic layer including a set of abstract entities known as semantic objects, each of which associates one or more physical entities of one or more data sources (not shown) with user-friendly names. The semantic objects may exhibit properties (i.e., metadata), such as a data type (e.g., text or numeric), a “qualification” (e.g., dimension, measure, detail . . . ), a “business type” (e.g., financial, time, geography, KPI . . . ), and a structure (e.g., OLAP hierarchies). Types of semantic layers and semantic objects are described in U.S. Pat. No. 5,555,403, and are provided by Business Objects products or other Business Intelligence products. Examples of semantic layers according to some embodiments include Business Objects Universes and OLAP data models.
Structured data 210 may also include report structures according to some embodiments. As will be described in further detail below, a report structure consists of a frame associated with a graphical primitive and at least one data axis. The frame may include zero or more other frames, each of which is also associated with a graphical primitive and at least one data axis. Any frames may be nested within any other frame.
Scripting engine 220 may generate a report based on a report structure and data of structured data 210, and on one of layout scripts 230. Generally, each of layout scripts 230 describes how primitive shapes are arranged with respect to one another within a report. Each of layout scripts 230 includes at least one axis expression and at least one property expression. As will be described below, scripting engine 220 may create instances of a graphical primitive associated with a frame based on data associated with a data axis of the frame and on an associated axis expression of a layout script. Similarly, scripting engine 220 may determine graphical properties of the graphical primitive instances based on data associated with the data axis of the frame and on an associated property expression of the layout script. Structured data 210 may store layout scripts 230 according to some embodiments.
Scripting engine 220 generates a report output including one or more of graphical primitives (e.g., line, box, curve, polygon, circle, etc.) with specified graphical properties (e.g., x-pos, y-pos, z-pos, size, depth, color, focal point, orientation, vertices, center, etc.), and transmits the report output to output client 240. Output client 240 may therefore require only basic graphical rendering functionality to display a report based on the report output.
The link to dimensional data is provided via one or more data axes associated with each frame. Each of the data axes drives the generation of instances of a frame. More particularly, the number of frame instances which will be generated is determined by the actual values of the data axes. The position and other graphical properties of each individual frame instance are determined by layout script 330 as will be described below.
Instantiation of a child frame instance is driven by the data axes of its parent frame. According to some embodiments, a child frame inherits the axes of its parent frame and instantiations thereof iterate over the same axes space. A child frame may be associated with all or part of the axes associated with its parent frame.
The graphical primitive associated with a particular frame may itself be associated with one or more graphical properties. The specific graphical properties for a particular instance of the graphical primitive are determined based on a corresponding property expression of a corresponding layout script 330. By virtue of these property expressions, layout script 330 may control the location (i.e., layout) of a graphical primitive instance with respect to each other graphical primitive instance of report output 340. A property expression may be based on values of dimensional data 320, properties of other (e.g., adjacent) primitive instances, etc. For example, a size of a graphical primitive instance may be based on a magnitude of the data associated with the primitive instance and/or an upper y-position of the primitive instance may be based on a lower y-position of a previous primitive instance.
Layout script 330 also includes axis expressions to drive the generation of primitive instances. The axis expressions (and therefore the generation of primitive instances) may depend at least in part upon the data model expressed within dimensional data 320. In this regard, an axis expression and a property expression of a layout script may be parameterized to allow use with other report structures and/or data bindings.
Layout script 330 may comprise a set of declarative statements governed by grammatical rules. The following describes the grammar of layout script 330 according to some embodiments.
As will be evident from the examples below, the formula-related grammar above may be useful for positioning child frames or frames associated with different sets of axes. For example, functions such as Min, Max, Sum, Count, etc. could be performed not only on data but on graphical properties as well. Since such usage requires the functions to be evaluated in an axis context, the IN function allows specification of the context in which any expression is to be evaluated.
By virtue of the foregoing, report output 340 consists merely of a collection of primitive instances, each of which is associated with one or more properties. Report output 340 may therefore be rendered by any graphical software having knowledge of the primitives and properties. Dedicated report rendering applications are therefore not required according to some embodiments.
Initially, a report structure is determined at 410. The report structure defines a frame, and the frame is associated with a graphical primitive and a data axis. As described above, the frame may be associated with more than one data axis. The report structure may be stored among structured data 210 and acquired therefrom by scripting engine 220 in response to a request from output client 240.
Next, at 420, data associated with the data axis is obtained from a structured data source. The data may include values of the data axis (e.g., Years) as well as data related to the data axis (e.g., Sales). Also obtained at 420 may be data associated with other data axes of the frame and data associated with the data axes of other frames of the report structure.
One or more instances of the graphical primitive are created at 430. The one or more instances of the graphical primitive are created based on the data associated with the data axis and on an axis expression of the layout script. In one simple example, one instance of the primitive is created for every value of the data axis. For frames associated with more than one axis, the axis expression will specify how many instances to create based on values of the more than one associated axis. Scripting engine 220 may also provide default behavior for creating primitive instances based on associated axes.
One or more graphical properties are then determined at 440 based on the data associated with the data axis and on a property expression of the layout script. The determined one or more graphical properties are associated with each of the one or more instances of the graphical primitive created at 430. Accordingly, the position, color, size, rotation, etc. of each graphical instance may differ based on the property expression and the data associated with the data axis. Examples of the foregoing are set forth in
Lastly, at 450, a report is output including the one or more instances of the graphical primitive and the associated one or more graphical properties. An output client may use this information (primitive instances and associated properties) to render a graphical report.
Some embodiments may therefore achieve any type of report layout through declaration of an expression that computes a position of primitive instances (x-pos, y-pos, z-pos, width, height, depth, rotation, etc.) and their graphical properties (color, border, shading, etc.). In contrast to those systems described in the Background, the layout is not dependent upon the availability and capabilities of several visualization-specific components.
More specifically, according to some embodiments, a pie chart is not an API that exposes the elements of a pie chart (e.g., a series of data) but is represented as a set of pie primitives laid out around a point according to a layout script. The rendering of the pie chart can be changed dramatically by simply changing the layout script, as opposed to changing the pie chart API by rewriting its library's code. Since visualization is achieved using a layout script and a frame, and frames can be combined, the types of available visualizations may be infinitely composable and extendable.
Moreover, embodiments may directly leverage the structure of the data model by basing the primitive instances and their layout on data axes. Actions performed on the data model (e.g., slice, pivot of axes) may seamlessly alter the report layout. Conversely, actions performed on the report layout may be seamlessly translated into the data model. For example, a selection of an axis thru a graphical representation may be simply interpreted as selection of an axis regardless of the type of the graphical representation (e.g., a set of pies, a set of bars, a set of columns, a set of sections, etc.).
As mentioned above, a layout script may use parameters to represent axes. Such a layout script is not tied to a specific set of axes. Accordingly, the layout script may be used as a template. Further, according to some embodiments, frames associated with a layout script may be combined infinitely by combining their associated data axes, and a corresponding report layout can be generated based on the combined data axes. Such axes combination involves well-known operations such as Cross-Join and Projection.
Report structure 710 of
According to some embodiments, the layout script grammar provides a declarative way of defining feedback on a rendered report output. Examples of such feedback include displaying a number in response to placing a cursor over a displayed primitive instance, and/or displaying a vertical line as a cursor follows a displayed curve.
Layout script grammar according to some embodiments may provide events for handling by an attached controller, such as a controller within output client 240. This event handling may allow a user to perform actions such as adding a column into a block or adding a curve into a graph.
Other events may be generated and handled internally based on the layout script. The events may be handled by controllers bound to a frame so as to receive messages when an action is performed on the frame. A controller may comprise an infoobject and a function coded in a compiled language. For example, a frame instance may include a boolean property “visible” which determines whether the frame instance is visible. A controller may change this property (and the resulting rendered report output) if a corresponding parent frame instance is double-clicked. In another example, a user may control an input widget such as a slider, and an associated controller may incrementally change a property of an associated frame instance in the rendered report output.
The embodiments described herein are solely for the purpose of illustration. Those in the art will recognize that other embodiments may be practiced with modifications and alterations limited only by the claims.