Metadata-driven audit reporting system with hierarchical relationships

Abstract

A system is provided that reports audit data. The system defines audit metadata that defines a business object of an application module and an attribute of the business object as being auditable. The system further defines business object metadata that defines a hierarchical relationship between the business object and a child business object. The system further generates audit data for the attribute of the business object based on the audit metadata, where the audit data includes a history of modifications to the attribute of the business object. The system further displays the audit data within a user interface. The system further displays the business object and the hierarchical relationship between the business object and the child business object within the user interface based on the business object metadata.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority of U.S. Provisional Patent Application Ser. No. 61/876,465, filed on Sep. 11, 2013, the subject matter of which is hereby incorporated by reference.

FIELD

One embodiment is directed to a computer system, and more particularly, to a computer system that audits data.

BACKGROUND

A software application (or “application”) is generally used for automating transactions related to processes of operations, such as business operations. Typically, processes include one or more transactions which may insert, update, or delete operations data (i.e., data related to the operations). The integrity and consistency of the operations data is generally very important, especially with regards to the creditability of records, service provisions, and maintenance of records. An application can be executed on a computer system in order to perform the operation processes.

In order to ensure integrity and consistency of the operations data, data auditing (or “auditing”) of the operations data can be performed. Auditing is a process of tracking modifications to data, such as what data has been modified, who has made the modifications to the data, and when the modifications to the data were made. Further, auditing can maintain a history of modifications in chronological order so that operations data can be restored in case of any loss of data or data corruption. Auditing can be performed on the operations data for various reasons, such as system security, fault investigation, maintenance of history, or compliance with organizational policies or regulatory requirements. Moreover, auditing can help in analyzing a pattern of modifications in the operations data.

SUMMARY

One embodiment is a system that reports audit data. The system defines audit metadata that defines a business object of an application module and an attribute of the business object as being auditable. The system further defines business object metadata that defines a hierarchical relationship between the business object and a child business object. The system further generates audit data for the attribute of the business object based on the audit metadata, where the audit data includes a history of modifications to the attribute of the business object. The system further displays the audit data within a user interface. The system further displays the business object and the hierarchical relationship between the business object and the child business object within the user interface based on the business object metadata.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments, details, advantages, and modifications will become apparent from the following detailed description of the preferred embodiments, which is to be taken in conjunction with the accompanying drawings.

FIG. 1 illustrates a block diagram of a system that can implement an embodiment of the invention.

FIG. 2 illustrates an example metadata structure utilized to generate audit data for an audit report system, according to an embodiment of the invention.

FIG. 3 illustrates an example audit configuration user interface, according to an embodiment of the invention.

FIGS. 4A and 4B illustrate an example business object audit configuration user interface, according to an embodiment of the invention.

FIG. 5 illustrates a generation of audit data, according to an embodiment of the invention.

FIG. 6 illustrates an example audit report user interface, according to an embodiment of the invention.

FIG. 7 illustrates a flow diagram of the functionality of a metadata-driven audit data reporting module, according to an embodiment of the invention.

FIG. 8 illustrates business object metadata for a business object definition, according to an embodiment of the invention.

FIG. 9 illustrates an example business object audit configuration user interface that displays a hierarchical relationship between business objects, according to an embodiment of the invention.

FIG. 10 illustrates an example audit report user interface that displays a hierarchical relationship between business objects, according to an embodiment of the invention.

FIG. 11 illustrates a flow diagram of the functionality of a metadata-driven audit data reporting module, according to another embodiment of the invention.

DETAILED DESCRIPTION

According to an embodiment, a metadata-driven audit reporting system is provided that can generate and display a report of audit data, where audit data includes a history of modifications that have been made to data in one or more software application modules (also identified as application modules), such as an operation that was performed on a business object of the application module, when the operation was performed, and how an attribute of the business object was modified. The audit reporting system can display, or otherwise show, hierarchical relationships (e.g., parent-child relationships) between business objects. For example, the audit reporting system can display a parent-child relationship between a parent business object and a child business object within a user interface that allows a user to configure metadata for business objects. As another example, the audit reporting system can display a parent-child relationship between a parent business object and a child business object within a user interface that displays an audit report containing audit data associated with either the parent business object, the child business object, or both business objects. In an embodiment, when searching on audit data, the audit reporting system can further allow a user to search attributes of a parent business object as well as attributes of any child business objects that are children of the parent business object. Further, in an embodiment, the audit reporting system can display audit data associated with a child business object, even if no modifications have been made to a parent business object that is being searched on.

FIG. 1 illustrates a block diagram of a system 10 that may implement one embodiment of the invention. System 10 includes a bus 12 or other communications mechanism for communicating information between components of system 10. System 10 also includes a processor 22, operatively coupled to bus 12, for processing information and executing instructions or operations. Processor 22 may be any type of general or specific purpose processor. System 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of machine or computer-readable medium. System 10 further includes a communication device 20, such as a network interface card or other communications interface, to provide access to a network. As a result, a user may interface with system 10 directly, or remotely through a network or any other method.

A computer-readable medium may be any available medium that can be accessed by processor 22. A computer-readable medium may include both a volatile and nonvolatile medium, a removable and non-removable medium, a communication medium, and a storage medium. A communication medium may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any other form of information delivery medium known in the art. A storage medium may include RAM, flash memory, ROM, erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

Processor 22 can also be operatively coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”). Display 24 can display information to the user. A keyboard 26 and a cursor control device 28, such as a computer mouse, can also be operatively coupled to bus 12 to enable the user to interface with system 10.

