WO2003091821A2

WO2003091821A2 - Dynamic database interface

Info

Publication number: WO2003091821A2
Application number: PCT/EP2003/003779
Authority: WO
Inventors: Thomas Bönnen; Andreas Lauterjung; Karl-Josef Errens
Original assignee: Informationsverarbeitung Leverkusen Gmbh (Ivl)
Priority date: 2002-04-24
Filing date: 2003-04-11
Publication date: 2003-11-06
Also published as: AU2003233965A8; AU2003233965A1; WO2003091821A3

Abstract

The invention relates to a method for operating a dynamic database interface for the communication between a database system application and a database system. According to the inventive method, said interface (i) receives a parameterised database system function call from the database system application, coded in the XML format, for the database system, (ii) converts said function call, as far as possible, into a format which is compatible with the database system, (iii) sends the corresponding parameterised database system function call, as far as possible, to the database system, in a format which is compatible with the database system, (iv) if a database system function call is successful, receives a parameterised result from the database system, coded in a format which is compatible with the database system, (v) if a database system function call is successful, converts the parameterised result into the XML format, and (vi) if a database system function call is successful, sends the received parameterised result, coded in the XML format, back to the database system application.

Description

Title: Dynamic database interface

Applicant: Informationsverarbeitung Leverkusen GmbH (INL), Overfeldweg 55, D - 51371 Leverkusen, BR Germany

The present invention relates to a dynamic database interface for flexible coupling of an application system to database systems.

In practice, it has repeatedly proven to be extremely difficult to connect various applications to existing database systems, although there is a great need here.

Database systems are to be understood here to mean a database system in a more general sense, that is to say both conventional database systems which have the data (such as user data, description data), a data query or data manipulation interface and / or an administration system (for example the schema administration) and possibly access synchronization , as well as newer database systems, such as those provided by the OMG (Open Management Group) and which also implement higher concepts, for example by expanding them at the conceptual level, for example with new data types and / or new functionalities by having other properties, such as persistence, transaction components or recovery components. In addition to the otherwise customary components for request and data manipulation, these extended type database systems can also contain complex functions, for example with regard to specific applications that operate on the database. Complete programming environments for changing or maintaining the database system can also be part of such database systems. An example of such a more complex database system is SAP (protected trademark) - System called. Such database systems can themselves use a database system internally in the more conventional sense mentioned at the beginning, such as how the SAP database system can work with an Oracle (protected trademark) database.

Large database systems with extensive databases are often already in existence, but are to be made accessible to different applications. On the other hand, however, these applications often do not have suitable interfaces for coupling to the database systems, so that in these cases either the database is transferred to a database system compatible with the application (application) or a database system interface suitable for the application has to be created.

The first case is extremely complex and labor-intensive and also has the disadvantage that if several applications are used for different database systems but the same data stock, the data must be kept redundant, which is susceptible to errors as a result of the comparison that is then necessary and inconsistencies in the data stock can lead.

But the second solution is also very labor-intensive, since it requires the creation of an individually created interface between each application and the database system.

It is therefore an object of the present invention to provide a connection system for database systems to applications which is as flexible as possible and which avoids individual interface programming as far as possible or at least reduces the effort required for this.

This object is achieved according to the invention by a method for operating a dynamic database interface for communicating a database system application with a database system, which

i. receives a parameterized database system function call for the database system coded in XML format by the database system application, ii. convert this, as far as possible, into a format compatible with the database system,

iii. sends, as far as possible, the corresponding parameterized database system function call to the database system coded in a format compatible with the database system,

iv. if a database system function call was made, receives a parameterized result from the database system coded in a format compatible with the database system,

v. if a database system function call was made, the parameterized result is converted into XML format and

vi. if a database system function call was made, the parameterized result received in XML format is sent back to the database system application.

Furthermore, this object is also achieved by a dynamic database interface system, which has a data processing system with a processor and a memory, which is set up in terms of programming so that it works according to the method according to the invention for operating a dynamic database interface, this being the case for all embodiments of the invention The procedure also applies.

The same naturally also applies to a computer program which has instructions which are set up to carry out the method according to the invention, and this also applies to all embodiments of the method according to the invention.

A large degree of independence from any non-standardized application formats is already achieved here by using the XML format (XML = Extended Markup Language), which corresponds to the W3C (World Wide Web Consortium) standard, which ensures widespread use. This data format for data communication is a set of rules, one also speaks of guidelines or conventions that make structured data available for exchange between different systems.

The XML itself is modular, so that own document formats can be defined within the standard by combining or reusing other formats. This ensures that all target systems can communicate with this format. If an XML interface for an application is not yet available, at least existing application interfaces can be easily mapped to XML, if only because of the properties mentioned above, so that there is a flexible connection solution from database systems to applications that already have an XML interface. which is increasingly the case, but at least the effort of programming an interface is reduced, since only an XML interface that is easier to create has to be created.

The method for operating a dynamic database interface according to the present invention preferably receives from the database system application the parameterized database system function call for the database system in XML format in such a way that, in addition to the respective parameter value or values

also an identification of the parameter, preferably a parameter identifier, and / or

also information about the structure of the parameter, and / or

Information about whether the respective parameter is an export or an import parameter

having.

The same can also be provided for the parameterized result received by the database system, which result is converted into XML format and sent back to the database system application.

In one embodiment of the method according to the invention, preferably before step (iii), particularly preferably using a separate implementation database, checks whether the database system function call received by the database application is actually available for call from the database system and / or whether all the parameters required by the database system for executing the database system function call have also been received by the database application , in the negative case an error message encoded in XML format is sent back to the database system application.

The implementation is carried out, preferably in step (ii), particularly preferably using a separate implementation database, for example based on an identification of the parameters (for example using the parameter identifier and / or the parameter structure and / or based on whether the parameters are export or import) ), which determines which parameters received from the database system application must be converted to which parameters compatible with the database system, which conversely can also be implemented by the database system in the direction of the database system application.

