Any samples showing how to use Progress.Lang.OERequestInfo?

Posted by dbeavon on 15-Mar-2019 15:07

Can someone point me to sample code that would use Progress.Lang.OERequestInfo?

Here is the documentation:

Apparently it is available via CURRENT-REQUEST-INFO attribute on the session's SESSION handle.

I don't know if it is made available to us, but what I'm most interested in is PASOE-related details.  IE. shouldn't I be able to programmatically discover the webapp name that was used to enter into my ABL session?  Shouldn't I be able to discover the HTTP session in tomcat that is associated with the current request?

These things would be extremely valuable for certain purposes (audit trails, admin, troubleshooting, etc).  Hopefully there is a mechanism to access to those details.

All Replies

Posted by Tim Hutchens on 15-Mar-2019 15:35


Here are a few reference links on this topic. Some of them identify pieces that are applicable to PASOE only.

CURRENT-REQUEST-INFO attribute reference (with example):

OERequestInfo class reference (this lists the properties of the Request you can access):

SESSION handle reference:

Hope this helps,


Posted by dbeavon on 15-Mar-2019 16:05

Thanks Tim, those are the places where I've been looking for context information that contains PASOE-related details.  Unfortunately, it doesn't seem like any PASOE-related details are made available to the ABL session.  I'm not sure how to find my related webapp name, or HTTP session ID from tomcat.  

Perhaps OERequestInfo is not even the right thing to be looking at, which is why I was hoping to find some samples that show how it is used.  It seems to allow some sort of persistent session/context for custom application purposes.  (IE. perhaps it has nothing to do with exposing the details about a request that is coming in via PASOE or tomcat )

Posted by Peter Judge on 15-Mar-2019 22:36

The exposes some of the webapp stuff, and the OpenEdge.Web.WebRequest shows how we get at that information.
You can see an example at and  - the latter has some (other) examples of getting info from the request info and the request.
The HTTP session is (can be?) written into the client-principal , in the CP’s SESSION-ID attribute., when there is a HTTP session (form authentication).

Posted by dbeavon on 17-Mar-2019 01:52

Thanks Peter, the docs about the "WEB-CONTEXT" handle didn't seem that applicable to APSV in PASOE:

Thanks for the pointers, I will see if there is something in here that will help me to discover the current webapp name and the current HTTP session ID (from my ABL code).

Posted by Peter Judge on 17-Mar-2019 14:54

True: the WEB-CONTEXT stuff is *only*  applicable to the web transport. The C-P SESSION-ID should apply to all tranports. Though if memory serves, you can only use basic in APSV which will have a new HTTP session per request.

Posted by Irfan on 17-Mar-2019 16:18

If you would like to know the context information of the request which means the (WebApp,Transport and Unique Request ID) then you can try the MDC feature we added in 12.0 and 11.7.4. You can get it by running the below code


For example, a REST request to ROOT WebApplication should give this - ROOT:r:00000001.



Posted by dbeavon on 18-Mar-2019 18:55

Thanks for the tip Irfan,

I tried some of the "current-request-info" properties like so:



The results are promising for many properties:


... However the session:current-request-info:RequestId is always being displayed as "?".

We only use the APSV transport.  Perhaps that "RequestId" doesn't work for APSV? 

Is there another way to retrieve the current WebApp name (and, ultimately, the HTTP session ID that would be recognized by the tomcat-manager-REST-interface)?

Posted by dbeavon on 18-Mar-2019 18:59

Perhaps I haven't got the correct prerequisites in place for MDC? ( ).

Is there a quick-start guide that I can look at for enabling MDC over APSV?

Posted by Irfan on 18-Mar-2019 19:11

It should run for all transports. All you have to do to get it working in 11.7.4 is

Set the value "REQIDLOGGING" to "y" in openedge_setenv.bat in windows. By default it should be disabled.

Posted by dbeavon on 18-Mar-2019 19:49

That didn't seem to work.  In fact I ran procmon while starting PASOE on windows and it never even uses openedge_setenv.bat, so far as I can tell.

I changed both the bat file in my instance (C:\OpenEdge\WRK\oepas1\bin\openedge_setenv.bat) and the one in the DLC directory.  I removed the word "rem" in front of "set REQIDLOGGING=y".  But there is no change in behavior when viewing the property in question:  session:current-request-info:RequestId.

More to the point, will this help me to ultimately discover my HTTP session ID?  That is what I'd really like to have.

Posted by Irfan on 18-Mar-2019 20:07

Worked for me.

[19/03/18@16:05:03.982-0400] P-011480 T-038444 2 AS-7 R-ROOT:a:00000005 AS Application Server connected with connection id: CEC418C079AC70F4F9BA25EF3BD958D6AAE5BBA4F19F.testinst. (8358)

