Skip to Content
Technical Articles
Author's profile photo Vikas Singh

Mass updates to security policy of SAP Java users


Recently I was working on a SLD migration project.  We were migrating from a older version of SLD : 7.20 to a newer version : 7.5 .

It was primarily done by BASIS team but from PI development team perspective, our team was helping out testing to do sanity checks around business system creation, transport mapping of business systems etc – the usual stuff.


Issue encountered:


During migration we realized that we will need to migrate a lot of users from version 7.2 to 7.5 of SLD. The users were getting migrated except for a small issue we discovered. The security policy for users was getting set as “Default” for these users in the new system.


It can be displayed using the user admin screen in the new SLD system using the URL.





The value which is appearing as “Default” needs to be changed to “Technical User”.

Sounds easy for a few users , may be few hundred users if you can have a nice cup of coffee to get rid of the monotony. However, we have 3500+ users and as our landscape has three SLDs, we’ll need to change around 10500+ users which will need to have the security policy updated.


Problem Statement Recap:

There are two default values for users and and we need to change the security policy from “Default” to “Technical”  for a lot of users.


Investigating Solution : Javadocs


Looking at Javadocs for 7.5 :


Under Compostion Environment -> Security, there is an interface IUserAccount which gives access to user account attributes and has methods for reading as well as setting the user attributes.


Link to this interface:


It has methods to read and set the security policy.

As modification of SAP user accounts is a sensitive feature, SAP wanted to make sure the developer really wanted to modify the user account object and hence even though we have reference to IUserAccount , we need to get a Mutable User Account . if you don’t do it, you’ll get an exception as the account is still not mutable.


Once we have reference to the Mutable user Account , setting security policy is straight forward.

Sample code to do the operation is highlighted below.

        IUserAccount account = UMFactory.getUserAccountFactory().getUserAccountByLogonId(user);
        IUserAccount mutUserAcct = UMFactory.getUserAccountFactory().getMutableUserAccount(account.getUniqueID());
        String secPolcyUpdate = “technical”;

We create a simple WebDynpro Java application which points to the file path with the list of users and a button to initiate processing .

File Path points to list of users for which the security policy needs to be updated.

On execution, messages appear at the bottom.

In case  there are any errors, they get displayed .

Hints for building the application:


In case you’re building the application, Interface IUserAccount has a dependency of DC tc/je/usermanagement/api in SC ENGFACADE.


If you don’t want to build the application, you can download the EAR file and deploy it to your target system. It should work for any Java system.


The ear file can be downloaded from this link .


Once deployed, the application can be executed using the below URL .





For each user, you need to click 5 times : Search  the User, Select , Modify , Change value to “Technical User” and Save again .

Apart from the time saved, it helped  BASIS colleagues from the mind numbing drudgery of clicking around over 52500 times for the list of 10500 + users.


Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Marco Noe
      Marco Noe


      If recreating the users is not an issue you could use (not documented) attribute




      in import file, example: