End-to-end business integration testing tool

A tool is provided for testing integration logic in a hub-and-spoke integration scheme. The testing tool exercises all spokes of the integration project for all objects in the model. A test document is sent to each adapter, which converts the generic objects to application specific objects and then converts the application specific objects back to generic objects. The testing tool then documents the return document of each spoke. The result is a catalog of total mappings, partial mappings, and empty mappings. These results may be analyzed to identify disagreements, lost data, and unused fields. The model may then be corrected by updating the mappings.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to data processing systems and, in particular, to application integration. Still more particularly, the present invention provides a method, apparatus, and program for testing application integration in a data processing system.

2. Description of Related Art

Application integration systems allow a company's applications to operate together. A main task of application integration is translating data and commands from the format of one application into the format of another application. Application integration is essentially data and command conversion on an on-going basis between two or more incompatible systems. Implementing application integration has traditionally been done by tedious programming. However, the trend today is to use message brokers, applications servers, and other specialized integration products that provide a common connecting point.

Most application integration systems may be classified as either point-to-point or hub-and-spoke systems. A traditional point-to-point integration scheme comprises a plurality of applications and a piece of integration code, also known as “middleware,” for every two applications that must operate together. Prior artFIG. 1illustrates an example point-to-point integration model. Application110and application120operate with one another. Integration logic115is provided to translate data and commands from the format of application110into the format of application120and vice versa. For small systems with a small number of applications, point-to-point integration may be used. However, as the number of applications increases, the number of pieces of integration code may grow exponentially. Thus, a point-to-point integration scheme may become unwieldy and is not easily extendible.

The hub-and-spoke integration scheme includes a hub of integration logic and several spokes. Typically, an application resides in each spoke and performs a function within the integration model. For example, a billing application may reside in one spoke and a customer database application may reside in another spoke. Because each application may be written independently without anticipating that the application will be integrated with other specific applications, the data models and interfaces may not agree. In other words, an application may expect data to be received in a first format while other applications in the system may output information in a second format. Adapter logic is provided between each application and the hub to convert or translate data so that each application receives data in an expected format.

With reference to prior artFIGS. 2A-2C, an example hub-and-spoke integration model is depicted. As shown inFIG. 2A, application210is connected to hub202by adapter215. Similarly, application220is connected to hub202by adapter225; application230is connected to hub202by adapter235; and, application240is connected to hub202by adapter245. The number of applications may vary depending upon the implementation.

Conventionally, the hub202consists of a generic business object model, such as generic business objects204, a transformation engine that maps application specific objects (not shown) to generic business objects204and vice versa, and a collaboration engine (not shown) that executes any process logic that is part of synchronizing the hub-and-spoke integration scheme. The generic business object model describes data that is used by all applications. This is in contrast to an application specific business object model, which is specific to one given application. The transformation engine is described in more detail below with reference toFIG. 2B.

One skilled in the art will readily recognize that mappings206document how application specific objects map to generic business objects204and vice versa. When data is sent from a first application to a second application, a data object must first be converted (mapped) from the format of the first application to the generic business object model. Then, the data object must be mapped from the generic business object format to the application specific business object format of the second application. Mappings206are conventionally created by a developer with a priori knowledge of the application interfaces. Mappings206may be created using an editor, such as an extensible Markup Language (XML) editor or text editor; however, mappings206may be created using other means, such as automated tools and the like.

With reference now toFIG. 2B, each adapter may also include a conventional transformation engine, such as transformation engine262of adapter260. Depending upon the implementation, transformation may take place in transformation engine252of hub250, transformation engine262of adapter260, or in both the hub and the adapter. For example, for application265, some transformation may take place in hub250using transformation engine252and mappings256and some transformation may take place in adapter260using transformation engine262and mappings266. In other examples, depending upon the application or the integration design, transformation may take place only in the adapter or only in the hub and this may vary from application to application within a single hub-and-spoke implementation.

Conventional mappings256,266may consist of Java classes, stylesheets, code, or other formats for storing data. Whenever a new application is added in the hub-and-spoke integration scheme, one must only add a spoke to the scheme. Mappings256may include mappings for all applications for which transformations take place in the hub, while mappings266, for example, include mappings only for application265.

Prior artFIG. 2Cillustrates the operation of a conventional hub-and-spoke business integration scheme. Application1270attempts to send data, application specific business object1(ASBO)292, to application2280. ASBO1292is converted to generic business object (GBO)294through any combination of a transformation engine (not shown) in adapter1275and a transformation engine (not shown) in hub290. Then, GBO294is converted to an application specific business object, ASBO2296, for application2280through any combination of a transformation engine (not shown) in adapter2285and a transformation engine (not shown) in hub290. Thus, application1270sends data in a format expected by application1270and application2280receives data in a format expected by application2280. The conventional hub-and-spoke integration model works well if the mappings are correct. However, objects do not map properly from application to application when the mappings are not correct.