In the method according to the invention for operating a dynamic database interface, the functions of the database system (for example so-called BAPIS and / or RFC-capable function blocks) are therefore mapped 1: 1 in XML according to this specification. Only the fields that are available are filled. If there are too few fields, only database system fields, such as SAP fields, are sent back that have an equivalent on the application side, for example on the side of a geographic information system (GIS). Overall, the process works according to the rules of set theory, i.e. If the database side is a subset of the application side, the parameters of the database system are completely imported into the application and vice versa. However, the database system indicates when a mandatory field (such as a so-called mandatory field in the SAP system) has to be filled. In short, the protocol runs as follows:

1.Funktionsaufruf

2.Check whether the function is available; if so 3. Check whether the structure is correct (field check, table check); if so

4. The function is executed

If the function does not exist ^■ > then the system is prompted to issue an error message.

If the structure does not exist "^ then the system should also issue an error message.

The method according to the invention is thus fault-tolerant and can be used in the same way for any database system.

In the following, the functionality is explained again for better understanding using an example in which SAP is used as a database system.

Function: BAPI CALL DEMO DATA

• Function name: BAPI_CALL_DEMO_DATA

• Import port parameters: A (structure), B (parameter)

• Export parameters: C (structure), D (parameters)

• Tables: E (table) implementation in XML:

Function call (partial way there): application to SAP

<EXPORTS> <C> Parameters C and D are sent to SAP as a request

<PARAM1> x </ PARAM1> sent - ^ exported; des-hafb are called C and </C> D export parameters.

<E>

<ROW1> x </ RO Wl> The table parameters are sent to SAP and picked up.

<RO Wn> x </ RO Ψn> table = import or export

</E> </TABLES>

</ BAPI CALL DEMO DATA>

Function call ^ eil2 way back): SAP to the application

<IMPORTS> This part represents the answer from SAP: compares the <A> request for parameters C and D.

<PARAM1> x </ PARAM1> the SAP existing and received values and </A> sends A and B as answer. Data are imported from <B> x </B> GIS view.

</ IMPORTS> <TABLES>

The structure of the table parameters from GIS and SAP is compared

</ TABLES>

</ BAPI CALL DEMO DATA> A particularly preferred embodiment of the method according to the invention for operating a dynamic database interface is characterized in that a geographic information system (GIS) is used as the database system application and at least one structural database system, preferably with a relational database, is used as the database system, in which structural, ie non-spatial data objects are stored from a geodatabase that also belongs to the geographic information system, the geodatabase being organized according to the spatial position of objects, preferably as a quad tree or relational, and at least the spatial data, preferably the geometric and / or geographic data of the objects, are stored therein , In addition to the spatial data for the respective objects, reference information associated with the respective object is also stored in the geodatabase, which contains the space stored in the geodatabase Assign object data to at least one object in the structure database system, and furthermore, when accessing an object of the geodatabase, automatically creates the assignment to the assigned objects of the structure database system via the dynamic database interface using the reference information stored here and thereby also access to the object stored here structural data belonging to the geodatabase is permitted.

Geographic information systems (GIS) usually provide their users with two fundamentally different types of information, namely spatial data, i.e. the data about the geometric relationships, such as the dimensions of the objects, which can be accessed using the geographic information system and which can be accessed through the GIS can also be displayed graphically and, on the other hand, other non-geometric data that are assigned to the individual objects.

As an example, here is a GIS that should help document the telephone connections of a certain area. On the one hand, there is spatial data about the location of the cable harnesses to the individual participants, but on the other hand there is also data about the participants themselves, such as their address, their respective terms and conditions, the responsibility of service employees, the type of installation, and which components are included - the associated references to possible parts lists up to the material numbers of the relevant spare parts that result from the parts lists.

Because a GIS has to handle these very different data, namely spatial data on the one hand and structural data on the other hand, the technical problem described below arises.

Basically, the requirements to be met by a database system that is to effectively manage the two types of data mentioned above are completely different:

For the management of spatial data, it is desirable due to the large amount of data that arises for reasons of reaction speed to database queries that the objects can be accessed particularly effectively on the basis of their spatial data, for example in that the spatial data of such objects that are in reality are geographically adjacent, are actually physically or at least logically closely 'adjacent' stored. This is necessary, for example, to enable the user of a GIS to be able to effectively navigate through the world of the graphical representation of the stored spatial data using appropriate navigation means (such as a mouse, a trackball or selected buttons on the control keyboard) navigate, such as being able to scroll here. Such an organization of spatial data can be achieved in various ways, for example by using so-called QuadTrees. For quick access to the spatial data, all of these methods take advantage of their inherent property that the objects are determined by their position. In this way, the requirement for effective access to the spatial data can be met, but at the price of a rather rigid database structure that is based on the position grid.

However, this technical organization of the spatial data, which is necessary for reasons of effectiveness, is extremely unsuitable for the structural data of the respective objects. Structural object data are usually stored according to the state of the art in relational databases, which give their respective users a logical view of the Things, namely the objects and their relationships to one another, without the user being further burdened with the actual technical implementation of these databases.

Thus, the direct 'appending' of the structural data to the technical organization of the spatial data in its database itself is extremely unsatisfactory and as a technical 'crutch', since its rigid organizational principle for the structural data and its diverse, oriented only to the spatial position Rections among each other is unsuitable.

Therefore, the current solution known according to the prior art usually consists in appending only the most necessary structural data to the spatial data and organizing the structural data in parallel and completely independently in a separate relational database. However, this solution also has decisive disadvantages. This means that two different databases have to be set up and maintained, which requires skilled operators, whose ideal type, in the form of both systems, is difficult to find. Inconsistencies in the management of the holdings of both databases are almost preprogrammed, since the operators of one database have to inform the operators of the other database of changes made for the purpose of supplementation and vice versa, which in practice is sufficient for large systems simply because of human error, such as Convenience, forgetting or even insightfulness occurs.