[19/03/18@16:05:04.025-0400] P-011480 T-038444 1 AS-7 R-ROOT:a:00000006 -- (Procedure: 'server2.p' Line:1) hello

[19/03/18@16:05:04.053-0400] P-011480 T-038444 2 AS-7 R-ROOT:a:00000007 AS Application Server disconnected with connection id: CEC418C079AC70F4F9BA25EF3BD958D6AAE5BBA4F19F.testinst. (8359)

Basically, the benefit of MDC is that you will have unqiue information across all the logs. So if you want to track a request failure or execution time, then you can do it using MDC as it can be used as a unique string to search across all the logs.

Posted by dbeavon on 18-Mar-2019 21:57

When I get a chance I will try again.  It is odd that you are having me change a "set" statement in the "openedge_setenv.bat" which is a batch file that seems to be never used (at least according to my procmon traces).

(Next time perhaps I will try creating a totally new PASOE instance from scratch.  I think the instance I'm using was created back in the days of 11.7.2 or so, and I've applied service packs and hotfixes since then.)

I believe that what you are showing me above is from the agent log for APSV traffic... and I'm really happy to see what appears to to be a tomcat session ID in there (ie. "CEC418C079AC70F4F9BA25EF3BD958D6AAE5BBA4F19F.testinst").  Hopefully if that is available for printing into the agent log then it is also available from our ABL sessions as well.  Can you tell me how I can retrieve it (via session:current-request-info or any other way)?

>> Basically, the benefit of MDC is that...

Have there been any slide-decks or videos about MDC yet?  It sounds pretty interesting.  Whenever something serious goes wrong, I will be happy to be able to correlate it to a tomcat session ID.  This may allow an application administrator to *expire* the session via the tomcat manager REST interface.  Once these session ID's are expired, that seems to clear away any residual resources that are being held by the PASOE session manager.

Posted by Irfan on 18-Mar-2019 23:24

Hi David,

If your goal is only get the HTTP Session information in the agent, then you can do it using SESSION:SERVER-CONNECTION-ID. This is basically a unique id for each APSV connection. For PASOE, this would be the HTTP SessionID.

If you were using 12.0 which has MDC enabled by default, you would get something like this in the localhost access log - anonymousUser [2019-03-18T19:22:20.571-04:00] "POST /apsv?CONNHDL=9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3 HTTP/1.1" 200 269 ROOT:a:00000003 - anonymousUser [2019-03-18T19:22:20.579-04:00] "POST /apsv?CONNHDL=9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3 HTTP/1.1" 200 243 ROOT:a:00000004 - anonymousUser [2019-03-18T19:22:26.221-04:00] "HEAD /apsv HTTP/1.1" 200 - ROOT:a:00000005 - anonymousUser [2019-03-18T19:22:26.228-04:00] "POST /apsv HTTP/1.1" 200 252 ROOT:a:00000006 - anonymousUser [2019-03-18T19:22:26.233-04:00] "POST /apsv?CONNHDL=E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3 HTTP/1.1" 200 269 ROOT:a:00000007 - anonymousUser [2019-03-18T19:22:26.237-04:00] "POST /apsv?CONNHDL=E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3 HTTP/1.1" 200 243 ROOT:a:00000008 - anonymousUser [2019-03-18T19:22:26.709-04:00] "HEAD /apsv HTTP/1.1" 200 - ROOT:a:00000009 - anonymousUser [2019-03-18T19:22:26.716-04:00] "POST /apsv HTTP/1.1" 200 252 ROOT:a:0000000a - anonymousUser [2019-03-18T19:22:26.720-04:00] "POST /apsv?CONNHDL=EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3 HTTP/1.1" 200 269 ROOT:a:0000000b - anonymousUser [2019-03-18T19:22:26.723-04:00] "POST /apsv?CONNHDL=EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3 HTTP/1.1" 200 243 ROOT:a:0000000c

Similarly, in the agent log you will something like this

2019-03-18T19:22:20.549-0400 023540 023549 2 AS-7 ROOT:a:00000002 AS Application Server connected with connection id: 9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3. (8358)

2019-03-18T19:22:20.570-0400 023540 023549 1 AS-7 ROOT:a:00000003 -- (Procedure: 'server2.p' Line:1) CONNECTION-ID for this request is  9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3

2019-03-18T19:22:20.577-0400 023540 023549 2 AS-7 ROOT:a:00000004 AS Application Server disconnected with connection id: 9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3. (8359)

2019-03-18T19:22:26.228-0400 023540 023549 2 AS-7 ROOT:a:00000006 AS Application Server connected with connection id: E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3. (8358)

2019-03-18T19:22:26.232-0400 023540 023549 1 AS-7 ROOT:a:00000007 -- (Procedure: 'server2.p' Line:1) CONNECTION-ID for this request is  E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3