According to one embodiment, memory 14 can store software modules that may provide functionality when executed by processor 22. The modules can include an operating system 15, a metadata-driven audit data reporting module 16, as well as other functional modules 18. Operating system 15 can provide an operating system functionality for system 10. Metadata-driven audit data reporting module 16 can provide functionality for reporting audit data, as is described in more detail below. In certain embodiments, metadata-driven audit data reporting module 16 can comprise a plurality of modules that each provide specific individual functionality for reporting audit data. System 10 can also be part of a larger system. Thus, system 10 can include one or more additional functional modules 18 to include the additional functionality. For example, functional modules 18 may include modules that provide additional functionality, such as “Oracle Fusion” middleware products, or other “Oracle Fusion” products, from Oracle Corporation.

Processor 22 can also be operatively coupled via bus 12 to a database 34. Database 34 can store data in an integrated collection of logically-related records or files. Database 34 can be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigational database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, or any other database known in the art.

FIG. 2 illustrates an example metadata structure 200 utilized to generate audit data for an audit report system, according to an embodiment of the invention. As previously described, audit data includes a history of modifications that have been made to data. For example, audit data can include specific operations (such as insert operations, update operations, and delete operations) that have been performed on data over a specific period of time. Audit data can further include a specific user that performed operations on data over a specific period of time. The metadata contained within metadata structure 200 can be utilized to generate audit data for an audit report system according to a metadata-driven object-based audit framework. More specifically, the metadata contained within metadata structure 200 can define business objects of an application module as being auditable. An application module is a collection of one or more computer-readable instructions for executing a specific functionality. A business object is a collection of data contained within one or more base database tables, where the data is logically related to a logical entity within an application module. When the metadata defines a business object as being auditable, the audit report system can expose the business object to a user (such as within a user interface), where the user can configure the business object to enable auditing, as is described below in greater detail.

Further, the metadata can define attributes of a business object as being auditable. An attribute is data contained within one or more fields of a base database table, where the base database table is associated with a business object. When the metadata defines an attribute as being auditable, the audit report system can expose the attribute to a user, where the user can configure the attribute to enable auditing, as is also described below in greater detail. The aforementioned metadata can be part of an object-based audit framework for an application module, where the object-based audit framework can be utilized in auditing transactions involving business objects (and their attributes) of the application module.

Metadata structure 200 includes two database schema tables, application module table 210 and attribute table 220. Application module table 210 and attribute table 220 each contain metadata that can define attributes of business objects of an application module, as well as the business objects themselves, as being auditable. These tables are referenced along with computer files that include computer program code to determine at runtime a complete configuration of which business objects and attributes are auditable. By defining attributes and/or business objects as being auditable, the metadata causes an audit reporting system to allow a user to configure the attributes and/or business objects in order to enable auditing, as is described below in greater detail. Thus, the metadata defines one or more attributes of one or more business objects as being auditable by an object-based audit framework.

Application module table 210 stores metadata that identifies one or more application modules of an application. More specifically, application module table 210 includes application column 211 and application module column 212. Application column 211 is a column (i.e., attribute) of application module table 210 that stores an application identifier that identifies an application. Application module column 212 is a column of application module table 210 that further stores an application module identifier that identifies an application module of an application.

Attribute table 220 further stores metadata that identifies one or more attributes associated with a business object. More specifically, attribute table 220 includes application column 221, business object column 222, attribute column 223, auditing enabled column 224, shadow database table name column 225, and shadow database column name column 226. Application column 221 stores an application identifier that identifies an application. Business object column 222 stores a business object identifier that identifies a business object of an application module. Attribute column 223 stores an attribute identifier that identifies an attribute of a business object. Auditing enabled column 224 stores an auditing enabled flag that identifies whether auditing is enabled for the attribute. Shadow database table name column 225 stores a shadow database table name that identifies a shadow database table that stores audit data, as is described below in greater detail. Shadow database column name column 226 stores a shadow database column name that identifies a column of the shadow database table that stores audit data, as is also described below in greater detail.

According to an embodiment, an application module of an application can be registered with application module table 210 by populating metadata within application module table 210, where the metadata includes an application identifier that identifies the application, and an application module identifier that identifies the application module of the application. In one embodiment, the application module can be registered with application module table 210 by passing the application identifier and the application module identifier to a service of the audit report system, where the service automatically populates metadata within application module table 210, where the metadata includes the application identifier and the application module identifier.

After an application module has been registered with application module table 210, a business object of the application module can be defined as being auditable by populating metadata within attribute table 220, where the metadata includes a business object identifier that identifies the business object. In one embodiment, a business object can be defined as being auditable by setting a value of a custom property of the business object to a value that indicates the business object is auditable. For example, as shown in the example computer program code, a custom property with the name “Auditable” can be set with a value “Y”:

<Properties>
<CustomProperties>
<Property
Name=“Auditable”
Value=“Y”/>
</CustomProperties>
</Properties>

According to the embodiment, by setting a custom property of the business object to a value that indicates the business object is auditable, the audit reporting system can automatically populate metadata within attribute table 220, where the metadata includes a business object identifier that identifies the business object.

Further, after a business object has been defined as being auditable, an attribute of the business object can be defined as being auditable based on computer files that include computer program code. Once an attribute is selected for audit in a runtime setup user interface, metadata is populated within attribute table 220, where the metadata includes an attribute identifier that identifies the attribute. In one embodiment, once a business object has been defined as auditable, all of its attributes are automatically defined as being auditable, unless an attribute is explicitly defined as not being auditable. According to this embodiment, an attribute can be defined as not being auditable by setting a value of a custom property of the attribute to a value that indicates the attribute is not auditable. For example, as shown in the example computer program code, a custom property with the name “Auditable” can be set with a value “N”:

<ViewAttribute
Name=“Attribute1”
IsUpdateable=“false”
PrecisionRule=“true”
EntityAttrName=“Attribute1”
EntityUsage=“AttributeEO”
AliasName=“ROWID”>
<Properties>
<CustomProperties>
Property
Name=“Auditable”
Value=“N”/>
</CustomProperties>
<SchemaBasedProperties>
<DISPLAYHINT
Value=“Hide”/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>

According to the embodiment, if the custom property with the name “Auditable” is set with a value “Y,” the attribute can be defined as being auditable if just the business object is selected for auditing. Further, if no custom property is defined for the attribute, a value of “Y” can be interpreted by the audit reporting system, and the attribute can be defined as being auditable but not preselected if the business object is enabled for auditing. Thus, according to the embodiment, by setting a custom property of the attribute to a value that indicates the attribute is auditable (or by not setting a custom property of the attribute to any value), the audit reporting system can automatically populate metadata within attribute table 220, where the metadata includes an attribute identifier that identifies the attribute.

Once metadata has been defined for, and populated within, application module table 210 and attribute table 220, a user of the audit reporting system can configure the metadata using a user interface of the audit reporting system, as is further described below in greater detail in conjunction with FIGS. 4A and 4B. According to an embodiment, a user-friendly display name can be defined for all application modules, business objects, and attributes. The display of a user-friendly display name can assist in the configuration of the metadata contained within application module table 210 and attribute table 220. Further, for application modules and business objects, a “tooltip” can be defined, where a tooltip is a text box that contains information, and where a tooltip can be displayed within the user interface when a user “hovers” a pointer, or other type of icon, over an object. The tooltip can display further information about the application module or business object that a user hovers the pointer over within the user interface. In one embodiment, a label property and/or a tooltip property can be defined for an application module, a business object, and/or an attribute. For example, as shown in the example computer program code, a label property and a tooltip property can be defined for a business object:

<Properties>
<CustomProperties>
<Property
Name=“Auditable”
Value=“Y”/>
</CustomProperties>
<SchemaBasedProperties>
<LABEL
ResId=“ViewObjectVO_LABEL”/>
<TOOLTIP
ResId=“ViewObjectVO_TOOLTIP”/>
</SchemaBasedProperties>
</Properties>
<ResourceBundle>
<XliffBundle
id=“oracle.apps.fnd.applcore.audit.test.model.view.common.
ViewObjectVOMsgBundle”/>
</ResourceBundle>

As another example, as shown in the example computer program code, a label property can be defined for an attribute:

<ViewAttribute
Name=“TableName”
PrecisionRule=“true”
EntityAttrName=“TableName”
EntityUsage=“FndAuditAttributesEO”
AliasName=“TABLE_NAME”>
<Properties>
<SchemaBasedProperties>
<LABEL
ResId=“TableName_LABEL”/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>

Further, according to the embodiment, the user interface of the audit reporting system can be used to search for a business object. Further, the business object can be searched using a key (i.e., an attribute) that may not be a primary key of the business object, by setting a value of a custom property of the attribute to a value that indicates the attribute is a user key for the business object. If not defined, the system can set the key to the first primary key. For example, as shown in the example computer program code, a custom property with the name “AUDIT_USER_KEY” can be set with a value “Y”:

<ViewAttribute
Name=“TableName”
IsUnique=“true”
IsNotNull=“true”
PrecisionRule=“true”
EntityAttrName=“TableName”
EntityUsage=“FndTablesEO”
AliasName=“TABLE_NAME”>
<Properties>
<CustomProperties>
<Property
Name=“AUDIT_USER_KEY”
Value=“Y”/>
</CustomProperties>
</Properties>
</ViewAttribute>

According to the embodiment, by setting a custom property of the attribute of the business object to a value that indicates the attribute is a user key of the business object, the business object can be searched upon within the user interface using the attribute.

Further, the metadata included within attribute table 220 can be configured. More specifically, an auditing enabled flag that is associated with an attribute can be set to a value that identifies that auditing is enabled for the attribute within attribute table 220. By setting the auditing enabled flag to a value that identifies that auditing is enabled for the attribute, the audit reporting system can generate audit data for the attribute, and can display the audit data within a user interface. An auditing enabled flag for an attribute can be set to a value that identifies that auditing is enabled for the attribute using a user interface of the audit reporting system, as is further described below in greater detail in conjunction with FIGS. 4A and 4B. In one embodiment, when an auditing enabled flag for an attribute is set to a value that identifies that auditing is enabled for the attribute, a shadow database table name that identifies a shadow database table that stores audit data can also be defined, and a shadow database column name that identifies a column of the shadow database table that stores audit data can also be defined. Further, the generation of the audit data is further described below in greater detail in conjunction with FIG. 5, and the displaying of the audit data is further described below in greater detail in conjunction with FIG. 6.

FIG. 3 illustrates an example audit configuration user interface 300, according to an embodiment of the invention. According to the embodiment, audit configuration user interface 300 allows a user to configure the auditing of data by an audit reporting system. More specifically, audit configuration user interface 300 allows a user to configure the auditing of data for an application using a metadata-driven object-based audit framework, and to also configure the auditing of data for an application using an event-based audit framework.