It is therefore problematic to specify a geographic information system (GIS), which enables both the effective management of spatial data and the problem-adequate management of structural data of the objects managed in GIS, without the need for parallel manual management of two differently structured databases. However, this can be achieved more easily with the above-described embodiments of the dynamic database interface according to the present invention.

This solution enables efficient administration and, in particular, efficient access to those with different spatial and structural characteristics - i 1 -

Allow data by assigning at least one piece of reference information to the associated structural data in the structure database system to the data organized according to spatial criteria in the geodatabase. This can be done, for example, by storing an access key for the structure database system in the geodatabase for the respective object. The access module, which is also associated with the GIS, can then access the associated objects of the structure database system there as reference information when accessing the geodatabase - which usually takes place according to spatial criteria, that is to say using a spatial key.

It should be noted in this connection that the geodatabase within the meaning of the present invention can also be regarded as organized according to the spatial position of objects if this organization is carried out in whole or in part on a purely logical level; This does not necessarily require a physical organization of the geodatabase according to the spatial position of objects, especially in view of the progressive database technology.

In addition to the structural data for the respective objects, back-reference information assigned to the respective object is preferably stored in the structure database system, which assigns the structural object data stored in the structure database system to at least one object in the geodatabase and which is retrieved from the geographic information system via the dynamic database interface or at least can be called up. This makes it possible to draw conclusions about the objects of the geodatabase when accessing the structure database system. In this case, for example, it can be determined in which houses there are gas connection components from a particular manufacturer. A back access module is preferably provided for this purpose, which does this on the basis of the back reference information or back reference information.

In the present invention, the geodatabase is preferably organized as a QuadTree, which is suitable for geographic information systems that are based on spatial aspects. organized, has proven particularly successful. The Smallworld system (protected trademark) represents, for example, such an embodiment which is suitable for the present invention.

However, it is also possible that the geodatabase is organized as a relational database according to the spatial position of objects. Here it can also be organized purely logically according to the spatial position of objects, for example by creating special - even geometric - relations between adjacent objects.

The structure database system preferably has a relational database, such as is used in SAP (protected trademark) systems, which corresponds to the structure of the structural data from the logical approach. But schema databases (CODASYL) or hierarchical or associative databases are also good for this.

In order to set up the dynamic database interface according to the present invention even better for use by many applications, a method for operating a pool manager for connecting a database system application to at least one database system by means of at least the dynamic database interface, which in each case according to the method according to the present According to the invention, the pool manager receives requests from the database system application for communication with the database system or the database systems and then, for the requesting database system application, an instance of itself or a communication module assigned to the requesting database system application generated or assigned at least one associated dynamic database interface.

The pool manager, preferably a Corba pool manager, is used here to enable applications that cannot independently establish a connection to a host system to access - possibly different - database systems. The pool manager is therefore to be seen as an intermediary between the requirements of a requesting system, that is to say the database system application and the database system. In all cases the pool manager must provide his services independently of the operating system. The pool manager should also be independent of the programming language of the requesting application. To the same extent, independence from proprietary communication systems of the database system is required.

So that the pool manager can meet the required conditions, its external interfaces can comply with the W3C (World Wide Web Consortium) standard. The data format for data communication is XML (Extended Markup Language), by means of which platform-independent through a set of rules, one also speaks of guidelines or conventions, structured data for the exchange between different systems is made available.

The XML itself is modular, so that own document formats can be defined within the standard by combining or reusing other formats. This ensures that all target systems can communicate with the new format, the interpretation of the content of the XML document preferably being carried out by the Corba module, particularly preferably by a Corbaserver module.

The data communication is thus defined in this embodiment by the Corba specification. The pool manager as Corba pool manager is then a server, which as an independent system e.g. is implemented or runs as a service or on its own data processing system and, when requested by an application, takes over the establishment of a connection to the database system and transparent communication of the data from and to the database system.

The pool manager, preferably Corba pool manager, is available as an external third-party application. Since no proprietary communication technology is used here, platform independence is ensured.

The calling application builds its request in an XML package, for example, which is sent to the pool manager, preferably Corba Poolmanager, via http. As soon as the latter receives a request, a separate instance of the pool manager is preferably created for this request. built up. This instance remains persistent until all communication between the application in question and the database system is ended.

The fact that a separate instance is set up also creates a separate connection to the database system. The advantage of this structure is that it has its own user rights and address spaces for the connection in question.

The applications that use the pool manager do not have to be of a special type.

As soon as an instance of the pool manager, preferably Corba pool manager, is created, a connection, preferably a Corba connection, to the host system, that is to say the database system, is created. If the number of instantiable connections on the corresponding data processing system serving as the server for the pool manager is too small, or if the host system does not respond temporarily, the connection establishment preferably remains in a waiting loop.

In order to connect to the correct database system, a connect string within the XML data packet is preferably evaluated by the instance of the pool manager or the communication module. The respective database system is thereby identified as the target system and a suitable connection to it is switched.

After the connection has been established, the instance of the pool manager or of the communication module in the form of a Corba module, preferably a Corbaserver module, serves as a translator between the information in the XML package and the data packages required for the database system in cooperation with a respective dynamic database interface Database system according to the present invention, also called a bridge.

In the case of a SAP system as a database system, a dynamic database interface associated with the instance of the communication module or the pool manager is then preferably set up as a so-called SAP bridge, in which the communication to SAP via SAP's own RFC. A Corbaserver module then interprets the XML structure and parameterizes the RFC calls via the SAP bridge.

