Mass user lock with abap program
Recently I had an issue with locking users. I have generated a report about users who have not been logged for a couple of months. This file contained only usernames, since that is all you need to know when it comes to locking someone. The expiration date in this task is the date of lock.
Since locking hundreds of users and setting their expiration date in a couple of systems is insanity, I had to find a different way to do so. Here is a program serving that task:
| Mass user lock |
|---|
| REPORT Z_MASS_USER_LOCK.
“variables for uploading and reading file with usernames “parameter for local file path “path to local file in wich users to be locked is stored CALL FUNCTION ‘ARCHIVFILE_CLIENT_TO_SERVER’ DATA: text TYPE TABLE OF string, pa_file = paa_file. “data of the user we want to lock DATA: wa_user type user. “ TRY . WHILE curpos <> endpos. READ DATASET pa_file INTO csvstr. wa_user–uname = csvstr. “set uname of the user to be locked DATA RETURN_DUMMY LIKE BAPIRET2 OCCURS 0. “set users expiration date “lock the user ENDWHILE. CLOSE DATASET pa_file. |
After starting the program, this is what you should get:
In p_file parameter you add path to local .csv file containing a list of users. An example file should look like this:
|
Users_to_be_locked.csv |
|---|
|
Username1 Username2 Username3 Username4 Username5 … Username n |
Afterwards you press F8 and the program should run perfectly.
The program uploads your local file into server and works on it. It sets expiration date as current date.
To lock users on other system, all you need is an RFC connection to them and to modify lines:
| “set users expiration date CALL FUNCTION ‘BAPI_USER_CHANGE’ EXPORTING USERNAME = wa_user–uname LOGONDATA = wa_user–logond LOGONDATAX = wa_user–logonx TABLES RETURN = RETURN_DUMMY . “lock the user |
to
| “set users expiration date CALL FUNCTION ‘BAPI_USER_CHANGE’ DESTINATION <rfc_name> EXPORTING USERNAME = wa_user–uname LOGONDATA = wa_user–logond LOGONDATAX = wa_user–logonx TABLES RETURN = RETURN_DUMMY . “lock the user |
Hope this proves usefull
Not very convenient way to block for which you want to write permission on the file system server. Easier to infer user ALV-table and allow locking / unlocking of selected records.
That could be done but it wouldn't be that convenient in our case. Our client wanted to lock users listed on a report.
When we had the report on a local file what point would there be in clicking all the users in alv. It was easier and faster for us to upload the file and lock the users we already had listed.
Worth mentioning this task was to be done in about 20 systems and we couldn't transport the program due to some conservation work on those systems so we had to use rfc in the program. I don't think ALV would be convient to run via rfc.
ALV is convenient to work with lists of users who to block. There are new users, and therefore constantly lying to edit a file on the application server to which access should be restricted.
Above Way Is Best practice or Just for System Program for FUN. 😉
Good Job 😀
Why do you want to re-invent the wheel? 😕 You can use the transaction SU10 which allows you to select the users using their logon data (e.g., days since last logon) & lock them in one-go.
- Suhas
And you can even use the file in the select criteria for user name. But maybe a square wheel is nicer... 😕
Well the back to back usage of BAPI_USER_CHANGE and BAPI_USER_LOCK even with COMMIT in between has disadvantage while Bulk processing.
BAPI_USER_CHANGE has impact on Lock status also. So during bulk processing, if there is a slightest delay between Parent and Child system, BAPI_USER_LOCK will execute first and then BAPI_USER_CHANGE which immediately removes the Lock set by first execution of BAPI_USER_LOCK, leaving the user in Unlocked state.
I currently have the same issue and searching for the solution.