BAPI for copying users

[Former Member]

Dear gurus,

I can actually understand that there isn't a BAPI for copying users which would corresponding to the Copy function in SU01 because SU10 does not offer it (nor the rename feature...), the CUA would be confused by it and it uses an enque lock on the user which is not a remote friendly mechanism.

However, I need to perform a mass copy of users within the same logical system not attached to a CUA.

The Su01 SUSR functions contain some CALL SCREEN statements and the SUSR_USER_COPY itself expects the lock otherwise it dumps. I don't think that locking all users is very reliable and the program already is slow, so an additional enque and deque would make it even slower.

Does anyone know a (safe) guru trick to perform a mass copy of users in the same client but adding only a suffix to the user name (so all roles, profiles, personalizations, etc) are included.

My current thoughts are a sy-batch check and prior checking that there are no user locks and the time is in the small hours of the morning - but I am hoping there is a better way.

Cheers,

Julius

[mvoros]

Hi Julius,

I don't know what you mean by "I don't think that locking all users is very reliable" but they won't to avoid any inconsistencies therefore they get a lock for each new user. But but you don't to lock source user so there shouldn't be any problem. There shouldn't be any impact on current users. You can use BAPIs BAPI_USER_GET_DETAIL and BAPI_USER_CREATE1. The first one does not get any locks.

Cheers

[Former Member]

Hi Martin,

I don't want to create users directly, I want to copy existing ones with a suffix in the name.

By "I don't think that locking all users is very reliable" I meant no disrespect to the enque server

It is needed but adds some performance overhead for me and it also means that the mass copy should ideally only run when no one else is doing any other user admin tasks. This is not reasonable to expect during the course of a normal day and possibly not even at night when other jobs run.

I was thinking of something like checking whether the user is locked, and then copying if not. But there isn't any API or even FM for this (SUSR_USER_COPY insists on the lock).

Yes, plan B would be a get_detail and then create1 each time but I need to process much more data in my program instead of SAP doing it each time.

Cheers,

Julius

[mvoros]

Julius,

I understand what you want to do but I don't understand why you think that source user needs to be locked during this operation. What I was saying is that SUSR_USER_COPY needs to have lock for new user but this is same for BAPI_USER_CREATE1. Anyway, you can use ENQUE_READ2 to get current locks but you can't be sure that somebody gets lock right after you call this FM.

Cheers

[Former Member]

@ Martin: SU01 sets a lock on the source user of the copy prior to the FM call and the FM appears to expect this as well.

@ David: Exactly that is why I am looking for an API function for copying users. I want a stable program and not a "toy" to use in production systems...

Cheers,

Julius

[mvoros]

Julius,

you are right but it seems that BAPI_USER_GET_DETAIL does not require any lock.

Finally, SOA is not a buzzword anymore (we have cloud :-). So just reusing services from vendor (BAPI_USER_GET_DETAIL and BAPi_USER_CREATE1) shouldn't be qualified as a "toy".

Cheers

[Former Member]

Yes, but that means I need to have more complicated code (get the details of all and loop through them to create1 each time) even if it is stable.

I was only refering to LSMW and eCATT as "ABAP fun toys"

I found a prototype which looks promising, and will update if it works nicely and performantly.

Cheers,

Julius

[Former Member]

Hi Julius

I use SU01 in an LSMW to do this (but for reference user copying), does this mean that I have been putting a 'strain' on the system by causing multiple locks/unlocks? Just concerned and if there is another preferred method that I should be adopting...

Regards

David

[Former Member]

Hi

Hangin' onto shirt tails here

Watching with interest - basic stuff that leads to system refinements is a bonus

Thankyou

David

[Former Member]

Warning: Unqualified comments following...

SUSR_USER_COPY itself expects the lock otherwise it dumps

Interesting: A short test program on our ECC 6.0 (based on NW 701 with ABAP/Basis SP 05 and no CUA) didn't result in any short dumps of SUSR_USER_COPY when not locking the source user. (The only dump I could produce was the quick test in SE37, where the generated test frame collided with expected parameter types.) I also was a bit disappointed that it didn't create any user, which I fixed by calling function SUSR_USER_BUFFERS_TO_DB. Roles and profiles were missing though and possibly other things as well...

In general though it sounds reasonable that the source user is also locked, because this way the source data is a bit less volatile - at least for a short moment.

I don't think that locking all users is very reliable and the program already is slow, so an additional enque and deque would make it even slower.

I'm kind of curious if you have actually measured this and can quantify even slower. My expectation would be that the locking logic (enqueue/dequeue) should be a very minor contribution to the overall runtime (especially since there should be quite a few DB operations involved for copying a user). If you haven't measured it, I'd recommend the usual approach of runtime analysis and SQL trace to see where most time is spent.

I want a stable program and not a "toy" to use in production systems

Maybe it's better than to focus on released functionality (like the BAPI's Martin mentioned) instead of unreleased SUSR_* functions.

Yes, but that means I need to have more complicated code (get the details of all and loop through them to create1 each time) even if it is stable.

I'd like to see a developer who calls this rather simple program complicated (even with long comments and sophisticated commit handling it should be rather short and very easy to understand). It's actually probably a great exercise to hand out to one of your junior ABAP developers: They can think about commit handling, locking and error recovery, memory considerations, session handling and buffering (e.g. often the standard SAP *READ* functions buffer data which is quite silly if you process tons of data, but never touch the same object twice), etc.

[Former Member]

 I'd like to see a developer who calls this rather simple program complicated (even with long comments and sophisticated commit handling it should be rather short and very easy to understand). It's actually probably a great exercise to hand out to one of your junior ABAP developers 

Reading this, an image of myself wearing only a cap with propeller on the top appeared briefly before my eyes...

What I meant is that it is nowhere near as easy as BAPI_USER_COPY would have been and I dont like to support code using unreleased functions with a potential for changes.

Okay, very easy still would be the suggestion of Martin (get user --> create1) and I will go that route.

Thanks to all for suggestions!

Julius

[Former Member]

Reading this, an image of myself wearing only a cap with propeller on the top

... now there's for my imagination ...

Edited by: Mylène Dorias on Nov 10, 2010 2:04 PM

[Srdjan]

This message was moderated.