Abstract:
A system to execute a function includes determination of a plurality of parameters associated with a function, determination of columns of a table based on the plurality of parameters, and generation of metadata defining the columns of the table and mapping the columns to associated ones of the plurality of parameters. Also included may be generation of a Structured Query Language query of the table based on the metadata, the query specifying a value of a first column of the table, assignment of the value to one of the plurality of parameters based on the metadata, and calling of the function with the assigned parameter value.

Description:
BACKGROUND 
       [0001]    Conventional enterprise computing systems may utilize data provided by many disparate sources. These data sources may include one or more relational databases, Online Analytical Processing (OLAP) databases, text files, application servers, etc. The enterprise computing system may connect to each datasource via a corresponding software connector. For example, to retrieve data from a datasource, the enterprise computing system transmits a Structured Query Language (SQL) query to the software connector corresponding to the datasource. By using such software connectors, the different data formats and access techniques of the datasources become substantially transparent to the enterprise computing system. 
         [0002]    The above-described architecture is insufficient for some potential sources of data. An Application Programming Interface (API), for example, may provide functions which return data to their callers and/or allow a caller to manipulate external data. However, no system currently exists to efficiently call a function and retrieve results thereof based on an SQL query. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0003]      FIG. 1  is a block diagram of a system according to some embodiments. 
           [0004]      FIG. 2  is a flow diagram of a process according to some embodiments. 
           [0005]      FIG. 3  is a view of an interface provided by an information designer according to some embodiments. 
           [0006]      FIG. 4  is a view of an interface provided by an information designer according to some embodiments. 
           [0007]      FIG. 5  is a view of an interface provided by an information designer according to some embodiments. 
           [0008]      FIG. 6  is a view of an interface provided by an information designer according to some embodiments. 
           [0009]      FIG. 7  is a view of an interface provided by an information designer according to some embodiments. 
           [0010]      FIG. 8  is a flow diagram of a process according to some embodiments. 
           [0011]      FIG. 9  is a view of an interface provided by an information designer according to some embodiments. 
           [0012]      FIG. 10  is a view of an interface provided by an information designer according to some embodiments. 
           [0013]      FIG. 11  is a block diagram of a system according to some embodiments. 
           [0014]      FIG. 12  is a flow diagram of a process according to some embodiments. 
           [0015]      FIG. 13  is a view of an interface according to some embodiments. 
           [0016]      FIG. 14  is a view of an interface according to some embodiments. 
           [0017]      FIG. 15  is a block diagram of a system according to some embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0018]    The following description is provided to enable any person in the art to make and use the described embodiments and sets forth the best mode contemplated for carrying out some embodiments. Various modifications, however, will remain readily apparent to those in the art. 
         [0019]      FIG. 1  is a block diagram of system  100  according to some embodiments. The elements of system  100  may operate to generate metadata associated with the parameters of a function. As will be described below, the metadata may be used to call the function based on an SQL query. Moreover, the metadata may be used to generate the SQL query. 
         [0020]    Each element of system  100  may be implemented by any suitable combination of hardware (e.g., one or more processors) and/or software (e.g., processor-executable program code). System  100  may include elements in addition to those illustrated, and some embodiments may omit one or more elements of system  100 . 
         [0021]    Function provider  110  may comprise any system exposing a callable API that is or becomes known, including but not limited to an Advanced Business Application Programming (ABAP) application server. The API may include one or more functions, each of which is associated with one or more input parameters and output parameters. Function provider  110  may support a particular protocol for calling its functions, which may depend on the programming language in which the functions are written (e.g., ABAP, Java, C++, etc.). 
         [0022]    In some embodiments, information designer  120  receives a list of functions from function provider  110 . Information designer  120  may also receive parameters of selected functions from function provider  110  and generate function metadata  130  based thereon. Information designer  120  may comprise a standalone, Web-based or other application executing on any computing device or devices that are or become known. 
         [0023]    For a given function, function metadata  130  includes metadata defining one or more “virtual” tables. The tables are referred to as “virtual” because the metadata does not represent physical tables. The virtual tables are representations of the given function, and may be used as described below to formulate SQL queries on the function and to return SQL-formatted results. As will also be described below, the metadata may associate particular columns of each table with particular parameters of the given function. 
         [0024]      FIG. 2  is a flow diagram of process  200  according to some embodiments. Process  200 , and all other processes described herein, may be executed by computer hardware and/or embodied in program code stored on a tangible computer-readable medium. Process  200  may be performed by information designer  120  of system  100 , but embodiments are not limited thereto. 
         [0025]    Initially, at  5205 , a function provided by a function provider is identified. Any system for identifying a function may be used at  5205  in some embodiments. For example, the function may be identified from documentation provided by a developer of function provider  110 . 
         [0026]      FIGS. 3 through 7  include user interfaces illustrating identification of a function according to some embodiments. The user interfaces are shown as displayed in a Web browser window. Accordingly, the user interfaces may be provided by a Web-based application (e.g., information designer  120 ) and presented by a display device of a client device in which the Web browser is executing. 
         [0027]    As shown in  FIG. 3 , an operator has selected the “Add datasource” menu item from user interface  300 . Window  400  of  FIG. 4  is displayed in response to this selection. Window  400  lists several different datasource vendors. Each vendor may be expanded to select a particular type of datasource provided thereby. These datasource types may include relational databases, OLAP databases, application files (e.g., spreadsheets), and other systems. In the present example, vendor SAP is expanded and a datasource type corresponding to an SAP Enterprise Resource Planning (ERP) system is selected. Moreover, the operator has assigned the name “Datasource6” to the datasource. 
         [0028]    It will be assumed that the present example illustrates creation of a datasource for a Java target system. Accordingly, since an SAP Enterprise Resource Planning (ERP) system provides an API written in ABAP, the target system may use the SAP ERP Java Connector adapter for calling a function from this datasource. In contrast, no adapter is needed for calling a function from a Java API, and Java native calls may be used (using Java Native Interface) to call a function from an API written in C++. 
         [0029]      FIG. 5  shows interface  500  to define properties of a connector to be associated with the datasource. For example, field  510  allows the operator to specify a configuration file for the connector. The connector will be used, in conjunction with the already-defined adapter, to communicate with the datasource during process  200 . The connector may also be used to create a function call based on an SQL query as described below with respect to process  1100 . 
         [0030]      FIG. 6  illustrates an area of interface  500  not shown in  FIG. 5 . Field  520  allows the operator to perform a wildcard search of function names provided by the datasource. This type of searching is provided by ABAP via the SAP ERP Java Connector adapter, but embodiments are not limited thereto. 
         [0031]    Generally, an adapter for a datasource may provide searching of available functions based on metadata including, but not limited to, name, class name, and package name. Languages such as Java and C++, for example, provide an introspection feature for discovery of all the classes and functions of a deployed package. This feature may be combined with a search algorithm to retrieve available functions associated with specified metadata. 
         [0032]    Window  700  of  FIG. 7  provides a list of available functions which satisfy the wildcard search. The operator has selected the function BAPI_FLCONN_GETLIST from the list in order to identify the function at S 205 . S 205  may also consist of identifying any functions that must be executed prior to calling the identified function, such as constructors and initialization functions. These functions may be identified automatically using introspection or other functions provided by the function&#39;s language for this purpose. Alternatively, an operator may manually identify these functions. 
         [0033]    Parameters associated with the identified function are determined at S 210 . Also determined at S 210  may be parameters of any constructors and/or initialization functions identified at S 205 . Again, ABAP provides functions to retrieve function parameters, and other languages may provide similar features. In this regard, parameters of a function may be determined through introspection and searching as described above. 
         [0034]    Columns of one or more tables are determined based on the function parameters at S 215 . Each column represents a function parameter. As described above, the tables are not physical tables for storing data. Rather, the tables are defined data structures to represent the identified function so that SQL queries on the function may be generated and fulfilled. 
         [0035]      FIG. 8  is a flow diagram of process  800  to determine the columns of the one or more tables based on the parameters according to some embodiments. In this regard, the function is associated with one “main” virtual table and may, as will be described below, be associated with additional virtual tables. 
         [0036]    A data type of a first parameter is determined at S 805 . If the data type of the parameter is “simple” (e.g., string data type, integer data type, float data type, Boolean data type, etc.), a column of the main table is determined and associated with the parameter. In some embodiments, the column name is the name of the parameter. Flow proceeds from S 805  to S 815  if the determined parameter data type is “complex” (e.g., class data type or structure data type). 
         [0037]    At S 815 , the complex parameter is recursively split into its constituent simple data type parameters. This splitting will create a hierarchy of simple data type parameters. Next, at S 820 , a main table column is determined for each simple data type parameter of the hierarchy as described above with respect to S 810 . However, in some embodiments, the name of the table column associated with a given parameter of the hierarchy indicates a parent parameter (if any) of the given parameter. For example, the name of the column may include the name of the given parameter and a prefix including the name of the parent parameter. 
         [0038]    If the parameter is determined to exhibit a list data type (e.g., arrays, tables, or vectors of simple and/or complex data types) at S 805 , a separate list table is associated with the parameter at S 825 . The name of the list table may include the parameter name and a prefix indicating that the table is associated with a list data type. Each column of the list table is associated with an element of the list parameter. At S 830 , nested list parameters (if any) are mapped to additional rows of corresponding complex and simple data types for each element of the list parameter. 
         [0039]    Flow proceeds to S 835  from S 810 , S 820  and S 830 . If the function is associated with additional parameters, flow returns to S 805  for processing as described above. If not, flow continues to S 220 . Embodiments are not limited to the specific order of steps illustrated in  FIG. 8 . For example, the columns associated with all parameters of a given data type (i.e., simple, complex, list) may be determined in a single pass, followed by the determination of columns associated with all parameters of a next data type. 
         [0040]    Returning to process  200 , each determined parameter is identified as an input parameter or as an output parameter at S 220 . If the programming language of the API does not provide a way of explicitly defining input parameters and output parameters, the operator may be asked to perform the identifications. 
         [0041]    Metadata is generated at S 225 . The metadata defines the columns of one or more tables associated with the identified function. The metadata may also specify whether each parameter is an input parameter or an output parameter based on the identification at S 220 . Moreover, the metadata may provide a mapping between each column and its associated function parameter. The metadata may be generated in any format, including but not limited to an eXtensible Markup Language (XML) format. 
         [0042]    Interface  900  of  FIG. 9  lists tables determined based on function parameters according to some embodiments of processes  200  and  800 . The tables were determined based on the parameters of the function identified at S 205  in the present example. The listing of the tables in interface  900  may be based on the metadata generated at S 225 . 
         [0043]    Interface  1000  of  FIG. 10  is displayed in response to operator selection of table TABLE_BOOKING_LIST in pane  910 . Interface  1000  illustrates the determined columns of table TABLE_BOOKING_LIST. Each column name indicates, using an “IN_” or “OUT_” prefix, whether a parameter associated with the column is an input parameter or an output parameter. The column information presented in interface  1000  may be determined from the metadata generated at S 225 . 
         [0044]      FIG. 11  is a block diagram of system  1100  to execute a function based on an SQL query according to some embodiments. For continuity, system  1100  includes function provider  110  and function metadata  130  of system  100 . However, system  1100  may comprise any function provider and corresponding function metadata. 
         [0045]    Briefly, and as illustrated, data consumer  1110  provides an SQL query to query server  1120 . Query server  1120  determines a function call based on the SQL query and on function metadata  130 , and the function call is provided to function provider  110 . Function provider  110  executes the function and returns results (e.g., output parameter values) to query server  1120 . Query server  1120  then generates SQL query results based on the returned results and on function metadata  130 . 
         [0046]      FIG. 12  is a flow diagram of process  1200  to more particularly describe the operation of system  1100  according to some embodiments. Process  1200  is not limited to performance by system  1100 . 
         [0047]    Initially, at S 1205 , an SQL query of a function datasource is received. The SQL query may be generated based on function metadata associated with the function. For example, the function metadata may describe virtual tables associated with the function, and the SQL query may select and filter columns of the virtual tables. 
         [0048]    By way of example,  FIG. 13  illustrates a Query Tool of interface  1000  which is not fully shown in  FIG. 10 . The Query tool allows an operator to generate an SQL query based on tables associated with a function datasource, and to execute the query in accordance with embodiments of process  1200 . Accordingly, the Query Tool provides functionality attributed to consumer  1110  and query server  1120  of system  1100 . 
         [0049]    As shown in  FIG. 13 , the operator has selected three columns of the virtual table TABLE_BOOKING_LIST. The three columns are associated with output parameters of the selected function datasource (i.e., BAPI_FLBOOKING_GETLIST). The operator has also specified filter values (i.e., ‘AA’ and ‘20’) associated with two other columns of the virtual table. These two columns are associated with input parameters of the selected function datasource. 
         [0050]    After operator selection of icon  1300 , the query column filter values are mapped to parameters of the function based on metadata associated with the function. As described above, the metadata may map columns of the virtual tables to function parameters. In the present example, the value ‘AA’ is mapped to the input parameter associated with column IN_AIRLINE (e.g., parameter “AIRLINE”), and the value ‘20’ is mapped to the input parameter associated with column IN_MAX_ROWS (e.g., parameter “MAX_ROWS”). 
         [0051]    The parameters are initialized at S 1215  based on the language of the function. For example, the Java Database Connector adapter may use default constructor and setter methods to initialize the corresponding parameters in ABAP. Other constructor and setter methods may be specified at design time. 
         [0052]    The appropriate adapter may then be used to call the function at S 1220  using the initialized parameters. In the present example, function provider  110  (e.g., the SAP ERP system) executes the function and returns values associated with the function&#39;s output parameters to query server  1120  at S 1225 . Query server  1120  maps the values to the output columns specified in the original query at S 1230  based on the metadata associated with the function. 
         [0053]    For example, query server  1120  may receive sets of values (i.e., rows) associated with the function&#39;s output parameters BOOKDATE, CLASS and PASSNAME at S 1225 . At S 1230 , these values are associated with table columns OUT_BOOKDATE, OUT_CLASS and OUT_PASSNAME based on the metadata defining table TABLE_BOOKING_LIST.  FIG. 14  illustrates window  1400  presenting the received values as mapped to virtual table columns according to some embodiments. 
         [0054]      FIG. 15  is a block diagram of system  1500  to perform process  1200  according to some embodiments. Each element of system  1500  may include elements not illustrated in  FIG. 15 . 
         [0055]    Consumers  1510  through  1514  may comprise software applications for object-based viewing of stored business data and/or creating object-based reports including stored business data. Examples of consumers  1510  through  1514  include BusinessObjects Web Intelligence, Crystal Reports, and BusinessObjects Explorer. Any number of consumers of one or more types may be supported according to some embodiments. 
         [0056]    Central management system  1520  includes abstraction layer metadata  1522  corresponding to data stored among one or more of datasources  1530 . Datasources  1530  include at least one function datasource as described herein. Embodiments are not limited to the number and types of datasources shown in  FIG. 15 . 
         [0057]    Abstraction layer metadata  1522  includes metadata defining a set of “business objects” that represent business entities, such as customers, time, financial figures, etc. Business objects may be classified as dimensions (along which one may want to perform an analysis or report), details (e.g., additional information on dimensions), and measures (e.g., indicators, most often numeric, whose value can be determined for a given combination of dimension values). The metadata of abstraction layer metadata  1522  maps the business objects to logical entities of datasources  1530 . Commonly-assigned and co-pending U.S. patent application Ser. No. 12/463,702 describes an abstraction layer, referred to therein as a semantic layer. 
         [0058]    Abstraction layer metadata  1522  allows consumers  1510  through  1514  to query datasources  1530  using intuitive terms rather than references to specific physical entities of datasources  1530 . For example, consumer  1510  may transmit a symbolic query including one or more of the business objects to information engine  1540 . Information engine  1540  then generates an SQL query based on the symbolic query and the metadata of abstraction layer metadata  1522 . 
         [0059]    Query engine  1542  may receive the SQL query and determine that the query is associated with a function datasource. Query engine may therefore execute process  1200  in conjunction with function connector  1544 , adapter  1546  and function metadata  1526  in order to execute the query. Information engine  1540  may receive the SQL-formatted results and provide the results in the desired object-based form to consumer  1510 . 
         [0060]    Accordingly, embodiments may facilitate the use of functions as datasources within existing systems. Moreover, embodiments may be compatible with systems designed to interface with multiple types of data sources and/or employing an object-based abstraction layer to facilitate interaction with underlying data. 
         [0061]    Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.