A metadata-driven object-based audit framework is previously described in conjunction with FIG. 2. An event-based audit framework involves the generation of audit data by the audit reporting system in response to an event within an application. An “event” is an action or occurrence detected by the application. An example of an event is a login failure, where the login failure has an event that records a user, a time, and an event identifier indicating that the login attempt was a failed login attempt. Upon the occurrence of an event, the audit reporting system can capture data and convert the captured data into audit data. The audit reporting system can further store the audit data into an event database table. The event database table can be separate from the shadow database table utilized by the metadata-driven object-based audit framework, and can have a format that is different from the format of the shadow database table. The audit reporting system can subsequently combine the audit data stored within the event database table with the audit data stored within the shadow database table, despite the difference in the two formats, and can display the audit data within a user interface. The two types of audit data can be displayed within the user interface using a single format.

According to the embodiment, a user can enable or disable auditing for an application according to a metadata-driven object-based audit framework using audit level drop-down list 310. By interacting with audit level drop-down list 310, the user can cause the audit reporting system to configure metadata, such as the metadata stored in metadata structure 200 of FIG. 2. Further, a user can enable or disable auditing for one or more specific attributes of one or more specific business objects according to the metadata-driven object-based audit framework using business object attribute configuration button 311. By interacting with business object attribute configuration button 311, the user can cause the audit reporting system to configure metadata, such as the metadata stored in metadata structure 200 of FIG. 2, for one or more specific attributes of one or more specific business objects. The configuration of metadata for one or more specific attributes of one or more specific business objects is further described below in greater detail in conjunction with FIGS. 4A and 4B. Further, in an alternate embodiment, audit level drop-down list 310 of audit configuration user interface 300 can enable or disable auditing for all business objects for the selected application that have been defined as being auditable.

According to the embodiment, a user can enable, disable, or configure auditing for an application according to an event-based audit framework using one of audit level drop-down lists 320, 330, and 340. More specifically, a user can set an audit level to one of a plurality of audit levels using one of audit level drop-down lists 320, 330, and 340, where each audit level defines an event type (or event types) that trigger a capture of data associated with the event, and the conversion of the captured data into audit data, which is subsequently stored within the event database table. In one example embodiment, the plurality of audit levels can include the following audit levels: (1) High (captures all events); (2) Low (only captures critical events); (3) Medium (only captures critical events and certain non-critical events); or (4) None (does not capture any events).

FIGS. 4A and 4B illustrate an example business object audit configuration user interface 400, according to an embodiment of the invention. According to the embodiment, business object audit configuration user interface 400 allows a user to configure metadata for one or more specific attributes of one or more specific business objects. By configuring metadata for one or more attributes, the user can enable or disable auditing for the one or more attributes. Further, the configuration of the metadata for an attribute can include setting a value of an auditing enabled flag that is associated with an attribute to either: (1) a value that identifies that auditing is enabled for the attribute; or (2) a value that identifies that auditing is disabled for the attribute. In one embodiment, business object audit configuration user interface 400 can be displayed upon an interaction with business object attribute configuration button 311 of FIG. 3.

According to the illustrated embodiment, business object audit configuration user interface 400 includes application drop-down list 410, business object window 420 and attribute window 430. A user can select an application using application drop-down list 410. In response to the selection of an application using application drop-down list 410, business object window 420 displays all business objects for the selected application that have been defined as being auditable. The business objects can be defined as being auditable based on metadata, such as metadata included within metadata structure 200 of FIG. 2. For each business object displayed within business object window 420, a user can “check” or “uncheck” an auditing enabled flag. By “checking” an auditing enabled flag for a business object, a user can cause one or more attributes of the business object to be enabled for auditing. By “unchecking” an auditing enabled flag for the business object, the user can cause one or more attributes of the business object not to be enabled for auditing. Upon “clicking” on save button 401, the audit reporting system can configure metadata, such as metadata included within metadata structure 200 of FIG. 2, based on the user's selections.

Further, a user can select a business object displayed within business object window 420. In response to the selection of a business object within business object window 420, attribute window 430 displays all attributes for the selected business object that have been defined as being auditable. The attributes can be defined as being auditable based on metadata, such as metadata included within metadata structure 200 of FIG. 2. For each attribute displayed within attribute window 430, a user can select or unselect the attribute. By selecting the attribute, the user can cause the attribute to be enabled for auditing. By unselecting the attribute, the user can cause the attribute not to be enabled for auditing. Upon “clicking” on save button 401, the audit reporting system can configure metadata, such as metadata included within metadata structure 200 of FIG. 2, based on the user's selections.

Further, in an alternate embodiment, one or more attributes can be flex fields. A flex field is a set of placeholder fields, also identified as segments, which are associated with a business object, and where a segment captures a single atomic value, which is represented in the base database table as a single column. Also, in an alternate embodiment, a user can initiate a tracking of a flex field attribute by the audit reporting system (also identified as synchronizing an attribute) using a synchronize button (not illustrated in FIGS. 4A and 4B), since flex fields may be defined at runtime.

FIG. 5 illustrates a generation of audit data, according to an embodiment of the invention. In accordance with a metadata-driven object-based audit framework, for every base database table (such as base database table 510) that is associated with a business object that is enabled for auditing, a shadow database table (such as shadow database table 520) is created. Shadow database table 520 can include an identical set of columns as base database table 510, and can include one or more additional columns for internal usage purposes. Further, upon creation of shadow database table 520, metadata (such as metadata included within metadata structure 200 of FIG. 2) can be configured to include a shadow database table name that identifies shadow database table 520, and a shadow database column name that identifies a column of shadow database table 520. During execution of an application, in response to a modification to data stored within base database table 510 (such as an insert operation, a delete operation, or an update operation), audit data is generated and stored within shadow database 520. Such audit data can include the data stored within base database table 510 prior to the modification, the data stored within base database table 510 after the modification, and/or a user identifier that identifies a specific user that performed the modification. The generation and storage of audit data within shadow database 520 can be accomplished through one or more application program interfaces (“APIs”), as understood by one of ordinary skill in the relevant art.

