TransportManager Version 5.0

Transcription

1 TransportManager Version 5.0

2 Contents TransportManager...3 Common Prerequisites...3 Special Prerequisites...3 System Landscape...3 Alternative Transport Methods...3 TMS Configuration...3 Functional Description...3 Technical Basics...3 Definition of Transport Levels...4 Definition of Destinations...4 Definition of User Groups...4 Definition of Projects...5 Definition of Critical Objects...5 Definition of Critical Aspects...5 The Collision Check...6 Definition of Dependency Information...6 The Workflow...7 Package definition...7 The Transport Control...8 Scheduling of Imports...9 Communication Interfaces...9 Tracking/Reporting...10 Backup...10 Licencing...11 Services...11 Software Support and Maintenance...11 Contact...12 As of Copyright REALTECH 2006 Page 2 of 12

3 TransportManager Common Prerequisites The prerequisites for the use of TransportManager are described in the document System Requirements. Special Prerequisites System Landscape All systems, managed by one TransportManager or sending their tracking information to a central tracking system, must have a unique SID. All systems, managed by one TransportManager, have to be reachable through an Remote Function Call (RFC). The SAP tool tp has to be able to connect to the database of a system from all of its application servers. The SAP tool tp has to be able to send an event to a SAP System from all of its application servers. TransportManager can manage transports between systems belonging to different SAP transport domains. Moreover he supports heterogeneous platform environments (NT, UNIX). Alternative Transport Methods When using TransportManager, the SAP standard means (TMS, tp) can be used in parallel for a selective import of single requests. The usage of Import all or Import all (project xyz) is not allowed because TransportManager maintains the TMS import queue himself and thus there would be unpredictable interferences. External transports can be tracked, too using a scanner. A synchronization of the workflow position of these transports is not possible. TMS Configuration TransportManager supports system landscapes with and without extended client transport control (CTC=1, CTC=0). Functional Description Technical Basics TransportManager is based on SAP s Transport Management System (TMS) architecture. It can transport all object types that are recorded within change requests and that can be distributed via TMS. The following change request types are supported: Customizing requests Workbench requests Transports of copies Relocation of objects without development class change As of Copyright REALTECH 2006 Page 3 of 12

4 Relocation of objects with development class change Relocation of a complete development class REALTECH assures the future support based on the TMS technology. Definition of Transport Levels Systems and clients, which are considered to be equal from a transport technical view, are assigned to a transport level. In the workflow, an approval is always done for all systems of the current transport level and not only for a single system of the level. The number of possible transport levels is limited to 25. There is no restriction concerning the name of a level. Its length is limited to 27 characters. Definition of Destinations A destination defines the sum of all systems and clients that should be delivered in future by a certain change request. The number of possible destinations is not limited There is no restriction concerning the name of a destination. The length is limited to 20 characters. Within the same destination, one system can be assigned to only one transport level. The number of systems and clients that is assigned to one transport level of a destination is not limited. At least one system has to be assigned to at least one transport level. For each transport level you can specify the number and type of necessary approval steps. The following configuration options are available: Technical approval Technical and content approval Technical and 2. content approval Technical, content and 2. content approval By defining and assigning user groups up to 9 sub approval steps can be defined for each approval step Definition of User Groups Users, which reflect a similar or equal role within the transport workflow, can be assigned to a common user group. The number of possible user groups is not limited There is no restriction concerning the name of a user group. The length is limited to 30 characters. One user can only belong to a maximum of one group As of Copyright REALTECH 2006 Page 4 of 12

5 A group can have unlimited users assigned Definition of Projects Projects are used to group change requests. They can be further used as a filter for the workflow monitor. Just as transport level and destination, project is an authorization field of TransportManager s authorization object. Thus projects offer a more flexible assignment of certain users or user groups to certain workflow steps. The number of possible projects is not limited There is no restriction concerning the name of a user project. The length is limited to 20 characters. At least one destination has to be assigned to a project For each transport level within a project, you can assign up to 9 user groups for the technical and 9 user groups for the content approval. It is also possible to define a certain approval order between these user groups. Definition of Critical Objects In order to support the approvers, it is possible to define a list of critical objects. During each approval step, the affected change request will be checked against this list. The number of possible critical objects is not limited All object types of the SAP transport system and their sub types can be defined (Example: R3TR PROG and LIMU REPS ) Critical Objects can be defined globally or system specific. System specific settings overwrite global settings. You have to assign a severity to each critical object ( Warning or Error ). If a critical object is detected during approval the further steps of the workflow are determined on the base of that severity. Definition of Critical Aspects Beside critical objects, there is a predefined set of other more common critical aspects that can be checked during an approval step: XPRAs Through integration of XPRAs into an object list of a change request, each developer is able to start any report he wants in production. Because this represents a potential security leak, XPRAs can be checked. SAP objects If there are SAP objects in a change request, we have to deal with modifications. Modifications are often very critical and thus the check of critical objects can be activated. Objects not original If objects are transported which are not a original of the TM System and if the original of the object is located on another system of the customer, the change to the transport object should be done equally to the original to keep both in sync. Tables without key specification If SAP tracks customizing changes to a change request, it only inserts the affected key ranges. If the As of Copyright REALTECH 2006 Page 5 of 12

