Integration test framework

According to some embodiments, systems and methods are provided, comprising a first platform including an Application Programming Interface (API) provider; at least one data source; an integration framework module operative to execute: an integration process to integrate a third-party application with the first platform, and a test process wherein one of a plurality of whitelisted APIs provided by the API provider is executed to analyze the integration; a user interface; a memory storing program instructions; and an integration framework processor, coupled to the memory, and in communication with the integration framework module and operative to execute program instructions to: receive input data associated with the at least one data source via the user interface; transform the input data to an XML format for the integration process; access an API of the plurality of APIs; one of enter XML, format data into the API and retrieve data from the API; transform the retrieved data into a non-technical format; and render the transformed data in a dynamic user interface. Numerous other aspects are provided.

BACKGROUND

To help prevent unauthorized access to an organization's computer network, only IP addresses in an Application Programming Interface (API) whitelist can make API calls to the organization's network. Generally speaking, a “whitelist” is an index of approved entities, and “whitelisting” is the practice of explicitly allowing some identified entities access to a particular privilege, service, mobility, access or recognition. Any entity not on the whitelist is blocked from access.

A third-party user may want to access the organization's computer network to avail themselves of the services/products and data stored on the organization's computer network. The data provided by the third-party user may need to be read, formatted and processed before being allowed to access the organization's computer network via an appropriate whitelisted API. These read, write, update, format, process operations may be difficult to execute as they are manual processes, and no user-friendly interface exists to facilitate these processes.

Additionally, a third-party user may build an application to access the organization's computer network using one or more whitelisted APIs provided by an API provider. Prior to using the whitelisted API in their application, the user may want to test the whitelisted API to determine the input and input parameters, as well as the output. The user may want to see the format of the input/output to understand how the data is received and provided in order to facilitate their development of their application. However, users may find it difficult to test whitelisted APIs from an API provider, as no user-friendly interface is provided.

The existing methodology for an API consumption revolves around an elementary form of data exchange, where the user is expected to interpret the underlying data structures, data types and the data format for input and output. Often, the exchange of data between the user and the API results in exchange failure due to the inability of the user to understand the data.

Systems and methods are desired which support efficient integration of a third-party user with an organization's computer network.

DETAILED DESCRIPTION

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.

For security reasons, third-party users/applications may not be given direct access to an organization's computer network. Instead these third-party users may use a whitelisted API to access the organization's computer network. As described above, only IP addresses in an Application Programming Interface (API) whitelist can make API calls to the organization's network. Generally speaking, a “whitelist” is an index of approved entities, and “whitelisting” is the practice of explicitly allowing some identified entities access to a particular privilege, service, mobility, access or recognition. Whatever is not on the whitelist is blocked from access.

The whitelisted API may receive data from the third-party user in a particular format for processing in order to access the organization's computer network. The data (e.g., documents) received from the third-party user may be read, formatted and further processed before being received by the whitelisted API. The processes to read, format, etc. may not be user friendly as they are manual processes in a language (e.g., JSON) not readily understandable by a non-technical user. Further, the third-party user may want to test the whitelisted API before using it to access the organization's computer network. The testing may include determining the input, input parameters and output, as well as determining the format of the input/output to understand how the data is received and provided.

The existing methodology for API consumption revolves around an elementary form of data exchange, where the user is expected to interpret the underlying data structures, data types and the data format for input and output. As shown in the user interface100inFIG. 1, the data is read in JSON format, so the user needs to understand this format to understand the data. Often, the attempted exchange of data between the user and the API provided by an API provider results in failure due to the inability of the user to understand the data.

One or more embodiments provide an integration framework module to: 1. Create, read, update and delete data in the platform so as to be integrated with a third-party application; and 2. Test any whitelisted APIs.

One or more embodiments provide for reading a specific record of a business object, as well as a dynamic visualization for creating/updating/viewing/testing data, and any other suitable data-related process. The UI may read the DML and list the information for display in the UI. The integration framework module, in one or more embodiments, may be a new technical layer on top of an API, and may interpret the input data and output data, and the complex formats, to provide the data to the user in a consumable manner (i.e., non-technical format without technical text of JSON or XML), without the user needing to understand the technical aspects of JSON or XML. The integration framework module supports non-technical users to consume APIs easily and productively. It is noted that one or more embodiments provide another layer on top of the XML (or other technical language) to make the UI understandable by the user, as typically XML is a technical text.