Further, in accordance with an event-based audit framework, a single event database table (such as event database table 530) is created for all base database tables (such as base database table 510). During execution of an application, in response to an event occurrence at base database table 510 (such as a login failure event), audit data is generated and stored within event database table 530. Such audit data can include the data stored within base database table 510 prior to the event, the data stored within base database table 510 after the event, an event identifier that identifies the event, a date, a time, and/or a user identifier that identifies a specific user that initiated the event. The generation and storage of audit data within event database 530 can be accomplished through one or more application program interfaces (“APIs”), as understood by one of ordinary skill in the relevant art.

FIG. 6 illustrates an example audit report user interface 600, according to an embodiment of the invention. According to the embodiment, the audit reporting system retrieves audit data from one or more shadow database tables, and displays the retrieved audit data within audit report user interface 600. In certain embodiments, the audit reporting system also retrieves audit data from an event database table, combines the audit data retrieved from the event database table with the audit data retrieved from the one or more shadow database tables, and displays the combined audit data within audit report user interface 600. According to the embodiment, the audit reporting system abstracts out the differences in the different formats of the audit data stored within the one or more shadow database tables and the audit data stored within the event database table, and displays the combined audit data within audit report user interface 600 using a single format.

According to an embodiment, a user can perform a search of the audit data using search window 610 of audit report user interface 600. More specifically, a user can perform a search of the audit data: (1) by entering a date or date range within date field 611; (2) by entering a user identifier within user field 612; (3) by entering a product identifier within product field 613; (4) by entering an event type within event type field 614; (5) by entering a business object type within business object type field 615; and/or (6) by entering a description within description field 616. Based one or more entered values within search window 610, the audit reporting system can retrieve and display audit data that includes the one or more entered values within search results window 620. If show attribute details checkbox 621 is enabled, search results window 620 can display attributes that have been modified, including old and new values for the attributes. Further, if show extended object identifier columns checkbox 622 is enabled, search results window 620 can display context columns that can help identify the business object that the attributes are associated with.

FIG. 7 illustrates a flow diagram of the functionality of a metadata-driven audit data reporting module (such as metadata-driven audit data reporting module 16 of FIG. 1), according to an embodiment of the invention. In one embodiment, the functionality of the flow diagram of FIG. 7, as well as the functionality of the flow diagram of FIG. 11, are each implemented by software stored in memory or other computer-readable or tangible medium, and executed by a processor. In other embodiments, each functionality may be performed by hardware (e.g., through the use of an application specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field programmable gate array (“FPGA”), etc.), or any combination of hardware and software. In certain embodiments, some, or all, of each functionality may be omitted.

The flow begins, and proceeds to 710. Alternatively, the flow proceeds to 760 rather than 710. At 710, metadata is defined, where the metadata defines a business object of an application module and an attribute of the business object as being auditable. In certain embodiments, the metadata includes a business object identifier that identifies the business object of the application module, an attribute identifier that identifies the attribute of the business object, an auditing enabled flag that identifies whether auditing is enabled for the attribute, a shadow database table name that identifies the shadow database table, and a shadow database column name that identifies a column of the shadow database table. Further, in certain embodiments, the business object includes data contained within one or more base tables.

In some embodiments, a value of a property of the business object is set to a value that indicates the business object is auditable, and a value of a property of the attribute is set to a value that indicates the attribute is auditable. Further, in these embodiments, a business object identifier that identifies the business object and an attribute identifier that identifies the attribute of the business object are populated within the metadata based on the value of the property of the business object and the value of the property of the attribute. The flow proceeds to 720.

At 720, the metadata is configured to enable auditing for the attribute of the business object. In certain embodiments, the auditing enabled flag of the metadata is set to a value that indicates that auditing is enabled for the attribute. The flow proceeds to 730.

At 730, object-based audit data is generated for the attribute of the business object based on the metadata. The object-based audit data includes a history of one or more modifications to the attribute of the business object. In certain embodiments, the one or more modifications include one or more modifications to data contained with a base database table of the one or more base database tables of the business object. Further, in certain embodiments, the object-based audit data is only generated when the auditing enabled flag of the metadata is set to a value that indicates that auditing is enabled. The flow then proceeds to 740.

At 740, the object-based audit data is stored within a shadow database table based on the metadata. In certain embodiments, the shadow database table is separate from the one or more base database tables. Further, in certain embodiments, the object-based audit data is stored within the shadow database table that is identified by the shadow database table name of the metadata and stored within the column of the shadow database table identified by the shadow database table column name of the metadata. The flow then proceeds to 750.

At 750, the object-based audit data is displayed within a user interface. In certain embodiments, a search criteria is received, and the object-based audit data that satisfies the search criteria is displayed within the user interface. Further, in some of these embodiments, the search criteria includes at least one of: a date or a date range, and a user identifier or a product identifier. The flow then proceeds to 780.

At 760, event-based audit data is generated for an event of a separate application. The flow proceeds to 770.

At 770, the event-based audit data is stored within an event database table that is separate from the shadow database table, where a format of the event database table is different from a format of the shadow database table. The flow proceeds to 780.

At 780, the event-based audit data is displayed within the user interface, where the event-based audit data and the object-based audit data are combined and displayed using a single format. The flow then ends.