The bridge is fault-tolerant when parameterizing the database system. This means - as already explained above for the dynamic database interface itself - that the parameter bars are filled up transparently for the user, and the return transport of the result data to the requesting application is reduced accordingly.

Any Corbaserver module communicates with the database system via a bridge.

In particular, it is permitted that any, including foreign, bridges are registered with the instance of the pool manager or the communication module, for example the Corbaserver module. This allows third-party applications to use their own access structures or make specialized access structures usable.

A Corbaserver module, which functions as a communication module, provides the methods "Register" or "Deregister" for the registration.

The bridges, that is to say the dynamic database interfaces according to the present invention, are themselves constructed in such a way that they accept an XML string, parse it and pass it on for the database system in accordance with the format. The results from the database system are converted back into XML, for which the methods "Call" and "UseFlushwrite" are made available.

A Corbaserver module can also communicate directly with other applications. To do this, they must have the Corba-specific IDL (Interface Definition Language). The connection is then preferably established as a so-called "named service".

Here too, communication and data exchange are transparent for the application. The Corbaserver module also serves as a general intermediary between independent applications and database systems. In the case of special applications, such as the GISConnect or GlSConnect NT applications, which connect a geographic information system (GIS) to a SAP system, the Corbaserver module provides the methods for establishing a connection to the SAP system and data communication via RFC via SAP Bridge.

Because of the structure of the connection establishment, the independent instantiation of a communication, the number of connection connections is not subject to any restrictions. In particular, several or individual applications can be connected to several or individual database systems by the pool manager according to the present invention. If in operation restrictions of the actually possible connections due to If storage space limits occur, a load distribution can be achieved, for example, by communicating with a second or further data processing system (s) with the pool manager. The two or more servers then preferably communicate via (a) named pipe (s).

The method according to the invention for operating a pool manager is thus fully scalable, a particular advantage being that it is also scalable on a task basis.

The various types of performance of a pool manager according to the present invention, which have already been mentioned above, are again shown systematically, but without any restriction to them, and it should be pointed out once again that all the exemplary embodiments are only as a specific specification with regard to a specific application task of the present invention.

The communication request from the database system application to the pool manager is preferably also in XML format with a data packet part, preferably a so-called connect string within the XML data packet, which the pool manager evaluates and which identifies the database system or the database systems to which the communication is being established the instance of itself or of the communication module is generated or assigned with at least one associated dynamic database interface which is used to communicate the data tenbank system application with the requested database system or database systems.

Furthermore, the method for operating the pool manager can be characterized in that the pool manager generates or assigns a Corba module, preferably a Corbaserver module as an instance of itself or as a communication module, so that communication with the database system application and / or or the respective dynamic database interface or database interfaces is processed directly or indirectly using the Internet Inter Object Request Broker Protocol (HOP).

In this way, access can be made using the so-called "Common Object Request Broker Architecture" (CORBA), which is becoming increasingly popular as an open standard for distributed network applications. However, access to a growing number of subscribers to the database system can be made scalable, which can be ensured, for example, by combining a certain number of subscribers (clients) who should have access to the database system on a so-called Corba server system be, which leads the data traffic to the respective client by means of HOP and this Corba server system is then connected to the actual database system.

A Corbaserver module is therefore preferably generated or assigned as a Corba module, which is designed in such a way that it handles its communication with the database system application via at least one CORBA intermediate instance, the pool manager preferably having a Corbaclient for the Corbaserver module generated or assigned in each case - Module created or assigned as an intermediate instance, which preferably converts the database application by means of data sent in XML format into the Internet Inter Object Request Broker Protocol (HOP) for the Corbaserver module and vice versa data received in this protocol by the Corbaserver module converts so that they are sent to the database application in XML format.

It can also be the case that the pool manager has a Corba application server module as the Corbaclient module or the Corbaser server module that is generated or assigned associated and thus also generated or assigned as an intermediate instance, which transfers data sent by the database application using an intermediate transfer protocol, preferably using the TCP / LP protocol in XML format, to the Internet Inter Object Request Broker Protocol (IIOP) for the Corbaser server. Module converts and vice versa converts data received by the Corbaserver module in this protocol so that it is sent to the database application in XML format by means of the intermediate transmission protocol, preferably the TCP / IP protocol.

In a preferred embodiment of the method for operating a pool manager according to the present invention, where a geographic information system (GIS) is used as a database application and an associated structural database system, it can be used as a geodatabase GIS Smallworld (protected trademark) and as a database system for realizing the An SAP (protected trademark) system can be provided in the structural database system. As a result, the advantages of the present invention for a geographical information system which have already been explained can be further improved for this use by using the pool manager according to the invention.

The pool manager can of course also be implemented in a system which has a data processing system with a processor and a memory and which is set up in terms of programming so that it operates according to the method for operating a pool manager according to the present invention.

This system can also be designed in such a way that it has at least two data processing systems connected to one another via a communication channel, each with at least one processor and one memory, the first being set up in terms of programming so that a pool manager is operated which handles the requesting database system application assigned Corbaserver module each generates or assigns with at least one associated dynamic database interface on the second data processing system, it handles its communication with the database system application via the Corbaclient module, which is located on the first data processing system, as an CORBA intermediate instance For the sake of completeness, it should also be mentioned that the pool manager can also be implemented as a computer program which has instructions which are set up to carry out the method according to the present invention.

The following functions are preferably used to implement the present invention when using a geographical information system (GIS) as a database system application and an SAP system as a database system.

ACP ENGINE.COMAND

With this function the GISConnect ACP is controlled from the GIS. The following functions are available:

Start ACP (START)

Starts the ACP process in the form of a Windows program

Entry: <ACP_ENGINE>

<EXPORTS> <COMAND> <MODUL> SAP </ MODUL> <CALL> START </CALL>

</ COMAND> </ EXPORTS> </ACP_ENGINE>