One or more embodiments provide for an integration framework module to set up an integration between the organization's computer network (“platform”) and a third-party user using whitelisted APIs in a create process. The integration framework module may dynamically read data from a format sent by the third-party user and generate data for consumption by an API associated with the organization platform. The platform may then receive the information via the API and create the data on the platform. The integration framework module may facilitate building applications on a cloud platform by reading data from the organization's platform (e.g., generating payload/data formats; visualizing how the application would look using the whitelisted API; and testing the whitelisted API). The integration framework module may also identify test integration requirements.

In one or more embodiments, the integration framework module may read data in XML/JSON formats received from a third-party application and render a dynamic user interface (UI) for a user to easily visualize and manipulate data to test the integration, and then save the manipulated data, without requiring knowledge of XML or JSON formats. It is noted that while XML may be the frequently data format for third party applications, any suitable format may be used. The UI may be dynamically rendered by the integration framework module intelligently identifying the Business Objects and the number of fields in the XML/JSON format, as described further below. Conversely, in one or more embodiments, the integration framework module may simulate the third-party application and create XML to read master data and transaction data from the organization's platform and synchronize with the third-party application to create documents for the application in the organization's platform.

As a non-exhaustive example, a Sales Force application (third-party application) is used to obtain customer details and sales orders, whereas fulfillment of the sales orders occurs via the organization's platform. While this non-exhaustive example may be referred to throughout the specification, any third-party application may be used.

In one or more embodiments, the integration framework module may read the data format of a whitelisted API and dynamically render a UI which may be used by a third-party user to read data from all systems across the organization's platform that publish APIs at an API provider. This read data may then be processed and updated back into the respective system. The integration framework module may, in one or more embodiments, support all Create, Read, Update, Delete (CRUD) operations that a given whitelisted API supports.

It is noted that, in one or more embodiments, the integration framework module may be integrated with an API provider or deployed on a cloud platform, and may also be included in a tool available on the organization's platform. The integration framework module may be used for testing and setting up integrations within the organization's landscape and with third-party applications.

Regarding testing, as described above, testing the APIs using existing tools may be very difficult due to lack of a user interface, and specific JSON/ODATA/REST/WL/SOAP knowledge to test the API. Embodiments provide the integration framework module to render a dynamic user interface based on a selected API for ODATA, REST and SOAP. Embodiments may provide sample data to the user in the expected formats for all fields of the API for a “create” test operation. Embodiments may provide for the user to view existing data of a record and “edit” the data as needed during testing.

FIGS. 2-15include a system200and flow diagrams of processes400(FIG. 4),800(FIG. 8) and1300(FIG. 13) for executing an integration framework module according to some embodiments. Processes400,800and1300may be executed by application server1630according to some embodiments. In one or more embodiments, the application server1630may be conditioned to perform the processes400,800,1300, such that a processor1610(FIG. 16) of the server1630is a special purpose element configured to perform operations not performable by a general-purpose computer or device.

All processes mentioned herein may be executed by various hardware elements and/or embodied in processor-executable program code read from one or more of non-transitory computer-readable media, such as a hard drive, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, Flash memory, a magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units, and then stored in a compressed, uncompiled and/or encrypted format. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software.

In one or more embodiments, the system200may include an organization computer network platform202(“organization platform”). As a non-exhaustive example, the platform may be any cloud-based or otherwise enterprise resource planning platform, such as SAP S/4HANA Cloud®. The platform202may include: one or more user interfaces204that may be accessed by one or more users (not shown) of the platform202; one or more applications206that may be executed on the platform202; and one or more databases208. Although not shown, the platform202may include any suitable processors, servers and processor-executable program code.

The system200may also include a cloud platform210(or other suitable platform) that may be accessed by the organization platform202via one or more APIs211. As used herein, the terms “Open API” and “Whitelisted API” may be used interchangeably. In some examples, the embodiments herein may be incorporated within software that is deployed on a cloud platform. The cloud platform210may include multiple tenants212. In an embodiment, a tenant may represent an application or system in a distributed computing environment (e.g., cloud computing environment). In some embodiments, multiple tenants may be deployed in the cloud computing environment, onto which the user may log on and execute specific functionalities or operations. The cloud platform210may include the internet, in that any servers on the cloud platform210may be located remote from clients/third-party users. In some embodiments, multiple third-party tenants212may access the cloud platform210via the internet or other suitable communication channel.