FIG. 8 illustrates business object metadata 810 for a business object definition 800, according to an embodiment of the invention. As previously described, a business object is a collection of data contained within one or more base database tables, where the data is logically related to a logical entity within an application module. Business object definition 800 can define the collection of data for the business object. Further, the business object can be a parent of one or more child business objects. Thus, according to the embodiment, business object metadata 810 can define (among other things) a hierarchical relationship between the business object and one or more child business objects. An example of a hierarchical relationship is a parent-child relationship, where the business object is a parent of the one or more child business objects. As an example, business object metadata 810 can include a business object identifier that identifies the business object, one or more child business object identifiers that identify the one or more child business objects, and a hierarchical relationship identifier that identifies the hierarchical relationship between the business object and the one or more child business objects as a parent-child relationship.

FIG. 9 illustrates an example business object audit configuration user interface 900 that displays a hierarchical relationship between business objects, according to an embodiment of the invention. As previously described in conjunction with FIGS. 4A and 4B, a business object audit configuration user interface (such as business object audit configuration user interface 900) allows a user to configure metadata for one or more attributes of one or more business objects. According to the embodiment, an audit reporting system can cause business object audit configuration user interface 900 to display a graphical representation of a hierarchical relationship (e.g., parent-child relationship) between a parent business object and one or more children business objects based on business object metadata that is associated with the parent business object. More specifically, the audit reporting system can: (a) view the business object metadata associated with the parent business object, (b) identify the parent business object using the business object identifier contained within the business object metadata, (c) identify that that the parent business object is a parent of one or more child business objects using the hierarchical relationship identifier contained within the business object metadata; and (d) identify the one or more child business objects using the one or more child business object identifiers contained within the business object metadata. According to the embodiment, business object audit configuration user interface 900 can display the graphical representation of the hierarchical relationship between the parent business object and the one or more children business objects within search results 910, where the graphical representation of the hierarchical relationship can be in the format of an indentation of the graphical representation of the child business object as compared to the graphical representation of the parent business object.

FIG. 10 illustrates an example audit report user interface 1000 that displays a hierarchical relationship between business objects, according to an embodiment of the invention. As previously described in conjunction with FIG. 6, an audit reporting system can retrieve audit data, and can display the retrieved audit data within an audit report user interface (such as audit report user interface 1000). According to the embodiment, the audit reporting system can cause audit report user interface 1000 to display a graphical representation of a hierarchical relationship (e.g., parent-child relationship) between a parent business object and one or more children business objects based on business object metadata that is associated with the parent business object. More specifically, the audit reporting system can (a) view the business object metadata associated with the parent business object, (b) identify the parent business object using the business object identifier contained within the business object metadata, (c) identify that that the parent business object is a parent of one or more child business objects using the hierarchical relationship identifier contained within the business object metadata; and (d) identify the one or more child business objects using the one or more child business object identifiers contained within the business object metadata. According to the embodiment, audit report user interface 1000 can display the graphical representation of the hierarchical relationship between the parent business object and the one or more children business objects within description field 1010, where the graphical representation of the hierarchical relationship can be in a string format that includes a string representation of the parent business object, a delineation character, and one or more string representations of the one or more child business objects (e.g., “Revenue Number: 336/Opportunity Name: 6666”).

Further, in one embodiment, audit report user interface 1000 includes include child object checkbox 1020. In situations where include child object checkbox 1020 is checked, when the audit reporting system receives a search criteria (where a search criteria is previously described in conjunction with FIG. 6), the audit reporting system can retrieve and display audit data for a parent business object that satisfies the search criteria, and can automatically retrieve and display audit data for one or more child business objects (where the one or more child business objects are children of the parent business object) based on business object metadata that is associated with the parent business object. More specifically, the audit reporting system can: (a) view the business object metadata associated with the parent business object, (b) identify the parent business object using the business object identifier contained within the business object metadata, (c) identify that that the parent business object is a parent of one or more child business objects using the hierarchical relationship identifier contained within the business object metadata; and (d) identify the one or more child business objects using the one or more child business object identifiers contained within the business object metadata. In one embodiment, the audit reporting system can automatically retrieve and display audit data for the one or more identified child business objects. In an alternate embodiment, the audit reporting system can only automatically retrieve and display audit data for the one or more identified child business objects that satisfies the search criteria. Further, in one embodiment, for each child business object, the audit reporting system can automatically retrieve and display audit data for one or more grandchild business objects (where the one or more grandchild business objects are children of the child business object) based on business object metadata that is associated with the child business object. In this embodiment, the audit reporting system can perform this functionality for any number of hierarchical levels.

In one example, a parent business object can be an opportunity object, and a child business object can be a revenue line object. An opportunity object is a collection of data contained within one or more base database tables, where the data is logically related to an opportunity, and where an opportunity is a product or service that fulfills one or more needs of a business market. A revenue line object is a collection of data contained within one or more base database tables, where the data is logically related to a revenue line, and where a revenue line is income associated with an opportunity. A user of the audit reporting system can use audit report user interface 1000 to search on a specific business object type (or other search criteria). The audit reporting system can retrieve and display the audit data for the opportunity object, where the audit data includes the modifications to the opportunity object. The audit reporting system can further automatically retrieve and display the audit data for the revenue line object, where the audit data includes the modifications to the revenue line object.

FIG. 11 illustrates a flow diagram of the functionality of a metadata-driven audit data reporting module, according to another embodiment of the invention. The flow begins and proceeds to 1110. At 1110, audit metadata is defined, where the audit metadata defines a business object of an application module and an attribute of the business object as being auditable. In certain embodiments, child audit metadata can also be defined, where the child audit metadata defines at least one child business object and an attribute of the at least one child business object as being auditable. The flow then proceeds to 1120.

