Integration extensions

Systems and methods for integration of applications are provided. A request for data associated with a second application is received from a first application. The data associated with the second application is generated using one or more process extension APIs. The one or more process extension APIs generate the data using one or more native APIs of the second application. The data is transmitted to the first application.

TECHNICAL FIELD

The present invention relates generally to integration extensions, and more particularly to a connector for implementing integration extensions such as, e.g., process extensions and system extensions.

BACKGROUND

Many software providers offer suites or collections of computer programs of related functionality. Often times, software providers need to provide integration capabilities for integrating such computer programs. Conventionally, the integration capabilities of such computer programs have specific nuances that make integration a complex and labor-intensive process.

BRIEF SUMMARY OF THE INVENTION

In accordance with one or more embodiments, systems and methods for integration of applications are provided. A request for data associated with a second application is received from a first application. The data associated with the second application is generated using one or more process extension APIs. The one or more process extension APIs generate the data using one or more native APIs of the second application. The data is transmitted to the first application.

In one embodiment, the data associated with the second application is generated by retrieving initial data from the second application using the one or more native APIs of the second application and applying integration logic to the initial data to generate the data. The integration logic may comprise at least one of method chaining, looping, or data transformations. The one or more process extension APIs perform functions not available on native APIs of the second application to generate the data.

In one embodiment, the receiving, the generating, and the transmitting are performed by a connector and the connector further comprises one or more system extension APIs for generating discovery data relating to the connector. The discovery data may comprise at least one of: 1) metadata of the connector, 2) events available on the connector, 3) objects, resources, or methods available on the connector, 4) metadata of the objects, the resources, or the methods available on the connector, or 5) test results of a connection. In one embodiment, the discovery data describes available resources of the connector as being a native resource or a custom resource. In one embodiment, the discovery data comprises an identification of available fields of a document. In one embodiment, the one or more process extension APIs are created based on the discovery data.

DETAILED DESCRIPTION

Embodiments described herein provide for a central integration platform to facilitate the exchange of data between two or more applications. The central integration platform comprises one or more connectors each associated with one of the applications. Each respective connector comprises standard resources representing the native APIs (application programming interfaces) of the associated application, as well as system extensions and process extensions. The system extensions are APIs for generating discovery data relating to the respective connector. The process extensions are APIs extending capabilities of the native APIs of the associated application by abstracting complex integration logic to provide functions for specific use cases. Advantageously, a connector in accordance with embodiments described herein provides for system extensions for generating discovery data relating to the connector to thereby facilitate the adoption of the connector, as well as process extensions to provide functionality for specific use cases to thereby extend the capabilities of the native APIs of the application.

FIG.1shows a schematic diagram of a system100for facilitating the exchange of data between two or more applications, in accordance with one or more embodiments. As shown inFIG.1, central integration platform102facilitates the exchange of data between two or more of Application A114-A, Application B114-B, and Application C114-C (collectively referred to as applications114). Applications114may be software programs, mobile apps, websites, systems, devices, or any other suitable application.

Central integration platform102comprises normalized connectors104-A and104-B (collectively referred to as normalized connectors104) each associated with a respective application114. Normalized connectors104provide a normalized interface for communicating with their associated application114. In particular, normalized connectors104interface with native APIs106-A and106-B (collectively referred to as native APIs106) representing the native APIs of their associated application114and respectively provide a normalized interface comprising standard resources108-A and108-B (collectively referred to as standard resources108), system extensions110-A and110-B (collectively referred to as system extensions110), and process extensions112-A and112-B (collectively referred to as process extensions112). Native APIs106, standard resources108, system extensions110, and process extensions112may be implemented according to any protocol or standard, such as, e.g., SOAP (simple object access protocol), ODATA (open data protocol), SDK (software development kit), and REST (representational state transfer). In one embodiment, standard resources108, system extensions110, and process extensions112are implemented according to the REST protocol with JSON (JavaScript object notation) payload.

Standard resources108comprises a normalized version of native APIs106. Native APIs106may be normalized according to any suitable, known approach.

System extensions110comprises APIs for generating discovery data relating to their respective normalized connector104. System extensions110provide a consistent set of APIs to enable a user (e.g., a developer or engineer) to rapidly integrate normalized connector104with applications114, regardless of the application or the API protocol or standard associated with the application. The discovery data generated by system extensions110is self-describing data relating to its respective normalized connector104to enable applications114to leverage the full flexibility of normalized connectors104in a dynamic manner. The discovery data allows the application consuming the connector to understand what data objects are available, and the payload/fields available on these objects. Any application consuming the connector can create user experiences to interact with the data of the business application in a dynamic way. The application consuming the connector can dynamically present the available objects and their data fields to the end user without needing to know anything about the business application itself.