Returns: <ACP_ENGINE>

<TYPE> S </ TYPE> <MODUL> SAP </ MODUL> <CALL> START </C ALL>

</ RETURN> </ IMPORTS> </ACP_ENGLNE>

SAP login dialog (SAP LOG IN)

The ACP provides its own SAP login dialog.

Entry: <ACP_ENGINE>

</ COMAND></EXPORTS></ ACP ENGINE> Return:

<ACP_ENGLNE>

</ RETURN> </ IMPORTS> </ ACP ENGINE>

SAP logout (SAP LOG OUT)

Function for logging off a user from SAP.

Input:

<ACP_ENGLNE>

</ COMAND> </ EXPORTS> </ACP_ENGINE>

Returns: <ACP_ENGINE>

</ RETURN> </ IMPORTS> </ACP_ENGLNE>

Silent SAP logon (SAP SILENT LOG IN) Logon is controlled by the client (GIS).

Input:

<ACP_ENGINE>

<EXPORTS> <COMAND> <MODUL> SAP </ MODUL> <CALL> SAP_SILENT_LOG_IN </CALL>

<LOGIN> <CLIENT> 050 </CLIENT> <USER> Lauterjung </ USER>

<PASSWORD> Secret </ PASSWORD> <LANGUAGE> DE </ LANGUA GE>

<SYSTEM> ivl - SAPDBIE1 - IE1 - development system 4.6B </ SYSTEM>

</ COMAND></EXPORTS></ ACP ENGINE> Return:

<ACP_ENGLNE>

</ RETURN></IMPORTS></ ACP ENGINE>

Silent SAP logout (SAP SILENT LOG OUT) Function for "silently" logging off a user from SAP.

Input:

<ACP_ENGINE>

<EXPORTS> <COMAND> <MODUL> SAP </ MODUL> <CALL> SAP_SILENT_LOG_OU </ CALL>

</ COMAND> </ EXPORTS> </ACP_ENGINE>

Returns: <ACP_ENGFNE>

<TYPE> S </TYPE> <MODUL> SAP </ MODUL> <CALL> SAP_SILENT_LOG_OUT </CALL>

</ RETURN> </ IMPORTS> </ACP_ENGINE>

The Multi XML function call

This call should be selected if several systems are to be connected to the GIS.

Entry: <ACP_ENGINE>

</ COMAND> </ EXPORTS> </ ACP_ENGINE>

Return:

<ACP_ENGINE>

</ RETURN> </ IMPORTS>

</ ACP ENGINE> Direct SAP call

This function has no intermediate wrapper and is passed on directly to SAP.

Input: XML statement. Returns: XML statement.

meta

Class classification I

Example: CACL_OBJECT_ALLOCATION_MAINT

statement:

<? xml version = "1.0" encoding = "ISO-8859-l"?> - <CACL_OBJECT_ALLOCATIÖN_MAINT> - <METAINF>

<TYPE> EXPORT / TYPE> Enter either "Export" or "Import"<TYPE> IMPORT </TYPE> X or "All"<TYPE> ALL </TYPE></ETAINF></ CACL_OBJECT_ALLOCATION_MAI T>

Export Class.xml

<? xrnl versιon = "1.0" encodιng = "ISO-8859-l"?:

<CACL_OBJECT_ALLOCATION_MAINT>

- <EXPORTS>

- <CHANGE_NO>

<SAPTYPE> 0 <SAPTYPE> <TYPE> String </TYPE> <LE GTH> 12 </ LE GTH> <DECI ALS> 0 </DECIMALS> </CHANGE_NO>

- <CLASS>

<SAPTYPE 0 </ SAPTYPE; SAPart = 0; string type; <TYPE> String </TYPE> length 18 characters; no deci

<LENGTH> 18 </LENGTH> f paint

<TYPE> string </ TYPE>

<TYPE> string </ TYPE>

<SAPTYPE> 1 </ SAPT PE> SAPart = 1; of type Date (Da-

<TYPE> Date </TYPE>>. turn); Length: 8 characters; no

<LENGTH> 8 A.ENGTH> decimal places

<TYPE> string </ TYPE>

<LEMGTH> K LEFMGTH>

<SAPTYPE> 0 <SAPTYPE> <TYPE> String </TYPE> <LENGTH> 30 </LENGTH> <DECIMALS> 0 </ DECI ALS> </OBJECT_TYPE>

- <STANDARD_CLASS>

<SAPTYPE> 0 </SAPTYPE> <TYPE> String </TYPE> <LENGTH> 1 </LENGTH> <DECIMAL5> 0 </DECIMALS> </STANDARD_CLASS>

- <STATUS>

<SAPTYPE> 0 </SAPTYPE><TYPE> String </TYPE><LEGTH> 1 </ LENGTH <DECIMALS> 0 </ ^' DECIMALS></STATUS></EXPORTS> - <TABLES>

- <ÜBJECT_IDENTIFICATION>

- <FIELD>

<SAPTYPE> 0 </SAPTYPE><TV ^f PE> String </TYPE><LEMGTH> 30 </ LE GTH><DECIALS> 0 </ DECI ALS></FIELD>

- <VALUE>

<SAPTYPE> 0 </SAPTYPE><TYPE> String </TYPE><LENGTH> 50 </LENGTH><DECIMALS> 0 </DECIMALS></VALUE></OBJECT_IDENTIFICATION></TABLES></ CACL OBJECT ALLOCATION MAINT ;

Import Class.xml

<? xml versιon = "l.ü" encodιng = "ISO-88S9-l"?> - <CACL_OBJECT_ALLOCATIGN_M ^ώ .INT><IMPO TS /> - <TABLES>

- <OBJECT_IDENTIFICATION>

- <FIELD>