In one or more embodiments the cloud platform210may include the integration framework module214. The cloud platform210may also include a cloud platform integration (CPI) module216. The CPI module216may allow the synchronization of data between another system component (e.g., SFTP server218) and the organization platform202. In one or more embodiments, the CPI module216may enable bi-directional process integration in real time between the system component and the organization platform. The CPI module216may include a machine learning process217whereby the machine learning process may include an Integration Content Advisor (ICA) to execute the source-target mapping. As a non-exhaustive example, the source may have “first name” and “last name” in different fields, but the target understands them in a single filed called “name format”. As such, the ICA may combine the two fields into one filed in the target based on existing training. It is noted that the mapping process may be via ICA, other machine learning processes, or event executed without machine learning (e.g., manually).

The system200may, in one or more embodiments, include a Secure File Transfer Protocol (SFTP) server218. The SFTP server218may be communicatively coupled to the cloud platform210, and in particular to the integration framework module214and the CPI module216. In one or more embodiments, the communicative coupling may be via an XML, exchange220or any other suitable channel.

Prior to the start of the process400, a map222is created to link every field of the third-party application to a particular location in a given API. In one or more embodiments, in the map222, the fields from the third-party application may be in XML format. In one or more embodiments, the map222may be generated by any suitable process (e.g., an i-flow process). As used herein, the terms “API” and “whitelisted API” may be used interchangeably.

Turning toFIG. 4, the process400to integrate data from the third-party tenants212with the organization platform202is provided.

Initially, at S410, input224is received via an integration framework module-created user interface for the third-party application212. In one or more embodiments, the UI created by the integration framework module214mimics the third-party application212, as the integration framework module214has built an API to receive the information from the third-party application. In one or more embodiments, the UI is dynamically generated by the integration framework module214, and then the data is filled in by the user. The input224may be the data entered by a user of the third-party application212, where the third-party application is the data source. In one or more embodiments, the input224may be received in JSON format or any other suitable format.

Continuing with the non-exhaustive example described above, the user of the third-party application212may create a sales order.FIG. 5, shows an example of user interface500to create a sales order via the third-party application212. The user interface500may include a record502from which the sales order may be created. Each record501may include one or more columns503of data. In the example shown herein, the user interface500displays a record502including sales orders for a particular sales order type504. The record502may include one or more columns503storing data elements506(e.g., sales organization, soldtoparty, etc.) for the respective column. The user may create the sales order by selecting the “create sales order” button508, or via any other selection element.

