Different software applications may need to exchange data. For example, a computer system running mySAP ERP® business software may need to exchange customer information, purchase and sales order information, or other information, with a different computer system running, say, Oracle® business software.
The two types of business software may differ in various ways. For example, they may differ in the message formats that they read and write, the file formats that they store data in, the data access methods that they use, the types of connectivity middleware that they are compatible with, and the like. To enable the exchange of information between the two types of software, these differences must be accounted for. The process of accounting for the differences may be referred to as “integration.”
Integration may involve, for example, mapping. Mapping involves, for example, identifying differences and similarities in software data structures, keys, values and behaviors, and building bridges or translations between these elements, so that software can communicate. Examples of mapping include key mapping and value mapping. Key mapping involves assigning correspondences between respective data keys used by two different business applications (e.g., “data key X for business application 1 is equivalent to data key Y for business application 2”), so that one application can understand what another application's key means. Similarly, value mapping involves assigning correspondences between respective data values used by two different business applications (e.g., “values {1, 2, 3 . . . } for business application 1 are equivalent to values {a, b, c, . . . } for business application 2”) so that the applications can understand each other.
Integration may further include manipulating data messages of two different systems based on an understanding of what the messages contain. For example, a programmer, to integrate two systems, might write code to create a new message usable by one of the systems based on data in a message or multiple messages of the other system. The code might, say, extract two fields from a source message emitted by one system, store the extracted fields in a field of a new output message, define initial values in fields of the output message, and the like, in order to make the output message suitable for use by the other system. Integration might, therefore, include copying, deleting, inserting or modifying messages or portions of messages, typically for the purpose of facilitating the exchange of information between different systems. The message types involved in such operations may be customer-specific. Accordingly, in the integration process, the programmer typically comes to have an expert knowledge of the message types and of the integration logic. The programmer therefore can produce code to directly manipulate the messages and thus, further, associated databases.
Once developed, an integration solution needs to be adjusted and controlled. That is, while there may an initial period when expert consultants develop an integration solution and deploy it on a computer system, it is typically the case that maintenance and daily operation must be performed. Usually, the consultants have moved on to another project and the maintenance tasks must be performed by end users, who typically do not have the expert knowledge of the consultants. Therefore, often as part of an initial deployment, expert consultants will develop user interfaces that enable an end user to perform required maintenance tasks. The maintenance tasks may involve making needed adjustments to the original integration solution. For example, an end user may need the capability to change message headers or other message properties on demand. Such a customizing capability may be provided by way of a maintenance user interface whereby an end user is able to make desired adjustments. That is, the user interface guides the user. The user need only, for example, respond to a series of prompts. In response to information entered by the user, underlying functionality coded by an expert performs the operations, such as the direct manipulation of data on a database, that are actually needed.
Administrative tasks of daily operation also involve user interfaces. Examples of typical administrative tasks include the daily monitoring of the overall integration system and monitoring/correcting exceptional operation conditions (e.g. exhausted table space in databases, non-delivered messages and so on).
Creating such a customized maintenance or administrative user interface manually (e.g., developing the corresponding screen displays and coding the underlying functionality) is typically a laborious, time-consuming and error-prone process. Often, creating the user interface takes considerably more time than providing the integration functionality itself. However, the capabilities of such user interfaces must be provided to an end user because the end user typically does not have the technical knowledge to control/monitor/customize/administer the associated integration operations directly.
In view of the above, embodiments of the present invention relate to automating the creation of user interfaces for integration. The user interfaces may be automatically generated based on integration metadata. The integration metadata may comprise information and functionality relating to the integration of two or more systems. The integration metadata may be automatically processed to generate the user interfaces. By automating the creation of user interfaces in this way, the laborious, time-consuming and error-prone effort of creating the user interfaces manually is avoided.
Once generated, the user interfaces may comprise one or more displays and background functionality. The displays or “front-end” of the user interfaces may, for example, guide a user through setting up an integration control operation that manipulates the behavior of the basic integration logic. Once performed, a control operation may, for example, change how messages are manipulated for purposes of inter-system communication. Thus, a control operation may change message mappings, content or appearance of messages or portions of messages, message properties, or other features. The background functionality of the user interface may process information entered by the user to set up the control operation, while the user need only respond to prompts from the front-end.
The integration metadata 101 may, for example, be collected over the course of doing the original work of integration. That is, as noted earlier, there may be an initial development phase for integration. This initial development phase may include defining/importing message types, doing all the necessary mapping, and developing functionality for performing the necessary manipulation of data. Thus, the original work, while creating a basic integration solution for deployment, also produces a useful storehouse of functionality and information relating to data manipulation, message formats, mappings and other information related to integration.
The integration landscape definitions 106 may be collected, for example, when deploying a concrete integration solution at a customer site, and may include connectivity information for the systems involved in the operation of the solution. The connectivity information, more specifically, may relate to connectivity protocols that will work to connect different systems, protocols such as HTTP (Hypertext Transfer Protocol), Open Database Connectivity (OBDC) or lava Database Connectivity (JDBC).
The control operation definitions 107 may include an identification of one or more control operations that are or may need to be performed on an ongoing basis, for example to perform maintenance after an initial integration project is completed. An example of a control operation is customizing a message, such as changing a message header to be customer-specific. Another example of a control operation is changing a zip code range that acts as a filter for messages. The foregoing (i.e., a message header and a message filter) are examples of control data that may be changed by a control operation. As used herein, “control data” means data that controls how messages look or are manipulated for purposes of inter-system communication. A control operation that changes control data may therefore change message mappings, content or appearance of messages or portions of messages, message properties, or other features.
The generator 102 may match information in the metadata 101 relating to message formats, mappings, data manipulations and so on with a given control operation definition in the definitions 107, taking into account the concrete integration landscape as defined in the landscape definitions 106, and build a user interface via which a user can set up the control operation to manipulate the behavior of a deployed integration solution.
The interfaces may be generated on-the-fly by the generator 102. The generator 102 may then hand over control to a user interaction tool 105 which enables a user to select an appropriate user interface 103.i. Via the selected user interface, the user can control the behavior of the integration solution without needing to go down to database level and actually manipulate control data directly. Instead, the user can simply navigate through the user interface, respond to prompts and enter information. The background functionality of the user interface may process the responses of the user to set up a control operation that can manipulate control data. The control data, in turn, controls the behavior of the integration solution (i.e., for example, the appearance of messages, how messages are mapped, how messages are manipulated for inter-system communication, and so on).
The functionality 103.ii and displays may further, for example, enable a user to link to various different systems that need to be integrated, retrieve data from the various systems, process the data and store the processed data on the various systems.
The generator 102 may further include search and extract logic 102.1. Based on the control operation definitions 107, the search and extract logic 102.1 may search for and extract corresponding information from the integration metadata 101 and integration landscape definitions 106. For example, a given control operation may be, say, the operation “Change message header for Customer XYZ.” Based on this information, the generator 102 may search for corresponding information in the metadata 101, extract it and display it in a user interface 103.1, 2, . . . , n. The extracted information may include, for example, the format of customer messages for customer XYZ. The user may then alter the information as desired.
The search and extract logic may further choose which screens to present/display and how to arrange their access due to the given integration metadata 101 and to the given integration landscape definition 106. Thus, the search and extract logic may allow the integration tool 105 to automatically arrange the navigation among the generated user interfaces accordingly.
The generator 102 may further include logic 102.2 to build background functionality 103.ii of the user interfaces. As noted earlier, the background functionality 103.ii may operate to save information initially entered in the displays 103.i1, i2, . . . , ik by a user, read stored information and display it in the displays 103.i1, i2, . . . , ik, enable the alteration of previously stored information and enabling the deletion of information. Based on information received way of such operations, the background functionality 103.ii may set up a control operation. User interface navigation and prompting logic may also be built by logic 102.2 based on the operation that needs to be performed.
In view of the above,
Based on the operation that needs to be performed, the generator 102 may process the integration metadata and/or the integration landscape definitions to extract corresponding information as shown in block 402.
As shown in block 403, the generator may generate, on-the-fly, user interface screen displays corresponding to the operation, using the extracted information. Further, the generator may build, on-the-fly, background functionality of the user interface using the extracted information, as shown in block 404. The generator may then hand over control to a user interaction tool, as shown in block 405.
Embodiments of the present invention may further relate to generating user interfaces that guide a user through an administrative operation, such as showing the state of progress for the overall processing of the integration solution and monitoring/correcting exceptional operation conditions. Showing the state of progress may include giving an overview of all currently ongoing and not-yet-completed/not-yet-begun jobs in order provide information as to how much of a workload is completed.
The embodiments of the invention described above may be implemented as computer-executable instructions and other data stored on machine-readable media such as magnetic tape 501, diskette 502, CD-ROM 503 and fixed disk 504. The computer-executable instructions may be retrieved from the machine-readable media 501-504 using their respective reading devices 505-508 into memory 500, and executed by a processor 510. The computer-executable instructions and other data may be distributed across a plurality of media, such as on physically separate storage devices respectively associated with physically separate computer systems that may communicate via a network. The functionality disclosed hereinabove may find specific implementations in a variety of forms, which are considered to be within the abilities of those of ordinary skill in the pertinent art after having reviewed the specification.
Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.