JCO V3 load balancing configuration and stateful connection

[Former Member]

Hello sap jco gurus,

I've got 2 questions for you.

I'm looking at replacing a (non pooled) jco destination from a java client to a single sap server and have instead

a (non pooled) jco destination from a java client to load balanced sap servers.

Currenly I have in my JCO destination the following properties :

jco.client.group

jco.client.sysnr

jco.client.client

jco.client.ashost

If I want to target load balanced servers,

It looks like I just need to take out the jco.client.ashost parameter and have instead

jco.client.mshost,

jco.client.r3name

jco.client.group

I understood that by reading another post in this forum. Am I right ? with this ?

Second question, I have stateful JCO connections to handle, Is that seamlessly taken care of by the load balanced servers ?

Is there some kind of sticky session mechanism ? or even better session replication between the load balanced sap servers ?

Thanks a lot for your precious help !

Cheers,

François

[Former Member]

Second question:

You seem to have a wrong understanding of what a load balanced logon does. The load balancing mechanism chooses an application server at logon time but then your connection sticks to this server (only if you made it stateful, of course, otherwise it doesn't matter anyway). The "session" is never been shifted or moved to another application server. So I think your question is obsolete then.

[Former Member]

Stefan, I think you're mistaken here as you're describing the load balancing for dialog users. With basis release 6.x SAP introduced the new RFC load balancing, which can be enabled per logon group. For external clients this should be supported with a RFC library 6.x or higher. Now I don't have a multiserver system at the moment to test this for JCo3, which doesn't have the librfc any longer, so I'm not sure if JCo3 can use the new RFC load balancing (search for SAP document mentioning this was inconclusive). However, I'm pretty convinced that JCo3 does support it.

Kind of funny though that they introduced it with the term new RFC load balancing, which by now is rather old. If they improve it in the future, they might have to name it something like the really new RFC load balancing...

François, I can't point you to any document describing what happens with stateful RFC calls. However, I'm pretty sure that all external RFC clients which utilize the new RFC load balancing stay on the same server for the duration of a session. I'm pretty sure that there is no session replication, because I've never heard of a feature transferring user sessions among servers.

Cheers, harald

[Former Member]

Hi Harald,

I think you are bringing some unnecessary complexity into this issue.

As far as I understood Francois' original question, he would like to know if there is some sticky session mechanism for stateful JCo connections and not how the load balancing is calculated or how the application server is choosen then.

And the short answer to this question is:

A stateful JCo connection is always 'sticky' to one particular application server, regardless if it was opened directly or using load/logon balancing and regardless if it is a dialog user or a communications data user. That's the main difference between being stateful and stateless.

Of course, this doesn't tell anything about what happens at the application server side when starting new RFCs from there, but this doesn't affect the original JCo connection itself.

So I really don't know what you would like to tell me with your comments?

And to your question regarding JCo3 I can assure you that it works the same on JCo 2.1 and 3.0. The difference is that with JCo 2.1 all JCO.Clients were stateful, with JCo 3.0 the clients are managed internally and the default behavior is being stateless instead. And as you already mentioned: the 'new' RFC load balancing feature was only new in 2003.

[Former Member]

Hi Stefan,

per your previous post

The load balancing mechanism chooses an application server at logon time but then your connection sticks to this server...

For anybody working on a 6.x system this is not longer true, because this can be configured for RFC connections. Maybe I misunderstood your posting, but to me it read like a description of the normal dialog user logon load balancing. So I thought it might be good to add a comment. I did not want to make this overly complex, just provide all the information details - no harm done, correct?!

Cheers, harald

[Former Member]

Harald,

external (meaning Non-ABAP) RFC clients work exactly this way as I described it (inclusive the quote you made).

And as I already said, this is true for dialog user types as well as communications data user types (the user type doesn't matter). And furthermore it is also true for connections to AS ABAP system releases 6.x and higher.

What has changed since release 6.x is the communication with the message server which provides the data for choosing an appropriate application server based on the new SMLG data. And the message server is queried by the external RFC Client only at logon time.

This thread is about JCO connections only.

So this time you are either wrong or we are really talking at cross purposes.

[Former Member]

The load balancing is done per RFC call, that's the nice new feature that was introduced with 6.x. This also works for external RFC clients, as described in OSS note [593058|https://service.sap.com/sap/support/notes/593058] that I had linked in my previous posting:

To use this procedure for external RFC clients (for example, SAP Internet Transaction Server (ITS)), you require an RFC library with Release 6.x or higher and an application server with Release 6.x or higher.

In Step 3 the OSS note describes that per RFC call the application server is chosen. The message server provides from time to time the configuration details about how the load balancing is achieved (setup in SMLG per group).

There's no comment about how stateful sessions are handled, but here it seems clear to me that the RFC client simply stays with the same application server (since I'm pretty sure that there's no user session transfer from application server to application server in the ABAP world).

My comment about dialog users was misleading, basically I wanted to distinguish between the type of logon, i.e. dialog sessions (port 32nn) versus RFC sessions (port 33nn). So for an interactive dialog user logging in via SAPgui, there's only load balancing once per logon.

However, it is unclear to me if the new RFC load balancing works also for JCo 3.x, since there's no librfc here. As I don't have access to a SAP system with multiple application servers, I unfortunately couldn't test it. But I was hoping that somebody else might shed some light onto this...

In theory I'd hope it works, but maybe this is a broken feature like the debugging via SAPgui that didn't work for some time in JCo 3.

[Former Member]

Hi Harald,

you are interpreting more into this note than there is.

With the term per RFC call the whole request process was meant inclusive the logon.

The note has been revised to clarify the behavior and to avoid further misunderstandings. It's not translated yet, but looking at your name I guess you probably do speak german, too.

Still, the behavior is as I described it here and it also works the same for JCo3. I already posted this on Mar 12, 2010 1:33 PM.

Hopefully there are no more questions left open here now.

[Former Member]

Hi Stefan,

Thank you so much for your patience with me and pointing out my error. It is an interesting eye opener to read the German version of OSS note [593058 - New RFC load balancing procedure|https://service.sap.com/sap/support/notes/593058] and compare version 18 and the now current version 19. So the RFC load balancing procedure works as you indicated in your fist posting and in the OSS note now all the terms referring to RFC calls have been substituted with Logon instead.

So I'm terribly sorry for insisting for long time on an RFC load balancing feature that simply doesn't exist. No good excuse (apart from the fact that the OSS note correction was just posted on March 15, 2010), I guess I just got carried away with this - really nice to have - feature. So Asche auf mein Haupt as we say in Germany, I really should've tested this instead of relying on descriptions...

Cheers, harald

[Former Member]

Hi Harald,

you're welcome. You don't have to excuse yourself. That's what a forum is for. And at least our disussion led to a clarification of the note. I don't guess, I know...

And one more thing to the background:

Of course, it has to work this way, otherwise you would really need shifting of sessions between the application servers.

Please think of the following RFC call sequence:

1. BAPI_READ_SOMETHING

2. BAPI_CREATE_SOMETHING

3. BAPI_UPDATE_SOMETHING

4. BAPI_TRANSACTION_COMMIT

And then think of adressing different application servers because of load balancing at any step. Would be dificult to handle then to get all the data correctly persisted to the database. Handling the error cases would also be a nightmare.

Furthermore I don't think that you would gain performance in doing this theoretical kind of load balancing. You also have to take into account that also the contexts with all the contained data (e.g. ITABs) have to be transferred then.

So I think, the way it is implemented now is reasonable.

And furthermore, the way JCo3 distinguishes between stateful and stateless connections and the way it is handling them, still lets room for future improvements. With JCo2 it turned onto a dead-end street from the design perspective.

[Former Member]

Hi Stefan,

My train of thought was the following: In many RFC calls we have stateless scenarios. For stateless calls each call is executed in a new context and thus I thought that there's no data stored on the server. Am I wrong here and the server still retains some data per connection (don't have a SAP system right now, so maybe my terminology is off, might be something like communication ID that we see on the gateway)?

It is my understanding that the RFC protocol decreases network traffic by transferring only delta data, so if I call for example a function module with a TABLES parameter that is filled before the call and then updated by the function and returned, only changed data in the table would be transferred back. Have to read up again, but I suspect you can shed some light onto this. If that feature exists, does this sharing also work across individual stateless RFC calls?

For the example that you've given I'd say you anyhow need to do stateful calls (at least last three), which should be an indicator that the calls have to be executed on the same application server. So my naive interpretation was that the RFC client keeps a connection to the message server (so stays logged on) and the message server then distributes the invocations per (stateless or begin of stateful session) call. So essentially the overhead would come down to opening up a new connection to the application server, if directed to a different one.

Anyhow, the more I think about it the clearer it becomes that the approach described in the OSS note is clearly geared towards logon load balancing; other factors would have to be considered and different approach for load balancing per call. Having worked on applications where RFC calls spawned other RFC calls, which quickly lead to quite a few, I thought it would be a neat feature in addition to the profile parameters limiting the resource consumption by RFC calls. Not sure if SAP contemplates possibly extending the load balancing or if I'm describing a silly feature that won't ever come...

Cheers, harald

[Former Member]

First Question:

This is a part of the official JCo API documentation for com.sap.conn.ext.DestinationDataProvider and should answer this:

The properties build 4 properties groups:

■user logon properties

■configuration for physical connection

■SNC configuration

■destination configuration

The minimal configuration contains user logon properties and physical connection configuration.

user logon properties

SAP client and language

user/user alias with password or SSO Ticket

configuration of physical connection

direct connection to SAP instance

SAP application server and system number

load balancing connection to a group of SAP instances

System ID of the SAP system, SAP message server and the group name of SAP application servers are mandatory.

SAP router string can be used in both cases, if the SAP systems is behind an SAP router.

To avoid lookups in the etc/services file you may define SAP message server port for load balancing configuration.

So, yes you are right with your properties for load balanced logon.

[Former Member]

@ Stefan,

Thank you.

This official com.sap.conn.ext.DestinationDataProvider doc your are referring to, is it online ?

I did not find it.

@ Harald,

Thank you.

So Stateful call will work on a sticky session kind of pattern. Good.

So I guess it's up the the ABAP RFC developer to program the RFC for it to handle gracefully the time when one of the server goes down.

[Former Member]

Had to read your posting again and delete my original message...

The JCo version 3 ships with the full API documentation; in there you'll find the reference to the interface DestinationDataProvider.

Edited by: Harald Boeing on Mar 12, 2010 2:44 AM