After selection of the “create sales order” button508, in one or more embodiments, the user may be presented with a template602to enter the input224into one or more fields604, as shown inFIG. 6. It is noted that each of the fields604in the template602may correspond to a column503in the record502. Continuing with the example shown herein, the user has decided to create an order for sales order24, and entered the input the user wants to integrate with the organization platform202. It is noted that the user of the third-party application212may enter input into all of the fields604or less than all of the fields604. It is noted that the UI the user enters data into is not the actual UI for the third-party application, rather, the UI is the simulated UI created by the integration framework module214for testing purposes. The determination of which fields to enter data in may be based on the business objects, which are selected via the application (e.g., mandatory fields are based on the selection of the business object. In one or more embodiments, only the mandatory fields need to have data entered therein. After the user enters data in the one or more fields604, the user may select the “create” button606. While a button is shown herein, any suitable selector may be used.

In one or more embodiments, selection of the “create” button606may transmit a JSON version of the template602to the integration framework module214. The integration framework module214then converts the received input into an XML, format file in S412. It is noted that the integration framework module214may convert the received input into any other suitable format.

In one or more embodiments, as part of S412, the integration framework module214may include an XML binding process302(FIG. 3). The XML binding process302may associate each of the columns503of the record503with an XML tag303. As used herein, the XML tag303may indicate the start and end of the information to be converted to XML. In one or more embodiments, each XML tag303may correspond to a column503of the record. In one or more embodiments, each column may include a sequence number associated therewith to indicate the order in which the columns were originally received. After the XML binding process302, a MAP Reduce (JS) process304may be executed. The MAP Reduce (JS) process304may use the associations created by the XML binding process302and manipulate these associations to create a smaller set of associations. It is noted that the XML binding process302may be for the technical component (e.g., Views) of the UI application, and may be separate from the XML placed in the SFTP server. A non-exhaustive example of a MAP Reduce (JS) process304may be Apache MapReduce®. The output of the MAP Reduce (JS) process304may then be received by a JSON to XML Parser306. In one or more embodiments, the JSON to XML Parser306may generate the XML format file. Next, the SFTP server218, and in particular, a servlet layer308of the SFTP server218may receive the generated XML format file. In one or more embodiments, the servlet layer308may be a JAVA servlet layer, and may be used to interact with the CPI module216and the JSON to XML Parser306of the integration framework module214, as well as the XML to JSON Parser310of the integration framework214, described further below. In one or more embodiments, the integration framework module214may transmit the generated XML format file to the SFTP server218via the XML exchange220, or any other suitable communication channel.

In one or more embodiments, after the SFTP server218has received the generated XML format file, the user may receive a confirmation message702(FIG. 7) via the user interface700.

Turning back to the process400, in S414, the CPI module216may receive the generated XML format file from the servlet layer308of the SFTP server218via another XML exchange220or any other suitable communication channel. The CPI module216may execute one of a pull process, whereby the CPI module216polls the SFTP server218to determine whether any new generated XML format files are available, and a push process, whereby the CPI module216receives notification of the existence of new generated XML format files. The polling may be executed in any suitable time interval.

The CPI module216may then read the XML format file and extract data therefrom in S416. In one or more embodiments, the extracted data may be the data values224included in the fields604(e.g., the information from the sales order). Next, in S418, the CPI module216may map the extracted data to the representative whitelisted API211per the map222created prior to execution of the process400. In one or more embodiments, mapping the extracted data to the representative whitelisted API211may include the CPI module216recognizing, via a machine learning (ML) based mapping process217, that the XML format file relates to a particular API. It is noted that the ML process217may be used to automate the XML reading, processing and formatting features.

Continuing with the non-exhaustive example, the CPI module216has been trained via the ML process217to recognize that the tags303in the XML format file correspond to a salesorder API211in the organization platform202. The CPI module216may then call the particular API (e.g., salesorder API), and determine where in the API to input the tags303from the XML format file. It is noted that the operation to be performed on the whitelisted API211(e.g., read/write/update/delete operation) based on the calls and what the user wants is configured by the CPI module. Continuing with the example, a salesorder ID from the XML format file (e.g., number34inFIG. 6) may be a bit in the API211and the salesorder ID from the API may be a field. As another non-exhaustive example, a “CUSTOMER ID” filed in XML coming from a third-party application may be a “SOLD TO PARTY” field in the organization platform (API). As yet another non-exhaustive example, “Quantity” and “Unit” (e.g., 50 pieces) in an organization platform (API) may be mapped to a different quantity and unit (e.g., 1 Carton) in the third-party application. The whitelisted API211is then completed with the extracted and mapped data in S420. Next, the CPI module216may push the completed whitelisted API211to the organization platform202for further processing in S422. At this point, the received input224has been created as a record in the organization platform202based on the data mapped to the API. Continuing with the non-exhaustive example herein, the organization platform202may fulfill the order per the received completed whitelisted API211.

Turning toFIGS. 8 and 9, a process800(FIG. 8)/900(FIG. 9) to receive data (e.g., a read operation) from organization platform202by the third-party application212is described. The read operation may be executed at any time after the data has been created in the organization platform202.

As shown inFIG. 9, a process may start when a user wants to perform, a read” operation and a “get data” operation from a data source. As described further below, the user may trigger the API from the API provider. The API provider may then request data from the data source. The fetched data may undergo transformation via the integration framework module to transform the fetched data into a non-technical format. For example, in one or more embodiments, the fetched data may be parsed, and XML binding may be executed to output the requested data in a suitable runtime format (e.g., consumable by a non-technical user). The transformed data may then be rendered in a dynamically built user interface, as shown inFIG. 12.

Initially, at S810a read request is received from a third-party application212to read data stored in the organization platform202. The read request may be received via the dynamically generated UI312of the integration framework module214via a request XML placed by the integration framework module214into the SFTP. In one or more embodiments, for testing, and not necessarily part of the deployment of the application, the user of the third-party application212may select1002(e.g., via highlighting) an XML format file1004(FIG. 10) stored on the SFTP server218. Then, in S812, the integration framework module214reads the XML format file and dynamically generates a list1102(FIG. 11) of the possible columns to display in the UI for the user. The list1102of columns may be based on the data in the selected XML format file1004. In one or more embodiments, each column in list1102may include a sequence number1104associated therewith. The sequence number1104may indicate the order in which the columns were originally received by the SFTP server218when the order was created, as described above with respect toFIG. 4. For example, the SalesOrganization column503has a sequence number1104of “27,” meaning that the SalesOrganization column503was the 27thcolumn in the input data received in S410. The user selects which columns they want to display in the dynamic UI in S814.

Next, in S816the SFTP server218retrieves all columns and displays the selected columns from the whitelisted API211via the CPI module216. In one or more embodiments, the CPI module216receives the request from the servlet308of the SFTP server218via the XML exchange220, and requests the particular API from the organization platform202. In one or more embodiments, the API is configured in the CPI module216by creating an integration flow where the API to be called is configured based on the XML file name and/or location. The CPI module216receives the requested API211from the organization platform202and maps the data in the completed API to the XML tags303, in a process opposite from S418, described above, to generate an XML format file. The CPI module216then pushes the generated XML format file to the servlet308of the SFTP server218via the XML exchange220. The SFTP server218then transmits the XML format file to the integration framework module214via the XML exchange220in S818. As shown inFIG. 3, the SFTP server218may pass XML as it is through the servlet308, which is taken over by XML to JSON parser310within the integration framework module214. The integration framework module converts the XML file format to a JSON format via XML to JSON parser310, the MAP Reduce (JS) process304and the XML binding process302. In one or more embodiments, and as described above, the XML is received at the XML to JSON parser310from the SFTP server218by way of the servlet308. The JSON converted by the XML to JSON parser310is utilized and processed via the map reduce process304. After processing at the map reduce process304, the JSON is again mapped to XML views othe UI of the integration framework module214via the XML binding process302. The integration framework module214then transmits JSON format file to a user interface1200of the third-party application212for display thereon as shown inFIG. 12.

As shown inFIG. 11, the data may be provided in a user-readable format, that is understandable by technical and non-technical users. With respect to a “read” functionality, the complexity involved in consumption of fields (during a “get” functionality) may be reduced in one or more embodiments by the integration framework module—at runtime, dynamically, as described above.

The integration framework module may support XML and JSON formats, and any other suitable formats. In one or more embodiments, the integration framework module may dynamically render the UI based on the XML and JSON format by intelligently identifying the business objects (associated with the respective field) and the number of fields in the XML/JSON format. As described above, the integration framework module may help the user visualize and edit the data in the dynamic UI without requiring a knowledge of XML or JSON formats.

In one or more embodiments, the integration framework module214may be used to update data stored in the organization platform202. The update may come from the third-party application212, which is then converted to an XML format file and saved in the SFTP server218, in a similar process as that described above with respect toFIG. 4. It is noted that the process is not exactly the same as that described above with respect toFIG. 4in that the update or change may be treated differently than a create order as there is already an existing order that is being modified, so that update may be written/associated with that existing order. In one or more embodiments, the integration framework module214may determine which fields have changed, and generate a separate XML format file that is marked with a particular naming convention to indicate the update (e.g., field update). The update may be, as two non-exhaustive examples, a user wants to change an existing sales order for 50 items to 100 items; or change the shipment destination from point A to point B. The SFTP server218may then save the updated XML format file in an appropriate location. For example, the SFTP server218may have a particular location for updated files so that when the CPI module216picks the new XML format files from the SFTP server218, the CPI module216knows it's an update operation. The updated XML format file is then transferred to the organization platform202in a similar process to that described above with respect toFIG. 4. Again, the difference may be that the CPI is now aware that the operation is an update operation and may then select the appropriate update operation of a particular API. For example, after a user of the third-party application reads the information displayed inFIG. 12, they may want to update the data. To that end, the user may select an entry displayed inFIG. 12via a radio button1202or any other suitable selector. It is noted that the API may or may not return a message about the update to the third-party application. In one or more embodiments, after completion of the update, a read operation is next called to check and show the updated data to the user.

Turning toFIG. 13, a process1300to test a whitelisted API is provided. In one or more embodiments, the user associated with the third-party application may test any whitelisted API211of the organization platform202via the integration framework module214, and the UI provided therefrom. The test process1300may occur in a test environment or via a testing tool used during runtime. The user may want to test the API to determine whether it may provide the desired information.

Initially at S1310the user selects the API for testing, including simulated data for visibility and the selection is received by the integrated framework module214. The UI1400inFIG. 14Aprovides a list1402of selectable APIs1404for testing. The user may select the API1404via any suitable selector. Then in S1312, the integration framework module214directly calls the selected API1404from the organization platform202. Based on the API selected, the data is read from the organization platform202via a respective service (e.g., OData or SOAP), and displayed on the UI in S1314, as shown inFIG. 14B. The displayed data may be the output for a test of the read operation. The output of the read operation may allow the user to see the fields and data values expected by the API and the specific format of those data values (e.g., 6 places or 4 places). The user may then determine whether more testing is desired. When no additional testing is desired in S1316, the process ends at S1318. When more testing is desired in S1316, the process proceeds to S1320and the user may select one of an “update” button1406or a “create” button1408. The user may edit the data by selecting the “update” button1406or create a new sales order, for example, by clicking on the “create” button1408. In one or more embodiments, when the update button1406is selected in the test environment, the user is able to edit the selected data (which is already read e.g., Sales Order), and call the update operation of this API.

In one or more embodiments, selection of the “create” button1408may generate a UI1500dynamically with a template1502for the respective service, as described above with respect toFIG. 4, and shown inFIG. 15. With the create operation, the user may have an option to pre-fill data, via selection of a pre-fill selector1504, based on prior created sales orders as per authorizations provided to the user. For example, a sales representative may be able to prefill data only from the sales order created by him, and no one else. It is noted that this pre-fill feature may help a user quickly and easily test the API by avoiding the need for the user to generate a separate JSON/XML Payload, as the fields are filled with existing data, which is mapped to respective fields. It is noted that even if a user is able to create a proper API payload, it may still be difficult to know what data combinations (e.g., specific Division 00 mapped to a specific Sales Organization1010in System 1, but may be mapped to another sales organization (e.g., Sales Organization1710) in System 2) are to be used to complete the API. It is also noted that the user may test the create process by supplying their own data via generation of a separate JSON/XML Payload. Once the data is pre-filled or entered, the user may be able to create the data in the organization platform202.

It is noted that in the absence of an organization network202, a user may try and test an API without connecting to the actual organization network202, and thereby may still do a test run or simulation mode. In this instance, the integration network module may use mock data.

FIG. 16is a block diagram of system architecture1600according to some embodiments. Embodiments are not limited to architecture1600or to a three-tier database architecture.

Architecture1600includes database1610, database management system (DBMS)1620, application server1630, applications1635, clients1640(e.g., third party application), an integration framework module214, an organization platform202and an SFTP server218. Applications1635may comprise server-side executable program code (e.g., compiled code, scripts, etc.) executing within application server1630to receive queries from clients1640and provide results to clients1640. A client1640may access the integration framework module214executing within application server1630. Additionally, the client1640may access their respective application server storing other applications.

Application server1630provides any suitable interfaces through which the client1640may communicate with the integration framework module214or applications1635executing on application server1630. For example, application server1630may include a HyperText Transfer Protocol (HTTP) interface supporting a transient request/response protocol over Transmission Control Protocol/Internet Protocol (TCP/IP), a WebSocket interface supporting non-transient full-duplex communications which implement the Web Socket protocol over a single TCP/IP connection, and/or an Open Data Protocol (OData) interface.

One or more applications1635executing on server1630may communicate with DBMS1620using database management interfaces such as, but not limited to, Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) interfaces. These types of applications1635may use Structured Query Language (SQL) to manage and query data stored in database1610.