6 complete table content is specified in the object list, the request was created manually. Because transporting complete tables represent a high risk of inconsistencies, this aspect can be checked. Application data Because of consistency reasons, application data should never be transported. No documentation If you want to force the developers to maintain the request s documentation, you can enable this check Warnings/Errors during export or test import If errors or warnings had been occurred during these steps, that might be relevant for the success of further imports. Requests with minimum export date Using this option, you can avoid that a request that was exported before the entered date is imported accidentally. Critical aspects can be defined globally or system specific. System specific settings overwrite global settings. You have to assign a severity to each critical aspect ( Warning or Error ). If a critical aspect is detected during approval the further steps of the workflow are determined on the base of that severity. The Collision Check In order to avoid mismatch problems, you can activate the collision check during each approval step. It can be customized, if colliding objects are always displayed when approving or only if the mean a potential mismatch problem. In addition, it can be specified if in case of mismatch problems only super users are allowed to approve. These global parameters can be overwritten for some types of relationships between change requests. Collisions are detected between requests: which contain partly the same objects which contains type and sub type of the same object R3TR R3TR PROG ZTEST >>>> LIMU REPS ZTEST FUGR ZFUGR >>>> LIMU FUNC ZFUNC table content with overlapping key ranges The only attributes that are used to categorize a change request as overshooter is its reference timestamp and its position in the workflow. If, during the approval of one request, the check detects an older request containing colliding objects, which himself has not yet reached the same position in the workflow, an overshooter is assumed. This concept avoids that younger versions are approved and thus imported before older versions of an object. Definition of Dependency Information Dependency information can be defined between change requests. TransportManager differs between five kinds of dependencies: Successor: The dependent request has to be imported after the current request Predecessor: The dependent request has to be imported before the current request As of Copyright REALTECH 2006 Page 6 of 12

7 Companion: Current and dependent request have to be imported together Accompanying Successor: The dependent request has to be imported after and together with the current request Accompanying Predecessor The dependent request has to be imported before and together with the current request Dependency information is checked during the approval process and is considered while creating the system queues. The Workflow TransportManager has implemented his own workflow. This workflow comprises all approval steps that are necessary to release a request for the import into other systems. The assignment of users to roles is only based on SAP s standard authorization concept and its tools (profile generator, etc). The workflow for a change request is started either manually or using a periodic batch job. It is also possible to use an implementation of an SAP Business Add-In, that is shipped with the CD. The content as well as the technical approval can be extended up to nine approval steps with a predefined order, depending on the project and user group settings. Approvals can be revoked in reverse order of the approvals. Therefore, users need the same authorization like for the approval itself. All workflow activities are logged to SAP standard files. These files can also be read from SAP transactions SE01, SE09 and SE10. One approval step can only be done at once for all systems that belong to the same transport level within the destination, assigned to the change request. On the one hand, this seems to be a decrease in flexibility, but on the other hand, this rule guarantees the synchronization of all systems, belonging to the same transport level. Package definition Several change requests can be grouped within a package. The order of the requests within such a package can be defined individually. This order also specifies the import order. Requests that are part of a package cannot be approved separately. This rule guarantees that always the whole package moves through the workflow. Basically a package behaves and is handled like a request. The following options are currently not available for packages: Automatic status switch Scheduling for a reserved date that deviates from the regular schedule dates Requests can only be put into a package if: they are assigned to the same project as the package they are assigned to the same destination as the package they reside in the same transport level and status as the package As of Copyright REALTECH 2006 Page 7 of 12

8 The Transport Control In general, TransportManager is technically based on SAP s TMS, respectively the underlying transport tool tp. There are two different methods to start imports. Both methods call the transport tool tp via RFC call on the target system. The following rules are valid for both methods: These requests are imported sequentially as single imports ( Single Mode ) or as a bundle ( Subset Mode ). If imports are executed in Subset Mode, the extended client control must be active on all target systems (CTC=1). If the extended client Control is disabled in SAP s TMS, the complete import will be repeated for each target client If the extended client Control is enabled in SAP s TMS and change requests that were created on a certain system are imported back into different clients of that same system, only the client dependant part will be re-imported. For all other systems the behavior is like with no extended client transport control. Every change request will be explicitly add to the import queue of the target system as well as it will explicitly be deleted after the import (Depending on the SAP basis version, there is no deletion afterwards) Additional transport options will be taken from SAP s transport control file. System queue The system queue is the standard mean for importing change requests. For each system that is part of a destination, at least one system queue is managed. If a system is assigned to several transport levels, there exists a system queue for each of the transport levels. The system queue can be scheduled (e.g. periodically), using TransportManager s Scheduling monitor. When an import job is starting all system queues are regenerated. The generated system queues are based on all new approved change requests. By using own stop mark logic, the synchronization of all systems belonging to the same transport level is guaranteed. If there are several new change requests to be imported, these are sorted by default in relation to their reference timestamp (which is normally equal to their export timestamp). This order can be overwritten through the definition of explicit dependencies. A system queue can also be started from the workflow monitor. In this case, there is no automatic queue generation. That has to be done manually before. If the import of a system queue is cancelled due to appropriate customizing settings within TransportManager, the behaviour of the system queue after specifiying to re-import failed imports is like this: a) Single Mode A request producing the interruption of the import queue is marked with a redo symbol. Requests that are marked with this symbol can be released for re-import at any time. The next import run of the queue will consider these requests again. b) Subset Mode All requests of the cancelled import run will be marked as candidate for re-import. If you try to prepare one of these requests for re-import, all requests of the failed import run will also be released for re-import. This is only possible up to the next import run that is cancelled due to the predefined return code. Afterwards, only requests of this import run can be released together for re-import. Requests of former cancelled import queues can only be released one by one afterwards. Personal queue For emergency and special transports, you can use the personal queue. Each authorized user can As of Copyright REALTECH 2006 Page 8 of 12

