Scribd
Upload
235 views3 pages

Enforce Transport Naming Conventions or Create A Sign Off Procedure Using CTS - REQUEST - CHECK

The document discusses using the Badi CTS_REQUEST_CHECK to add custom validation and processes around the creation and release of transports. It provides examples of how to check for valid naming conventions when creating transports and implement a sign-off process requiring senior developers to approve releases. The Badi allows customizing transport management to enforce conventions and quality control.

Uploaded by

Jamie MacCuish
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
235 views3 pages

Enforce Transport Naming Conventions or Create A Sign Off Procedure Using CTS - REQUEST - CHECK

The document discusses using the Badi CTS_REQUEST_CHECK to add custom validation and processes around the creation and release of transports. It provides examples of how to check for valid naming conventions when creating transports and implement a sign-off process requiring senior developers to approve releases. The Badi allows customizing transport management to enforce conventions and quality control.

Uploaded by

Jamie MacCuish
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

The idea behind this blog post is to promote the use of the Badi CTS_REQUEST_CHECK.

Managing transports is a vital component of a successful project and often to facilitate this or to allow for traceability of changes back to tickets or projects, naming conventions for transport are mandated. However, in the absence of any systems checks these conventions are often more honoured in the breach than the keeping. This is where Badi CTS_REQUEST_CHECK comes in extremely useful as it allows for the addition of custom code around the process of creation and release of transports. For example, if we have a naming convention that states that a transport should start with a valid module name, followed by an incident ticket number then we could create a function module that checks that an input string adheres to this convention and would raise an error otherwise. Then we would implement method CHECK_BEFORE_CREATION for badi CTS_REQUEST_CHECK and call this function module from this method displaying an error message if the text was found non compliant.

METHOD if_ex_cts_request_check~check_before_creation. CALL FUNCTION 'ZABAP_TRANSPORT_TEXT' EXPORTING iv_text = text EXCEPTIONS naming_convention = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE e001(ZABAP). RAISE cancel. ENDIF. ENDMETHOD.

This method is called as the name suggests when a new transport is created. Of course, there are other methods of this Badi that allow for other functionality to be developed. For example by using the method CHECK_BEFORE_RELEASE (called when we try to release the transport) we can create a sign off procedure whereby more senior developers would have to sign off for all changes as a form of quality control. For example:

METHOD if_ex_cts_request_check~check_before_release. DATA: lv_bname TYPE xuser, lv_password TYPE xubcode, ls_signoff TYPE zabap_signoff. CALL FUNCTION 'ZABAP_TRANSPORT_TEXT' EXPORTING iv_text = text EXCEPTIONS naming_convention = 1 OTHERS = 2. IF sy-subrc <> 0.

MESSAGE e001(zabap). RAISE cancel. ENDIF. IF type = 'K'. IF NOT sy-uname = 'F25850A' AND NOT sy-uname = 'OC1603' AND NOT sy-uname = 'OC384'. CALL FUNCTION 'ZPOPUP_GET_USER_PASSWORD' EXPORTING iv_user = 'F25850A' IMPORTING user = lv_bname password = lv_password EXCEPTIONS cancel_pressed = 1 OTHERS = 2. IF sy-subrc <> 0 OR lv_password IS INITIAL. CALL FUNCTION 'ZPOPUP_GET_USER_PASSWORD' EXPORTING iv_user = 'OC1603' IMPORTING user = lv_bname password = lv_password EXCEPTIONS cancel_pressed = 1 OTHERS = 2. IF sy-subrc <> 0 OR lv_password IS INITIAL. CALL FUNCTION 'ZPOPUP_GET_USER_PASSWORD' EXPORTING iv_user = 'OC384' IMPORTING user = lv_bname password = lv_password EXCEPTIONS cancel_pressed = 1 OTHERS = 2. IF sy-subrc <> 0 OR lv_password IS INITIAL. MESSAGE e002(zabap). RAISE cancel. ENDIF. ENDIF. ENDIF. CALL FUNCTION 'SUSR_LOGIN_CHECK_RFC' EXPORTING bname = lv_bname password = lv_password EXCEPTIONS wait =1 user_locked =2 user_not_active =3 password_expired =4 wrong_password =5 no_check_for_this_user =6 password_attempts_limited = 7 internal_error =8 OTHERS = 9. IF sy-subrc <> 0.

MESSAGE e003(zabap). RAISE cancel. ENDIF. ls_signoff-request = request. ls_signoff-uname = lv_bname. INSERT into zabap_signoff values ls_signoff. ENDIF. ENDIF. ENDMETHOD.

This also gives us an opportunity to double check the naming convention because some automatically generated transports can slip through the net of the previous check in CHECK_BEFORE_CREATION. We then check is the user releasing is one of the three authorised users and if not we require that one of these users enters a password to sign off on the changes and finally we create a log of these changes in the table zabap_signoff. Of course may other checks are possible. I was very interested by the idea of triggering the code inspector on release of a transport that I stumbled over while preparing this blog http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2013/09/19/how-totrigger-atc-or-code-inspector-checks-during-the-release-of-a-transport-task. As I said at the beginning the goal of this blog is just to hopefully make more people aware of this Badi and the possibilities it presents to improve the management of our transports.

You might also like