DBMS1620serves requests to retrieve and/or modify data of database1610, and also performs administrative and management functions. Such functions may include snapshot and backup management, indexing, optimization, garbage collection, and/or any other database functions that are or become known. DBMS1620may also provide application logic, such as database procedures and/or calculations, according to some embodiments. This application logic may comprise scripts, functional libraries and/or compiled program code.

Application server1630may be separated from, or closely integrated with, DBMS1620. A closely-integrated application server1630may enable execution of server applications1635completely on the database platform, without the need for an additional application server. For example, according to some embodiments, application server1630provides a comprehensive set of embedded services which provide end-to-end support for Web-based applications. The services may include a lightweight web server, configurable support for OData, server-side JavaScript execution and access to SQL and SQLScript.

Application server1630may provide application services (e.g., via functional libraries) which applications1635may use to manage and query the data of database1610. The application services can be used to expose the database data model, with its tables, hierarchies, views and database procedures, to clients. In addition to exposing the data model, application server1630may host system services such as a search service.

Database1610may store data used by at least one of: applications1635and the integration framework module214. For example, database1610may store the map222accessed by the integration framework module214during execution thereof.

Database1610may comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Database1610may comprise a relational database, a multi-dimensional database, an eXtendable Markup Language (XML) document, or any other data storage system storing structured and/or unstructured data. The data of database1610may be distributed among several relational databases, dimensional databases, and/or other data sources. Embodiments are not limited to any number or types of data sources.