<SAPTYPE> 0 </SAPTYPE> <TYPE> String </TYPE> <LENGTH> 30 </LENGTH> <DECIMALS> 0 <DECIMALS> </FIELD>

- <VALUE>

<SAPTYPE> 0 <SAPTYPE> <TYPE> Strmg </TYPE> <LEMGTH> 50 </LENGTH> <DECIMALS> 0 </DECIMAL5> / VALUE> </OBJECT_IDENTIFICATION> </TABLES> </CACL_OBJECT_ALLOCATION_MAINT>

Classification II, features, equipment and functional locations are structured in the same way.

function calls

CACL_CLASSIFICATION_SAVE

statement

- <CACL_CLASSIFICATI N_SAVE> - <EXPORTS>

<I_COMMIT> X </ I_COM IT></EXPQRTS><I PO TS /><CACL_CLASSIFICATIN_SAVE> Responds

<? xml version = "1.0" encoding = "ISO-8859-l"?: - <CÄCL_CLASSIFICATION_SAVE> - <EXPORTS>

<I_COMMIT> X </I_COMMIT> </EXPORTS> <I PORTS /> </CACL_CLASSIFICATION_SAVE>

Class.ExistenceCheck

statement

<? xml υersioπ = "1.0" encoding = "ISO-88S9-l"?;

<BAPI_CLASS_EXISTENCECHEC>

- <EXPORTS>

<CLASSNUM> STATIOIM </CLASSNUM> <CLASSTYPE> 003 </CLASSTYPE> </EXPORTS>

</ BAPI_CLASS_EXISTENCECHECK>

Responds

<? xml version = "1.0" encoding = "ISO-88S9-l"?> - <BAPI_CLASS_EXISTENCECHEC>

- <EXPORTS>

<CLASSNUM> STATION <CLASSNUM>

- <TABLES>

- <RETURN> - <R0W1>

Leave <MESSAGE> type 003: STATION has already been created <MESSAGE>

<LOG_NO />

<LOG_MSG_NO> 000000 </ LOG_MSG_NO>

<MESSAGE_V1> 003 </ MESSAGE_V1>

<MESSAGE_V2> STATION </ MESSAGE_V2>

<ESSAGE_V3 />

<MESSAGE_V4 />

In the following, non-restrictive exemplary embodiments are discussed with reference to the drawing. In this show:

La-d the operation of the inventive method for operating a dynamic database interface for communication of a database system application with a database system using schematic representations of the parameter exchange,

2a-c different possibilities of a communication link between a database system application and a database system via a dynamic database interface according to the present invention, and

Fig. 3 is a schematic representation of an embodiment of a pool manager system according to the present invention.

La-e show the functioning of the method according to the invention for operating a dynamic database interface for communicating a database system application with a database system on the basis of schematic representations of the parameter exchange.

The images shown here depict the process, in particular with regard to the structure and / or the functioning of the XML protocol, FIG. 1 a illustrating the general principle according to which a function call by the application, here GIS, and then a check, whether the function is present, whereby if the function is available on the part of the database system, here SAP, the function is carried out and the parameters are returned to the application. If the function does not exist, an error message is preferably returned.

Fig. Lb shows the case that the parameters passed do not match. The GIS page is too large here, there are too few fields in SAP because field 3 does not exist. SAP still sends the requested data back, because in this case SAP represents a subset of the incoming GIS data. There is therefore no error message here. 1c shows the case in which fewer parameters are made available by the application than SAP can process as parameters for the function call. This transaction also does not generate an error message because GIS provides a subset of the SAP function parameters here. An error message would only appear if the missing fields 3 and 4 were mandatory. The example illustrates the principle of mapping all transactions 1: 1 and the claim of fault tolerance.

FIG. 1d shows, analogously to FIG. 1c, the case in which the SAP parameter subset is completely mapped on the GIS side.

2a-c show different possibilities of a communication link between a database system application and a database system via a dynamic database interface according to the present invention.

Fig. 2a shows the case that a geographic information system acts as a database system application, it communicates in XML format with a Corba module as an instance of a communication module, here called GISConnect.NT Engine, which in turn is a dynamic database system according to the The present invention, namely here a bridge, is assigned, which converts the XML format to the format of the database system, for example in RFCs.

In Fig. 2b, a Corbaclient module is connected as an intermediate instance between the Corbaserver module, here called GISConnect.NT Corba server, which transmits data sent by the database application, here GIS, in XML format to the Internet Inter Object Request Broker Converts protocol (HOP) for the Corbaserver module and conversely converts data received by the Corbaserver module in this protocol in such a way that it is sent to the database application in XML format. The Corbaserver module is also assigned a dynamic database system according to the present invention, namely a bridge, which converts the XML format to the format of the database system, that is to say, for example in RFCs, and conversely carries out the conversion into XML. 2c finally shows the case in which a Corba application server module was created or assigned as a further intermediate instance to the Corbaserver module that was generated or assigned, which was created by the database application, here GIS, using an intermediate transmission protocol, preferably using TCP / IP protocol converts data sent in XML format into the Internet Inter Object Request Broker Protocol (HOP) for the Corbaserver module and conversely converts data received from the Corbaserver module in this protocol in such a way that it is preferably by means of the intermediate transmission protocol of the TCP / IP protocol are sent to the database application in XML format.

This Corba application server version, preferably Corba HTTP application server version, assumes that the application runs under any operating system or on the web. The pool manager then preferably creates personalized Corba objects. The connection to the pool manager preferably runs via a TCP / IP socket connection, the protocol being XML. The HTTP Corba Applications server can run under Windows NT, for example, but its structure is basically platform-independent. There is no operating system dependency for the clients.

3 shows a schematic representation of an embodiment of a pool manager system according to the present invention.

Here, database systems are accessed using the so-called "Common Object Request Broker Architecture" (CORBA), which is becoming increasingly popular as an open standard for distributed network applications. However, access to a growing number of participants in the database system can be made scalable, which is ensured, for example, by the fact that a certain number of participants who should have access to the database system on a so-called Corba application server system, upper part of the image (GISConnect .NT HTTP Server), which leads the data traffic to the respective client using IIOP and this Corba application server system then with the actual database system, here SAP, via the XML shown in the lower part of the figure Corbaser server system via SAP bridges (embodiments of dynamic database interfaces according to the present invention) is connected.

A Corbaserver module is preferably generated or assigned here as a Corba module, which is designed in such a way that it processes its communication with the database system application via at least one CORBA intermediate instance, namely a Corbaclient module, the pool manager preferably generating each or assigned Corbaserver module creates or assigns such a Corbaclient module as an intermediate instance, which converts data sent by the database application in XML format into the Internet Inter Object Request Broker Protocol (IIOP) for the Corbaserver module and vice versa by the Corbaserver module. Module converts data received in this protocol so that it is sent to the database application in XML format.

A Corba application server module, which performs the above implementation process, can either anonymously with an assigned Corbaclient module (which then preferably does not implement itself in and after IIOP) as well as via known users, for example for http communication (as Corbaclient- Module, which then also implements), for example via the World Wide Web. The type of the requesting application is independent of this, the registration form depends on the database system involved.

When calling up such an HTTP Corbapplication server module, when the system is started up, the Corbaclient modules 1-n are preferably used as (anonymous [approximately assigned to a Corba application server module that is implemented by and in 1TOP]) or by name [approximately even as a Corba application Server module acting and implemented by and in IIOP]) access objects. At the same time, SAP bridges (SAP Bridge 1-n) are automatically started or generated at the start of a session, for example if SAP is used as the database system. The pool manager manages the incoming requests and assigns one Corbaclient module each. If the number of Corbaclient modules is too low, the requests preferably remain in a queue until the pool manager can allocate a free space. All transactions can take place without a user (user) reference, ie a user does not have to log on to the SAP system with their own profile, since the logon takes place automatically when the system is started (for example because the pool uses preconfigured users) ). The flashes for the applications in the figure, labeled with XML, make it clear that the evaluation of a request takes place in XML format. It is also possible for a user to register personally; registration takes place directly at the HTTP Corba application server module, to which a personalized Corbaclient module is assigned.

However, as already mentioned, it can also be the case that the pool manager creates a Corba application server module as the Corba client for the respectively created or assigned Corbaserver module or only assigns it to a Corbaclient module and thus also creates or assigns as an intermediate instance which one converts data sent by the database application using an intermediate transmission protocol, preferably using the TCP / IP protocol in XML format, into the Internet Inter Object Request Broker Protocol (IIOP) for the Corbaserver module and vice versa from the Corbaserver module in this protocol converts received data in such a way that they are sent to the database application in XML format using the intermediate transmission protocol, preferably the TCP / LP protocol. If the Corba application server module itself does not function as a Corbaclient module, but is only assigned to it, this is preferably because the Corbaclient module then only serves for the assignment to the, preferably anonymous, user rights and the implementation from and to IIOP in this Not from the Corbaclient module, but from the Corba application server module assigned to it.

The HTTP Corba Applications server system shown here in the upper part of the figure can also be controlled from other applications. This makes it possible for the external application to specifically retrieve data from the database system. This enables a synchronous or asynchronous connection to the database system to be established under the control of the external application. This property of the HTTP Corba application server system seen here also allows targeted use in test systems. In particular, the direct communication test via a website is possible. Overall, this minimizes development times.

Claims

Title: Dynamic database interface Applicant: Informationsverarbeitung Leverkusen GmbH (IVL), Overfeldweg 55, D - 51371 Leverkusen, BR Germany

1. Method for operating a dynamic database interface for communicating a database system application with a database system, which

(i) receives a parameterized database system function call for the database system coded in XML format by the database system application,

(ii) if possible, convert this into a format compatible with the database system,

(iii) sends the corresponding parameterized database system function call to the database system, as far as possible, coded in a format compatible with the database system,

(iv) if a database system function call was made, receives a parameterized result from the database system coded in a format compatible with the database system,

(v) if a database system function call was made, the parameterized result is converted into XML format, and (vi) if a database system function call was made, the parameterized result received and encoded in XML format is sent back to the database system application.

2. Method for operating a dynamic database interface according to claim 1, characterized in that it receives the parameterized database system function call for the database system in XML format from the database system application in such a way that, in addition to the respective parameter value or parameter values, it also identifies the Parameters, preferably a parameter identifier.

3. Method for operating a dynamic database interface according to claim 1 or 2, characterized in that it receives the parameterized database system function call for the database system in XML format from the database system application in such a way that, in addition to the respective parameter value or parameter values, it also contains information about the structure of the parameter.

4. A method for operating a dynamic database interface according to claim 1, 2 or 3, characterized in that it receives the parameterized database system function call for the database system in XML format from the database system application in such a way that it is next to the respective parameter value or parameter values also has information about whether the respective parameter is an export or an import parameter.

5. Method for operating a dynamic database interface 1, 2, 3 or 4, characterized in that it converts the parameterized result received by the database system into XML format and sends it back to the database system application in such a way that it is next to the respective parameter value or Parameter values also have an identification of the parameter, preferably a parameter identifier.

6. Method for operating a dynamic database interface 1, 2, 3, 4 or 5, characterized in that it converts the parameterized result received by the database system into the XML format and returns it to the database system application. sends that in addition to the respective parameter value or parameter values it also has information about the structure of the parameter.

7. The method for operating a dynamic database interface according to claim 1, 2, 3, 4, 5 or 6, characterized in that it converts the parameterized result received from the database system into the XML format and sends it back to the database system application in such a way that it In addition to the respective parameter value or parameter values, it also has information as to whether the respective parameter is an export or an import parameter.

