Patent Application
20140067447
The present disclosure relates to databases, and more particularly to methods of identifying application programming interface (“API”) functions that may be used to operate on business-transaction data similar to that entered and/or displayed via a business-transaction graphical user interface.
Enterprise resource planning (“ERP”) systems, such as SAP ERP Central Component (“ECC”) provided by SAP AG of Weinheim, Germany, are designed to coordinate some or all of the resources, information, and activities needed to complete business processes. An ERP system may support business functions including some or all of manufacturing, supply chain management, financials, projects, human resources, customer relationship management, and the like.
Many ERP systems incorporate a centralized database or other ERP data store, and many ERP vendors provide an application programming interface (“API”) by which business transactions may be performed programmatically (as opposed to performing a business transaction via a user interface). However, it can be difficult for many business users, who may have little programming knowledge, to make use of an ERP business-transaction API (“BAPI”).
One factor that makes it harder for business users to effectively utilize BAPIs is the sheer volume of different BAPIs provided by the ERP system. For example, ECC version 6.0 provides approximately 4,000 distinct BAPI functions.
Business users, including business users with little or no programming skill, use business transaction user interface (“UI”) screens to query and extract information from one or more transaction-related database tables of an ERP system. For many business transactions (e.g., Purchase order creation, sales order creation, and the like), multiple table fields in multiple database tables may be referenced and/or updated in the course of performing the business transaction. In many cases, the ERP system may provide many different BAPI functions that operate on a similar set of database tables and fields. However, using existing tools, it can be difficult and cumbersome for a typical business user to manually identify such BAPI functions for a given business transaction.
According to various embodiments, as described below, an ERP client may automatically determine a list of one or more ERP database tables and fields that store the data associated with a particular business transaction in the ERP system. Various embodiments identify screen fields presented via the business transaction UI, map the screen fields to database-table fields, identify one or more application programming interface functions that operate on some or all of the same database-table fields, and report to the business user a list of some or all of the identified application programming interface functions.
The detailed description that follows is represented largely in terms of processes and symbolic representations of operations by conventional computer components, including a processor, memory storage devices for the processor, connected display devices and input devices. Furthermore, these processes and operations may utilize conventional computer components in a heterogeneous distributed computing environment, including remote file Servers, computer Servers, and memory storage devices. Each of these conventional distributed computing components is accessible by the processor via a communication network.
Reference is now made in detail to the description of the embodiments as illustrated in the drawings. While embodiments are described in connection with the drawings and related descriptions, there is no intent to limit the scope to the embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents. In alternate embodiments, additional devices, or combinations of illustrated devices, may be added to, or combined, without limiting the scope to the embodiments disclosed herein.
In some embodiments, ERP Server 110 may further comprise an application server (not shown), and/or ERP Server 110 may further include the functionality of an application server.
In various embodiments, network 150 may include the Internet, a local area network (“LAN”), a wide area network (“WAN”), and/or other data network.
The ERP client device 200 also includes a processing unit 210, a memory 250, and an optional display 240, all interconnected along with the network interface 230 via a bus 220. The memory 250 generally comprises a random access memory (“RAM”), a read only memory (“ROM”), and a permanent mass storage device, such as a disk drive. The memory 250 stores program code for a record to BAPI routine 400 (see
Although an exemplary ERP client device 200 has been described that generally conforms to conventional general purpose computing devices, an ERP client device 200 may be any of a great number of devices capable of communicating with the network 150 and/or ERP Server 110, for example, a personal computer, a game console, a set-top box, a handheld computer, a cell phone, or the like.
Each screen UI field (e.g., 305-307) typically corresponds to a particular field in a persistent database table in the ERP database. In some cases, there may be zero or more layers of indirection between a screen UI field and a corresponding persistent database table.
Various methods for dereferencing UI fields to identify a persistent database table, notwithstanding various layers of indirection, are described in co-pending U.S. patent application Ser. No. 13/464,707, titled “ERP Transaction Recording to Tables System and Method”, and filed May 4, 2012 under attorney docket number WINS-2012025.
For purposes of this disclosure, it is assumed that given a screen UI field, a corresponding field in a persistent database table can be identified using a standard ERP dereferencing function, using methods such as those described in co-pending application Ser. No. 13/464,707, or via other suitable means.
Database table fields (e.g., fields 321, 331, and 351) may also be associated with a “data element” (e.g., data elements 322, 332, and 352). In some embodiments, a data element is an elementary type, which describes the type attributes (e.g., data type, field length, possibly the number of decimal places, and the like) and content attributes such as screen information (e.g., explanatory text, field help, and the like) about unstructured data objects such as table fields, structure components, and the like. Table and UI fields and structure components that should have the same contents should refer to the same data element to ensure that the attributes of such fields remain consistent. In some embodiments, a data element may be identified using an identifier referred to as a “roll identifier” or “rollname”.
Business APIs 303 represents a collection of API functions (e.g., API function 370) that are provided by an ERP system for performing business transactions. An API function typically has one or more input parameters (e.g., parameters 371A-B), each of which is associated with a “structure” (e.g., structures 375A-B) A structure is a template of a field of a database table or of a database table, the structure fields being filled with data values at the time of program execution. Structures are temporary or non-persistent intermediates, typically located in RAM or other short-term memory, where data is stored while it is being processed by a program. For example, as illustrated in
Based on the recording and/or observation, in block 410, routine 400 determines a list of one or more screen UI fields that are involved in the business transaction. For example, in one embodiment, the list may include all screen UI fields of all UI screens of the business transaction.
In subroutine block 500 (see
In subroutine block 600 (see
In subroutine block 700 (see
In block 505, subroutine 500 initializes a BAPI Parameter list to store (at least transiently) BAPI parameter metadata as discussed further below. As the term is used herein, “initialize” refers to setting a variable, field, or other data structure to an initial state. In some cases, initializing may include allocating transient memory to store the data structure, and in some cases, the initial state may be an empty state.
In various embodiments, the BAPI Parameter “list” may comprise, at various times, a list, array, hash, XML data, one or more database tables, or other like data structure stored in transient or persistent memory. In some embodiments, the BAPI Parameter “list” may further be capable of associating two pieces of data with one another. For example, in one embodiment, the BAPI Parameter list may include a list (or array, or hash, or the like) of key-value pairs or similar associative structure. In other embodiments, the BAPI Parameter list may include a pair of parallel lists (or arrays or the like), with associated entries being stored at related indices. In still other embodiments, any other suitable data structure may be employed.
Beginning in opening loop block 510, subroutine 500 processes each of the BAPI functions identified in block 501. In block 515, subroutine 500 determines for the current BAPI function a function name or other function identifier and a set of one or more input parameters for the current BAPI function. See, e.g., columns 1 and 2 of Table 1, above. For example, in one embodiment, such BAPI function metadata may be determined by accessing one or more ERP tables (e.g., table FUPARAREF in an SAP ERP system) storing such metadata.
Beginning in opening loop block 520, subroutine 500 processes each of the input parameters determined in block 515 for the current BAPI function. In block 525, subroutine 500 identifies a structure associated with the current BAPI input parameter. For example, in one embodiment, a structure associated with the current BAPI input parameter may be determined by accessing one or more ERP tables (e.g., table FUPARAREF in an SAP ERP system) storing such metadata.
In various embodiments, a structure identifier may be a string including an optional delimiter string (e.g., “-”). For example, as shown in Table 1 above, a structure identifier may have no delimiter (e.g., “BAPIMGVMATNR”) or one delimiter (e.g., “BAPIMATALL-MATERIAL”).
In block 530, subroutine 500 determines a table identifier identifying a data table corresponding to the structure identified in block 525 for the current BAPI function input parameter. For example, in one embodiment, a table identifier may be a string corresponding to a portion of the structure identifier from the beginning of the structure identifier string up to an optional delimiter string (if present, e.g., “BAPIMATALL”) or to the end of the string (if no delimiter is present, e.g., “BAPIMGVMATNR”).
In decision block 535, subroutine 500 determines whether the structure identified in block 525 specifies a table-field identifier identifying a field of a data table. For example, in one embodiment, if the structure identifier includes a delimiter string (e.g., “-”), then subroutine 500 may determine that the structure specifies a table-field identifier (e.g., “MATERIAL”) and proceed to block 540 to determine a roll identifier identifying a data element associated with the specified table field. In block 545, subroutine 500 adds to the BAPI Parameter list initialized in block 505 an entry including at least the function identifier determined in block 515, the structure identifier determined in block 525, and the roll identifier determined in block 540.
Otherwise, if in decision block 535, subroutine 500 determined that the structure identified in block 525 does not specify a table-field identifier, then in block 550, subroutine 500 identifies one or more fields that comprise the identified data table. Beginning in opening loop block 555, subroutine 500 processes each table field in turn.
In block 560, subroutine 500 determines a roll identifier identifying a data element associated with the current table field. In block 565, subroutine 500 adds to the BAPI Parameter list initialized in block 505 an entry including at least the function identifier determined in block 515, the structure identifier determined in block 525, and the roll identifier determined in block 560.
In closing loop block 570, subroutine 500 iterates back to block 555 to process the next table field (if any). Once all table fields have been processed, in ending block 575, subroutine 500 iterates back to block 520 to process the next BAPI function input parameter (if any). Once all input parameters have been processed, in ending block 580, subroutine 500 iterates back to block 510 to process the next BAPI function (if any). Once all BAPI functions have been processed, subroutine 500 ends in block 599.
In block 610, subroutine 600 initializes a matched_functions list to store (at least transiently) BAPI function metadata as discussed further below. In various embodiments, the matched_functions “list” may comprise, at various times, a list, array, hash, XML data, one or more database tables, or other like data structure stored in transient or persistent memory. In some embodiments, the matched_functions “list” may further be capable of associating two pieces of data with one another. For example, in one embodiment, the matched_functions list may include a list (or array, or hash, or the like) of key-value pairs or similar associative structure. In other embodiments, the matched_functions list may include a pair of parallel lists (or arrays or the like), with associated entries being stored at related indices. In still other embodiments, any other suitable data structure may be employed.
Beginning in opening loop block 615, subroutine 600 processes each of the given screen UI fields in turn. In block 620, subroutine 600 determines for the current screen UI field a corresponding data table identifier, table-field identifier, and roll identifier. See, e.g., screen UI technical information shown in
In decision block 625, subroutine 600 determines whether the UI-field roll identifier determined in block 620 matches roll identifiers corresponding to one or more BAPI function input parameters (see blocks 545 and 565 of
On the other hand, if in decision block 625, subroutine 600 determines that the UI-field roll identifier determined in block 620 matches roll identifiers corresponding to one or more BAPI function input parameters, then beginning in opening loop block 630, subroutine 600 processes each of the matching BAPI function input parameters in turn.
In decision block 635, subroutine 600 determines whether the current UI-field table identifier (determined in block 620) matches the structure identifier of the current matching BAPI function input parameter (see block 525 of
If in decision block 635, subroutine 600 determines that the current UI-field table identifier does match the structure identifier of the current matching BAPI function input parameter, then in block 645, subroutine 600 adds the current BAPI function identifier to the matched_functions list initialized in block 610.
Otherwise, if in decision block 635, subroutine 600 determines that the current UI-field table identifier does not match the structure identifier of the current matching BAPI function input parameter, then in decision block 640, subroutine 600 determines whether the current UI-field table identifier and table-field identifier (determined in block 620) match the structure identifier of the current matching BAPI function input parameter. For example, in decision block 640, subroutine 600 would find a match between a UI-field table identifier of “BAPIMATALL-MATERIAL” and a BAPI-function-input-parameter structure identifier of “BAPIMATALL-MATERIAL”. Conversely, in decision block 635, subroutine 600 would not find a match between a UI-field table identifier of “BAPIMATALL” and a BAPI-function-input-parameter structure identifier of “BAPIMATALL-MATERIAL”.
If in decision block 640, subroutine 600 determines that the current UI-field table identifier and table-field identifier does match the structure identifier of the current matching BAPI function input parameter, then in block 645, subroutine 600 adds the current BAPI function identifier to the matched_functions list initialized in block 610.
In closing loop block 650, subroutine 600 iterates back to block 630 to process the next BAPI function input parameter (if any). Once all BAPI function input parameters have been processed, in closing loop block 655, subroutine 600 iterates back to block 615 to process the next screen UI field (if any). Once all screen UI fields have been processed, subroutine 600 ends in block 699, returning to the caller the matched_functions list.
Beginning in opening loop block 705, subroutine 700 processes each of the given BAPI functions in turn. In block 710, subroutine 700 initializes a UIfield_count variable (or other suitable incrementable data store) corresponding to the current BAPI function, e.g., to an initial value of zero.
Beginning in opening loop block 715, subroutine 700 processes each input parameter of the current BAPI function in turn. In block 720, subroutine 700 identifies a parameter structure corresponding to the current BAPI function input parameter. See, e.g., column 3 of Table 1, above.
In decision block 723, subroutine 700 determines whether the parameter structure identified in block 720 matches a table identifier of a screen UI field of the given business transaction UI screen. For example, in decision block 723, subroutine 700 would find a match between a UI-field table identifier of “BAPIMGVMATNR” and a BAPI-function-input-parameter structure identifier of “BAPIMGVMATNR”. Conversely, in decision block 723, subroutine 700 would not find a match between a UI-field table identifier of “BAPIMGVMATNR-MATNR” and a BAPI-function-input-parameter structure identifier of “BAPIMGVMATNR”.
If in decision block 723, subroutine 700 determines that the parameter structure identified in block 720 does match a table identifier of a screen UI field of the given business transaction UI screen, then in block 730, subroutine 700 updates the UIfield_count variable corresponding to the current BAPI function, e.g., by incrementing its value.
Otherwise, if in decision block 723, subroutine 700 determines that the parameter structure identified in block 720 does not match a table identifier of a screen UI field of the given business transaction UI screen, then in decision block 727, subroutine 700 determines whether the parameter structure identified in block 720 matches a table identifier and a table-field identifier of the given business transaction UI screen. For example, in decision block 727, subroutine 700 would find a match between a UI-field table identifier of “BAPIMATALL-MATERIAL” and a BAPI-function-input-parameter structure identifier of “BAPIMATALL-MATERIAL”. Conversely, in decision block 723, subroutine 700 would not find a match between a UI-field table identifier of “BAPIMATALL” and a BAPI-function-input-parameter structure identifier of “BAPIMATALL-MATERIAL”.
If in decision block 727, subroutine 700 determines that the parameter structure identified in block 720 does match a table identifier and a table-field identifier of a screen UI field of the given business transaction UI screen, then in block 730, subroutine 700 updates the UIfield_count variable corresponding to the current BAPI function, e.g., by incrementing its value.
In closing loop block 735, subroutine 700 iterates back to block 715 to process the next input parameter of the current BAPI function (if any). Once all input parameters of the current BAPI function have been processed, in closing loop block 740, subroutine 700 iterates back to block 705 to process the next BAPI function (if any). Once all BAPI functions have been processed, in block 745, subroutine 700 sorts the given BAPI functions in descending order according to the UI field count values determined in iterations of blocks 725 and 730, such that BAPI functions with a higher UI field count value appear higher in the sorted list.
In block 750, subroutine 700 provides the sorted BAPI functions for presentation to a business user. Subroutine 700 ends in block 799, returning to the caller.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a whole variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. For example, although the description above refers to embodiments involving enterprise resource planning systems, other embodiments may be similarly used in other types of enterprise application systems in which a transaction between an enterprise client and an enterprise server may be recorded and mapped, as variously described above. For example, the systems and methods described herein may be used in connection with enterprise systems such as customer relationship management (“CRM”) systems, accounting systems, supply chain management systems, and the like. This application is intended to cover any adaptations or variations of the embodiments discussed herein.
