Evaluating user password in NetWeaver ABAP systems

ABAP programmers sometime need to authenticate a user during the runtime of some ABAP application. As an example of this need; one can say that if user is supposed to confirm some data in ABAP application a system shall ask for user’s password and once it is correct it really does the confirmation. Assumption here is that once user is entering the password he or she must be really aware that a particular activity (e.g. confirming a batch in manufacturing process) is untended to be done.

So being as the ABAP programmer how would I validate the user password? Luckily SAP is providing a very handy function module to do that. The name of the FM is SUSR_LOGIN_CHECK_RFC. It has very simple interface of importing parameters and by evaluating exceptions I can suite my application with regards either validation passed, user is locked, password is wrong etc.

REPORT ZMM_PWD_CHECK.

PARAMETERS: p_usr TYPE sy-uname,
            p_pwd TYPE rsyst-bcode.

CALL FUNCTION 'SUSR_LOGIN_CHECK_RFC'
 EXPORTING
   bname                  = sy-uname
   password               = p_pwd
 EXCEPTIONS
   wait                   = 1
   user_locked            = 2
   user_not_active        = 3
   password_expired       = 4
   wrong_password         = 5
   no_check_for_this_user = 6
   internal_error         = 7.

WRITE: sy-subrc.
CASE sy-subrc.
  WHEN 0. WRITE: 'everything OK'.
  WHEN 1. WRITE: 'wait'.
  WHEN 2. WRITE: 'user_locked '.
  WHEN 3. WRITE: 'user_not_active'.
  WHEN 4. WRITE: 'password_expired'.
  WHEN 5. WRITE: 'wrong_password '.
  WHEN 6. WRITE: 'no_check_for_this_user'.
  WHEN 7. WRITE: 'internal_error'.
  WHEN OTHERS.
ENDCASE.

Source code available at: github.com/softy12/ABAP-PWD-CHECK

Historic versions of DTP

DTP or Data Transfer Process is basically used to load data between two BW’s InfoProviders. It carries an information like from the data is extracted from; where the data is supposed to be loaded to; setting on how the extraction and loading shall be executed, error handling etc. All these information can be adjusted for one DTP.  This leads to creation of many version of the DTP over its life time.

These versions are stored in table RSBKDTPH - DTP: Historic Versions. Normally when the DPT is shown in tcode RSA1 the latest version is shown. When former version of the DTP or called as Historic Versions in BW’s terminology shall be shown it can be used as well. Within the UI of the DTP within the RSA there is a screen called Version Management available.

However in this screen only meta-data of the DTP version is shown. No real picture of the DTP how it really looked at the time when now historic version was active one.

To showing historic version of the DTP how it really looked in the common DTP framework we need to use different tool. The tool is called tcode RSDTP. Below are screenshots of the same DTP displayed its different historic versions in the RSDTP. In this view it is clearly visible what was different in the two versions.

Development package for obsolete standard BW’s DDIC Objects

Some time back I wrote about BW system Data Dictionary (DDIC) objects that are being locked for further changes. This means the changes are not foreseen to be done into these objects (stored in development package RS_DTEL_LOCKED). There is another interesting development package called BW_WHM_TO_BE_DELETED available in BW systems.

This one stores obsolete BW objects that are not supposed to be used anymore. However due to many references that may exist in SAP standard or customer ABAP programs the objects are not deleted just “parked” in this way into special development package.

As an example of the objects stored in here I list a database table “RSDDSTAT - Statistics data BW for aggregate selection and accounting”. The table was in pre 7.x versions of BW used to stored BI Statistics data. In the 7.x version is not needed anymore.