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 sysubrc <> 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 sysubrc <> 0.
MESSAGE e001(zabap).
RAISE cancel.
ENDIF.

IF type = ‘K’.
IF NOT syuname  = ‘F25850A’  AND
NOT syuname = ‘OC1603’ AND
NOT syuname = ‘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 sysubrc <> 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 sysubrc <> 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 sysubrc <> 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 sysubrc <> 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-to-trigger-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.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply