How to identify which user is running code on an appserver?

Hope, following information would be helpful to you.

There is no direct way of determining the userid of a client from the AppServer. However, this can be achieved through 4GL / ABL code that passes the userid of a client as a parameter to the AppServer in the CONNECT() method. Use an AppServer connect procedure to store that information in the SERVER-CONNECTION-CONTEXT attribute of the Appserver's SESSION handle.

The connect procedure should be similar to the following:

/* connect.p. */

DEFINE INPUT PARAMETER pcUserid AS CHARACTER NO-UNDO.

DEFINE INPUT PARAMETER pcPassword AS CHARACTER NO-UNDO.

DEFINE INPUT PARAMETER pcInfo AS CHARACTER NO-UNDO.

ASSIGN SESSION:SERVER-CONNECTION-CONTEXT = pcUserid.

Specify this procedure as the AppServer connect procedure in one of the following ways:

In Progress Explorer: Open the AppServer Properties, go to Server -> Advanced features, type the connect procedure name in the field labeled 'Connect'.

In OpenEdge Explorer: Navigate to Resources> OpenEdge> AppServer> asbroker2> Configuration and click the Edit button. In the Advanced section, type the connect procedure name in the field labeled 'Connect procedure'.

In the ubroker.properties file: Add the 'srvrConnectProc' parameter in the section related to the desired AppServer.

The client code should be similar to the following:

DEFINE VARIABLE hServer AS HANDLE NO-UNDO.

CREATE SERVER hServer.

hServer:CONNECT("-H myhost -AppService asbroker1", "myUserid", "", "").

The second, third and fourth parameters in the CONNECT() method are passed as the first, second and third input parameters in the connect procedure on the AppServer respectively.

The final result is that "myUserid" will be stored in SESSION:SERVER-CONNECTION-CONTEXT on the AppServer. Other programs running on the same AppServer agent can read SESSION:SERVER-CONNECTION-CONTEXT to retrieve the userid of the user connected to the AppServer.

Note that for stateless and state-free AppServers, all requests from a connected client are not guaranteed to run on the same AppServer agent. See Progress article 000011213 for a technique to determine the connected userid from procedures running on a stateless AppServer.

Not really, I like to know from external by example who is the initiator of a long running query though an appserver.

The only ID I can see is the user of the appserver itself and this is not the user connected to the appserver.

Is this correct?

There is no way to do this generically without modifying your application to somehow make it possible.

SESSION:SERVER-CONNECTION-CONTEXT  is used to store the user and other things.

But how does this help for promon or protop?

"But how does this help for promon or protop?"

Those are database-centric tools.

For those to report what you want, you'll need to make sure the AppServer agent switches to the correct database user ID at the start of the request.

For stateless & state-free operating modes, that means setting up the Activate configuration procedure to do so.

"agent switches to the correct database user ID"

The software developer told me that they tried it in the past and this had big performance impact.

How did they do it? Using client-principal to assert identity shouldn't result in that much of a hit to performance.

They probably tried to reconnect the db's every call. That's not cricket. Tim's right, the client-principle is the way to go. Once you implement that a lot of other features are opened up to you (auditing, multi tenancy, etc).

Tim, can you show we a small code example please what you mean with "client-principal to assert identity"

Check the docs for client-principal, there's code and usage examples in there.

note also that you can still use the 4GL setuserid () function to establish the identity of the user on behalf of whom the app server is operating.

I may be reading too much into this but I *think* that Stefan really wants to know what the link between session ids (or usr#) is rather than user names.  It doesn't do you a whole lot of good to know that "tom" is  the user name for app server session X if "tom" is logged in to 3 different client sessions on the db.

What would be helpful would be an interface of some sort that helps administrators easily map the relationships between all of these things.  In the simple 1 db, 1 app server case it would be nice to see something in the _connect record that says that this client has a connection to such and such an app server session.  On the app server side it would be great to see something that says that the app server session is related to such and such a db connection.

Obviously that gets a lot more complicated when there are more databases and more app servers thrown into the mix.