Hi Colleagues, as you may know, the RPCINFO subprogram retrieves information of the current RPC session; I’m wondering whether it can be used to get the userID ( 32 char string ); I could not find this within its parameter area, so, is there any other subprogram instead of RPCINFO that can give the desired info ?.
I noticed that the RPCINFO do provide me the current session conversation ID, the S-CON-ID; is there any way for asking EntireX Server to provide me the userID giving the S-CON-ID obtained by the RPCINFO ?
Thanks in advance, Esteban.
*CONV-ID gives the conversation id.
If you are using Natural Security with EntireX, *USER will contain the user id.
Douglas, thanks for your reply, we are not using any kind of security within EntireX, we just have clients request that use the following java line to logon:
…
Broker broker = new Broker(brokerId ,“aNumber”);
…
where “aNumber” represents a specific user id.
While the connection is open they send requests to our Natural RPC Server, if I check those connections using the Control Center I can see the corresponding sessions with the conv id and the “aNumber” string also.
What I just need to do is to get that “aNumber” string from within the Natural RPC subprgram that receives the requests in the oher side. Is that possible ?
Thanks once again, Esteban.
Not presently possible that I know of without EntireX Security or Natural Security being used.
I’d suggest a Change/Enhancement request - it probably needs to go under the Natural C/E forum. This type of request pops up every now and then, so I suspect other customers would like to see it also.
On the other hand…what are you planning to do with this “user id”? Since it is not validated or authenticated in any way, it is just data. If your server (Natural) application needs the data, just add it as another IN parameter for the Java applications to fill in.
Douglas, thanks once again, the purpose of using this data is to validate permissions against a custom, home made ( Natural/adabas based ) security system.
I can’t modify the parameter area, or at least trying to avoid it, because the subprograms are currently used by the online applications ( maps->programs->subprograms ). Now we are publishing exactly the same subprograms via EntireX in order to reuse these ( business logic ) from the outside ( mainly from middlewares ).
Maybe I should go further on EntireX Secutity ( without Natural Security )and try using a SECEXIT on the Natural Stub side…
Many thanks Douglas, Esteban.