Unique ID for PASOE ABL session? - Forum - OpenEdge Development - Progress Community

Unique ID for PASOE ABL session?

This question is not answered

Is there any way within an ABL session under PASOE to get some the Process ID (PID) of the agent, and some sort of unique identifier of the specific session within the multi-session agent?

In the appname.agent.log file, the prefix for each entry appears to show PIDs, as well as some unique values preceded by T- and AS-:

[19/07/30@11:22:02.119-0500] P-015080 T-008024 1 AS-8 ...

I'm wondering how I could get those programmatically, since it would be useful for troubleshooting.

Thanks in advance.

All Replies
  • Hi,

    In 12.0 we have added a feature called as RequestID which is the unique identifier of a request in PASOE. It will be in the format of <WebApp>:<transport>:<RequestID>.

    Example:- ROOT:r:00001

    It will be generated in all the logs in PASOE and if you want to get it in the code, then you can get it from the RequestInfo Object.



  • Take a look at the OREquestInfo object, which is available as an attribute on the SESSION handle. That has some of what you're after. Not the PID though.
  • Irfan, if you're talking about CURRENT-REQUEST-INFO:RequestID, that's present in my 11.7.4 product, but the ID at the end keeps incrementing on each request, and doesn't match the agent log.  

    SESSION:CURRENT-REQUEST-INFO:RequestId = Appname:w:00000024

    I'm actually looking for something that identifies which particular session of the multi-session agent.

    For example, in WebSpeed, you can get the PID by doing this:


    Now that we can have more than one session per OS process, I need to track specifically which session has done something.

  • In your <PASOE Instance>/bin/openedge_setenv.sh, you should find the following line.


    Enable this line, to get the RequestID in the agent log.



  • Irfan, thanks but I'm not looking to put the requestID in the log.  I'm trying to get the PID and Thread ID.

    I've found that this code works (as an embedded Speedscript file) but it's not ideal to have to write and read just to get these.

    <script language="speedscript">
    DEFINE VARIABLE cAgentLog AS CHARACTER INIT "C:\apps\lisa\logs\ingridabl.agent.log" NO-UNDO.
    cUniqLogString = SUBSTITUTE(cUniqLogString,STRING(RANDOM(1,1000000))).    
    FILE-INFO:FILE-NAME = cAgentLog.   
    INPUT FROM VALUE(cAgentLog).
    MESSAGE cUniqLogString. /* Stick it in the log file */
    	IF cTextIn MATCHES "*" + cUniqLogString + "*" 
    	    THEN ASSIGN
    	    cPID = SUBSTRING(ENTRY(2,cTextIn," "),3)
    	    cThreadID = SUBSTRING(ENTRY(3,cTextIn," "),3)
    END. /* repeat */
    INPUT CLOSE.    
    <div class="bodycontent">
    <h1>Agent Info</h1>
    <p>Information about the agent</p>
            <td>Process ID</td> 
            <td>Thread ID</td> 


  • Why not use RequestID as a unique identifier to debug the issue. You will get this information in all logs(tomcat and MS-Agent). Why do you need to track the agentId or parse the agent log?



  • In WebSpeed, sometimes you would have an agent get "stuck" and you could see that it was just burning resources and not completing the request.  When a user gets impatient, they sometimes repeat the same request and get all your agents stuck.

    In the past, we'd see a given PID that had gone sideways, and need to figure out what it was running and who was running it.  If the application code can figure out its PID (and in this case, it's thread) then it can be made to store that info along with other details about the request as a way of troubleshooting.  So when something freezes in PID 999, you scan the records and see what the last thing was that started to run on that PID, and who the user was.

    Another thing we would do is have inter-process communication between WebSpeed agents for various things like having them refresh cached data after an update.  With PIDs and ThreadIDs, we could track which agents have picked up the communication and performed the requested action.

    My hope is to have all the same abilities that we relied on in WebSpeed available in PASOE for these odd use cases.

  • For monitoring and understanding which requests are stuck and what each request is running, we have added API's like oemanager and JMX. There are more than 50+ API's that tells you what is happening inside the server. We even have API's that tells us the which ABL Procedures were executed, which requests are hung by providing a timeout value and the stacks of all the sessions in the agent and individual ABL session.

    But if you would like to use old style, then you can still use RequestInfo Object. You can use session:current-request-info:AgentId  to get the AgentID and similary, there should also be SessionID attribute to get the ABL session value.

    So we have the data, but I would incline towards using API's in an automated way. In-case you need specific API's which are not available then please let us know. We can work on providing API's that will be useful for you to debug issues with PASOE in runtime.



  • Thanks for the reply. I've spent a little time looking at oemanager, but the lack of documentation is slowing me down a bit.  Unformatted json is also making it hard to read.  

    If I'm looking at the right document, it really doesn't describe what all the fields are.  For example, this page shows example output, but doesn't describe what SessionState is, or what all the possible values mean.

    It also doesn't seem like it has an API to show requests, unless you know what agent you want to look at.

    Let me back up a bit and ask this:

    What do AgentID, SessionID and ThreadID mean in the context of this?

    When I asked for a ThreadID, what I was looking for was something unique and permanent to the individual ABL session within an agent.  From what I can tell, the ThreadID can change from request to request against the same ABL session.

  • to get the process id on linux, set up link to system call:

    procedure getpid external "/usr/lib/glibc.so" cdecl:

    define return parameter pid as long no-undo.

    end procedure.

    /* then to use it: */

    def var p as integer no-undo.

    p = getpid ().

    on windoze:

    procedure GetCurrentProcessId external "kernel32.dll":

    define return parameter pid as long.

    end procedure.


    def var p as integer no-undo.

    run GetCurrentProcessId (output p).

  • I didn't see anyone mention it but OEE allows you to browse all the agents of an ABL application, and explore the sessions that are running within each of them.  You can even click to see the callstack for each of the sessions.  If one of them is "stuck" then you will find it in OEE with a related session state (something other than IDLE).

    Are you windows or Linux? I find that the oemanager REST api is helpful for management.  You can use it with curl or powershell.  Below is session detail for a certain agent (for some reason agents in oemanager are identified by some strange looking character string, that is not the PID).  see screenshot from an oemanager REST request.

    If you want a powershell example, you can get a basic example here (the purpose of this was to trim sessions, but the same structure might apply to investigating misbehaving sessions too):


  • We Provide Swagger for OEManager API's and I think it provides ample documentation. Once you know which API's you want to use, you can choose either REST API's or JMX to automate them. David has given an example of using REST API's in this thread. If you would like to do it using JMX, then you can use OEJMX.

    Documentation to enable Swagger for OEManager - docs.progress.com/.../Enable-Swagger-UI-for-management-REST-API-access.html

    Documentation for oejmx utility - docs.progress.com/.../Use-OEJMX-to-manage-and-monitor-an-instance.html

    An ABL Session can have more than 1 threads and so an ABL session can have more than 1 ThreadID's. It is only useful for us to debug the Multi-Session agent. For your context, each ABL session can be tracked by its session-id and agent-id. But if you would like to monitor requests that are getting executed on that MS-Agent, then RequestID would be the key to debug. Please enable Swagger and look at the API's in "AgentManager" section and see if any of them matches your case.



  • Hi

    In order to get the agent number in PASOE I'm using SESSION:CURRENT-REQUEST-INFO:SessionId

    (if I did not miss this, it was not mentionned in this thread).



    There's an AgentId property on the OERequestInfo object that's no in the doc. SessionId is not the same as AgentId.
  • Irfan, thanks.  I've enabled Swagger, and I'm exploring that right now.  

    It looks like it only provides interfaces to some of the APIs, but not all.  For example /applications/{appname}/agents/{agentID}/sessions that David shows above is missing.

    I'd disagree with you on the notion that Swagger provides ample documentation.  The swagger screens provide no documentation on what the fields mean, and only a very brief description of what the API does.  While the names of the various properties and such in the responses may mean something to the engineering team, they are not all self-explanatory.  

    I'm not very familiar with Swagger, but looking at other examples out on the web, I'm seeing the ability to put a lot more documentation into it.  For example, this implementation shows a model for the responses that provides information on the fields.

    Is there a reference somewhere else for this that explains each API and the output?