As one can see, application integration using the hub-and-spoke model poses significant data integration challenges as compared to the point-to-point model. These challenges spring from the very nature of the hub model and the necessity for a single integrated object model among all applications throughout the integration project. Knowing how each object maps to each application, which objects are used by the applications, and how a new application affects the existing model are difficult problems to be solved in the hub-and-spoke integration scheme. More particularly, when objects do not map properly from application to application, it is difficult to determine where the problem lies. Mappings may be incorrect in the hub or in any adapter in the integration model.

The only existing solution to solve the above problems consists of manual inspection of the object model after manual test runs of each spoke in the model. This solution is labor-intensive and prone to human error.

SUMMARY OF THE INVENTION

The present invention recognizes the disadvantages of the prior art and provides a tool for testing integration logic in a hub-and-spoke integration scheme. The testing tool of the present invention exercises spokes of the integration project for objects in the model. A hub sends a test document to an adapter in a spoke. One or both of a transformation engine in the hub and a transformation engine in the adapter converts the document from a generic object model to an application specific object model and then converts the document from the application specific object model back to the generic object model. The testing tool repeats this process by sending the test document through the adapter of each spoke. The testing tool then documents the return document of each spoke. The result is a catalog of total mappings, partial mappings, and empty mappings. These results may be analyzed to identify disagreements, lost data, and unused fields. The model may then be corrected by updating the mappings.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures,FIG. 3depicts a pictorial representation of an integration model testing tool in accordance with a preferred embodiment of the present invention. Adapter315is provided to connect an application (not shown) to hub302. Similarly, adapters325,335, and345are provided to connect applications to hub302. The number of adapters may vary depending upon the implementation.

Typically, conventional hub302includes generic business objects304, transformation engine308that maps all of the application specific objects to generic form and vice versa, and a conventional collaboration engine (not shown) that executes any process logic that is part of synchronizing the hub-and-spoke business integration scheme. A generic business object (GBO) provides fields that describe the data used by all applications. This is in contrast to an application specific business object (ASBO), which is specific to one given application. Mappings306document how ASBOs map to GBOs and vice versa. Mappings306may consist of Java classes, stylesheets, code, or other formats for storing data (described in further detail herein).

Each adapter in the business integration model300may also include a conventional transformation engine, such as transformation engine328in adapter325. Depending upon the implementation, transformation for an application (not shown) corresponding to adapter325may take place in transformation engine308of hub302, transformation engine328of adapter325, or in both the hub and the adapter. For example, for the application corresponding to adapter325, some transformation may take place in hub302using transformation engine308and mappings306and some transformation may take place in adapter325using transformation engine328and mappings326. In other examples, depending upon the application or the integration design, transformation may take place only in the adapter or only in the hub and this may vary from application to application within a single hub-and-spoke implementation.

Conventional mappings306,326may consist of Java classes, stylesheets, code, or other formats for storing data. Mappings306,326are conventionally created by a developer with a priori knowledge of the application interfaces. Mappings306,326may be created using an editor, such as an extensible Markup Language (XML) editor or text editor; however, mappings306,326may be created using other means, such as automated tools and the like. Whenever a new application is added in the hub-and-spoke integration scheme, one must only add a spoke to the scheme. Mappings306may include mappings for all applications for which transformations take place in the hub, while mappings326, for example, include mappings only for application325.

FIGS. 4A-4Cillustrate example business objects in accordance with a preferred embodiment of the present invention. More particularly,FIG. 4Aillustrates an example GBO400.FIG. 4Billustrates a customer relation management (CRM) object420, which is an example of an ASBO for a CRM application. In this example, only a subset of the fields in the GBO400are used in ASBO420. The CRM ASBO420also uses address lines422to store zip code, city, and state information. The CRM ASBO also includes additional fields424that are not included in the GBO, such as “Last Call Time” and “Last Call Rep.” Transformation engines in a hub or in an adapter for a CRM application would map the fields of GBO400to the fields of ASBO420and vice versa using mappings, such as mappings306and/or mappings326inFIG. 3.

FIG. 4Cillustrates a billing application object430, which is another example of an ASBO. The billing application business object430includes very few fields compared to GBO400. In fact, the first name, middle initial, and last name are all stored in a single “Name” field432. Also, all address data is stored in a single “Address” field434. Billing ASBO430also includes an additional field436that is not included in GBO400.

