SAP web dispatcher session dispatching

[former_member263346]

HI,

We have noticed that our web dispatcher does not load balance correctly when a server is taken out of the logon group in SMLG. The web dispatcher still directs traffic to that server. We are on web dispatcher 720 patch 526.

We have noticed that, under session dispatching, the 'Show logon groups' page does not change and still shows the group that was removed within SAP. Even purging outdated sessions is hit or miss on whether that group entry is replaced. The context_timeout should take care of this and purge these entries after 1 hour, but we see entries in there that are days old.

Is there a parameter/setting that can be used to ensure that sessions are directed to the correct server through the dispatcher, once the server has been removed in SMLG?

Thanks

Stuart Banner

[isaias_freitas]

Hello Stuart,

If logon groups are indeed used for HTTP load balancing, the Web Dispatcher would still forward already active sessions to the instance that was taken out of the logon group, for as long as the instance is still available and that same session exists.

Notice that, by default, the Web Dispatcher will use all available instances and logon groups are not used, unless you configure logon groups at the service definitions (transaction SICF).

Maybe you could provide some screenshots showing the configuration you have in place (SMLG, SICF) and what you are observing as incorrect behavior, so we can better understand the scenario.

Regards,

Isaías

[former_member263346]

Isaias,

Thank you for the quick response.

We have the logon group WEBDISP set up in SMLG on server 'abc'

Users use ''http://<web dispatcher>/sap/crm_logon' to access the CRM system from a browser. crm_logon is an alias for 'sap/bc/bsp/sap/crm_ui_start'.

WEBDISP is in the following services:

When we change the logon group out, to 'def', session dispatching shows the abc server under logon groups. When refreshed it shows a blank field. Then when refreshed again it will show 'def'. This cycle continues in a loop each time we refresh that page.

Thanks

Stuart Banner

[isaias_freitas]

Hello Stuart,

The Web Dispatcher will periodically (parameter "wdisp/auto_refresh"; default: 25 seconds) refresh the logon group information (which instances are part of which logon groups; which URL prefixes are assigned to which logon groups) by requesting the update information to the backend system.

If you perform a change at SMLG, it may take a few seconds (parameter mentioned above) until the Web Dispatcher has the updated information.

However, if no more changes were made at SMLG, I would expect no changes at the Web Dispatcher admin. page as well.

Please attach the complete profile from the Web Dispatcher, so we can see how it is configured.

There is an option for you to attach the file itself (might have to "zip" it first) instead of having to paste the entire content at your post.

Regards,

Isaías

[former_member263346]

Isaias,

Thank you for your feed back. The web dispatcher does indeed switch the logon group out in the 'Monitor Server Groups' section of the admin tool, but the old server is still in the 'Session Dispatching' section, so that it still send users to the server that has been taken out of SMLG.

ABC010.TCT has been attached.

Thanks

Stuart Banner

ABC010.TXT.zip

[isaias_freitas]

Hello Stuart,

If there is an entry at the dispatching table it is because there is an active session (a user is logged on to SAP).

At the backend, such section is known only to the specific instance where the user has logged on.

Thus, the Web Dispatcher must send the user always to the same instance.

If the user is already logged on to an instance that you have removed from the logon group, such user must still be sent to that instance, even though it is not part of the logon group, because it is only that instance that knows the user session.

New logons, however, will not go to that instance.

In other words, the logon group is used only at the logon time.

Afterwards, the Web Dispatcher must keep the session stickiness.

Regards,

Isaías