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.
dbeavon
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):
SESSION handle reference:
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 )
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).
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
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.
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.
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)
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.
Regarding openedge_setenv.bat, this article says not to modify it:
knowledgebase.progress.com/.../pasoe-is-it-safe-to-modify-openedge-setenv-bat-sh