In some embodiments, the data of database1610may comprise one or more of conventional tabular data, row-based data, column-based data, and object-based data. Moreover, the data may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof. Database1610may support multi-tenancy to separately support multiple unrelated clients by providing multiple logical database systems which are programmatically isolated from one another.

Database1610may implement an “in-memory” database, in which a full database is stored in volatile (e.g., non-disk-based) memory (e.g., Random Access Memory). The full database may be persisted in and/or backed up to fixed disks (not shown). Embodiments are not limited to an in-memory implementation. For example, data may be stored in Random Access Memory (e.g., cache memory for storing recently-used data) and one or more fixed disks (e.g., persistent memory for storing their respective portions of the full database).

Client1640may comprise one or more individuals or devices executing program code of a software application for presenting and/or generating user interfaces to allow interaction with application server1630. Presentation of a user interface as described herein may comprise any degree or type of rendering, depending on the type of user interface code generated by application server1630.

For example, a client1640may execute a Web Browser to request and receive a Web page (e.g., in HTML format) from a website application1635of application server1630via HTTP, HTTPS, and/or Web Socket, and may render and present the Web page according to known protocols. The client1640may also or alternatively present user interfaces by executing a standalone executable file (e.g., an .exe file) or code (e.g., a JAVA applet) within a virtual machine.

