|
Blogs
In large implementations with multiple teams working on the same development box with a fixed transport route, more often there are collisions between the transports involving common objects. This is especially true for large implementations with multiple rollout strategy where the system is already live and there are simultaneous releases of transports by users belonging to different groups. Coupled with the fact that these transports can be imported into subsequent systems at certain times which only the BASIS team is aware of, there needs to be a process for notifying the failed transports to the owners to take corrective action. This program is an attempt to bridge such confusion arising out of such problems. Problem statement: Important time wasted in analysing a whole bunch of transports when mass import is happening to subsequent systems. Difficult to co relate the correction transport with original failed transport Systems like Quality testing and Integration can be in an inconsistent state for a long time due to syntax errors affecting a number of other users work. Without immediate notification coupled with the fact that transport owner might not be present at the given moment, it becomes difficult to trace who is responsible for the development. Creeping of transport failures ( and hence an inconsistent system state) in systems ahead of Quality in the transport chain Solution: 1. Immediate notification of the transport errors in Quality and other systems to the transport owner and the team lead 2. Create a process of Defect management for every transport failure 3. Import all the transports in the same order as imported into ECQ and make sure that the corrected transports are also present in the import queue. This can be better achieved by having the failed transport number present in the description of the correction transport How to send notifications? Create the program Z_ALERT_TRANSPORT_STATUS (Can be assigned a transaction code if needed). It can achieve the following 1. Notify the transports which are imported into the subsequent systems like Quality, Integration and Production to the transport owner as he might be unaware when specific imports will occur for these systems 2. Serve as one single report to monitor errors (for BASIS) across subsequent systems right in the development system 3. Send out Alert mails to individual transport owners about their transports and their statuses 4. Send out an Alert to Team leads (Based on configuration in OOCU_RESP) about their teams transports status and to take corrective action if necessary. How this Program can be used? 1. Immediate Notification of status of a transport imported into subsequent system 2. Can be scheduled as a background job after the import job in a specific system to import the transport queue is scheduled or can be scheduled as a nightly job (Time zone issue!!) 3. All jobs can be scheduled in 1 system only. This program need not be transported to subsequent system as can be run/scheduled from/in Development system itself. Program Details and Functioning: Diagram1. Selection screen of Program Report Output Diagram 2.2 Report Output Team Alerts:Why team Alert and how is it useful 1. More often the transport owner might be on leave or might have left the project. To take care of these transports, the team leader needs to be notified. 2. Defect creation process: A process for identifying each transport layer and correcting them can be taken through the some defect management system to ensure the visibility of failures. Please note that this mechanism is not an alternative or substitute to proper analysis that should be made by the transport owners prior to release but acts as a feedback on their analysis. Below diagram depicts a possible process that can be followed Assumptions: 1. The SM59 destinations are maintained such that the first 3 letters correspond to the system ID. 2. For a transport step, any code a. Greater or equal to 8 is treated as ERROR, b. 4 as Warning and c. 0 as success. Implementation Details: There are 4 basic parts to this solution with an additional step to implement the Team Alert concept. 1. Selection of the delta set of transports which need to be picked up based on when they were imported into a subsequent system. This can be picked up in 2 ways. a. Based on the information of last changed timestamp for each of the log files created in application server for each transport. However there are some drawbacks like i. The file path where each of these log files is most likely different based on the operating system. For UNIX it might generally be in directory /usr/sap/trans/cofiles/. And there is a correlation between the file name and the transport number such that the file name can easily be derived. ii. We cannot know by looking at this last changed timestamp information of the file whether this change was due to import into which specific system iii. Need to use C Function calls to get to know the file meta data which can be a bit complex. b. Establish the last changed date of the transport by looking up table E070 in the remote system. This is a client independent table so any client in the remote system can be used as a RFC destination. Since this is a cleaner way the current code is selecting delta transports based on the above logic. 2. Get the transport statuses for each of the transports selected in the above step 3. Send alert/mail to the transport owner using the Alert Category. If you are not familiar with creation of Alert category you refer to step 3 in setting up Team Alert section below or write code to send user e-mail using any one of SAP provided FMs 4. Write a report using ALV grid display (classes) Step 1:Create a Function group ZS_TRANSPORT_MGMT with a Function Module Z_GET_TRANSPORT_LOG as given.This is a copy of the FM TR_LOG_OVERVIEW_REQUEST except that the last part of the display of the log is commented and some export parameters are inserted. Please copy the top include of the Function group TR_LOG_OVERVIEW and include RDDKORRI in your custom Function pool Step 2:Create structures for report output and mail output. Please create appropriate Data elements mentioned below starting with Z. Structure Name: ZS_TRANSPORT_LOG_INFO
Structure Name: ZS_TRANSPORT_MAIL_INFO
Main Program: Z_ALERT_TRANSPORT_STATUS Create Screen 100 with the custom control with name CO_GRID_CONTAINER for report display.If you dont want to set up the Team Alert comment out the statements accessing table ZS_PROJ_USER and the PERFORM send_alert in the main program below How to set up Team Alert ? For Team Alert concept an additional 2 tables are required or the team name can be maintained in any field or User master. In this specific case I have created 2 tables for this purpose and these are used in the program above Database Table Name: ZS_PROJ_TEAM
Database Table Name: ZS_PROJ_USER
Four steps need to be done in order to set up Team Alert in Development System where the job is scheduled. 1. Create a Team name with Description a. Go to SM30 and give the table name as ZS_PROJ_TEAM b. Insert the Team name and description if not already present. c. Go to SM30 and give the table name as ZS_PROJ_USER d. Insert entry for each user for the team to which they belong e. You can also insert the team members who have left the programme to track their transports belonging to you team. 2. Transaction: PFAC. Create a Rule of category R Agent Determination : Responsibilities a. Create a container element with PROJ_TEAM_NAME 3. Create an Alert Category from transaction ALRTCATDEF a. Give appropriate description b. Create 4 container elements i. TRANSPORT_LIST of type ZS_TRANSPORT_MAIL_INFO. ii. FROM_DATE of type SY-DATUM iii. TO_DATE of type SY_DATUM iv. PROJ_TEAM_NAME of type PROJECT_TEAM_NAME. c. Specify the rule created in Step 2 above and bind the container element PROJ_TEAM_NAME between the Alert category and Rule. d. Give appropriate content in the long text and title so that these apper on the alert displaying the Transport List with status. 4. Maintain Responsibilities in transaction OOCU_RESP. a. Give rule number XXXXXXXX present in the alert category you have defined and click on change(Pen) button Diagram 2.4 - Maintain Responsibilities I Create a responsibility for the Alert ..ideally each team can create a responsibility for themselves Diagram 2.5 - Maintain Responsibilities - II 5. Create a User (Ideally the Team leader) for this responsibility who will receive notification about the transport statuses for each of the team members Diagram 2.6 - Maintain Responsibilities - III Possible Enhancements: 1. At present this program has been designed keeping in mind that only the subsequent systems in the Transport layer and not client specific imports. This can be enhanced to check the status codes based on individual clients. Hint:Check structure ls_request in FM Z_GET_TRANSPORT_LOG 2. Make this as one consolidated report to monitor and review transports across SAP systems landscape from just one SAP client. i.e. Monitor and Alert transport statuses for users across systems like SCM, SRM, CRM, BW and XI just by executing or scheduling the job in SAP core development system as long as relevant SM59 destinations are maintained for each of these systems in Dev box. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Showing messages 1 through 2 of 2. | ||
|
|
||
| Titles Only | Main Topics | Oldest First |
regards,
Nigel James
| Showing messages 1 through 2 of 2. |