8. The method for operating a dynamic database interface according to one of claims 1 to 7, characterized in that it checks before step (iii), preferably using its own implementation database, whether the database system function call received by the database application on the part of the database system is actually available for calling, and in the negative case sends an error message encoded in XML format back to the database system application.

9. A method of operating a dynamic database interface according to claim 8, characterized in that it checks before step (iii), preferably using its own implementation database, whether all the parameters necessary for the execution of the database system function call by the database system are also required by the database. Application were received, in the negative case it sends an error message encoded in XML format back to the database system application.

10. The method for operating a dynamic database interface according to claim 9, characterized in that it determines which parameters received from the database system application during the implementation in step (ii), preferably using a separate implementation database, particularly preferably using an identification of the parameters to which parameters compatible with the database system must be implemented.

11. A method of operating a dynamic database interface according to claim 10, characterized in that it determines which parameters received from the database system are assigned to which during the implementation in step (v), preferably using a separate implementation database, particularly preferably using an identification of the parameters parameters compatible with the database system application must be implemented.

12. Method for operating a dynamic database interface according to one of claims 1 to 11, characterized in that a geographic information system (GIS) is used as the database system application and at least one structural database system, preferably with a relational database, is used as the database system, in which structural, i.e. Non-spatial data of objects from a geodatabase that is also associated with the geographic information system are stored, the geodatabase being organized according to the spatial position of objects, preferably as a quad tree or relational, and therein at least the spatial data, preferably the geometric and / or geographic data of the Objects are stored, in addition to the spatial data for the respective objects, reference information associated with the respective object is also stored in the geodatabase, which assign the spatial object data stored in the geodatabase to at least one object in the structure database system, and furthermore when an object is accessed Geo-database automatically creates the assignment to the assigned objects of the structure database system via the dynamic database interface by means of the reference information stored here and thereby also access to the data stored here structural data belonging to the object of the geodatabase is allowed.

13. The method for operating a dynamic database interface according to claim 12, characterized in that, in addition to the structural data for the respective objects, back-reference information associated with the respective object is also stored in the structural database system, which is the structural object data stored in the structural database system for at least one object assign in the geodatabase and which are accessed from the geographic information system via the dynamic database interface.

14. A method for operating a pool manager for connecting a database system application to at least one database system by means of at least one dynamic database interface, which is operated according to the method according to one of claims 1 to 13, wherein the pool manager requests from the database system application for communication with receives the database system or the database systems and then for the requesting database system application an instance assigned to the requesting database system application itself or a communication module is generated or assigned with at least one associated dynamic database interface.

15. The method for operating a pool manager according to claim 14, characterized in that it receives the communication request by the database system application in XML format and evaluates a data packet part, preferably a so-called connect string within the XML data packet, which identifies the database system or the database systems , to which the communication is to be set up, the instance of itself or the communication module being generated or assigned with at least one associated dynamic database interface, which serves or serve to communicate the database system application with the requested database system or database systems.

16. The method for operating a pool manager according to claim 15, characterized in that the pool manager generates or assigns a Corba module, preferably a Corbaserver module, as an instance of itself or as a communication module, so that communication with the database system application and / or the respective associated dynamic database interface or database interfaces is processed directly or indirectly using the Internet Inter Object Request Broker Protocol (IIOP).

17. A method for operating a pool manager according to claim 16, characterized in that a Corbaserver module is generated or assigned as a Corba module, which is thus create that it communicates with the database system application through at least one intermediate CORBA instance.

18. A method for operating a pool manager according to claim 17, characterized in that the pool manager generates or assigns a Corbaclient module as an intermediate instance to the Corbaserver module generated or assigned, which data sent by the database application in XML format into the Internet Inter Object Request Broker protocol (IIOP) for the Corbaserver module converts and conversely converts data received by the Corbaserver module in this protocol so that it is sent to the database application in XML format.

19. The method for operating a pool manager according to claim 17 or 18, characterized in that the pool manager for a Corbaser application module generated or assigned a Corba application server module as Corbaclient module or a Corbaclient module associated with or assigned, which of the database Application converts data sent using an intermediate transmission protocol, preferably using TCP / IP protocol in XML format, into the Internet Inter Object Request Broker Protocol (IIOP) for the Corbaserver module and conversely converts data received in this protocol from the Corbaserver module that they are sent to the database application in XML format using the intermediate transmission protocol, preferably the TCP / IP protocol.

20. Method for operating a pool manager according to one of claims 14 to 19 insofar as these are related to claim 12 or 13, characterized in that an SAP (protected trademark) GIS Smallworld (protected trademark) and as a database system for implementing the structural database - System is provided.

21. Dynamic database interface system, characterized in that it has a data processing system with a processor and a memory, which is set up in terms of programming so that it works according to the method for operating a dynamic database interface according to one of claims 1 to 13.

22. Pool manager system, characterized in that it has a data processing system with a processor and a memory, which is set up in terms of programming so that it works according to the method for operating a pool manager according to one of claims 14 to 20.

23. Pool manager system according to claim 22 insofar as it relates to one of claims 17 to 20, characterized in that it has at least two data processing systems connected to one another via a communication channel, each with at least one processor and one memory, the first being set up in terms of programming technology, that a pool manager is operated on it, which operates according to the method for operating a pool manager according to one of claims 17 to 20, and the pool manager generates the Corbaserver module assigned to the requesting database system application with at least one associated dynamic database interface on the second data processing system or assigns, it handles its communication with the database system application via the CORBA intermediate instance, preferably the Corbaclient module, which is located on the first data processing system.

24. Computer program which has instructions which are set up to carry out the method according to one of claims 1 to 13.

25. Computer program which has instructions which are set up to carry out the method according to one of claims 14 to 23.