At 1120, the audit metadata is configured to enable auditing for the attribute of the business object. In certain embodiments, the child audit metadata can also be configured to enable auditing for the attribute of the at least one child business object. Further, in some of those embodiments, both the configuration of the audit metadata and the child audit metadata can be done using a business object configuration user interface. The flow then proceeds to 1130.

At 1130, business object metadata is defined, where the business object metadata defines a hierarchical relationship between the business object and the at least one child business object. In certain embodiments, the hierarchical relationship can be a parent-child relationship, where the business object is a parent of the at least one child business object. Further, in some of those embodiments, the business object metadata can include a business object identifier that identifies the business object, at least one child business object identifier that identifies the at least one child business object, and a hierarchical relationship identifier that identifies the hierarchical relationship between the business object and the at least one child business object as a parent-child relationship. The flow then proceeds to 1140.

At 1140, audit data is generated for the attribute of the business object based on the audit metadata. The audit data includes a history of one or more modifications to the attribute of the business object. In certain embodiments, child audit data is also generated for the attribute of the at least one child business object based on the child audit metadata. The child audit data includes a history of one or more modifications to the attribute of the at least one child business object. The flow then proceeds to 1150.

At 1150, the audit data is displayed within a user interface. In certain embodiments, the child audit data is also displayed within the user interface. Further, in certain embodiments, a search criteria is received, and the audit data that satisfies the search criteria is displayed within the user interface. In some of these embodiments, the search criteria includes at least one of: a date or a date range, and a user identifier or a product identifier. Further, in some of these embodiments, when the audit data that satisfies the search criteria is displayed within the user interface, the child audit data is automatically displayed within the user interface based on the business object metadata. The flow then proceeds to 1160.

At 1160, the business object and the hierarchical relationship between the business object and the at least one child business object are displayed within the user interface based on the business object metadata. In certain embodiments, the business object and the hierarchical relationship are displayed within a business object configuration user interface. In other embodiments, the business object and the hierarchical relationship are displayed within an audit report user interface. The flow then ends.

Thus, an audit reporting system is provided that can display a hierarchical relationship between a parent business object and one or more child business objects within a user interface based on business object metadata. Thus, when displaying audit data associated with a business object, the audit reporting system can automatically display audit data associated with one or more child business objects that are children of the business object. This can allow the audit reporting system to provide a more complete perspective of the audit data, and provide a more user-friendly experience for the user, since the user is not required to be aware of which business objects are children of a specific business object.

The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of “one embodiment,” “some embodiments,” “certain embodiment,” “certain embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases “one embodiment,” “some embodiments,” “a certain embodiment,” “certain embodiments,” or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

Claims

1. A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the processors to implement a middleware architecture that comprises a plurality of application modules, each application module comprising instructions for executing a software application, the implementing comprising:

defining audit metadata for an attribute of a business object contained within a base database table, wherein the business object comprises a plurality of attributes, the business object comprising a collection of data logically related to a logical entity within at least one of the application modules, the audit metadata including:

a business object identifier,

an attribute identifier,

a shadow database table name that identifies a shadow database table associated with the base database table, and

a shadow database column name that identifies a column of the shadow database table associated with the attribute of the business object;

defining business object metadata that defines a hierarchical relationship between the business object and at least one child business object;

during execution of the software application and in response to a modification to data stored within the base database table, generating, by an audit data reporting module, audit data for the attribute of the business object based on the audit metadata, the audit data including a history of one or more modifications to the attribute of the business object, the history including:

a first value of the attribute stored within the base database table prior to a modification,

a second value of the attribute stored within the base database table after the modification, and

a user identifier that identifies a user that performed the modification;

storing the audit data for the attribute of the business object in the shadow database table identified by the shadow database table name and the shadow database column name of the audit metadata; and

displaying the audit data within a user interface including displaying the business object and the hierarchical relationship between the business object and the at least one child business object based on the business object metadata;

wherein the business object is indicated to be auditable by the audit data reporting module by setting a custom property of the business object and the plurality of attributes are defined as being auditable in response to selecting the business object for auditing.

2. The non-transitory computer-readable medium of claim 1, the implementing further comprising:

during execution of the software application and in response to an event occurrence at the base database table, generating second audit data and storing the second audit data in an event database table, wherein the event database table has a different format than the shadow database table.

3. The non-transitory computer-readable medium of claim 2, wherein the event within the software application comprises an action or occurrence detected by the software application and includes a login failure.

4. The non-transitory computer-readable medium of claim 1, the implementing further comprising:

defining child audit metadata that defines the at least one child business object and an attribute of the at least one child business object as being auditable;

displaying a business object audit configuration user interface including the child audit metadata; and

generating child audit data for the attribute of the at least one child business object based on the child audit metadata, the child audit data including a history of one or more modifications to the attribute of the at least one child business object,

wherein displaying the audit data includes displaying the child audit data.

5. The non-transitory computer-readable medium of claim 4, wherein displaying the audit data includes:

receiving a search criteria;

displaying the audit data that satisfies the search criteria within the user interface; and

automatically displaying the child audit data within the user interface based on the business object metadata.

6. The non-transitory computer-readable medium of claim 1, wherein the hierarchical relationship comprises a parent-child relationship, and wherein the business object is a parent of the at least one child business object.

7. The non-transitory computer-readable medium of claim 6, wherein the business object metadata comprises a business object identifier that identifies the business object, at least one child business object identifier that identifies the at least one child business object, and a hierarchical relationship identifier that identifies the hierarchical relationship between the business object and the at least one child business object as a parent-child relationship.

