Any samples showing how to use Progress.Lang.OERequestInfo? - Forum - OpenEdge Development - Progress Community

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

 Forum

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

This question is not answered

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

Here is the documentation:

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop%2Faccessing-client-context-regardless-of-applicati.html%23

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
  • 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):

    documentation.progress.com/.../index.html

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

    documentation.progress.com/.../index.html

    SESSION handle reference:

    documentation.progress.com/.../index.html

    Hope this helps,

    Tim

  • 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 )

  • The github.com/.../IWebRequest.cls exposes some of the webapp stuff, and the OpenEdge.Web.WebRequest shows how we get at that information.
     
    You can see an example at github.com/.../TokenResolver.cls and github.com/.../TokenResolver.cls  - 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).
     
     
  • Thanks Peter, the docs about the "WEB-CONTEXT" handle didn't seem that applicable to APSV in PASOE:

    documentation.progress.com/.../index.html

    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).

  • 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.
     
     
  • 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

      session:current-request-info:RequestID.

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

    Regards,

    Irfan

    Regards,

    Irfan

  • Thanks for the tip Irfan,

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

       LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:AdapterType)).
       LOG-MANAGER:WRITE-MESSAGE(session:current-request-info:ClientContextId).      
       LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:SessionId)).     
       LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:ThreadId)).      
       LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:AgentId)).       
       LOG-MANAGER:WRITE-MESSAGE(session:current-request-info:ProcedureName).         
    
       LOG-MANAGER:WRITE-MESSAGE(session:current-request-info:RequestId).           
    

    The results are promising for many properties:

    APSV
    MWphYQb9c0Gp+XP07QVT+Q
    8
    4
    31800
    app/Production/Maintenance/AppServer/BurdenAltDescMaintenance.p&BrowseFirstPage
    ?

    ... 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)?

  • Perhaps I haven't got the correct prerequisites in place for MDC? ( documentation.progress.com/.../index.html ).

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

  • 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.

    Regards,

    Irfan

  • 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.

  • 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.

    Regards,

    Irfan

  • 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.

  • 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

    172.30.1.119 - anonymousUser [2019-03-18T19:22:20.571-04:00] "POST /apsv?CONNHDL=9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3 HTTP/1.1" 200 269 ROOT:a:00000003

    172.30.1.119 - anonymousUser [2019-03-18T19:22:20.579-04:00] "POST /apsv?CONNHDL=9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3 HTTP/1.1" 200 243 ROOT:a:00000004

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.221-04:00] "HEAD /apsv HTTP/1.1" 200 - ROOT:a:00000005

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.228-04:00] "POST /apsv HTTP/1.1" 200 252 ROOT:a:00000006

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.233-04:00] "POST /apsv?CONNHDL=E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3 HTTP/1.1" 200 269 ROOT:a:00000007

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.237-04:00] "POST /apsv?CONNHDL=E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3 HTTP/1.1" 200 243 ROOT:a:00000008

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.709-04:00] "HEAD /apsv HTTP/1.1" 200 - ROOT:a:00000009

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.716-04:00] "POST /apsv HTTP/1.1" 200 252 ROOT:a:0000000a

    172.30.1.119 - anonymousUser [2019-03-18T19:22:26.720-04:00] "POST /apsv?CONNHDL=EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3 HTTP/1.1" 200 269 ROOT:a:0000000b

    172.30.1.119 - 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)

    Regards,

    Irfan

  • 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.

    Regards,

    Irfan

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

    knowledgebase.progress.com/.../pasoe-is-it-safe-to-modify-openedge-setenv-bat-sh