2019-03-18T19:22:26.236-0400 023540 023549 2 AS-7 ROOT:a:00000008 AS Application Server disconnected with connection id: E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3. (8359)

2019-03-18T19:22:26.716-0400 023540 023549 2 AS-7 ROOT:a:0000000a AS Application Server connected with connection id: EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3. (8358)

2019-03-18T19:22:26.720-0400 023540 023549 1 AS-7 ROOT:a:0000000b -- (Procedure: 'server2.p' Line:1) CONNECTION-ID for this request is  EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3

2019-03-18T19:22:26.723-0400 023540 023549 2 AS-7 ROOT:a:0000000c AS Application Server disconnected with connection id: EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3. (8359)

Posted by Irfan on 18-Mar-2019 23:26

Can you help us understand what exactly are you looking for and whats your use-case ? Wanted to make sure we are giving you the right information instead of providing you with the information that might not fit your scenario.

Posted by ske on 19-Mar-2019 06:19

Regarding openedge_setenv.bat, this article says not to modify it:

Posted by Irfan on 19-Mar-2019 09:54

If PASOE finds a in CATALINA_BASE/bin then it runs it. We have added openedge_setenv.bat|sh to add some additional environment variables so that file is specific to Progress. The intent of this kbase is If you want to load your own environment variables, then instead of modifying|bat create your own XXX_setenv.bat|sh and the environment variables mentioned there will be loaded for your application.

Posted by Michael Jacobs on 19-Mar-2019 10:11

The general rule still applies: do not edit the openedge_setenv.x script as it may be overwritten in an update and loose all of the changes.  In this one case Irfan is providing the instructions to edit the file in a very specific way - it does not mean that you can edit anything you like in the file.   The MDC in 11.7.4  was a back-port into 11.7.4 from 12.0.0 and has to be turned on at the PASOE instance level to operate in the Agent log files.  Hence the openedge_setenv.x environment variable.  

As a side note: the 12.0.0 logging framework, including MDC, is the default and logging entry formats and configurations change subtly.   Its a good idea to check the documentation set and migration information when beginning to work with version 12.

FYI:  openedge_setenv.x  is executed from the Tomcat startup's setenv.x found in the DLC/servers/pasoe/bin/ directory.  The setenv.x scripts scan for, and execute, any *_setenv.x files found in the instances's bin/ directory (both OE supplied and ones you supply for your product's startup).   So, you will not find a direct reference to it.  

Posted by dbeavon on 19-Mar-2019 13:14

>> Can you help us understand what exactly are you looking for and whats your use-case ?

Hi Irfan,  We are finding that certain remote openclients are able to create ad-hoc requests for APSV data that may run indefinitely long (eg. for three hours). But the client-side openclient HTTP timeout can be much shorter than that ... so the openclient will give up and close the connection (eg. after only one hour).

At that point the session manager notices that the remote connection was closed, and this fact is printed in the session manager log.  It includes the tomcat session ID (but until now I've never known if/how there is a way to retrieve the session ID from custom ABL).

Despite the fact that the remote openclient is long-gone, (and the session manager was made aware of the fact) the tomcat session ID remains intact.  And it holds onto resources within the ms-agent process.  Based on my observations, even after the ABL session finally finishes its work (in three hours), it does NOT appear like the session manager wants to release hold of the ABL session (via the act of trimming-active-sessions for example).   In other words, that session's resources seem to be "pinned" as long as the tomcat session ID remains intact (as viewed in the tomcat manager webapp for HTTP sessions).  As a side note, our tomcat session timeouts are extremely long (24 hrs) for the sake of compatibility with the legacy "state-free/session-free" APSV connections.

To make a long story short, expiring tomcat session ID's seems to be the key to getting PASOE to release hold of certain resources within the ms-agent process.  If the tomcat session ID is orphaned, and remains intact for 24 hours then there will be "pinned" resources in the ms-agent for that entire time.

Initially I am hoping to simply accumulate session ID's from these ad-hoc requests (based on the a list of usual suspects, as identified from "session:current-request-info:ProcedureName") .  And the session ID's will be cross-referenced periodically against the tomcat manager REST interface.  And any of these ad-hoc sessions that are still present after an hour will start triggering emails to the application administrators (along with the related tomcat session ID's and instructions on how to perform clean up via the tomcat "manager" webapp).

Hopefully this is clear.  Let me know if not.  I'm not trying to make things harder than they need to be.  The problem is always with the greedy, ad-hoc requests from power users.  I think there are some theoretical ways to handle this in ABL too (STOP-AFTER) but it doesn't seem to work reliably.  I'd rather inform PASOE about the HTTP session's expiration, and force PASOE to deal with those runaway ABL sessions.



This thread is closed