FIG. 4Dillustrates an example mapping in accordance with an exemplary embodiment of the present invention. Mappings450describe how fields from a GBO are to be mapped to fields of an ASBO for given application. For example, the fields “First Name,” “Middle Initial,” and “Last Name” in the GBO model are mapped to a single “Name” Field in the ASBO model. Similarly, fields “Address Line 1,” “Address Line 2,” “Address Line 3” in the GBO model are mapped to a single “Address” filed in the ASBO model. As another example, an “Optional Field 1” field in the GBO model is mapped to a “Last Call Date” field in the ASBO model. In the depicted example, mappings450are shown as a table; however, mappings450may alternatively consist of Java classes, stylesheets, code, or other formats for storing data (described in further detail herein).

Returning toFIG. 3, in accordance with a preferred embodiment of the present invention, hub302sends test document352(described herein) to adapters315,325,335,345for a round-trip back to hub302. In the present invention, transformation engine308converts test document352to ABSO354using mappings306and converts ABSO354back to a generic object, as return document356, using mappings306. In this example, as shown inFIG. 3, adapter315may not have a transformation engine. Thus, adapter315simply conveys data to or from the application (not shown).

However, when test document352is sent to the spoke of adapter325, test document352may be converted to ABSO358by transformation308or transformation328or both. The ABSO is then converted back to a GBO using one or both of transformation engine308and transformation engine328to form return document360. The adapters315,325,335,345may be modified to enable a round-trip of documents from the hub302without forwarding documents to the applications.

Test document352may be a GBO, such as GBO400inFIG. 4A, that includes every field for the object. Next, the testing tool populates every field in the test document352. For example, test document352may look like the example shown inFIG. 4Awith every field populated with a value. Each of the return documents, such as return document356and return document360, should be identical to test document352if the mappings are correct. If a particular return document is different from test document352, then this may indicate a problem with mappings. For example, if return document356is not identical to test document352, then mappings306may be incorrect. If return document360is not identical to test document352, then mappings306, mappings326, or both may be incorrect.

The testing tool documents the return document of each spoke into documentation370. The result is a catalog of mapped fields for every return document for every spoke in the model. The mapped fields may include totally mapped fields, partially mapped fields, and empty mappings. These results in documentation370may be analyzed to identify disagreements, lost data, and unused fields. The hub-and-spoke business integration model may then be corrected by updating mappings, such as mappings306and mappings326.

Each data field from the test document352may be recorded in documentation370as a total mapping, a partial mapping, or an empty mapping. A totally mapped field is one in which every spoke returns the same data in the same field in which it was sent.FIG. 5Aillustrates an example of a test document in accordance with an exemplary embodiment of the present invention, whileFIG. 5Billustrates an example of documentation in accordance with an exemplary embodiment of the present invention. InFIG. 5B, if every return document has a value of “Newville” for “City” field524, then “City” field524is totally mapped. This is the expected outcome and indicates that the field is properly mapped for all applications.

Partial mappings result when different spokes “disagree” on the return value for a particular field. For example, if test document500inFIG. 5Ais sent to spoke1and the transformation engine(s) in that spoke maps the first name, middle initial, and last name to a single field, “First Name” field512, then this will result in a disagreement, because the other spokes will result in these fields being mapped to three separate fields512,514,516, as shown inFIG. 5B.

As another example, the transformation engine(s) in spoke2may return a document with “Address Line 3” field518populated with a value of “87722.” This indicates a disagreement in the mapping, which would result in a partial mapping because not all spokes would return the same value for that field. Spoke2may also return the document with an empty “ZipCode” field522. This is a disagreement that must be corrected in the mappings or adapter code.

Empty mappings are mappings for which all spokes return an empty data field in the return document. If this occurs then there are unused data fields in the model. As an example, the “Address Line 4” field520in the example inFIG. 5Bhas no data being returned from any spoke. This is referred to as an empty mapping, because all spokes return no value for the field. If a field is unused, it may be removed or used for other data. For example, a simple “YES/No” field may be converted to a gender field (MALE/FEMALE).

With reference again toFIG. 3, as an example, adapter315may be an adapter for a billing server. Adapter325may be an adapter for a customer database. Adapter335may be an adapter for a metering application server. And adapter345may be an adapter for an employee database. To exercise the spokes, the testing tool creates a fully-defined sample GBO, in this case a customer object with every attribute specified by a unique variable. The testing tool sends this sample through every spoke that supports it. In this example, adapter345for the employee database may not support a customer object.