9 manage an own user related queue. He can feed this queue with any number of requests and for any number of systems (that belong to the destinations of these change requests). The only prerequisite is that these requests are completely approved for the affected systems. An import using the personal queue does not prevent a request from being imported again later with the next scheduled system queue. This principle should minimize the danger of mismatch problems. The personal queue can only be started from the workflow monitor and cannot be scheduled. The author of the queue is responsible himself for the correct order of the change requests inside. TransportManager can only support the right order by detecting an order that contradicts an explicit predefined order. You are not allowed to leave TransportManager while running your personal queue. Because the queue is started in an own task, this would be killed together with his parent task. Scheduling of Imports System queues can be scheduled, using TransportManager s own scheduling monitor. You can schedule single or periodic jobs. In principle, the import jobs can also be scheduled via SAP standard or any other external scheduling product supporting SAP. In that case, you should have a higher flexibility in scheduling your jobs. The view on these external scheduled jobs in the scheduling monitor is indeed limited. Communication Interfaces CCMS Optionally, alerts can be sent to SAP s CCMS. This can be done in the following cases: o Return code higher than 8, respectively 12 during import. This can be configured globally or system related. o Import jobs that did not start transports o The import scanner did not run longer than a predefined time interval theguard! ApplicationManager REALTECH s System Management solution theguard! ApplicationManager offers appropriate Managed objects for all CCMS messages SAP Office Optionally, partly executable documents are sent to the SAP office of the TransportManager server. The following options are available: o Mail to every user whose approval is requested next (executable document) o User specific notifications about executed imports in general or in case of import problems for: Own change requests Change requests, approved by the owner All change requests External Mail systems Within the MS Outlook versions that are supported by SAP, you can connect Outlook clients to SAP office via SAP-Mapi interface. If in addition a SAPGUI is installed on the front end the complete functionality of SAP Office is available in Outlook, too. Other external mail systems can only be connected using alternative means (SAP-Connect, SAP-Exchange, etc.). But this means do not offer the whole functionality of the SAP-Mapi interface. For example, you cannot log in to TransportManager from within the mail. In addition, a bi-directional synchronization between external mail system and SAP Office is also not possible. The implementation of the connection is not part of the standard installation that is offered by REALTECH. As of Copyright REALTECH 2006 Page 9 of 12

10 Tracking/Reporting The following data is recorded: Time of an approval Object of an approval Person, who approves Were critical objects/aspects ignored during approval List of violated dependency definitions This data is logged in SAP s action logs. Therefore, they can be accessed via SAP standard transactions SE01, SE09 and SE10. An accumulative analysis is not possible for this type of tracking data. In addition, every import activity is logged. For this type of data a long term analysis is available. The following items are logged for each import: Target system of the import Target client of the import Change request Author of the change request Date/Time of the import Return code of the import Short text of the change request Request type (Customizing, Workbench, etc.) TM project and current position within TM s workflow The tracking also includes data about imports, done without TransportManager. A prerequisite is that the Import scanner is scheduled on every target system. Further more, TransportManager offers a delta tracking to compare the import history of two systems. The result is always based on a certain time interval and thus is only complete if a reference timestamp with a delta of 0 exists (e.g. after a system copy). A subsequent determination of tracking information that originates from a time before using TransportManager is not possible. Backup If the TransportManager Server is going to be refreshed, e.g. via system copy, all TransportManager data should be saved and should be re-applied to the system afterwards. REALTECH provides the report /RTC/TM_BACKUP. This report saves all relevant data into a change request and exports it. Attribute data of type File is currently not saved and will be lost after system copy. As of Copyright REALTECH 2006 Page 10 of 12

11 Licencing Licensing of TransportManagementCenter is described in an additional document. Services The provided services are described in an additional document. Software Support and Maintenance See Service Description for Support Services. As of Copyright REALTECH 2006 Page 11 of 12

12 Subject to alterations and mistakes, 06/2006. Trademarks are: Windows, Windows/NT/2000, Outlook by Microsoft, SAP R/3 by SAP, theguard! By REALTECH system consulting GmbH. Contact Further information about REALTECH s software solutions: REALTECH AG Industriestr. 39c Walldorf Germany Tel Fax customer-services@realtech.com As of Copyright REALTECH 2006 Page 12 of 12