Abstract: Architecture for handling large data selections with small and substantially constant memory footprints. The architecture facilitates the creation of sets of data objects (e.g., rows) of a data source based on selection of the data objects. The set structures can be defined according to a range (span) of data objects selected and a pattern of the objects selected. These set structures are then saved in memory, rather than the data objects, to provide optimized memory usage. In a database implementation, the solution stores the set representation (the structure) in nearly a constant amount of memory, regardless of the number of rows in the grid, and regardless of the number of rows selected. Memory usage can be proportional to the number of discontinuous spans of rows selected by the user. Structures in memory can be consolidated, replaced, or eliminated dynamically as the user changes row selections and pattern criteria.

Abstract: Architecture for handling large data selections with small and substantially constant memory footprints. The architecture facilitates the creation of sets of data objects (e.g., rows) of a data source based on selection of the data objects. The set structures can be defined according to a range (span) of data objects selected and a pattern of the objects selected. These set structures are then saved in memory, rather than the data objects, to provide optimized memory usage. In a database implementation, the solution stores the set representation (the structure) in nearly a constant amount of memory, regardless of the number of rows in the grid, and regardless of the number of rows selected. Memory usage can be proportional to the number of discontinuous spans of rows selected by the user. Structures in memory can be consolidated, replaced, or eliminated dynamically as the user changes row selections and pattern criteria.

Abstract: Architecture for handling large data selections with small and substantially constant memory footprints. The architecture facilitates the creation of sets of data objects (e.g., rows) of a data source based on selection of the data objects. The set structures can be defined according to a range (span) of data objects selected and a pattern of the objects selected. These set structures are then saved in memory, rather than the data objects, to provide optimized memory usage. In a database implementation, the solution stores the set representation (the structure) in nearly a constant amount of memory, regardless of the number of rows in the grid, and regardless of the number of rows selected. Memory usage can be proportional to the number of discontinuous spans of rows selected by the user. Structures in memory can be consolidated, replaced, or eliminated dynamically as the user changes row selections and pattern criteria.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Architecture for operating an industrial solution on top of a performance management platform using a custom business type library. The platform can plug/unplug the custom business type library, interacts with the type library to ensure data integrity and enforce business rules, and simplifies localizations of the industrial solution. The custom type library extends the capability to define specific behavior for models and dimensions, and create and define content specific to any industry, reuse, and packaging. The custom type library inherits from a generic type library of the platform. The customized type library defines business object types and associates business rules therewith. Through a common interface, the performance management platform can iterate through the business rule chains and enforce/apply the business rules during the operations.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Architecture for handling large data selections with small and substantially constant memory footprints. The architecture facilitates the creation of sets of data objects (e.g., rows) of a data source based on selection of the data objects. The set structures can be defined according to a range (span) of data objects selected and a pattern of the objects selected. These set structures are then saved in memory, rather than the data objects, to provide optimized memory usage. In a database implementation, the solution stores the set representation (the structure) in nearly a constant amount of memory, regardless of the number of rows in the grid, and regardless of the number of rows selected. Memory usage can be proportional to the number of discontinuous spans of rows selected by the user. Structures in memory can be consolidated, replaced, or eliminated dynamically as the user changes row selections and pattern criteria.

Abstract: Architecture that employs a journal assignment that can be created on demand when journal is created, and operates outside the business cycle. The assignment is routed to reviewers and approvers based on predefined company policy that users define. The assignment encloses a changelist of data changes created by the journal. The changelist is used for rendition and calculation for reviewers and approvers (in addition to the journal contributor) to view/verify and modify the data as if the data is already written into the model. At the time that other users access this model, the data is not present. At the end of the successful workflow chain the changelist is written into the model. If failed, the changelist will be used as that basis for correction or the user can discard the changelist.