In one embodiment, the discovery data generated by system extensions110may comprise: 1) discovery data of metadata of the normalized connector104(e.g., capabilities supported by normalized connector104, authentication type supported by normalized connector104, the native APIs106leveraged by normalized connector104, etc.); 2) discovery data of events available on the normalized connector104(e.g., changes in the objects, resources, or methods of normalized connector104); 3) discovery data of objects, resources, or methods available on the normalized connector104; 4) discovery data of the metadata of objects, resources, methods of the normalized connector104(e.g., input and output models available on normalized connector104, whether an object is custom or standard, self-describing metadata about normalized connector104(e.g., name, version, description, search tags, lifecycle stage, etc.), operations and capabilities that are available on normalized connector104(e.g., supports events, supports bulk, supports search, etc.), categorization of the object, resource, or method, etc.); and 5) discovery data of test results of a connection when the normalized connector104is authenticated. In one embodiment, the discovery data generated by system extensions110may describe all available resources (e.g., functionality) of normalized connector104as being a part of standard resource108(i.e., a native resource of the application114) or a custom resource (i.e., a resource of system extensions110or process extensions112), and may logically categorize the resources (e.g., as being standard or custom). In one embodiment, if a certain resource is called, system extensions110may generate discovery data all the way down to the field level. For example, an invoice resource API of system extensions110may be called for identifying what fields of an invoice are available and searching the identified fields for foreign keys, primary keys, and specific values of specific fields for feeding into models.

Process extensions112comprise APIs extending capabilities of the native APIs106of the associated application by abstracting complex integration logic to provide functions for specific use cases (or business processes). The APIs of process extensions112may be reused for the specific use cases. In one embodiment, the functionality of process extensions112is not available in native APIs106of the application114. In this manner, process extensions112extend the functionality of native APIs106. By abstracting complex integration logic, process extensions112may be utilized by users who may not be experts in the business workings and technical API nuances to implement a specific use case. Process extensions112may be created, modified, and published by, e.g., expert users and made available via normalized connector104to provide a consistent interface for developing integration for an application114.

In one embodiment, process extensions112are created based on the discovery data generated by system extensions110. A user configures the steps that happen in between process extensions112receiving the input and generating the output. The configuration of process extensions112leverages the connector system extensions110to present a user interface to end users with the connector capabilities and API endpoints that are available to work with to define the process. Steps for configuring process extensions112can include, for example, (multiple) API calls to an application, writing custom code, data mapping, decision trees, error management, etc. In one example, process extensions112may comprise an API triggered based on events discovered by systems extensions110. The integration logic implementing process extensions112may comprise complex logic, such as, e.g., method chaining, looping, custom code, integration with other components or systems, data transformations, combining multiple data results into a single response, etc. The end result is the output that process extensions112will return to the connector104consuming application. By exposing the API endpoints of process extensions112, any application114can be made to integrate in an identical manner, and the integration logic can be rapidly exposed for adoption by any application that consume central integration platform102. Advantageously, each application114can avoid implementing duplicate logic in every application and rely on consistent data to solve a business challenge.

One exemplary use case for process extensions112is for submitting a payment to an invoice. This use case is implemented different for different types of systems (e.g., NetSuite ERP (enterprise resource planning) vs. SAP S/4HANA vs. Sage Intacct). Process extensions112provides a normalized API interface that abstracts the nuances for each of the systems and provides a single unified interface to the user to submit payment without having to worry about the differences amongst each.

Another exemplary use case for process extensions112is for retrieving data for completing a purchase order. This use case presents unique challenges across various systems that store purchase order data. For instance, System A may store all data via a single API, however System B may require a user first retrieve the raw purchase order data, after which calls must be made to one or more subsequent APIs to obtain company information, the billing address, line items, discount information, etc. Process extensions112provide for APIs to retrieve purchase orders without needing to manage the complexity or needing to know the nuances of every external system.FIG.2shows an exemplary purchase order template200generated in accordance with one or more embodiments. Purchase order template200is generated by calling process extensions API214, which retrieves information for completing purchase order template200via APIs202-212. API202is for retrieving company name, API204is for retrieving vendor billing address, API206is for retrieving line items, API208is for retrieving purchase order number, API210is for retrieving vendor shipping address, and API212is for retrieving discounts and taxes.

FIG.3shows a diagram300of exemplary APIs, in accordance with one or more embodiments. Diagram300shows APIs for standard resources302, process extensions304, and system extensions306. In one example, standard resources302are standard resources108ofFIG.1, process extensions304are process extensions112ofFIG.1, and system extensions306are system extensions110ofFIG.1. Standard resources301comprise APIs for getting bank accounts and getting financial institutions. Process extensions304comprise APIs for creating a full purchase order, searching for a full purchase order, and retrieving a full purchase order by ID. System extensions306comprise APIs for getting a list of all available objects, getting swagger docs for an object, and getting a list of all fields for an object.

FIG.4shows a method400for retrieving data from an application, in accordance with one or more embodiments. Method400may be performed by any suitable computing device or devices, such as, e.g., computing system500ofFIG.5. Method400will be described with continued reference toFIG.1. In one embodiment, the steps of method400are performed by a connector, such as, e.g., normalized connector104-A or104-B of central integration platform102ofFIG.1.