For each round trip of the sample engine through a given spoke, one or both of transformation308in hub302and a transformation engine in an adapter, such as transformation engine328, receive the test document, convert the test document to an application specific representation of the test document, convert the application specific representation back to the generic representation, and return the generic representation of the test document to the hub302. The result is an object that has round-tripped the spoke. By comparing the resulting variables in this round-tripped document for all adapters, the testing tool may create a mapping visualization. An operator may then access the documentation of the round-tripped documents and analyze the visualization to find disagreements, lost data, and unused data fields.

FIG. 6depicts a pictorial representation of a network of data processing systems in which the present invention may be implemented. Network data processing system600is a network of computers in which the present invention may be implemented. Network data processing system600contains a network602, which is the medium used to provide communications links between various devices and computers connected together within network data processing system600. Network602may include connections, such as wire, wireless communication links, or fiber optic cables.

In the depicted example, hub server604is connected to network602along with storage unit606. Integration logic, such as generic business objects605and mappings306inFIG. 3, may be stored in storage unit606. In addition, application servers608,610, and612are connected to network602. These application servers608,610, and612may also have adapters for connection to hub604and may also store integration logic, such as mappings326inFIG. 3. In the depicted example, hub server604provides integration logic for application servers608-612. Network data processing system600may include additional servers and other devices not shown.

Workstation614is connected to network602. An operator may use workstation614to access documentation stored in storage606. For example, after the spokes have been exercised, an operator may access the documentation to analyze the object model and mappings. The operator may also use workstation614to update mappings in hub server604or any one or more of application servers608,610,612that may have integration logic therein to correct disagreements and the like.

Referring toFIG. 7, a block diagram of a data processing system that may be implemented as a server, such as hub server604inFIG. 6, is depicted in accordance with a preferred embodiment of the present invention. Data processing system700may be a symmetric multiprocessor (SMP) system including a plurality of processors702and704connected to system bus706. Alternatively, a single processor system may be employed. Also connected to system bus706is memory controller/ cache708, which provides an interface to local memory709. I/O bus bridge710is connected to system bus706and provides an interface to I/O bus712. Memory controller/cache708and I/O bus bridge710may be integrated as depicted.

Peripheral component interconnect (PCI) bus bridge714connected to I/O bus712provides an interface to PCI local bus716. A number of modems may be connected to PCI local bus716. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to application servers608-614inFIG. 6may be provided through network adapter720, for example, connected to PCI local bus716through add-in connectors.

Additional PCI bus bridges722and724provide interfaces for additional PCI local buses726and728, from which additional modems or network adapters may be supported. In this manner, data processing system700allows connections to multiple network computers. A memory-mapped graphics adapter730and hard disk732may also be connected to I/O bus712as depicted, either directly or indirectly.

Those of ordinary skill in the art will appreciate that the hardware depicted inFIG. 7may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention. The data processing system depicted inFIG. 7may be, for example, an IBM eServer pSeries system, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system or LINUX operating system.

FIG. 8is a flowchart illustrating the operation of an application integration testing tool in accordance with a preferred embodiment of the present invention. The process begins and generates a test document (step802). The hub sends the test document to an adapter for a round-trip back to the hub (step804). After the transformation engine(s) convert generic objects to application specific objects and then converts the application specific objects back to generic objects, the hub receives a return document for the spoke (step806). The testing tool then documents the fields in the return document (step808).

A determination is made as to whether the spoke is the last spoke in the model (step810). If the spoke is not the last spoke, the testing tool considers the next adapter (step812) and returns to step804to send the test document to the next adapter. If the spoke is the last spoke in step810, the process analyzes the documentation to find disagreements, lost data, and unused fields (step814). Thereafter, the process updates mappings, if necessary (step816). Then, the process ends.

Thus, the present invention solves the disadvantages of the prior art by providing a tool for testing application integration models, particularly integration logic in a hub-and-spoke integration scheme. The testing tool of the present invention exercises spokes of the integration project for objects in the model. A test document is sent to each adapter. One or both of a transformation engine in the hub and a transformation engine in the adapter of a given spoke converts the generic object to an application specific object and then converts the application specific object back to generic object. The testing tool then documents the return document of each spoke. The result is a catalog of total mappings, partial mappings, and empty mappings. These results may be analyzed to identify disagreements, lost data, and unused fields. The model may then be corrected by updating the mappings.

The testing tool of the present invention also applies to messaging-bus type integration architectures as long as there exists a common object model and mapping repository. The testing tool of the present could then send test objects to the components of the architecture and update the mappings based on the results.