Performance issues with using set parameter id

[Former Member]

Hello,

Is there a significant performance impact when using parameter id's in SAP memory? There is a thought of setting a parameter id per user when the user logs into SAP. The memory is assumed to be freed when the user logs out? Is this a correct assumption? What is the impact on system performance with having a large amount of parameter ID's in SAP memory?

Please advise.

Regards,

Anna-Liza

[RichHeilman]

I wouldn't think the performance hit would be visible, how many are we talking about?

Regards,

Rich Heilman

[Former Member]

At this time, we are talking about <1000. entries. We have a legacy system and when the user swipes their cards to go home and there are still in SAP we need to log them out. The problem is that the legacy system cannot identify correctly whether there are in or out.

Thanks for your help.

Regards,

Anna-Liza

[Former Member]

Can you clarify more please?

"When the users swipe their cards to go home", what does this trigger or where will it be recognized? SAP knows that someone swiped out or does the legacy system know about it? Who or which system keeps track of the swiping of cards and is there any interface to SAP with that data?

What is the solution you have in mind to log out the users and where do parameters come into picture here?

Srinivas

[Former Member]

Hello,

The proposed solution is the following:

When the user logs in and he belong to the legacy group, then a parameter id is set in memory.

When the user logs out of legacy, a call is made via RFC and if the parameter id is set for legacy user, then the user would be logged out of the SAP system as well.

Regards,

Anna-Liza

[Former Member]

Why do you need parameter ids for that? Can you not simply check if the user is logged on to the SAP system? SM04 tells you which users are logged into the system. It achieves this by calling the following system function.

  call 'ThUsrInfo' id 'OPCODE' field opcode_list
    id 'TAB' field usr_tabl-*sys*.

Look at the SM04 logic(report RSM04000_ALV).

You can wrap this logic in nice little RFC and get your logon status per user. Then you can logout the user.

Hope this helps,

Srinivas

[Former Member]

Hello,

Yes, we have looked at this statement from SM04 and ultimately we are planning on using this for the logout process.

But, we would need log out only those users of a specific legacy system.

The user will only log out of the legacy system and therefore, we would need to have them out of SAP as well.

There are other options we have (user parameter ids in master record, custom table that indicates user logged in/out of the legacy system) or the parameter id in SAP memory.

Just trying to figure out, if there are significant performance issues to consider with SAP memory usage.

Regards,

Anna-Liza

[Former Member]

<i>But, we would need log out only those users of a specific legacy system.</i>

Here is the logic I am thinking about.

1) User logout of a specific legacy system. I am assuming you are trapping this event.

2) you then immediately check in SAP if the user is logged in. I am assuming you know the mapping of legacy user id to SAP user id. You will check this using the code I pasted.

3)If the user is logged in, log him out(I don't know how).

Srinivas

[Former Member]

Even when you are not adding any paramter IDs, there is a lot that SAP is keeping in the memory and it can handle lot more. There shouldn't be any noticeable performance downgrade. Yes, you are correct in saying that once the user logs out, the user buffer is cleared/freed.

If you are talking about thousands of parameter ids, then there may be some issue. Also remember, your parameter value cannot exceed the length of 250.

What is the need for so many parameter ids?

Srinivas