Abstract:
A method for setting change options of software systems of a software system landscape, wherein the systems are interconnected by logical transport paths for the transport of software services therebetween, the software services defining changes to at least one of the code and the data of at least one system, each system having change options that define changeability restrictions pertinent to the system, is described. The method includes providing an interface in each system, the interface allowing read and write access to the change options of the respective system from the outside of the system; providing a central control software system; providing an interface in the central system for communication with the interfaces of the systems; selecting a group of systems based on software service parameter data; and accessing the group of selected systems from the central system via the interfaces and centrally managing a change option in each system of the group.

Description:
CLAIM OF PRIORITY 
     The present patent application claims the priority benefit of the filing date of European Application (EPO) No. 04 025 503.6 filed Oct. 27, 2004, which is incorporated herein by reference. 
     TECHNICAL FIELD 
     This application relates generally to servicing of a software system landscape, and more particularly to a method for setting change options of software systems of a software system landscape and to a computer system with software systems having change options. 
     BACKGROUND 
     Complex software like applicant&#39;s SAP R/3 Release 4.5 (SAP) requires customization, e.g. selection of predefined functionality, and adaptation, e.g. addition of or amendment to functionality, as well as other servicing like program and data updates, cf. “SAP System Landscape Optimization” by A. Schneider-Neureither (Ed.), SAP Press, 2004, ISBN 1-59229-026-4, and “SAP R/3 Änderungs-und Transportmanagement” by Metzger and Röhrs, Galileo Press GmbH, Bonn, Germany, 4 th  reprint 2004, ISBN 3-934358-42-X. 
     Before such servicing may be performed, however, it has to be assured that the customizations, adaptations, program and data updates etc. are free of errors and integrate flawlessly into the software and data environment. In a factory for instance servicing errors are bound to result in costly workflow disruptions due to software malfunction or data corruption. 
     Such complex software may therefore be implemented in form of separate logical systems that together form a system landscape. A typical implementation of the aforementioned SAP software for instance may, cf.  FIG. 1 , comprise a development system  101  for customizing and development work, a quality assurance system  102  for testing functionality using representative test data, a training system  103  for training new users, and several productive systems  104 , e.g. each for a different factory, for actual productive use. Other or additional users and systems may be defined according to the particular requirements. 
     The logical systems are identical in large parts, function autonomously and may be executed on a single computer. The quality assurance system  102  for example resembles the productive system  104  in that it provides all the functionality, its present data and additionally special test data. New customization settings or adaptations may thus be thoroughly tested in the quality assurance system  102  without jeopardizing the productive system  104 . Likewise, the training system  103  resembles the productive system  104  in that it provides some of the functionality and special test data. A new user using the training system  103  may thus become accustomed to the functionality and observe the effect of his actions, albeit without disturbing the productive system  104 . 
     A transport management system connects the logical systems and serves to forward approved services to the next stage of the system landscape via logical transport paths  105 . A service may for example be approved in the development system  101  for export. It will then be forwarded to an input buffer of the quality assurance system  102 . Import into the quality assurance system  102  is approved manually by an operator. Once the service has been imported into the quality assurance system  102 , it will automatically be forwarded to an import buffer of the training system  103  and the productive systems  104  where it will be imported following manual approval by an operator. 
     Additionally, the operator may also effect a software service directly by manually performing customizations, adaptations, program and data updates etc. in a system. Such direct software servicing does not require a formal software service to be sent through the systems in the system landscape. 
     For the sake of system stability, in particular with respect to the productive system, it is desirable to restrict the changeability of one or more systems not only on a user or operator basis, but also on a system basis so that a user or operator who principally has sufficient authorization to approve an import or effect a change may be prohibited from doing so in a particular system. It is known to define the changeability on a system basis by change options that are kept within each system. If the change options of a system need to be altered, a sufficiently authorized operator has to log in into the system and alter the change options manually. This is time consuming, in particular when different systems are affected by different projects, and bears the risk of errors. 
     SUMMARY 
     In one aspect of the invention, a method is provided for setting change options of software systems of a software system landscape, wherein the systems are interconnected by logical transport paths for the transport of software services therebetween, the software services defining changes to at least one of the code and the data of at least one system, each system having change options that define changeability restrictions pertinent to the system, the method including providing an interface in each system, the interface allowing read and write access to the change options of the respective system from the outside of the system; providing a central control software system; providing an interface in the central system for communication with the interfaces of the systems; selecting a group of systems based on software service parameter data; and accessing the group of selected systems from the central system via the interfaces and centrally managing a change option in each system of the group. 
     In a further aspect of the invention, a computer system is provided comprising: a plurality of logical systems, each logical system having a change option that defines a changeability restriction pertinent to the system; an interface in each system for read and write access to the change options of the respective system from the outside of the system; logical transport paths interconnecting the logical systems to form a software system landscape and to transport software services between the systems, the software services defining changes to at least one of the code and the data of at least one system, a central control software system with an interface for communication with the interfaces of the logical systems; means for selecting a group of systems based on software service parameter data; and means for accessing the group of selected systems from the central system via the interfaces and for centrally managing a change option in each system of the group. 
     In a still further aspect of the invention, a computer program product is provided, the computer program product comprising on a storage medium a computer code that upon execution on a computer system performs the method according to the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Further embodiments of the invention are inferable from the following description and the claims. 
         FIG. 1  shows a system landscape of the prior art. 
         FIG. 2  illustrates a system landscape according to an example embodiment of the invention. 
         FIG. 3  illustrates a central control system according to an example embodiment of the invention. 
         FIG. 4  shows an example embodiment of the hardware of a computer system according to an example embodiment of the invention. 
         FIGS. 5 ,  6  and  7  each show a flow diagram of a method according to an example embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION 
     The example embodiment shown in  FIG. 2  illustrates an SAP R/3 Release 4.5 system landscape  200  with separate logical systems  201  that are here divided into a global part  202 , e.g. at a main development and production facility, and local parts  203   a ,  203   b ,  203   c , e.g. at other production facilities. 
     The global part  202  comprises at least a development system  201   a  for customizing and development work, a quality assurance system  201   b  for testing functionality using representative test data, and a productive system  201   c  for actual productive use. 
     The local part  203   a  comprises a development system  201   d  for customizing and development work of local adaptations to SAP, e.g. to meet different legal requirements if part  203   a  is localized in a different country than the global part  202 . The local part  203   a  further comprises a quality assurance system  201   e  for testing functionality using representative test data, a training system  201   f  for training new users, and a productive system  201   g  for actual productive use. 
     The local part  203   b  comprises a development system  201   h , a quality assurance system  201   j  and a productive system  201   k , but no training system. The local part  203   c  is a two system landscape comprising a development system  201   l  and a productive system  201   m  only. 
     The system landscape may be different according to the actual requirements. Fewer or more, different or differently connected or grouped systems  201  may be defined as needed. 
     The logical systems  201  are identical in large parts and function autonomously. The quality assurance system  201   j  for example resembles the productive system  201   k  in that it provides all the functionality, its present data and additionally special test data. New customization settings or adaptations may thus be thoroughly tested in the quality assurance system  201   j  without jeopardizing the productive system  201   k.    
     Each system  201  comprises an import buffer  204 . A transport management system connects the logical systems  201  and serves to effect software services across the system landscape via logical directional transport paths  205 . A service may for example relate to customization of a system  201 , e.g. a selection of predefined functionality in the system  201 , or an adaptation of a system  201 , e.g. an addition of or amendment to functionality, or to program and data updates or the like. 
     Each system  201  further comprises a set  206  of change options. The change options define changeability restrictions for the respective system and are stored in a table or data base entry. Preferably, each set  206  comprises at least one change option that restricts the changeability of the respective system for all users and operators irrespective of their level of authorization, so that a user or operator who principally has sufficient authorization to approve an import or effect a change may be prohibited from doing so. Each set  206  also comprises at least one change option that restricts the changeability of the respective system for certain users or allows changes by users having at least a predetermined level of authorization. 
     In particular, the set  206  comprises one or more of the following change options:
         A change option that, when set, inhibits any change to the respective system, irrespective of the user authorization. If changes to the system are desired, this change option needs to be cleared first.   A change option that, when set, inhibits any change to a particular part of the respective system, e.g. all or a part of the customization settings, program code, or the data, in particular those parts that provides fundamental functionality.   A change option that, when set, allows changes by software services, imported or directly effected, if they carry a particular identifier. The identifier indicates that the software service belongs to a particular project.   A change option that implements an authorization hierarchy for users and/or operators, defining which particular users respectively operators or which authorization level of users respectively operators is allowed to effect certain changes or types of changes, either by approving import of a software service or making changes to the system directly.       

     A system&#39;s change options may be directly set, cleared, defined, specified etc., e.g. managed, by a sufficiently authorized operator who is logged in into the system. 
     A system&#39;s change options may also be managed from the outside of the system. For this purpose, the set  206  of each system  201  is accessible via an interface  207 . The interface  207  allows access to the set  206  from a central system  301 , cf.  FIG. 3 , that comprises a compatible interface  302 . 
     The central system  301  holds a copy  303  of the sets  206  of all systems  201 . The copy  303  is available for read and write access to an operator of the central system  301 , and also to a program  304  in the central system  301  that manages the system service. The copy  303  is held up to date. If a change option of a system  201  is directly set, cleared, etc., the respective system  201  may inform the central system  301  of such change. Alternatively, the central system  301  accesses the systems  201  periodically to update the copy  303 . If no copy  303  is present, the central system  301  accesses a particular system  201  if its change options are required e.g. for display to the operator or for the program  304 . 
     The systems  201  of each part  202 ,  203   a ,  203   b ,  203   c  and the central system  301  may be located and simultaneously run in a single computer, but are distributed across separate hardware. The global part  202  and the local parts  203   a ,  203   b ,  203   c  each run on physically separate computer systems, which themselves may comprise different computers. 
     An example implementation of the local part  203   a  may comprise, cf.  FIG. 4 , a data base layer  401  for storing and retrieving business data like a factory inventory, employee data, sales figures etc. The data base layer  401  comprises one or more data base servers  402  and four data bases  403 , one for each of the systems  201   d ,  201   e ,  201   f  and  201   g.    
     Connected to the data base layer  401  by a suitable network  404 , e.g. a LAN, is an application layer  405  for execution of the software of the systems  201   d ,  201   e ,  201   f  and  201   g . The application layer  405  comprises one or more application servers  406 . 
     Finally, connected to the application layer  405  by a suitable network  407 , e.g. a LAN, is a presentation layer  408  for the graphical user interface (GUI). The presentation layer  408  may comprise dumb terminals  409 , Personal Computers  410  and/or wireless access devices  411  like PDAs. 
     The method according to an example embodiment of the invention is now described with reference to  FIGS. 5 ,  6 ,  7 . 
     An operator authorizes himself  501  in the central system  301  for use of the program  304 . The program  304  displays  502  the set  206  of a system  201  selected by the operator. The operator sets, clears, defines, specifies  503  a change option of the set  206 . The central system  301  then accesses  504  the respective change option to effect the operator&#39;s amendment in the system  201 . The central system  301  updates  505  the copy  303 . The operator may amend one or more change options before they are communicated to the selected system  201 . 
     The operator may also select a group of systems  201 . In this case, the program  304  preselects the group of systems  201  based on software service parameter data, see operation  601  in  FIG. 6 . In particular, the preselected group of systems  201  comprises all systems  201  affected by a particular project; in  FIG. 2 , only the systems  201   h ,  201   j  and  201   k  of local part  203   b  may belong to a project while the other systems do not, so that the preselected group is comprised of the systems  201   h ,  201   j  and  201   k  in this example. The operator may be given an opportunity to add or delete systems  201  from the preselected group or to confirm the preselection, thereby defining  602  a selected group of systems  201 . The operator then amends  603  a change option for all systems  201  of the selected group. The central system  301  then accesses  604  the respective change option in each system  201  of the preselected group of systems  201  to effect the operator&#39;s amendment. The central system  301  updates  605  the copy  303 . The operator may amend one or more change options before they are communicated to the selected system  201 . 
     In a further embodiment, the program  304  suggests predefined change options for a system  201  or group of systems  201 . The suggestions may be stored in a table and define standard values for a project, e.g. the adaptation of the systems  201   h ,  201   j ,  201   k  of part  203   b  to new legislation. Upon completion of the project, the program  304  suggests to undo the amendments to the change options performed at the beginning or a project. The program  304  may suggest amendments automatically and request an operator to log in and approve the suggestions. 
     Once the change options are configured, the systems  201  respond as follows to change requests. 
     Referring to  FIG. 7 , a software service is provided  701  using a transport request  208 . The transport request  208  is structured data that comprises an identifier  209 , e.g. DEVK900251, a project identifier  210 , general information  211  regarding the service, e.g. indicating that the service is a program patch, and service data  212 , e.g. a piece of program code for a patch. The transport request  208  is fed  702  into the import buffer  204  of one of the systems  201 , e.g. the quality assurance system  201   b  of the global part  202 . This initial feeding occurs from the development system  201   a  through a transport path  205 , but may also be effected manually as shown by path  211 . 
     At operation  703 , the system  201   b  detects the transport request  208 , accesses at least a part of its data, in particular the identifiers  209 ,  210  and the general information  211 , and decides  704  based on its change options in the set  206  how to proceed. Preferably, the options to proceed comprise one or more of the following: notifying  705  the operator that a software service is in the import buffer that may not be imported; forwarding  706  the transport request  208  to the next system  201 ; deleting  707  the transport request  208 ; requesting  608  the operator to approve the import. 
     Although the foregoing has been a description of an example embodiment of the invention, it will be apparent to those skilled in the art upon review of this disclosure that numerous variations and modifications may be made in the invention. For example, instead of using SAP R/3 Release 4.5, other SAP and non-SAP systems may benefit from the invention.