Patent Application
20130262378
Enterprises rely on ever-increasing amounts and types of data. As the amounts and types of data have increased, so too have the numbers and types of services relied on to process the data. As the number and types of data and services have increased, the complexity of managing the data and services has also grown. Therefore, enterprises have increasingly turned to enterprise business applications (EBAs) to integrate data and services across an enterprise. An Enterprise Resource Planning (ERP) application is one example of an EBA.
Much information about the data and services to be integrated into an EBA can be known before the EBA is deployed and thus can be designed into the EBA. However, other data, information about data, and services may not be known before an EBA is deployed. These types of data and services cannot be designed into the EBA and are accessed in some other way. EBAs may therefore rely on reference data or external services to support, complement, or extend built-in functionality.
Conventional EBAs may have been configured in a “one-off” fashion by adding custom code for addressing one issue in one way. These conventional EBAs may have been designed with additional software that relied on a specific piece of external reference data that was available at a specific location via a specific interface or protocol. Similarly, an EBA may have been custom-coded with additional software to rely on a specific external service available at a specific location via a specific protocol to calculate a specific value.
Before additional software can be used, the additional software has to be found, designed, coded, or built in a timely or cost-effective manner. Then, after the additional software is found or built, the additional software still needs to be verified, validated, deployed, and maintained. Unfortunately, this type of custom integration with additional software directly couples systems, makes EBAs difficult to configure, requires significant efforts from systems integration personnel or programmers, requires ongoing maintenance by systems integration personnel, and makes EBAs vulnerable to changes in the custom crafted additional software.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Example apparatus and methods provide an aggregation point that facilitates integrating external items (e.g., reference data, services) and an EBA. The aggregation point decouples data models native to the EBA and native to providers of external items. The aggregation point may also decouple protocols native to the EBA or providers of external items. The aggregation point facilitates performing the binding of EBA items and external items outside proprietary systems.
Example apparatus and methods facilitate having an EBA describe an EBA item for which support from external items is desired. The EBA item may be described to the aggregation point using metadata. Example apparatus and methods also facilitate having external providers describe reference data or services to the aggregation point using metadata. Example apparatus and methods also facilitate discovering external data or services that are available for use by an EBA.
The accompanying drawings illustrate various example apparatus, methods, and other embodiments described herein. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. In some examples one element may be designed as multiple elements or multiple elements may be designed as one element. In some examples, an element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.
Example apparatus and methods provide an aggregation point and aggregation point services that facilitate automatically integrating external items (e.g., reference data, services) and an enterprise business application (EBA).
In one embodiment, the first interface 120 may accept metadata from the external provider 110. The metadata may describe the external item 100, which may be associated with a first data model that is native to the external provider 110. The second interface 140 may accept metadata from the EBA 150. The metadata may describe an EBA item found in a second data model that is native to the EBA 150. In one embodiment, the metadata describing the external item 100 or the EBA item 150 may be XML-based. While extensible markup language (XML) is described, other metadata-based approaches may be employed.
The aggregation point 130 is configured to bridge gaps between data models or protocols. To facilitate bridging the gaps, the aggregation point 130 may receive a metadata mapping that describes how to relate items. The aggregation point 130 may also receive a metadata-based transform that describes how to transform a portion of the external item 100 to an EBA item or vice versa. The transformation can be performed at the aggregation point 130 using the metadata mapping or the metadata-based transform. The transformation may be performed external to the EBA 150. In different examples the metadata-based mapping or transform could be provided by the EBA 150, by the external provider 110 of the external item 100, or by a third party. In one embodiment, the transformation may be performed as a cloud computing service. The decoupling achieved by the aggregation point 130 facilitates having the EBA 150 appear to have a direct connection 160 to an external item 100.
Therefore, more generally, an aggregation point may be configured with a flexible metadata-based description framework that facilitates understanding data from the point of view of an EBA data model and understanding external items from the point of view of an external provider's data model. The metadata-based description framework may include a mapping that describes how to relate external items to EBA items and may include a transform that describes how to transform data from one data model to another data model. The metadata-based description framework may also include information concerning resolving different protocols for exchanging data. When a suitable external item, a suitable mapping, and a suitable transform have been discovered and understood, example apparatus and methods may use the aggregation point to bind the external item to an EBA item.
“Binding” refers to activating an integration solution at the aggregation point. After the external item and the EBA item are bound, data may then be exchanged between the EBA and the external item. Exchanging the data may involve mapping between data models and resolving protocol differences. Rather than having just a one-time exchange at binding, the aggregation point may be configured with a metadata-based synchronization framework, agent, process or other logic configured to co-ordinate and control ongoing data exchanges. The metadata-based synchronization framework may also facilitate automatically responding to changes in either the EBA or the external data and services. For example, the description of the EBA item may change in its data model or the description of an external item may change in its data model. Instead of these types of changes requiring customized code—as may be required in conventional systems—a change to a portion of a data model may be described to the aggregation point using metadata.
Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a memory. These algorithmic descriptions and representations are used by those skilled in the art to convey the substance of their work to others. An algorithm is considered to be a sequence of operations that produce a result. The operations may include creating and manipulating physical quantities that may take the form of electronic values. Creating or manipulating a physical quantity in the form of an electronic value produces a concrete, tangible, useful, real-world result.
It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, and so on. It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it is appreciated that throughout the description, terms including processing, computing, and determining, refer to actions and processes of a computer system, logic, processor, or similar electronic device that manipulates and transforms data represented as physical quantities (e.g., electronic values).
Example methods may be better appreciated with reference to flow diagrams. For simplicity, the illustrated methodologies are shown and described as a series of blocks. However, the methodologies may not be limited by the order of the blocks because, in some embodiments, the blocks may occur in different orders than shown and described. Moreover, fewer than all the illustrated blocks may be required to implement an example methodology. Blocks may be combined or separated into multiple components. Furthermore, additional or alternative methodologies can employ additional, not illustrated blocks.
Method 300 also includes, at 320, collecting a metadata-based description of an external item into the aggregation point. The external item may belong to a second data model used by a provider of the external item. The second data model may be, for example, a schema that describes financial data. The external item may be, for example, a data item or a service. The metadata-based description of an external data item may describe items similar to those associated with the EBA item. The metadata-based description of an external service may describe, for example, inputs accepted by the external service, outputs produced by the external service, terms of use for the external service, costs associated with the external service, connection points for the external service, endpoints for the external service, error handling for the external service, data encoding instructions for the external service, data decoding instructions for the external service, and other attributes.
Method 300 also includes, at 330, collecting into the aggregation point a mapping that describes a mapping between the EBA data item and the external item. The mapping may describe which field in a first data model corresponds to a field in a second data model. Method 300 also includes, at 340, collecting into the aggregation point a metadata-based transformation function. The transformation function may describe how to compute a value for a field in a first data model using a field(s) in a second data model. Examples of a mapping and a transformation are described later in connection with
Method 300 also includes, at 350, binding the EBA item to the external item. Binding the EBA item to the external item causes a data exchange between the items. The binding and exchange are based, at least in part, on the mapping and the transformation function. In one embodiment, the binding performed at 350 occurs outside an EBA. For example, the binding may occur in an EBA client, in a synchronization agent, in a service, in a cloud computing service, or elsewhere. Having an initial transfer of data at binding is useful. Having an ongoing transfer of data may be more useful.
Therefore
Method 400 includes, at 460, collecting synchronization metadata and, at 470, synchronizing the EBA item and the external item. The synchronization performed at 470 is controlled, at least in part, by the synchronization metadata collected at 460. The synchronization metadata may describe items including, but not limited to, an external item and an EBA item to synchronize, a time to perform synchronization, a direction to exchange data during synchronization, an approach for resolving synchronization conflicts, and a sequence for exchanging data.
An EBA may process different types of data and services for an enterprise. The data may include, for example, tax rates, lists of businesses, diagnostic codes, lists of states, lists of countries, universal product codes (UPC), and other types of data. Different industries may have different data sets and different data models. While several examples of data have been provided, different types of data that can be described by metadata may be employed. Services may include, for example, tax rate calculation services, geo-coding services, business information acquisition services, and other services. While several examples of services have been provided, different types of services that can be described by metadata may be employed. EBA services may create data that travels from an EBA, to an EBA, or in both directions. For example, an EBA service may provide a business name to a business information service and the business information service may return additional information (e.g., credit rating, number of employees) for the business.
In one embodiment, the interface between the external providers and the aggregation point may be configured to facilitate registering an external item. Collecting the external item metadata at 420 may include registering the external item. Registering an external data item may include defining how to ingest the data item, how to connect to the data item, how to expose the data item in a format usable to an EBA, cardinality for the data item, a direction in which data will be exchanged, and other actions. Describing how to connect to the data item may include, for example, providing a database connection string, providing credentials, providing security information, and other actions. Ingesting or consuming data may include reading the metadata, executing operations on data described by the metadata-based on the metadata, and other actions.
Registering an external data item may also include defining a mapping between the external data item and an EBA item. The mapping may be defined in terms of an EBA schema. To understand a mapping, consider that an external item has its format and structure and an EBA item has its format and structure. If the two structures are both known to the provider of the external item, then the provider can identify how the external item relates to the EBA item. The relation may be direct, where no transformation is required, or indirect, where a transformation function may be required. Registering an external data item may therefore include defining the transformation for resolving differences between an external item and an ERP item.
Registering an external service may include defining the service to be exposed by describing credentials to access the service, protocols associated with the external service, security employed by the external service, and other items. Defining the external service or data may also include describing terms of an offer for using the external item. The terms may include, but are not limited to, how the external item is to be displayed, the price for the external item, and the terms of service associated with the external item.
Over time, both data items and services may change. The changes may occur in either the EBA data model or the external data model. Since the aggregation point decouples the two data models and the systems that use the two data models, these types of changes can be accounted for in the aggregation point rather than in the systems themselves. In one embodiment, method 400 may therefore include, at 480, selectively updating the binding between the external item and the ERP item. Updating the binding at 480 may include collecting additional or up-to-date metadata concerning an external item, an EBA item, a mapping between items, or a transformation associated with the mapping.
While
The second representation includes a parent field CURR1510 that has a one-to-many relationship with sub-fields CURR2512, RATE 514, and DATE 516. The two date fields may correspond directly and thus a direct mapping may be made between the two fields. The first representation may store amounts while the second representation may only store a rate. However, the second representation may provide information from which CURR2Amt 506 can be computed. Thus, it may be able to describe a transformation between the fields. The two representations may be used as described below.
Consider an EBA that may need to have available an exchange rate to support a financial service that computes a piece of financial data (e.g., current funds available for Canadian purchases). A particular exchange rate (e.g., US dollars to Canadian dollars) is data that may not be known when an EBA is deployed. The fact that the exchange rate will need to be calculated may be known, an equation for computing the current funds available for foreign purchase may be known, and even the EBA data model representation of the currency may be known. But the value of a variable (e.g., exchange rate) needed to resolve the equation may not be known at deployment time. Further complicating matters, exchange rates may be dynamic and change daily, hourly, or even more frequently. Example apparatus and methods may therefore provide an aggregation point that accepts a metadata-based representation of a currency item from the EBA data model point of view, that accepts a metadata-based representation of a currency item from an external provider data model point of view, and that accepts information for integrating the items.
Consider that an EBA may also be configured to perform a certain function (e.g., calculate sales tax) but also not have available at deployment time information about all the taxing authorities with which it will interact or all the rules for all the taxing authorities with which it will interact. For example, one item (e.g., clothing) may be taxable in one taxing authority but may not be taxable in another taxing authority. Additionally, tax rules and rates may also be dynamic. Therefore, the aggregation point may also accept a metadata-based representation of the tax rate calculation service desired by the EBA and may accept a metadata-based representation of the tax rate calculation service. The EBA will describe the service from the point of view of its data model. The external provider will describe its service from the point of view of its data model. If an acceptable transformation can be performed, metadata describing the mapping needed for the transformation can be provided to the aggregation point. In different examples the mapping may be provided by users of the EBA, by an external provider, or by a third party. In one example, data items, either EBA items or external reference items may be described using a hierarchical tree query.
The set 630 of logics may include a first logic 632 that is configured to receive information into an aggregation point. The information will concern an external item that is to be made available to an ERP system. The first logic 632 may interact with a publisher portal interface to accept, store, validate, and expose the information concerning the external item. The information concerning the external item may include, for example, information concerning how to ingest an external data item, how to connect to the external data item, and how to expose the external data item. The information concerning the external item may also include a mapping between the external data item and an ERP data item, a transformation based on the mapping between the external data item and the ERP data item, terms of use for the external data item, and a price for using the external data item. When the external item is a service, the information concerning the external item may include an endpoint associated with an external service, an operation performed by the external service, a credential for accessing the external service, a data type to input to the external service, a data type to receive from the external service, a term of use for the external service, a protocol associated with the external service, security employed by the external service, and a price for using the external service.
The set 630 of logics may also include a second logic 634 that is also configured to receive information into the aggregation point. This information concerns an ERP item for which an external item is sought. The second logic 634 may be configured to interact with the ERP system to accept, store, validate, and expose the information concerning the ERP item.
The set 630 of logics may also include an ERP client logic 636 that is configured to provide an ERP client for binding the external item to the ERP item. The binding may be based, at least in part, on a metadata-based transformation and a metadata-based mapping between the external item and the ERP item. In one example, the ERP client binds the external item and the ERP item, which includes exchanging data from one item to another item as controlled by the metadata-based mapping and the metadata-based transformation.
The set 630 of logics may also include a synchronization logic 638 that is configured to provide a synchronization agent for synchronizing the ERP item and the external item. The synchronization agent may support post-binding exchanges between the external item and the ERP item by controlling one or more of, identifications of external items and ERP items to be synchronized, discrete times for synchronizing external items and ERP items, periods for synchronizing external items and ERP items, events that trigger synchronizing external items and ERP items, direction of travel for data exchanged during a synchronization, a synchronization conflict resolution protocol, and an order in which data is exchanged during synchronization.
Method 700 also includes, at 730, accessing an ERP interface that is configured to accept, validate, publish, and store metadata concerning an ERP item. Method 700 also includes, at 740, controlling the computer to accept metadata concerning the ERP item through the ERP interface and to store it in a data store. In one embodiment, the ERP interface facilitates looking for, examining, requesting, managing, and purchasing external items that have been made available to the ERP system in the aggregation point through the publisher portal. In different embodiments, the ERP interface can be accessed through a web browser, through an ERP system, via a set of application programming interfaces (API), and in other ways. A web browser embodiment of the first interface may be linked to the ERP system. A native embodiment of the first interface may be embedded in the ERP system. Embedding the ERP interface or linking to the ERP interface may include interacting with the ERP interface through a set of APIs or libraries. In one embodiment, the ERP interface may only display or otherwise make available external items that have been validated by an ERP client.
With the two sets of metadata available, method 700 may proceed, at 750, to control the computer to determine whether the external item is suitable for binding to the ERP item. The determination may be based, at least in part, on discovering a mapping or transformation between the external item and the ERP item. If a suitable mapping and transformation are found, then method 700 may proceed, at 760, to control the computer to establish a binding between the external item and the ERP item.
Method 700 may also include, at 770, controlling the computer to maintain synchronization between the external item and the ERP item. Binding to and using an external item may not be free. Therefore method 700 may include, at 780, controlling the computer to account for use of the external item. Accounting for the use may include, for example, tracking a number of times an item is accessed, tracking a number of times an item is updated, and other actions.
In one example, a method may be implemented as computer executable instructions. Thus, in one example, a computer-readable storage medium may store computer executable instructions that if executed by a machine (e.g., computer) cause the machine to perform methods described herein including method 700. While executable instructions associated with the above method are described as being stored on a computer-readable storage medium, it is to be appreciated that executable instructions associated with other example methods described herein may also be stored on a computer-readable storage medium.
“Computer-readable storage medium”, as used herein, refers to a medium that stores instructions or data. “Computer-readable storage medium” does not refer to propagated signals. A computer-readable storage medium may take forms, including, but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, tapes, and other media. Volatile media may include, for example, semiconductor memories, dynamic memory, and other media. Common forms of a computer-readable storage medium may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an ASIC, a CD, other optical medium, a RAM, a ROM, a memory chip or card, a memory stick, and other media from which a computer, a processor or other electronic device can read.
Generally describing an example configuration of the mobile device 900, the processor 902 may be a variety of various processors including dual microprocessor and other multi-processor architectures. The memory 904 may include volatile memory or non-volatile memory. Non-volatile memory may include, for example, read only memory (ROM), programmable ROM (PROM), and other memory. Volatile memory may include, for example, random access memory (RAM), dynamic RAM (DRAM), and other memory. The memory 904 can store an operating system that controls and allocates resources of the mobile device 900.
The interface 906 may be a single internal bus interconnect architecture or other bus or mesh architectures. While a single bus is illustrated, it is to be appreciated that the mobile device 900 may communicate with various devices, logics, and peripherals using other busses (e.g., PCIE, 1394, USB, Ethernet). The interface 906 can be types including, for example, a memory bus, a memory controller, a peripheral bus, an external bus, a crossbar switch, or a local bus.
The mobile device 900 can operate in a network environment and thus may be connected to a network through network devices via the external interfaces 910. The mobile device 900 may be logically connected to remote computers through the network and the network devices. Through the network, the mobile device 900 may also be connected to services provided in the cloud. Networks with which the mobile device 900 may interact include, but are not limited to, a LAN, a WAN, a telephony network, a telephony system, a cellular system, a satellite system, and other networks.
Mobile device 900 may include a special purpose logic 908 that is configured to provide a functionality for the mobile device 900. For example, logic 908 may provide a client for interacting with an aggregation point.
The following includes definitions of selected terms employed herein. The definitions include various examples or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Both singular and plural forms of terms may be within the definitions.
References to “one embodiment”, “an embodiment”, “one example”, and “an example” indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, though it may.
“Data store”, as used herein, refers to a physical or logical entity that can store data. A data store may be, for example, a database, a table, a file, a list, a queue, a heap, a memory, a register, and other physical repository. In different examples, a data store may reside in one logical or physical entity or may be distributed between two or more logical or physical entities.
“Logic”, as used herein, includes but is not limited to hardware, firmware, software in execution on a machine, or combinations of each to perform a function(s) or an action(s), or to cause a function or action from another logic, method, or system. Logic may include a software controlled microprocessor, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions, and other physical devices. Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim.
To the extent that the term “or” is employed in the detailed description or claims (e.g., A or B) it is intended to mean “A or B or both”. When the Applicant intends to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).
To the extent that the phrase “one or more of, A, B, and C” is employed herein, (e.g., a data store configured to store one or more of, A, B, and C) it is intended to convey the set of possibilities A, B, C, AB, AC, BC, or ABC (e.g., the data store may store only A, only B, only C, A&B, A&C, B&C, or A&B&C). It is not intended to require one of A, one of B, and one of C. When the applicants intend to indicate “at least one of A, at least one of B, and at least one of C”, then the phrasing “at least one of A, at least one of B, and at least one of C” will be employed.
Although the subject matter has been described in language specific to structural features or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
