Many organizations rely on computing systems such as enterprise resource planning (ERP) systems to electronically manage business processes and functions. These ERP systems may contain different modules to perform different tasks, such as invoicing, accounting, inventory control, and so on. These modules may be used by different businesses in different industries—each of these businesses and industries may have unique business processes or procedures. For example, in the telecommunications industry, phone companies may charge customers a flat rate for certain services and a fixed per-use rate for other services. However, in the aviation industry, airlines may routinely modify the fares charged for each flight so that different customers may pay different fares depending on when they booked their flight. Thus, the same invoicing module may be configured differently for different industries, such as the airline industry or the telecommunications industry.
Even with the same industry, different companies may implement different policies and procedures. For example, one company may accept credit cards as a payment option while another may only accept checks.
Since a single ERP system may be used by different companies in different industries, the ERP system may be initially configured to support a wide range of different business practices, policies, and procedures. This initial configuration may include data structures, such as databases and tables, including wide varieties of data fields that may be used by different companies. Given the wide variety of data fields included in ERP system to accommodate different industries and functions, it is likely that at least some of the data fields will not be used by different companies.
These unused fields may be stored in memory leading to an inefficient use of computing resources. While it is possible to manually remove each of the unused fields from the data structures and memory, doing so is impractical and costly. ERP systems may have hundreds of data structures containing hundreds of fields—the personnel requirements alone may be cost prohibitive. Additionally, if a data field in use is improperly edited or removed, unexpected errors may occur at runtime. Diagnosing these errors may also require additional resources and expense that could otherwise be avoided.
In sum, there is a need to eliminate extraneously information from data structures and memory to improve system performance at runtime while minimizing the potential for errors.
In an embodiment of the invention, data structures, such as databases, tables, and other storage arrangements that store data in an enterprise resource planning (ERP) system may be configured and custom-generated in a configuration mode. In the configuration mode, the organization may select a subset of optional data fields that the organization intends to use during runtime to avoid allocating space and resources to the unused data fields. This selection may be performed by computer configuration experts or other computer users working for the organization who may select these optional data fields from catalogs displayed in a user interface. Some of these exemplary catalogs and user interfaces are described below and shown in the figures.
Data structures may then be created using the selected subset of data fields so that at runtime the generated data structures no longer support the non-selected data fields. This in turn saves space and resources that would otherwise be allocated but not used. In ERP systems which include a wide variety of data fields designed for different processes used by different organizations in different industries with different computing requirements, substantial space and computing resources may be saved by only allocating space and resources to data fields that are actually used.
Once the particular data fields, such as optional fields, that an organization intends to use in the ERP system have been identified in the configuration mode, the data structures may be generated. The data structures may be generated to only include the selected fields the organization intends to use as well as other essential fields necessary for the ERP system to function, such as, for example, any fields designated as mandatory fields. Similar fields that appear in more than one data structure may be automatically linked or otherwise associated to preserve data consistency and continuity between different functions and processes in the ERP system.
Once the data structures have been generated, the data associated with each of the data structures may be inserted, imported, or otherwise entered, accessed, and/or modified in each data structure as determined by the ERP system. At runtime, the data associated with the fields included in the generated data structures may be loaded into memory where the other fields not included in the generated data structures may not be loaded into memory.
If a data structure is to be changed in the future, such as if the organization decides to keep track of an additional parameter or provide an additional service necessitating the need to store an additional field, the configuration mode may be re-entered. The data fields that are to be added may be selected and thereafter, a new data structure may be generated or the existing data structure may be modified. If an additional data field is added to an existing data structure, then the data structure may be expanded to accommodate the additional data. Alternatively, if a new data structure is created, the new data structure may be used in conjunction with the old structure.
In some instances the field catalog may list individual data fields, such as customer first name field and customer last name field. The field catalog may also list broader categories representing a compilation of data fields. For example, the credit card payments fields 127 may including those data fields relating to credit card payments, such as credit card number field, expiration date field, credit card name field, authorized code field, charged amount field, and so on. In some instances, the field catalog may have a hierarchical tree structure with broader categories of fields that may be selected, and/or individual fields within a category that may be selected. Thus, in the credit card example, fields such as the credit card number field, expiration date field, credit card name field, authorized code field, charged amount field, and so on may be selectable nodes that appear when the credit card payment field 127 is expanded. Each field catalog, its descendents, and/or its ancestors may be individually selected or deselected. In some instances, selecting or deselecting a parent node may automatically select or deselect its children and/or other descendants.
The amount of space (in bytes) allocated to each data field in field catalog 120 database is shown in the data dicitonary (DDIC) length column 130. In this example, if space was allocated for each of the possible data fields listed in the field catalog 120, each data record would have an untailored length of 672 bytes as shown in untailored length 140. However, by generating a data structure that only supports the selected quantity fields 122 and invoice description fields 126, in addition to the mandatory basic data fields 121, the space allocated for each data record in the structure may be reduced to 256 bytes as shown in tailored length 150, resulting in an estimated space savings of over 60% in a hypothetical computing environment.
If a data structure including each of the fields listed in the field catalog 120 is generated, populated with data, and loaded into memory, each data record may be estimated to be allocated about 1,300 bytes of memory in a hypothetical computing environment, representing the sum of length of data in the mandatory basic data fields 321 (310 bytes), the selected quantity fields 322 (22 bytes), the selected invoice description fields 326 (100 bytes), the null values in the remaining fields and the other fields, such as any mandatory standard fields (868 bytes).
When selecting the fields to be included in generated data structures in a tailored 350 embodiment, the data structure including only the actually selected and used data fields may be generated, populated with data, and loaded into memory. In this case, the generated data structure may only include the mandatory basic data fields 321, and the selected 310 quantity fields 322 and invoice description fields 326. Thus, when these data records are loaded into memory, each data record may be expected to occupy only 944 bytes of memory, representing the sum of the allocated length of data 330 in the mandatory basic data fields 321 (310 bytes), the selected quantity fields 322 (22 bytes), the selected invoice description fields 326 (100 bytes), and the other fields, such as any mandatory standard fields (512 bytes). This may result in an expected memory savings of more than 25% over the untailored scenario 340.
While in the configuration mode 410, optional fields that may be included in at least one data structure supported or used by the ERP to store, manage, or organize data may be identified. The data structure provides an organized arrangement for large quantities of data that may be stored, accessed, changed, or otherwise managed by the ERP system. In some embodiments the optional fields may be identified by extracting a list of fields that may be included in each data structure used by the ERP system, identifying the unique, non-duplicated fields, and then presenting a consolidated list of the optional fields to another program or procedure for selection. A field catalog may be created from the list of fields. The field catalog may, in some instances, group together related fields into broader field categories. These groupings may include tree structures with the broader categories representing parent nodes and the narrower categories and individual fields representing child nodes.
In some instances, the broader field categories included in the field catalog may represent particular modules or functionality offered by the ERP system. For example, both an invoicing function and an accounting function may, if the organization accepts credit cards, read and process stored credit card data through a credit card module. Thus, if an organization intends to process credit card payments, the credit card payment field category may be selected, which may include a credit card type field, credit card number field, credit card name field, credit card expiration date field, and so on. The category name, in this case credit card payment category, and the data fields included with the category may be determined by the structure of the fields in the ERP system. For example, in some embodiments, each of the aforementioned credit card fields may be included in a same credit card processing module. Thus, the extraction process may, in some instances, identify broader field categories and the specific data fields included in the categories from various modules included in the ERP system.
Once the data fields or field categories have been identified, a selection may be made of those fields or field categories that the organization actually intends to use. In box 412, each of the data structures in the ERP system in which the selected fields or field categories appear may be identified.
In box 413, each of the identified data structures may be generated to include support for any mandatory fields and data as well as the additional selected fields and/or field categories. Those non-mandatory fields and/or field categories that were not selected for inclusion in the data structure need not be included in the data structure and need not be supported by the data structure. The data structure may be generated as an Advanced Business Application Programming (ABAP) Data Dictionary (DDIC) structure or, in some other embodiments, that may be an equivalent array or map structure in Java.
The runtime mode 420 may be used during runtime, when the ERP system is used to facilitate business operations and processes. For example, in an invoicing system, the invoices may actually be generated in the runtime mode using customer data and product/usage data stored in the generated data structures.
In box 431, the generated data structures may be populated with data associated with each of the fields in the data structures. In some instances the data may be imported from or obtained from other external computing systems or data storage systems. In other instances the data may originate from another source, such as through a form containing customer supplied information. The data may be then be stored in the data structure itself for use by the ERP system. The data structures may be initially populated with data in the runtime mode 420. Changes to data in the data structure that occur during business operations may occur in the runtime mode 420.
In box 421, data associated with the data fields and/or field categories of the generated data structures may be loaded into memory to facilitate quicker access to the data. The loading of this data into memory may occur in the runtime mode 420. To minimize memory use, only data associated with those fields and field categories included in the generated data structure may be loaded into memory. Any other non-mandatory data fields or field categories need not be loaded into memory.
Each of the systems, clients, and devices in
Communications device 504 may enable connectivity between the processing devices 502 in each of the systems and the network 550 by encoding data to be sent from the processing device 502 to another system over the network 550 and decoding data received from another system over the network 550 for the processing device 502.
In an embodiment, memory 503 may contain different components for retrieving, presenting, changing, and saving data. Memory 503 may include a variety of memory devices, for example, Dynamic Random Access Memory (DRAM), Static RAM (SRAM), flash memory, cache memory, and other memory devices. Additionally, for example, memory 503 and processing device(s) 502 may be distributed across several different computers that collectively comprise a system.
Processing device 502 may perform computation and control functions of a system and comprises a suitable central processing unit (CPU). Processing device 502 may include a single integrated circuit, such as a microprocessing device, or may include any suitable number of integrated circuit devices and/or circuit boards working in cooperation to accomplish the functions of a processing device. Processing device 502 may execute computer programs, such as object-oriented computer programs, within memory 503.
The foregoing description has been presented for purposes of illustration and description. It is not exhaustive and does not limit embodiments of the invention to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from the practicing embodiments consistent with the invention. For example, some of the described embodiments may include software and hardware, but some systems and methods consistent with the present invention may be implemented in software or hardware alone.
Number | Name | Date | Kind |
---|---|---|---|
7720804 | Fazal et al. | May 2010 | B2 |
20020178188 | Irizarry | Nov 2002 | A1 |
20030083962 | Araki et al. | May 2003 | A1 |
20030093337 | Song et al. | May 2003 | A1 |
20070250769 | Bass et al. | Oct 2007 | A1 |
20100107056 | Underhill et al. | Apr 2010 | A1 |
20100205551 | Underwood et al. | Aug 2010 | A1 |
20110029577 | Notani et al. | Feb 2011 | A1 |
20110119689 | McCrae et al. | May 2011 | A1 |
20110202442 | Rabstejnek | Aug 2011 | A1 |
Entry |
---|
McIntosh, Nathaniel, et al., “Whole-Program Optimization of Global Variable Layout”, Java, Compilers, and Tools Laboratory, Hewlett-Packard Co., 2006, pp. 164-172. |
Nakar, Doron, et al., “Selective Main Memory Compression by Identifying Program Phase Changes”, Tel Aviv University, 2004, pp. 96-101. |
Number | Date | Country | |
---|---|---|---|
20130046940 A1 | Feb 2013 | US |