At step402ofFIG.4, a request for data associated with a second application is received from a first application. The first and second applications may be software programs, mobile apps, websites, systems, devices, or any other suitable application. In one example, the first and second applications are different ones of applications114ofFIG.1. In addition to requesting the data (e.g., for a single object), data sets of multiple objects (e.g., lists) may also be retrieved, data (e.g., create/update) may be pushed to the second application, or deletion of data in the second application may be requested. In one embodiment, the request is received by a connector, such as normalized connector104-A or104-B ofFIG.1. In one embodiment, the first application is the application consuming the connector and the connector APIs and the second application is the business system for which the connector was created and of which the connector consumes the APIs. Accordingly, integration logic from the first application is abstracted to avoid dealing with the complexity when integrating with the second application.

At step404ofFIG.4, the data associated with the second application is generated using one or more process extension APIs. The one or more process extension APIs generate the data using one or more native APIs of the second application. In one embodiment, the data is generated by the connector.

The one or more process extension APIs are APIs created on the connector that extend the capabilities of the native APIs of the second application by generating the data for a specific use case. In one embodiment, the one or more process extension APIs retrieve initial data from the second application using one or more native APIs of the second application and apply complex integration logic to the initial data to generate the data. The complex integration logic may comprise, for example, method chaining, looping, custom code, integration with other components or systems, data transformations, combining multiple data results into a single response, etc. In one embodiment, the one or more process extension APIs perform functions not available on the native APIs of the second application to generate the data. In one example, the one or more process extension APIs are process extensions112ofFIG.1of normalized connector104ofFIG.1and the one or more native APIs may be standard resources108ofFIG.1.

In one embodiment, the connector may also comprise one or more system extension APIs. The one or more system extension APIs are APIs created on the connector for generating discovery data relating to the respective connector. In one example, the one or more system extension APIs are system extensions110ofFIG.1. The discovery data facilitates adoption by the second application. In one embodiment, the one or more process extension APIs are created based on the discovery data.

At step406ofFIG.4, the data is transmitted to the first application. In some embodiments, the data may additionally or alternatively be output by displaying the data on a display device of a computer system, storing the data on a memory or storage of a computer system, or by transmitting the data to a remote computer system

FIG.5is a block diagram illustrating a computing system500. Computing system500may be configured to execute the methods, workflows, and processes described herein, including method400ofFIG.4, or may be configured to implement systems described herein, including central integration platform102ofFIG.1, according to one or more embodiments of the present invention. In some embodiments, computing system500may be one or more of the computing systems depicted and/or described herein. Computing system500includes a bus502or other communication mechanism for communicating information, and processor(s)504coupled to bus502for processing information. Processor(s)504may be any type of general or specific purpose processor, including a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Graphics Processing Unit (GPU), multiple instances thereof, and/or any combination thereof. Processor(s)504may also have multiple processing cores, and at least some of the cores may be configured to perform specific functions. Multi-parallel processing may be used in some embodiments.

Computing system500further includes a memory506for storing information and instructions to be executed by processor(s)504. Memory506can be comprised of any combination of Random Access Memory (RAM), Read Only Memory (ROM), flash memory, cache, static storage such as a magnetic or optical disk, or any other types of non-transitory computer-readable media or combinations thereof. Non-transitory computer-readable media may be any available media that can be accessed by processor(s)504and may include volatile media, non-volatile media, or both. The media may also be removable, non-removable, or both.

Additionally, computing system500includes a communication device508, such as a transceiver, to provide access to a communications network via a wireless and/or wired connection according to any currently existing or future-implemented communications standard and/or protocol.

Processor(s)504are further coupled via bus502to a display510that is suitable for displaying information to a user. Display510may also be configured as a touch display and/or any suitable haptic I/O device.

A keyboard512and a cursor control device514, such as a computer mouse, a touchpad, etc., are further coupled to bus502to enable a user to interface with computing system. However, in certain embodiments, a physical keyboard and mouse may not be present, and the user may interact with the device solely through display510and/or a touchpad (not shown). Any type and combination of input devices may be used as a matter of design choice. In certain embodiments, no physical input device and/or display is present. For instance, the user may interact with computing system500remotely via another computing system in communication therewith, or computing system500may operate autonomously.

Memory506stores software modules that provide functionality when executed by processor(s)504. The modules include an operating system516for computing system500and one or more additional functional modules518configured to perform all or part of the processes described herein or derivatives thereof.

One skilled in the art will appreciate that a “system” could be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a cell phone, a tablet computing device, a quantum computing system, or any other suitable computing device, or combination of devices without deviating from the scope of the invention. Presenting the above-described functions as being performed by a “system” is not intended to limit the scope of the present invention in any way, but is intended to provide one example of the many embodiments of the present invention. Indeed, methods, systems, and apparatuses disclosed herein may be implemented in localized and distributed forms consistent with computing technology, including cloud computing systems.

It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like. A module may also be at least partially implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, include one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may include disparate instructions stored in different locations that, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, modules may be stored on a computer-readable medium, which may be, for instance, a hard disk drive, flash device, RAM, tape, and/or any other such non-transitory computer-readable medium used to store data without deviating from the scope of the invention. Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.