8. A computer-implemented method for implementing middleware architecture that comprises a plurality of application modules, each application module comprising instructions for executing a software application, the computer-implemented method comprising:

defining audit metadata for an attribute of a business object contained within a base database table, wherein the business object comprises a plurality of attributes, the business object comprising a collection of data logically related to a logical entity within at least one of the application modules, the audit metadata including:

a business object identifier,

an attribute identifier,

a shadow database table name that identifies a shadow database table associated with the base database table, and

a shadow database column name that identifies a column of the shadow database table associated with the attribute of the business object;

defining business object metadata that defines a hierarchical relationship between the business object and at least one child business object;

during execution of the software application and in response to a modification to data stored within the base database table, generating, by an audit data reporting module, audit data for the attribute of the business object based on the audit metadata, the audit data including a history of one or more modifications to the attribute of the business object, the history including:

a first value of the attribute stored within the base database table prior to a modification,

a second value of the attribute stored within the base database table after the modification, and

a user identifier that identifies a user that performed the modification;

storing the audit data for the attribute of the business object in the shadow database table identified by the shadow database table name and the shadow database column name of the audit metadata;

displaying the audit data within a user interface including displaying the business object and the hierarchical relationship between the business object and the at least one child business object based on the business object metadata;

wherein the business object is indicated to be auditable by the audit data reporting module by setting a custom property of the business object and the plurality of attributes are defined as being auditable in response to selecting the business object for auditing.

9. The computer-implemented method of claim 8, further comprising:

during execution of the software application and in response to an event occurrence at the base database table, generating second audit data and storing the second audit data in an event database table, wherein the event database table has a different format than the shadow database table.

10. The computer-implemented method of claim 9, wherein the event within the software application comprises an action or occurrence detected by the software application and includes a login failure.

11. The computer-implemented method of claim 8, further comprising:

defining child audit metadata that defines the at least one child business object and an attribute of the at least one child business object as being auditable;

displaying a business object audit configuration user interface including the child audit metadata; and

generating child audit data for the attribute of the at least one child business object based on the child audit metadata, the child audit data including a history of one or more modifications to the attribute of the at least one child business object,

wherein displaying the audit data includes displaying the child audit data.

12. The computer-implemented method of claim 11, wherein displaying the audit data includes:

receiving a search criteria;

displaying the audit data that satisfies the search criteria within the user interface; and

automatically displaying the child audit data within the user interface based on the business object metadata.

13. The computer-implemented method of claim 8, wherein the hierarchical relationship comprises a parent-child relationship, and wherein the business object is a parent of the at least one child business object.

14. The computer-implemented method of claim 13, wherein the business object metadata comprises a business object identifier that identifies the business object, at least one child business object identifier that identifies the at least one child business object, and a hierarchical relationship identifier that identifies the hierarchical relationship between the business object and the at least one child business object as a parent-child relationship.

15. A middleware architecture system that comprises a plurality of application modules, each application module comprising instructions for executing a software application, the system comprising one or more processors configured to:

define audit metadata for an attribute of a business object contained within a base database table, wherein the business object comprises a plurality of attributes, the business object comprising a collection of data logically related to a logical entity within at least one of the application modules, the audit metadata including:

a business object identifier,

an attribute identifier,

a shadow database table name that identifies a shadow database table associated with the base database table, and

a shadow database column name that identifies a column of the shadow database table associated with the attribute of the business object;

define business object metadata that defines a hierarchical relationship between the business object and at least one child business object;

during execution of the software application and in response to a modification to data stored within the base database table, generate, by an audit data reporting module, audit data for the attribute of the business object based on the audit metadata, the audit data including a history of one or more modifications to the attribute of the business object, the history including:

a first value of the attribute stored within the base database table prior to a modification,

a second value of the attribute stored within the base database table after the modification, and

a user identifier that identifies a user that performed the modification;

store the audit data for the attribute of the business object in the shadow database table identified by the shadow database table name and the shadow database column name of the audit metadata;

display the audit data including displaying the business object and the hierarchical relationship between the business object and the at least one child business object based on the business object metadata;

wherein the business object is indicated to be auditable by the audit data reporting module by setting a custom property of the business object and the plurality of attributes are defined as being auditable in response to selecting the business object for auditing.

16. The system of claim 15, wherein the processors are further configured to:

during execution of the software application and in response to an event occurrence at the base database table, generate second audit data and storing the second audit data in an event database table, wherein the event database table has a different format than the shadow database table.

17. The system of claim 16, wherein the event within the software application comprises an action or occurrence detected by the software application and includes a login failure.

18. The system of claim 15, wherein the processors are further configured to:

define child audit metadata that defines the at least one child business object and an attribute of the at least one child business object as being auditable;

display a business object audit configuration user interface including the child audit metadata; and

generate child audit data for the attribute of the at least one child business object based on the child audit metadata, the child audit data including a history of one or more modifications to the attribute of the at least one child business object,

wherein displaying the audit data includes displaying the child audit data.

19. The system of claim 18, wherein the processors are further configured to:

receive a search criteria;

display the audit data that satisfies the search criteria within the user interface; and

automatically display the child audit data within the user interface based on the business object metadata.

20. The system of claim 15, wherein the hierarchical relationship comprises a parent-child relationship, and wherein the business object is a parent of the at least one child business object;

wherein the business object metadata comprises a business object identifier that identifies the business object, at least one child business object identifier that identifies the at least one child business object, and a hierarchical relationship identifier that identifies the hierarchical relationship between the business object and the at least one child business object as a parent-child relationship.