FIG. 17is a block diagram of apparatus1700according to some embodiments. Apparatus1700may comprise a general- or special-purpose computing apparatus and may execute program code to perform any of the functions described herein. Apparatus1700may comprise an implementation of one or more elements of system1600. Apparatus1700may include other unshown elements according to some embodiments.

Apparatus1700includes an integration framework processor1710operatively coupled to communication device1720, data storage device/memory1730, one or more input devices1740, and one or more output devices1750. Communication device1720may facilitate communication with external devices, such as application server1730. Input device(s)1740may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)1740may be used, for example, to manipulate graphical user interfaces and to input information into apparatus1700. Output device(s)1750may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer.

Data storage device/memory530may comprise any device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, Random Access Memory (RAM) etc.

The storage device1730stores a program1712and/or integration framework platform logic1714for controlling the processor1710. The processor1710performs instructions of the programs1712,1714, and thereby operates in accordance with any of the embodiments described herein, including but not limited to processes400,800and1300.

The programs1712,1714may be stored in a compressed, uncompiled and/or encrypted format. The programs1712,1714may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor1710to interface with peripheral devices.

All systems and processes discussed herein may be embodied in program code stored on one or more computer-readable non-transitory media. Such non-transitory media may include, for example, a fixed disk, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid-state RAM or ROM storage units. Embodiments are therefore not limited to any specific combination of hardware and software.

The 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 limited only by the claims.