functionality to prevent users from logging onto a central (CI) type server?

[Former Member]

Hi folks

My question relates to SAP systems where there is a central DBCI instance along with additional remote appservers. 

From a performance POV we want to minimize load on the DBCI instance from users logging in directly there and running stuff --- instead want to force all users to logon to some remote appserver.

I am well aware of SMLG logon groups and how these can be part of this strategy to shift user load where you want it.  But in many cases, as an admin, we are not able to dictate what sort of sap logon pad configuration end users set up on their own PC!  So despite being told not to do it, many users still configure their sap logon pad w/ the DBCI server name directly.

What I really want to know here is -------------------does SAP have any built-in functionality to help here?  Seems like this must be a common issue for customers so they should have something.  At our company we have some customization/tool which we CAN try to use to help accomplish this (tool uses special Z* tables and Z* programs) but it's not ideal for us to put in so much extra customization (we'd rather use something standard w/ SAP).

Please advise --- thanks

[Former Member]

1. Cant we use web dispatcher here and remove the CI from load balancing ?

and Not sure if option 2 can be applicable in your case. Perhaps depends on version you are using.

2. Separate your CI from PAS

Regards,

Pavan Gunda

[isaias_freitas]

The SAP Web Dispatcher performs load balancing of HTTP/HTTPS requests only.

[Former Member]

oops !! I am in a assumption of web requests. You are correct.

what about option 2 ?

cant this be a good idea , separate ASCS from PSA  ?

Ultimately Ben wants his user to restrict to login into CI to reduce load and maintain high availability. By separating ASCS from PAS, he can achieve high availability . 

[isaias_freitas]

By separating the ASCS from PAS, the PAS/CI would be essentially the same as any dialog instance.

Then, I would believe there would be no reason for not having users logging on to it.

[Former Member]

Hello Ben,

You can achieve what you want by using the customer exit ZXUSRU01 which is called from standard exit EXIT_SAPLSUSF_001.

As I don't want to take credit for other peoples coding work, use your favourite search engine with the above abaps as keywords along with "central instance" and you will find many ready made examples.

I have my own "home brew" working on various production systems for years now.

Hope the above helps.

Kindest Regards,

Amerjit

[isaias_freitas]

Hello,

I believe that the best solution for your case would be to set the parameter "rdisp/gui_auto_logout" to a very (VERY) low value, at the CI only.

If a user logs on directly to the CI, he/she would be kicked out very fast .

However, you should not be kicked out if you logon to an app server and then switch to the CI through SM51 .

[isaias_freitas]

PS: Matt and I replied at the same time . I would go with Matt's suggestion .

[Former Member]

lol .... seems I was also in the replying at the same time loop.

[Matt_Fraser]

Hi Ben,

The way we achieve this here is via a combination of logon groups (SMLG) as you mentioned, and a centrally managed SAPLogon configuration file. In other words, we don't push saplogon.ini configs to the users' desktops, but rather have them all use a central saplogon.ini that the administrator controls. It's true that this doesn't prevent users from adding their own custom entries (which would be stored locally on their desktops), but with a centrally managed connection entry already present, there's little motivation for them to do so. Plus, if you distribute SAPLogonPAD instead of SAPLogon, they couldn't add their own entries anyway, but we didn't go that far.

Additionally, under the new scheme for installations, a pure DB/CI instance needn't have any dialog work processes, so there would be nothing to log on to anyway. In this case I'm referring to the ASCS instance that the new SWPM installation tool creates, where the enqueue service and message server are split off from the regular ABAP instance.

If you look at my blog series about setting up SAPGUI Installation Servers which starts at , you'll find in there instructions for how to setup the centrally managed saplogon.ini.

Cheers,

Matt