Patent Application
20080163200
The present invention relates to methods and systems for distributing software between systems. More particularly, the invention relates to methods and systems for distributing software that may comprise changes, including changes that may concern software components as well as data.
Enterprises and organizations of any size often rely on software applications to conduct business. To meet the specific needs of such enterprises and organizations, the built-in functionality and predefined data of software components, and/or the data itself of a software application, may be changed. The process of changing software components and/or data is referred to as customization.
Customization of software components and/or data may usually not, however, be performed while the software system is running. Thus, enterprises may use at least two systems during customization. For instance, the customization may be initially carried out on the first system. This system may be denoted as the customization system. The second system, on the other hand, may be denoted as the productive system. In such an arrangement, changes are transported from the first system to the second system only after those changes have been successfully tested on the first system.
Other arrangements may use at least three systems—a customization system, a quality assurance system, and a productive system. Again, the customization system may be used to customize the applications. The quality assurance system, however, may be used to test the changes to determine that they work correctly. The changes are thus transported from the customization system to the quality assurance system and, then, from the quality assurance system to the productive system. The transport of changes from a first system to another system is referred to herein as software distribution.
Typically, enterprises and organizations use many different software applications. If these software applications are customized centrally on a customization system—for example by a team of administrators—a number of different applications may be distributed from the customization system to at least a further system. Normally, different software applications provide their own distribution tools. Therefore, a number of different distribution tools and distribution methods may be necessary to distribute different software applications. However, by using different distribution tools, there exists a higher risk of making mistakes during the software distribution process.
Accordingly, there exists a need to simplify the distribution of software and data involving different software applications.
Systems and methods consistent with the invention relate to the distribution of software. According to one exemplary embodiment, a method for distributing software from a first system to a second system comprises determining a software object to be transported, where the software object is part of the software to be distributed. The method provides source information for the software object and creates, on the first system, a transport request which comprises an object list. The method defines, on the first system, a transport container and includes the source information for the software object in the transport container. The method also includes the transport container in the object list and provides the transport request to the second system.
Other objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and together with the description, serve to explain the principles of the invention. In the drawings:
The following description refers to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or similar parts. While several exemplary embodiments and features of the invention are described herein, modifications, adaptations and other implementations are possible, without departing from the spirit and scope of the invention. For example, substitutions, additions or modifications may be made to the components illustrated in the drawings, and the exemplary methods described herein may be modified by substituting, reordering, or adding steps to the disclosed methods. Accordingly, the following detailed description does not limit the invention. Instead, the proper scope of the invention is defined by the appended claims.
Each of systems 10, 20, 30 may represent a heterogeneous system which may comprise computer hardware and computer software. For example, the computer software may implement an enterprise relationship management system or a supply chain management system. Further, systems 10, 20, 30 may be connected by a communication network (not shown) such as an Ethernet, Wireless LAN or other appropriate network. In a further embodiment of the invention, only customization systems 10 and quality assurance system 20 may be connected by a communication network. In such an embodiment, productive system 30 may be separate from the systems 10, 20 for security reasons.
As shown in
As noted above, customization may take place on customization system 10. Customization may comprise, for example, developing new software applications, modifying existing software applications, developing new software modules, modifying existing software modules, generating new master data records and/or changing existing master data records. Further, customization may also comprise modifications to user master data and application data.
Systems 10, 20, and 30 may implement any type of software application. For instance, systems 10, 20, and 30 may include software applications such as native Windows™ applications, JAVA based applications and/or various database management systems. Software applications on systems 10, 20, and 30 may also comprise operating systems for common computer systems as well as operating systems for software controlled devices, such as industrial robots. Further, systems 10, 20, and 30 may include an entire software application or only a part of a software application. A software application or a part of a software application may be referred to as a software object. A software object may also contain master data, user data, application data and/or program code.
As shown in
A further embodiment of the invention may comprise only two systems, namely customization system 10 and productive system 30. In such an arrangement, customization system 10 may be used for customization as well as for quality assurance testing, and productive system 30 may be used for actual productive activities.
During a first phase, the software applications located on customization system 10 are customized.
During the export, changed software modules and/or master data records may be stored (as shown by arrow 45) into a data file 60 which may be located on a storage device. For the purpose of storing the software objects into data file 60, the export mechanism may evaluate the object list. As described above, the object list may provide information about the source location of the software modules to be transported. The source location may be one of a ‘stored in database’ and ‘stored on file system’ location. Considering this information, the export mechanism may copy the software modules and/or master data records from a database into the data file or from a file system into the data file. Thus, the export mechanism may create a single data file which may contain a plurality of software modules to be transported and/or a plurality of master data records to be transported.
Additionally, the object list may be transported (as shown by arrow 48) from customization system 10 into import buffer 50. Thus, in the exemplary embodiments, data file 60 may be not transported from system 10 to system 20. Data file 60 should, however, be accessible by both quality assurance system 20 and customization system 10.
During a second phase, the changes which have been imported into import buffer 50 may be imported into quality assurance system 20. As shown in
Yet further, within the second phase, the verified changes are transported (shown as arrow 49) from the import buffer 50 to the import buffer 51 which belongs to productive system 30. If productive system 30 has no access to the storage device where data file 60 is stored, then data file 60 may be transported (as shown by arrow 90), e.g. by storage means such as compact discs (CD), digital versatile discs (DVD) or other means to productive system 30. The transport of data file 60 may also be carried out by a special software program which may be adapted for copying data files from a source location to a target location, whereby the special software program may have access to the source location and the target location. The transported data file is shown by item 61 in
As shown in
Because systems consistent with the invention may transport a software object to systems other than a quality assurance system, however, the description below refers to the destination of a transported software objects as a target system. In
The software objects to be transported may be located on different storage or processing sources of customization system 10. For example, master data records may be stored in a database management system, new software modules may be stored on a file system as well as in a database management system, and JAVA modules and applications may be stored as JAVA archives on the file system. Systems and methods consistent with the invention may, though, transport any type of software object, including .NET modules, irrespective of the storage or processing source.
The distribution system may then provide source information for the determined software objects (step 100). The source information may, for example, be one of ‘stored on file system’ and ‘stored in database’.
The distribution system may then generate a transport request or, if a transport request was already created before, select a transport request (step 101). A transport request may include an object list identifying the customized software objects, as well as header information containing, e.g., administrative information.
In one embodiment, a transport request may be created automatically for each software object to be transported. However, other embodiments may use an existing transport request. In any case, a user may request the generation of a new transport request for the software objects. Further, if there already exists a transport request containing a particular software object, the distribution system may automatically select that transport request and update the particular software object in the transport request with the corresponding changed software object.
The distribution system may then define or create a transport container (step 102). The transport container may hold a key of the software object to be transported and source information as described above. The key may be represented by a pointer to the respective software object. The key of the software object determined in processing step 100 may then be inserted into the created transport container (step 103). In one exemplary embodiment, each transport container may hold exactly one key. However, additional information about the software object to be transported may also be stored within the transport container, such as the type or size of software object. Thus, transport containers may hold information such as source location and/or key about different kinds of software objects, e.g. JAVA archives or .NET objects. Further, information about master data records may be stored within a transport container. If information about master data records coming from a data base are stored within the transport container the stored source location information may be ‘stored in database’ together with detailed description of data base, e.g. the instance of the data base, the source relation of the data record, etc.
Each created transport container may further comprise instructions specifying how the included software objects have to be handled during the distribution process. For example, the instructions may comprise methods or references to methods which are executed before the software objects are transported or copied into the data file. These methods may include compressing the software objects for the purpose of saving storage space or bandwidth of the communication network. Methods which are executed before the software objects are transported or exported are denoted as ‘before-export-methods’.
Furthermore, the instructions may also comprise methods which are executed after the software objects are imported into the target system. These methods may include, for example, decompressing the software objects. Methods which are executed after the software objects have been imported are denoted as ‘after-import-methods’. Generally, after-import-methods may also be used to activate the imported software objects within the target system.
Returning to
Finally, the transport request is provided for further use, e.g. for importing into the target system (step 105). The changes which have been performed during the customization are thus exported. The exporting may store the software objects in a single data file on a file system. A reference to the single data file may be created and inserted into the transport request. The file system may belong to the system where the changes have been made or may be an external file system or data storage device such as a DVD or CD. Thus, the data file may contain a number of different software objects, which, as described above, may be compressed before being copied into the data file.
In exemplary embodiments, processing step 105 may further include two sub-steps: locking the transport request, and exporting the software objects. As part of the locking sub-step, distribution systems consistent with the invention may lock the transport request, such that, e.g., the transport request cannot be changed anymore. As part of the exporting sub-step, systems consistent with the invention may copy, into the single data file, the software objects for which information is stored within the object list.
Providing the transport request may also include importing the transport request into the import buffer of the target system (see, e.g., arrow 48 and buffer 50 in
During customization, all changes to the software application may be recorded in an object list 31 which may have a number of transport containers. Each transport container may store information about exactly one software object to be transported from source system 10 to target system 20. As shown in the example of
After releasing the changes, e.g., releasing the software objects to be transported from customization system 10 to quality assurance system 20, the software objects are exported 45 via interface 12 into the single data file 60 which is located on file system 5. The single data file 60 may be shared by both system 10 and system 20. When the software objects have been exported successfully, the transport request may be automatically added 48 to import buffer 50 of the target system 20. Thus, import buffer 50 may hold a list of transport containers which store information about the software objects 60 to be imported into target system 20. The stored information may also include information as to whether the software objects may be imported into the database or into the file system of target system 20. Due to security reasons, the import mechanism may be triggered manually.
During the import, the software objects which are stored with the single data file 60 are read and copied 46 into target system 20. For this purpose, software application 11′ which corresponds to source application 11 may provide an interface 12′ which is adapted for obtaining the software objects. Furthermore, interface 12′ may provide functionality for activating the imported software modules A′ and B′. The activating functionality may be one of the above mentioned after-import-methods. Further, an after-import-method may call an activating method provided by interface 12′. The software module A′ corresponds to the software module A. The database B′ corresponds to the database B.
As described above, database B may store master data records which may be changed during the customization step. Thus, copying software modules into target system 20 may comprise inserting master data records into a database B′.
Further, the distribution system may perform the after-import-methods as a last step of the import or after each imported software object. Finally, after the software objects have been imported and activated successfully, they may be deleted from import buffer 50. In a further embodiment of the invention, successfully imported software objects may be marked as “already imported” in order to prevent a further import of the objects.
For purposes of explanation only, certain aspects and embodiments are described herein with reference to the components illustrated in
Further, the sequences of events described in
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
